Open Architecture in Unmanned Systems

Open architecture in unmanned systems organizes hardware and software into modules connected through documented, usable interfaces. The aim is to change a sensor, mission application, controller, or operator station without redesigning every surrounding component. Its practical value depends on whether a replacement meets both the interface and the vehicle's operating requirements.

An interface must describe more than a connector or message name. The receiving component needs to understand what the data means, when it is valid, who may issue commands, and what happens when communication fails. That is where an open design becomes a working system.

Choose the boundary that needs to remain replaceable

Start with a concrete change: replacing a navigation sensor, adding an inspection payload, changing the autonomy software, or operating another vehicle from an existing station. Each opens a different part of the system. A documented payload port does not establish that the flight-control software or ground station can be replaced.

The official Modular Open Systems Approach overview describes MOSA as a combined acquisition and engineering strategy built around modularity, open interfaces, and verified conformance. It identifies technology refresh and competition as intended benefits. Those are objectives, not automatic savings for a particular project.

The useful design question is which dependencies should cross the chosen boundary. A navigation module might expose a position estimate, timestamp, reference frame, and health state while keeping its estimation algorithm internal. The downstream controller should not need that algorithm's private memory layout to consume its output.

Source-code access is a separate matter. For example, the MAVLink project permits its MIT-licensed message definitions and generated C library to be used in closed-source applications. A published interface can therefore connect components whose internal implementations remain proprietary.

For an actual supplier change, ask who can obtain the interface documentation, use the necessary tools, implement the required messages, and maintain that implementation. An interface description that omits essential extensions leaves the replacement problem unresolved.

How modules exchange data and control

Consider an inspection aircraft with a flight controller and a separate mission computer. PX4's v1.16 system architecture documents this arrangement: the flight controller runs the flight stack, while the companion computer can provide functions such as computer vision. Serial or IP communication connects them. The same documentation shows sensors, motor controllers, payloads, and the ground station around that core.

In a representative modular implementation, a measurement-to-action path works as follows:

A sensor driver converts device output into the software's expected message format.
A perception or navigation component consumes measurements and produces a state estimate or interpreted observation.
A mission application uses that information to request a movement or payload action.
The vehicle controller applies its supported command semantics and operating limits.
Status messages report the resulting state to the application and operator.

These are functional boundaries, not a requirement to put every function on a separate computer. The decisive issue is whether a replacement can satisfy the neighboring components without changing their private internals.

Two communication patterns matter. In publish-subscribe communication, producers send data streams that interested consumers receive. In request-response communication, a client asks a particular service to perform an operation or report information. MAVLink combines streaming telemetry with point-to-point subprotocols for tasks such as mission and parameter exchange.

Receiving a reply does not always establish a completed action. The MAVLink command protocol distinguishes an accepted command from a completed operation: ordinary acceptance means the flight stack will attempt the action. An application should use the appropriate completion or state feedback before declaring the mission step finished.

What the main interface approaches cover

MOSA, JAUS, UMAA, ROS 2, and MAVLink answer different engineering questions. They should not be treated as interchangeable labels for compatibility.

JAUS: services and protocol behavior

The Joint Architecture for Unmanned Systems, or JAUS, defines service interfaces through SAE service-set documents. OpenJAUS's implementation documentation explains services in terms of input and output messages, internal events, and protocol behavior. Its examples include mobility and manipulator service sets.

For a ground robot, this provides a way to express capabilities through defined services. However, the protocol does not prescribe every internal application behavior. Two implementations can exchange the expected messages while differing in how their hardware carries out the requested action. Specify the applicable service-set revision and required services, then evaluate the robot's behavior as well as its message exchange.

UMAA: onboard maritime autonomy components

The Unmanned Maritime Autonomy Architecture public resource describes a Navy initiative for reusable software across unmanned surface and underwater vehicles. UMAA organizes onboard autonomy into components with defined services and uses Data Distribution Service, or DDS, as a core communication mechanism.

