Concurrent engineering is the coordinated development of a system by multiple disciplines at the same time. For a space programme, propulsion, structures, avionics, thermal, software, operations, manufacturing and verification share current assumptions and make trades together. Speed comes from replacing delayed handoffs with fast integrated decisions, while controlled baselines preserve what was agreed.
Working in parallel is not automatically concurrent engineering. Teams can all be busy at once and still discover at integration that they designed against different masses, power limits or interface versions. Real concurrency requires shared context, clear decision authority and a reliable way to record and propagate change.
What is concurrent engineering?
The European Space Agency definition describes concurrent engineering as a systematic approach to integrated product development built around collaboration, trust and parallel work. ESA's Concurrent Design Facility brings specialists, shared data and supporting tools into one environment so mission concepts can be evaluated as a connected system.
The method shortens feedback loops. Instead of a mission team writing requirements, handing them to subsystem teams and waiting weeks for separate analyses, the relevant experts examine the same evolving concept. A mass increase can immediately reach propulsion, structure, launch and cost. A communications choice can be considered with power, thermal and ground operations in the same session.
“Concurrent Engineering (CE) means working in a team rather than individually.”
The practical objective is to make the latency between a change and its multidisciplinary assessment deliberately small. Not every decision has to occur in one room, but every significant trade needs a shared starting point, visible assumptions and an authoritative result.
What concurrent engineering is not
It is not unrestricted simultaneous editing. If several teams change shared constraints without ownership or merge rules, the programme creates more conflict, not more speed. It is also not permanent meeting attendance. A team can spend every day in calls and still lack an authoritative model afterwards.
Concurrent engineering does not remove discipline, interfaces or configuration management. It changes when they happen. Interfaces are negotiated while the design is moving, assumptions are exposed earlier and baselines are updated more frequently through controlled decisions.
Nor does it mean that every specialist must understand every detail. Each discipline remains responsible for its analysis. The shared environment lets experts see the system-level consequence of their local work and makes the trade visible to the people who depend on it.
Why concurrency helps space programmes
Space systems are tightly coupled. Mass affects launch, structure and manoeuvre. Power affects arrays, batteries, thermal rejection and operations. A payload concept changes data handling, downlink and ground architecture. Sequential handoffs make these feedback loops long, and every delayed answer increases the chance that another team proceeds with an obsolete assumption.
Concurrency brings cross-domain information into the decision before local work hardens. That can retire feasibility risks sooner, reduce late rework and help a team compare more alternatives in the available concept phase. NASA research on MBSE in concurrent engineering centres also highlights the value of model-based information for multidisciplinary concept evaluation.
The approach is especially useful when the team is learning what the requirements should be. Early requirements and architecture develop together. The programme can preserve hard mission obligations while using analyses and trades to derive realistic subsystem constraints.
What must be in place before teams work in parallel?
| Foundation | What the team needs | What fails without it |
|---|---|---|
| Shared objective | Mission outcome, study questions and decision criteria | Disciplines optimise different products |
| Visible assumptions | Current values, uncertainty, source and owner | Models appear consistent while inputs differ |
| Interface ownership | Named people for both sides and decision authority | Boundary conflicts remain unresolved |
| Common data model | Agreed objects, units, relationships and applicability | Tool outputs cannot be compared reliably |
| Change workflow | Proposal, impact review, decision and baseline update | Parallel changes overwrite or bypass each other |
| Decision record | Rationale, alternatives, evidence and follow-up | The next session repeats the argument |
An ESA-inspired before, during and after protocol
Before: establish the decision envelope
A focused session begins with a defined decision or study question. The facilitator confirms the starting baseline, unresolved assumptions and criteria. Each discipline brings the simplest model needed to answer the question, with inputs and outputs mapped to the shared system view.
During: trade against one visible system state
As trades develop, a data owner or integrated model records changed values and their sources. Interface owners identify consequences across boundaries. The systems lead makes conflicts and uncertainty visible. Decisions are captured with rationale, not only announced verbally.
After: publish a controlled delta
After the session, the programme should have a controlled delta: which requirements, assumptions, interfaces, architecture elements, risks and verification plans changed; which remain proposed; and who owns the next action. A colourful wall of results is not enough if the working teams return to different versions.
| Live decision-log field | Purpose |
|---|---|
| Decision or unresolved question | Separates an accepted outcome from an open trade |
| Applicable baseline and configuration | Fixes the system state against which the decision was made |
| Alternatives and criteria | Preserves why one option was preferred |
| Changed assumptions and interfaces | Provides the first set of downstream impact candidates |
| Authority, owner and due date | Makes approval and follow-up responsibility explicit |
Roles that make the protocol work
The study or programme lead defines the decision boundary and holds overall authority. A systems lead protects mission coherence and the quality of cross-domain relationships. Domain experts own their models and explain limitations. Interface owners negotiate boundaries. A data or configuration role maintains the integrated record and baseline.
Facilitation is a real engineering capability. The facilitator needs to expose disagreement without allowing one discipline or senior voice to dominate the model. They keep the session moving towards a decision while preserving unresolved uncertainty honestly.
Responsible engineers should be able to propose and challenge constraints directly. That does not mean every contributor can approve every change. Contribution can be broad while decision rights remain explicit.
How do requirements behave in concurrent engineering?
Hard external obligations remain controlled. Customer commitments, safety limits and launch-interface constraints cannot be casually traded away. Many lower-level requirements, however, are design decisions expressed as limits. Concurrency lets teams negotiate those constraints while the system consequence is visible.
A requirement should carry maturity. Early in a study it may be a candidate or design target. As evidence and authority increase, it can become reviewed and baselined. Treating every early number as equally fixed suppresses useful trades; treating every number as optional prevents disciplined design.
Every accepted change should propagate to the relevant owners and verification work. The guide to agile requirements management for NewSpace describes a compatible operating model.
Can distributed teams practise concurrent engineering?
Co-location makes high-bandwidth discussion easier, which is one reason facilities such as ESA's CDF are powerful. Distributed teams can still work concurrently when they combine focused live sessions with an excellent asynchronous record.
The programme needs more than screen sharing. Participants should see current requirements, budgets, assumptions and interfaces in a shared structured workspace. Changes should be visible as proposals, comments should stay attached to the affected item and decisions should update the controlled context after the session.
Time zones can even improve throughput if handoffs are explicit. One team can run an analysis while another reviews a related interface, provided both use the same baseline and know what may change before they continue.
How does concurrent engineering relate to agile and MBSE?
Concurrent engineering describes who works together and when. Agile describes how the programme structures repeated learning and delivery. MBSE describes how models support engineering work. A team can use all three: multidisciplinary experts work concurrently on a connected model during short iterations, then preserve accepted requirements and evidence through configuration control.
Each approach can also fail independently. Agile without concurrency produces fast local sprints and slow integration. MBSE without accessible collaboration creates a sophisticated model maintained by a small priesthood. Concurrency without controlled data creates quick meetings and unreliable follow-through.
How should a team introduce concurrent engineering?
- Select one cross-disciplinary decision with real schedule or integration pressure.
- Define the starting baseline, study question, decision criteria and required disciplines.
- Expose shared assumptions, interfaces, budgets and uncertainty before the session.
- Use lightweight domain models connected through agreed inputs and outputs.
- Capture decisions, rationale and affected requirements as the trade develops.
- Publish a controlled delta and assign every unresolved item after the session.
- Measure decision latency, rework and stale-assumption incidents before expanding.
How Arc supports concurrent engineering
Arc gives multidisciplinary teams one structured workspace for requirements, architecture, systems, interfaces, tests and evidence. Engineers can propose work in branches, compare changes, discuss the affected records and merge accepted updates into the programme baseline.
That model supports fast parallel contribution without making the shared design anonymous. Owners, relationships and verification implications stay visible. Configurable agents can help flag conflicting assumptions, missing links and downstream effects for engineers to review.
Related reading
Read how MBSE and requirements management fit together, then use change-impact analysis to control the deltas created by parallel work.
Frequently asked questions
What is concurrent engineering?
Concurrent engineering is an integrated approach in which multiple disciplines develop and assess a system in parallel, sharing current assumptions, requirements, interfaces and analyses so decisions reflect the whole product rather than sequential handoffs.
How is concurrent engineering different from agile?
Concurrent engineering focuses on multidisciplinary work happening together. Agile focuses on short learning and delivery cycles. A hardware programme can use both by running cross-functional design and verification inside repeated controlled iterations.
Does concurrent engineering remove design reviews?
No. It creates more frequent alignment between formal reviews, so PDR, CDR and other gates assess a current integrated design rather than discovering months of hidden divergence.
Can concurrent engineering work with distributed teams?
Yes, if the programme provides shared structured context, low-latency decision channels, visible changes and reliable asynchronous records. A video call alone does not create concurrency.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.