Source-linked AI summary
Toward AI-Augmented Cooperative Engineering Workflows: Requirements and Architecture the European Rover Challenge
Ahmed R. Sadik, Frank Joublin, Mariusz Bujny, Antonello Ceravola, Joan Smith
TL;DR
The paper examines how AI might support cooperative engineering workflows, beyond isolated technical tasks, in ERC teams coordinating complex work under time pressure. A role-adaptive survey of ERC teams identifies workflow bottlenecks and informs requirements for an initial assistant architecture. The reported challenges are largely organizational and infrastructural, and the architecture is proposed as a foundation for supporting hybrid human–AI engineering teams.
Problem
AI use in engineering is often limited to isolated tasks, while cooperative workflows require teams to coordinate requirements, tasks, communication, knowledge transfer, and subsystem integration.
Source: §1 · p. 2, §5 · p. 14Method
A role-adaptive survey of ERC teams examined workflow practices and AI use, and its findings informed requirements and an initial assistant architecture.
Source: §1 · p. 3Results
ERC teams reported organizational and infrastructural challenges, including unclear requirements, fragmented communication, limited documentation, informal task allocation, and substantial rework and integration delays.
Source: §5 · pp. 13–14Takeaways & Limitations
The paper argues that AI’s potential lies not only in accelerating isolated tasks but also in reducing organizational friction and hidden coordination work.
Source: §5 · p. 15Findings reflect self-reported perceived challenges rather than direct observation, and the proposed architecture has not been evaluated in a deployed ERC setting.
Source: §5 · p. 15
Abstract
from arXiv · showhide
The growing availability of Artificial Intelligence (AI) tools creates new opportunities to support engineering design processes, yet their current use often remains limited to isolated tasks such as coding, documentation, or information retrieval. Less attention has been given to how AI can support cooperative engineering workflows at the process level, where teams must coordinate requirements, tasks, communication, knowledge transfer, and subsystem integration. This paper investigates this challenge in the context of the European Rover Challenge (ERC), where student teams design and integrate complex rover systems within a single academic cycle under strict time constraints and high subsystem interdependence. We conducted a role adaptive 40 question survey with ERC 2025 teams, yielding 104 responses from 14 teams. The survey examined team structure, knowledge transfer, task management, integration practices, communication patterns, and current AI usage. The results reveal recurring workflow bottlenecks, including limited documentation, unclear requirements, fragmented communication, informal task monitoring, and substantial integration rework. Based on these findings, we derive requirements for AI augmented cooperative engineering work-flows and propose an initial assistant system architecture that connects user facing interfaces, credential management, service selection, specialized AI services, and external engineering tools. The proposed architecture aims to support task clarification, requirement and compliance management, communication summarization, integration risk detection, and continuous knowledge capture. In doing so, the paper contributes empirical requirements and an architectural direction for AI augmented cooperative engineering workflows in hybrid human AI team settings.
1 Introduction
The introduction frames complex engineering projects as cooperative systems in which teams must coordinate interdependent work under time pressure. It investigates ERC workflows to identify bottlenecks and derive requirements for an AI-augmented assistant architecture.
1 Introduction
- Poorly specified tasks and fragmented communication are associated with cognitive overload, stress, rework, inefficiency, and burnout in project-based environments.The introduction frames these challenges as symptoms of weak shared awareness, task traceability, knowledge continuity, and cross-subsystem coordination infrastructure.Source: §1 · p. 2
- ERC teams work under intense time pressure, strict external constraints, high subsystem interdependence, high turnover, and uneven experience levels.The paper presents ERC as an empirical setting for studying connections among requirements, tasks, communication, documentation, and integration.Source: §1 · p. 2
- Work-design and Job Demands–Resources perspectives link imbalanced demands and resources with degraded performance and wellbeing in engineering teams.The paper identifies task clarification, knowledge capture, dependency tracking, and shared situational awareness as potential structural resources.Source: §1 · p. 2
- The study examines how AI could support cooperative engineering workflows by analyzing ERC organizational and workflow practices and deriving assistant-architecture requirements.The role-adaptive survey received 104 responses from 14 ERC-2025 teams and covered team structures, task practices, communication, knowledge transfer, integration, and AI use.Source: §1 · pp. 2–3
- The paper proposes an initial AI-augmented cooperative information-system architecture, alongside empirical workflow findings and requirements for supporting engineering teams.The architecture connects user-facing interfaces, credential management, service selection, specialized AI services, and external engineering tools.Source: §1 · p. 3
- ERC teams face recurring bottlenecks including unclear requirements, fragmented communication, limited documentation, informal task monitoring, and late-stage integration rework.These are presented as empirical insights motivating requirements for AI support.Source: §1 · p. 3
2 Survey Structure and Question Flow
The survey used role-adaptive branching to gather perspectives tailored to participants’ responsibilities, then asked everyone about shared workflow practices. This design linked organizational and coordination practices with reported outcomes such as rework and delays.
2 Survey Structure and Question Flow
- Participants first identified as team leaders, group leaders, or team members, then received role-specific question blocks.Team leaders reported on structure and knowledge transfer; group leaders on task coordination and monitoring; team members on day-to-day execution.Source: §2 · p. 3
- The survey structure was designed to balance analytical depth with respondent burden and inform assistant-architecture requirements.The role-adaptive branching structure is shown in Fig. 1.Source: §2 · p. 3, Figure 1 · p. 4
- All participants completed shared questions on task definitions, dependencies, deadlines, integration planning, communication, and current AI usage.Combining role-specific insights with a common workflow perspective supported analysis of where AI tools could assist.Source: §2 · p. 3
3 Empirical Findings and Derived Requirements
The survey identifies recurring coordination and integration bottlenecks across ERC teams, then uses them to derive requirements for AI-supported cooperative information systems.
3.1 Team Structure and Organizational Model
- 70% of respondents reported functional, subsystem-based team structures, while participants described substantial interdependence during integration and testing.Just over half rated their team organization effective, and a quarter selected a neutral rating.Source: §3.1 · p. 5
3.2 Knowledge Transfer and Documentation
- No teams rated knowledge transfer easy or very easy; 42.9% rated it medium and 42.9% difficult.Documentation was the main handover method (92.9%), but subsystem implementations often outpaced documentation and left newcomers to recover missing design rationale.Source: §3.2 · pp. 5–6, Figure 2 · p. 6
3.3 Task Assignment, Monitoring, and Execution
- Task assignment and monitoring relied heavily on informal communication, with only 13% using online task boards for systematic progress tracking.At least 23% of group leader responses indicated diffuse responsibility, unclear ownership, or limited traceability; missing updates in tightly coupled subsystems could cascade into delays.Source: §3.3 · pp. 6–7, Figure 3 · p. 7
3.4 Workflow Quality, Rework, and Delays
- Unclear requirements and inconsistent planning affected up to 25% of team members, while many teams said testing, validation, and documentation could have been more efficient.Rework and delay findings point to issues being identified late in development.Source: §3.4 · pp. 8–9
- 20–40% of project time was spent revisiting work, with testing–integration (60.6%) and testing–design (48.1%) the most frequent rework loops.Insufficient early testing (65.4%), supplier delays (58.7%), and communication problems (42.3%) were the most frequently cited delay causes.Source: Figure 4 · p. 8, §3.4 · pp. 8–9, Figure 5 · p. 9
3.5 ERC Requirement Tracking and Communication
- Requirement tracking was mostly manual and decentralized, while teams used multiple communication channels and reported misunderstandings (52.9%) and late or missing updates (51.9%).Respondents also cited delayed responses (40.4%), and critical information was scattered across chats, documents, and platform-specific threads.Source: §3.5 · pp. 9–10, Figure 6 · p. 10
3.6 Use of AI Tools and Desired AI Support
- Although 78.8% reported using AI tools, respondents’ unmet needs centered on organizational support and system-level coordination rather than local technical tasks.Desired capabilities included requirement handling, task coordination, communication summarization, integration-risk analysis, and subsystem compatibility analysis.Source: §3.6 · pp. 10–11
4 Proposed AI-Augmented Cooperative Engineering Architecture
The proposed architecture places an intermediary between team members, specialized AI services, and external engineering tools, aiming to support cooperative workflows without replacing existing tools or imposing a rigid process. It combines multiple user-facing interfaces with server-side service selection and tool integration.
4 Proposed AI-Augmented Cooperative Engineering Architecture
- The architecture acts as an intermediary between team members, specialized services, and engineering tools, supporting low-intrusion workflow assistance rather than replacing existing tools.Fig. 7 depicts the proposed assistant-system architecture.Source: §4 · p. 11, Figure 7 · p. 12
- Chat, voice, and image interfaces support requests, hands-on progress reporting, design-rationale capture, and visual interaction with engineering artifacts.The dispatcher manages communication between the user and server.Source: §4 · p. 12
- A credential server manages user identity and permissions, while the service selector routes requests to specialized services according to engineering context, user role, and available tools.HTTP supports request–response interactions; WebSocket connections support continuous or interactive exchanges.Source: §4 · p. 12
- Specialized services connect to engineering tools and data sources to support requirement traceability, task monitoring, knowledge capture, communication summarization, and integration-risk detection.Examples include linking competition rules to tasks, capturing rationale from interactions, and analyzing subsystem dependencies and interface assumptions.Source: §4 · pp. 12–13
- In the illustrative workflow, a voice-reported wiring concern is routed to an integration-risk service, which retrieves related information, summarizes the conflict, and suggests follow-up actions.The response may also be logged as shared project memory.Source: §4 · p. 13
5 Discussion and Conclusions
The discussion frames ERC workflow difficulties as organizational and infrastructural, linking them with rework, integration delays, and documentation debt. It argues that AI support should strengthen cooperative information infrastructure, and describes an initial architecture while noting that the findings are self-reported and the architecture remains unevaluated in a deployed ERC setting.
5 Discussion and Conclusions
- ERC teams report organizational and infrastructural challenges, including informal task allocation, unclear requirements, fragmented communication, limited documentation, and weak feedback, alongside rework, integration delays, and documentation debt.The paper relates these conditions to cognitive overload, uneven workload distribution, and increased reliance on late-stage corrective effort.Source: §5 · pp. 13–14
- Coordination work such as clarifying tasks, tracking dependencies, and reconstructing knowledge often remains implicit, risking overload among highly engaged individuals and masking systemic inefficiencies.Time pressure, volunteer participation, turnover, and academic constraints leave little room for heavy process enforcement.Source: §5 · p. 14
- Although ERC participants widely use AI for isolated technical tasks, those uses do not directly address cooperative workflow problems such as task ambiguity, weak traceability, and late discovery of incompatibilities.The paper proposes an intermediary architecture connecting people, specialized services, and external tools to support traceability, knowledge capture, communication summaries, and integration-risk detection.Source: §5 · p. 14
- Voice interaction could let members report status, problems, risks, and design rationale during hands-on work, while aggregated outputs could give leaders a more continuous view of workload and bottlenecks.The described support emphasizes timely feedback, shared awareness, and adaptive coordination rather than tighter control.Source: §5 · p. 14
- The paper concludes that AI-augmented workflows may address organizational friction and hidden coordination work, and presents its architecture as a foundation for hybrid human–AI engineering teams.The architecture connects human-facing interfaces, service selection, specialized AI services, and engineering tools.Source: §5 · p. 15
- The findings reflect perceived workflow challenges from self-reported surveys, and the initial architecture has not been evaluated in a deployed ERC setting.Future work is to implement selected services, integrate existing team tools, and empirically evaluate their effects.Source: §5 · p. 15