Its scope is particularly important: the public description addresses onboard autonomy software and excludes the external command element. A UMAA component interface therefore does not by itself establish interoperability with an arbitrary shore-based control station. The resource identifies public UMAA 6.0 documents; an integration should name its component definition and applicable interface documents rather than claim generic “UMAA support.”

ROS 2 and MAVLink: practical software connections

ROS 2 provides communication facilities with configurable delivery policies. MAVLink provides drone messages and task-specific subprotocols. Either can be part of a larger modular design, but neither name specifies all of a vehicle's hardware, behavior, or integration requirements.

For a concrete aircraft example, the PX4 v1.16 ROS 2 guide describes a client on PX4 connected to an agent on the companion computer. That bridge makes selected flight-stack messages available to ROS 2 applications. The guide also documents differences in coordinate conventions that an application must handle. The bridge transports data; it does not eliminate the need to interpret it correctly.

Where compatible components still fail

Use the following table to turn a broad compatibility claim into specific integration questions. It is an editorial synthesis of the cited PX4, ROS 2, MAVLink, JAUS, and UMAA documentation, not a formal conformance test suite.

Interface boundary	What must be agreed	Failure to investigate	Useful verification
Hardware connection	Bus, electrical requirements, wiring, mounting, and supported driver	A device connects physically but cannot provide usable measurements	Check the exact hardware and driver documentation, then verify the installed signal path
Message definition	Message set, version, required fields, and supported operations	A peer decodes a message but does not support the requested operation	Exercise the required messages and inspect rejection responses
Data meaning	Units, axes, reference origin, and validity indicators	Plausible values describe the wrong direction or reference	Supply known inputs and verify the receiver's interpreted result
Timing and delivery	Clock basis, data age, queueing, and delivery policies	Old samples arrive successfully, or incompatible policies prevent delivery	Observe receive behavior under the intended traffic and delay conditions
Control and feedback	Command authority, operating state, acknowledgement, and completion	An accepted command is mistaken for a finished action	Verify state feedback and the result of rejected or interrupted commands
Fault and restart	Timeout, invalidation, fallback, and re-entry behavior	A stopped component leaves the rest of the system acting on stale state	Test bounded loss and restart in simulation or a controlled test environment

Three documented examples show why these distinctions matter.

Delivery mismatch: the ROS 2 Jazzy quality-of-service documentation states that incompatible policies can prevent delivery. A best-effort publisher cannot satisfy a subscriber requesting reliable delivery. Matching the topic name and data type does not fix that mismatch.

Coordinate mismatch: PX4's ROS 2 guide contrasts North-East-Down and East-North-Up world conventions, as well as different body-axis conventions. A bridge that passes numbers unchanged can preserve the message structure while changing the physical meaning of a requested movement. The integration must apply the correct transformation for the particular message.

Controller loss: PX4 v1.16 Offboard mode requires a continuing external-controller signal and defines a timeout and configured failsafe response when it is lost. Merely proving that the external application can send a setpoint misses the failure path. Confirm how the vehicle leaves external control and what must happen before that control resumes.

Security is another interface property. MAVLink 2 message signing allows receivers to check whether a message came from a trusted source and defines timestamp checks. It also leaves policies for accepting unsigned messages to the implementation. Thus, “supports signing” is incomplete: the integration needs an explicit receive policy and a verified trust boundary.

The performance and maintenance tradeoffs

Open interfaces can make change easier, but abstraction does not remove resource limits. More communication, conversion, or processing must still fit the system's timing and capacity. For a navigation input, distinguish how often a new estimate is published from how old its underlying measurement is when the controller uses it. Measure the complete path that matters to the mission.

ROS 2's sensor-data profile illustrates a real choice. Its documentation favors timely new readings over guaranteed delivery of every sample and uses best-effort delivery with a smaller queue. A recording application and a live controller may therefore need different policies. Reliable delivery is not a substitute for a data-age requirement.

