A system-of-systems architecture connects useful, independently operated systems so they can deliver a capability together. For unmanned platforms, that means defining how vehicles, control stations, mission services, communications, and people exchange information and authority. The central design question is what each participant can decide locally, what requires coordination, and what happens when that coordination becomes unavailable.
A successful unmanned system architecture makes those boundaries explicit. A shared map or common radio is only part of the arrangement: the participants also need an agreed meaning for tasks, status, completion, and failure.
On This Page
- Where the system boundary belongs
- From mission intent to vehicle action
- Interfaces must carry meaning as well as messages
- Choosing where coordination runs
- Failure modes to design and exercise
- Applications across air, ground, and underwater operations
- What to require before integration
Where the system boundary belongs
An aircraft with a camera, autopilot, and radio is a system. Connecting several aircraft does not automatically make the result a system of systems. The distinction concerns the constituent systems' continuing usefulness and independence, together with the new capability their integration creates. The U.S. Department of Defense's Systems Engineering Guide for Systems of Systems, version 1.0, also distinguishes an acknowledged arrangement, where participants retain separate ownership and development, from a directed arrangement organized around a centrally managed purpose. This is engineering guidance from 2008, not a universal requirement for civilian robots. DoD guide, sections 1.4–1.5.
Consider a hypothetical flood-response operation. An aerial survey service supplies observations, a ground-robot team inspects accessible structures, and an incident-management service allocates work. Each can serve other missions. Combining their capabilities requires agreements about coverage, location accuracy, task ownership, and who may withdraw an asset.
Include the people and enabling infrastructure in the boundary. A launch crew, communications relay, charging facility, or map service may determine whether a mission is possible even though it never receives a movement command. NASA's systems-engineering guidance treats architecture as the relationships among hardware, software, people, communications, and operations, with functions allocated to the appropriate elements. NASA System Design Processes.
For procurement, draw a second boundary around responsibility: who owns each interface, approves a change, and pays to preserve compatibility? Two vehicles may exchange today's messages successfully while their suppliers follow incompatible upgrade schedules.
From mission intent to vehicle action
A useful design separates four responsibilities. This is a functional breakdown, not a mandated stack or a requirement for four computers.
- Mission direction: A person or authorized service defines the desired result, operating area, priorities, and limits.
- Coordination: A mission service assigns work, manages shared resources, and tracks dependencies between participants.
- Vehicle execution: Each platform turns its assigned task into a feasible local plan and reports progress or rejection.
- Control and protection: Vehicle controllers execute motion and enforce the constraints allocated to them.
The output of one level becomes a constrained input to the next. In the flood example, an instruction to inspect a bridge should specify the bridge identifier, requested observation, expiry, and completion criteria. It should not require a remote coordinator to supply every steering adjustment. The returned result should identify what was actually inspected and any gap in coverage.
Keep task acceptance separate from task success. The MAVLink command protocol provides a concrete example: an accepted command means the flight stack will attempt the action; it does not establish completion. Long-running commands can report progress and a final result. MAVLink Command Protocol.
A mission dashboard should therefore distinguish requested, accepted, executing, completed, rejected, and unknown outcomes where the underlying interface supports them. If contact disappears after acceptance, showing the task as completed would turn a communications gap into a false operational conclusion.
Interfaces must carry meaning as well as messages
An interface description needs more than a topic name and a list of fields. For each exchange, specify the sender, permitted recipients, units, coordinate frame, time basis, freshness limit, response behavior, and supported versions.
Coordinate conventions are a practical trap. ROS REP 103 describes east-north-up local geographic coordinates and a transformed north-east-down secondary frame; its camera optical convention differs from the normal body frame. The same three numbers can describe different directions unless the frame is carried or fixed by agreement. REP 103 is an informational ROS convention, not an all-platform certification standard. REP 103: units and coordinate conventions.
The following interface checklist is an engineering synthesis of the NASA, ROS, and MAVLink documentation cited here. Its suggested questions are integration choices, not quoted requirements.
| Exchange | Information to agree | Question that exposes a hidden mismatch |
|---|---|---|
| Task assignment | Task identifier, authority, version, expiry, cancellation | Can an old assignment become active after reconnection? |
| Position or observation | Frame, units, timestamp, uncertainty, source | Can the receiver distinguish an old position from a current one? |
| Progress and result | Accepted versus completed, partial output, failure reason | What evidence closes the task? |
| Control transfer | Current controller, permitted actions, transfer sequence | Can both stations believe they control the same vehicle? |
| Health and capability | Available functions, resource limits, degraded modes | Does an online vehicle still have the sensor needed for its task? |
Delivery settings also affect interoperability. ROS 2 Jazzy documents reliability, queue history, deadline, lifespan, and liveliness policies. Incompatible quality-of-service profiles can prevent message delivery. Reliability concerns delivery; lifespan concerns whether a sample is still usable, and deadline concerns the expected interval between messages. A reliable stream is not automatically a fresh stream. ROS 2 Jazzy QoS documentation.
Separate security from task authority, too. MAVLink 2 signing lets a receiver check that a message came from a trusted source. That does not, by itself, decide which trusted participant should command a particular vehicle at this moment. Specify command permissions and handover behavior alongside authentication. MAVLink message signing.
Choosing where coordination runs
Central coordination puts task allocation and the shared mission picture in one logical place. It can make a tightly coupled job easier to reason about, but the design must address loss of that service and its links. Distributed coordination shares decisions among participants; it still needs rules for conflicting decisions and incomplete information. A hybrid can coordinate shared tasks centrally while retaining local execution and protection. These are design options to compare against the mission, not a ranking from least to most capable.
NASA's CADRE research demonstrates why the labels need qualification. The 2025 planning paper describes an elected leader that schedules work for the team, shared state, and controllers on individual agents. Leadership can move between agents, while planning remains centralized on the active leader. A distributed collection of robots can therefore use centralized planning. CADRE planning, scheduling, and execution paper.
Choose placement by the consequence of waiting. A high-level survey assignment may tolerate a communications pause; an action requiring several platforms to remain coordinated may not. CADRE's authors explicitly identify delayed abort messages as a limitation for coordinated actions. Resilience to a failed leader should not be interpreted as unrestricted operation through any network outage.
Before selecting an arrangement, compare these tradeoffs for the actual mission:
- Freshness versus delivery: Should an old observation be retransmitted, or replaced by the latest sample?
- Shared awareness versus bandwidth: Which information must cross the network, and which can stay on the vehicle?
- Local capability versus resources: What computation, electrical power, thermal capacity, and software assurance does onboard decision-making require?
- Coordination versus independence: Which tasks remain useful when the common mission service is absent?
Do not set a universal fleet-size or latency limit from an architecture label. A useful measurement is the elapsed time from an observation's acquisition to its use in a decision, including processing, queuing, and transport. Set its permitted age from the task and hazards, then exercise the entire path under the expected load. Include competing payload traffic in that exercise; a quiet-network demonstration does not establish performance during a mission.
Failure modes to design and exercise
Most revealing integration exercises cross a boundary. A component can behave as specified while the combined operation fails because another participant interprets its state differently.
The table below proposes exercises based on the documented interface and coordination issues above. Outcomes must be selected for the specific platform and operating environment; they are not universal emergency procedures.
| Failure or disturbance | Combined-system consequence | Behavior to specify and exercise |
|---|---|---|
| Link interruption during a task | Coordinator cannot tell whether work continues | Vehicle behavior while disconnected and an explicit unknown task state at the coordinator |
| Coordinator replacement | Old and new assignments overlap | Authority transfer, cancellation, and task reconciliation before new work |
| Old observation arrives late | A plan uses a location that is no longer current | Timestamp handling, freshness rejection, and treatment of missing data |
| Frame or unit mismatch | A valid message describes the wrong motion or location | Known reference cases through the complete conversion path |
| QoS mismatch after an update | Endpoints exist but no useful messages arrive | Compatibility checks using the deployed versions and settings |
| Shared relay or supporting service fails | Several otherwise healthy platforms lose a dependency | A dependency-loss exercise and a defined remaining mission capability |
Recovery deserves its own sequence. After contact returns, compare current vehicle state with the coordinator's last known state, resolve outstanding task identifiers, and establish who can issue new work. Reconnection alone should not replay an expired mission. Define the fallback per platform: stopping a ground vehicle, holding an aircraft, and changing an underwater mission each have different environmental and energy consequences.
Also test the operator's view. Can a person tell which vehicle is under which authority, which observations are old, and which tasks need intervention? NASA's design guidance includes human-system responsibilities and operational scenarios involving faults and mode transitions. That makes the display and handover procedure part of the architecture, not a finishing layer added after the robots work.
Applications across air, ground, and underwater operations
Air and ground response: In the hypothetical flood operation, aerial coverage can identify places worth closer inspection, while a ground team returns local observations. The handoff needs a common location reference and a clearly defined inspection request. Passing an image without its position, time, and requested follow-up leaves the next system to guess.
Underwater inspection: Communications can change the division between operator control and local autonomy. WHOI's documented 2012 Nereus demonstration combined acoustic control and tracking with optical video when within optical range. It illustrates allocating different information to different links; its experimental ranges and rates are not specifications for today's underwater vehicles. WHOI's Nereus communications demonstration.
Cooperative exploration: CADRE provides a researched example of agents coordinating exploration and sensing. It illustrates multi-robot autonomy mechanisms, rather than proving that every robot team has the managerial independence of an acknowledged system of systems. The featured photograph shows a December 2023 clean-room drive test at JPL, not lunar operations. NASA's CADRE test photograph.
Across these cases, the useful result is defined at mission level: an inspection completed, a usable observation delivered, or a coordinated measurement obtained. Counting connected vehicles says little about whether those results can survive a missing participant.
What to require before integration
Ask for an architecture package that names constituent systems and owners, traces mission tasks to interfaces, states who controls each action, and defines operation during loss and recovery. Require the exact interface versions and a demonstration that includes delayed messages, service restart, and at least one unavailable participant relevant to the mission.
Begin that demonstration with a complete task and end with its result. Follow what each system believed, commanded, and reported along the way. If the team can explain both the successful path and the interrupted path, it has a much stronger basis for integration than a diagram showing that every box is connected.
Sources
- DoD, Systems Engineering Guide for Systems of Systems, version 1.0, August 2008: original government guidance, hosted by AcqNotes; definitions and governance distinctions.
- NASA Systems Engineering Handbook, System Design Processes: official guidance on boundaries, functional allocation, interfaces, people, and fault scenarios.
- MAVLink Command Protocol: primary protocol documentation distinguishing command acceptance, progress, and outcome.
- ROS REP 103, Standard Units of Measure and Coordinate Conventions: official informational convention for units and frames.
- ROS 2 Jazzy, Quality of Service settings: official documentation source covering delivery compatibility and timing policies.
- MAVLink Message Signing: primary documentation for trusted-source authentication.
- Rabideau and colleagues, Planning, scheduling, and execution on the Moon, AAMAS 2025: original CADRE architecture research and communication limitations.
- WHOI, Nereus wireless communications demonstration, November 14, 2012: institutional report of a historical field demonstration.
- NASA Photojournal, PIA26164: official featured-image record and December 2023 test context.
Last checked: September 6, 2026.
