Higher score = stronger methodological discipline in published open-architecture aviation work.
What "open architecture" is trying to fix
The core problem is integration cost. Every time a federal aviation platform replaces a component, adds a sensor, or swaps a processor, the integration work has historically been expensive and slow — because each component was built to talk to the rest of the platform in a custom, proprietary way. Open architecture is the program-office fix: agree on the interfaces, publish them, and require every component to conform.
Two layers of standards make this real. The policy layer is MOSA — the Modular Open Systems Approach, codified in 10 U.S.C. §2446a, that requires major weapon systems to use modular open architectures where practical. The implementation layer is a stack of open specifications: DDS (a real-time messaging standard), OMS (the Air Force's Open Mission Systems specification), and FACE (the Future Airborne Capability Environment), among others.
The honest finding in the published literature: conformance to these standards does not automatically deliver the cost savings the policy promised. How a program implements the standards matters at least as much as the standards themselves — sometimes more.
DDS: the messaging substrate underneath everything
DDS — Data Distribution Service for Real-Time Systems, an OMG (Object Management Group) standard — is the dominant messaging middleware in mission-critical aviation. Think of it as a real-time post office: components publish messages on named "topics," and any component subscribed to that topic gets the message, with delivery guarantees set per topic. Open implementations include RTI Connext DDS, Eclipse Cyclone DDS, and OpenDDS.
The control surface that matters is QoS — Quality of Service. DDS lets you set per-topic policies for deadline ("this message has to arrive within 50 ms"), reliability ("must never drop"), durability ("late subscribers get the last message"), and resource limits. The published guidance is unambiguous: QoS has to be configured consistently across every endpoint that uses a topic. One misconfigured endpoint breaks the guarantee the rest of the system depends on.
Discovery is the other recurring pain point. Discovery is the process by which DDS participants find each other at startup. Dynamic discovery (figure it out at runtime) is convenient when you're prototyping; static discovery (lock it down at deployment) is what production aviation uses, because dynamic discovery makes certification much harder and consumes runtime resources that the platform may not have.
OMS: the avionics service catalog on top of DDS
OMS — Open Mission Systems, an Air Force specification — sits one layer above DDS. Where DDS defines how messages move, OMS defines what the messages mean. It specifies a service catalog (target track service, mission planning service, sensor service, etc.) along with the message formats and interface contracts each service uses. OMS has been the focal point for Air Force open-architecture investment since the early 2010s.
This distinction matters for procurement. A platform that uses DDS for transport but ignores OMS message formats is DDS-compliant but not OMS-compliant. Programs that ask for OMS in the contract and accept DDS-only delivery quietly lose the portability benefit OMS was meant to provide.
Internal architecture matters as much as the external interface. A monolithic mission system that bolts an OMS-compatible facade on the outside but stays tightly integrated inside captures very little of the cost saving MOSA was reaching for. The published guidance favors decomposing the mission system along the same service boundaries the OMS catalog defines — so upgrades happen by replacing services, not by re-integrating the whole platform.
MOSA: the policy and the practice
MOSA is the federal policy that requires modular open systems wherever practical. The text lives in 10 U.S.C. §2446a and is implemented through DoD Instruction 5000.02. In practice, MOSA translates into program decisions: which interfaces to open, what conformance evidence to require, and how to test for conformance over time.
The hardest part is producing consistent conformance evidence across primes. Programs that test conformance at integration time, with each prime using its own tooling, end up with a fragmented evidence base that cannot support the cross-prime substitution MOSA was supposed to enable. The published norm is a centralized conformance harness, run continuously against the published interface, with results stored in a form acquirers and auditors can query.
The acquirer side is often the missing piece. MOSA does not enforce itself. An acquirer who accepts a non-compliant delivery — even once — accelerates drift back toward the proprietary state MOSA was meant to escape. The published case studies of successful MOSA programs consistently put acquirer discipline on equal footing with vendor compliance.
Latency and resource budgets: the quiet integration risk
Open data buses are not free — they add overhead. The discipline is to treat the overhead as a budget: tolerable up to the point where the mission function's latency budget breaks. Per-data-flow latency budgets, allocated across hops, verified against the deployment configuration — that's what the published latency-engineering literature recommends.
Resource budgets (CPU, memory, network bandwidth) work the same way. A high-frequency DDS topic with aggressive QoS can eat more CPU than the flight software budget allows, especially on resource-constrained platforms. Budget explicitly, allocate per data flow, verify against the actual deployment.
End-to-end measurement matters more than per-hop measurement. Each individual hop can meet its budget while the end-to-end latency still breaches the mission requirement — because hops compound, queues interact, and discovery traffic competes with data traffic. The published patterns favor end-to-end measurement against the deployment configuration, not synthetic per-hop benchmarks.
Certification: the constraint that shapes everything
Aviation systems get certified — for airworthiness under DO-178C (the FAA / DoD standard for safety-critical aviation software), for safety under MIL-STD-882, for security under the Risk Management Framework. Certification adds constraints that purely-functional architectures don't feel: the system has to be deterministic where it claims to be, worst-case behavior has to be documented, every requirement has to trace to a test, and resource consumption has to be bounded.
Static configuration is the recurring theme. A bus configuration that is determined at deployment time and never changes at runtime is dramatically easier to certify than one that adapts during flight. The published guidance does not say dynamic configuration is impossible to certify; it says it is much more expensive, and most programs should default to static unless they have a specific reason not to.
Failure-mode documentation is the second theme. A certification artifact that lists exactly which failure modes the bus tolerates, which it does not, and under what conditions each applies is more durable than one that asserts general robustness. Standard tools like FMEA (Failure Mode and Effects Analysis) and fault-tree analysis map onto data-bus behavior with adaptation; the discipline is to do that adaptation explicitly.
| Standard / approach | Scope | Common gap in practice |
|---|---|---|
| DDS (OMG) | Publish-subscribe transport, QoS policies | QoS misconfigured at endpoints; dynamic discovery in production |
| OMS (USAF) | Mission-system services, message formats | External interfaces conform but internal monolith persists |
| FACE (Open Group) | Avionics software architecture, units of conformance | Conformance evidence fragmented across primes |
| MOSA (DoD policy) | Modular open systems requirement, conformance gates | Acquirer accepts non-conformant deliveries |
| DO-178C | Airworthy software certification | Bus configuration not static; failure modes underdocumented |
Interoperability is more than wire-level conformance
Cross-platform interoperability — the whole point of open architecture — needs more than the bytes lining up. Three deeper layers also matter. Semantic interoperability: does the field labeled "altitude" on Platform A mean the same thing as the field labeled "altitude" on Platform B (above mean sea level? above terrain? above the ellipsoid?). Temporal interoperability: are the two platforms' clocks aligned tightly enough for the data to be useful? Operational interoperability: do the workflows the data feeds into actually mesh?
Programs that nail wire-level conformance but miss the semantic and temporal layers spend their open-architecture savings on rework. The patterns that work in the literature are mundane: documented data dictionaries, version-controlled message schemas, and tooling that catches semantic drift between platforms before integration starts. The patterns that fail are also mundane: informal dictionaries, schema versions tracked by filename, and validators that check only the wire format.
Degraded-mode behavior: what happens when things go wrong
Aviation platforms routinely operate under degraded conditions — link loss, partial sensor failure, ground-segment outage. A data bus that runs well in nominal conditions but fragments under stress does not survive operational evaluation. The published reliability literature treats degraded-mode behavior as a first-class verification target, with explicit test cases for the conditions the bus is expected to tolerate and explicit documentation of the conditions it is not.
The design goal is graceful degradation: when stressed, the bus reverts cleanly to a reduced-function mode that preserves the highest-priority data flows while shedding lower-priority ones. DDS QoS gives you the levers to do this. The discipline is to use them deliberately, configured against the actual mission priority structure rather than left at defaults.
Common questions on the public-record framing
Why does conformance not automatically deliver MOSA savings?
Because syntactic conformance does not enforce internal modularity, semantic alignment, or acquirer discipline. The savings come from the practice, not the standard alone.
Where does dynamic discovery fail in production?
Resource pressure, certification surface, and non-determinism. Static discovery configurations are the published norm for certification-bound deployments.
What does this article not cover?
Specific aircraft programs, specific OMS or FACE conformance findings under restriction, or any Precision Federal architectural approach. The framing is general public methodology only.
Frequently asked questions
DDS (Data Distribution Service) is the real-time messaging standard that lets aviation components publish and subscribe to data with strict per-topic guarantees on timing, reliability, and resource use. It's the OMG-standard "post office" most federal aviation programs use under the hood.
OMS (Open Mission Systems) is an Air Force specification focused on mission-system services and message formats. FACE (Future Airborne Capability Environment) is an Open Group standard with broader avionics-software scope and a formal "units of conformance" structure. They overlap and are sometimes both required on the same platform.
Because the savings depend on internal modularity, semantic alignment, and acquirer discipline — none of which the standard alone enforces. A program can be syntactically conformant and still be tightly coupled inside, semantically misaligned across platforms, and accepting non-compliant deliveries. That's where MOSA's promised cost savings get spent.
Because hops compound, queues interact, and discovery traffic competes with data traffic. Each individual hop can meet its budget while the end-to-end path still breaches the mission requirement. End-to-end measurement against the deployment configuration is the only honest verification.
How we use this site
We write articles like this to make our reading visible — what we think the open literature says, what we think the open gaps are, and where careful work might land. We do not use these pages to preview proposed approaches in active program spaces. Precision Federal is a software-only SBIR firm. If your office is funding work in this area and would value a software-first partner with a documented public-reading habit, we welcome the introduction.