Hardware boundaries carry their own constraints. PX4 documents several sensor and actuator buses, so a common application interface does not mean every replacement can use the existing wiring. A software adapter may preserve the rest of the application while still requiring a different driver or electrical integration.

The maintenance decision is where to accept that adaptation work. A stable interface around a frequently replaced payload can localize future changes. An interface exposing low-level implementation details may force neighboring components to change whenever the payload changes. Treat this as a design tradeoff to review, not a promised reduction in engineering hours.

Work through a component replacement

Suppose a team wants to replace an inspection aircraft's mission computer while retaining its flight controller and operator interface. This is a hypothetical engineering example, not a tested configuration.

First, freeze the baseline: flight-controller release, required messages, mission application behavior, and supported control modes. Record which functions are being replaced. A replacement computer that also changes navigation or the command route has expanded the scope of the integration.

Next, compare the interface contract. Confirm the communication transport, message definitions, coordinate conversions, and delivery settings. If the new application produces East-North-Up coordinates and the receiving interface expects North-East-Down, assign the conversion to one explicit boundary and verify the interpreted directions. Distinguish the application's requested action from the flight controller's accepted state and the eventual mission result.

Then exercise both the normal path and loss of the replacement component. Begin with simulation or a controlled bench setup. Challenge startup order, interrupted communication, application restart, rejected commands, and re-entry to external control. The PX4 Offboard documentation provides a concrete reason to include continuing controller health and configured loss behavior in that evaluation.

Finally, assess the remaining vehicle-specific changes. A successful software exchange does not settle mounting, power, thermal integration, or the behavior of the complete aircraft. Preserve the exact configuration and results so a later update can be compared with the accepted baseline.

This sequence separates three claims that are often collapsed into one: the component implements the interface, it interoperates with the selected peers, and the resulting system performs the required mission. Ask suppliers which of those claims their evidence actually supports.

Specify the replacement you need

An effective open-architecture requirement names the module that may change, the interface it must preserve, and the system behavior that must remain acceptable. Request the applicable interface revisions, supported service or message subset, integration documentation, and results for normal operation and failure recovery.

Choose the boundary around the change your program expects. Then verify it with the intended peers and operating conditions. That makes openness an engineering capability a team can use, rather than a label attached to the vehicle.

Sources

Modular Open Systems Approach: official government overview of modular design, interface conformance, acquisition strategy, and intended benefits.
PX4 System Architecture, v1.16: project documentation for flight controllers, companion computers, sensors, actuators, and communication paths.
MAVLink Developer Guide: project documentation for communication patterns, message dialects, and licensing.
MAVLink Command Protocol: project specification explaining acknowledgements, rejection, progress, and completion semantics.
OpenJAUS: JAUS Services: implementation documentation explaining service interfaces and protocol versus application behavior; not a substitute for the SAE standards.
Unmanned Maritime Autonomy Architecture: AUVSI-hosted public initiative resource describing scope and linking government-released documents.
PX4 ROS 2 User Guide, v1.16: project documentation for the client-agent connection and coordinate conventions.
ROS 2 Jazzy: Quality of Service Settings: official documentation source covering delivery-policy compatibility and sensor-data settings.
PX4 Offboard Mode, v1.16: project documentation for external control, continuing controller signals, timeouts, and configured loss behavior.
MAVLink Message Signing: project specification for message authentication, timestamp handling, and receive policies.
Steuereinheit eines professionellen Quadrocopter oder Multicopter: original photograph by Clicklabs, reproduced unchanged. It shows connected hardware, not proof of interface conformance.
CC BY-SA 3.0: license for the featured Clicklabs photograph.

PX4 examples refer to v1.16 documentation; the ROS 2 delivery-policy example refers to Jazzy. These examples do not establish compatibility for a different release or vehicle configuration.

Last checked: September 6, 2026.