Spectral Autonomy

Open Mission Systems (OMS): The Mission-System Abstraction Layer

Part of the Open Architecture Field Guide. All information is derived from unclassified, publicly releasable (Distribution A) sources.

OMS, Open Mission Systems, is a government-owned abstraction layer that separates mission software from the platform it runs on. Software built as Units of Replaceability targets the OMS layer rather than a specific avionics bus, so a service written once can run on any conformant platform. It is maintained by the Air Force through the Open Architecture Collaborative Working Group (OACWG).

What it does

Mission software has usually been written against a specific platform's avionics bus. That ties the software to one aircraft, so reusing a capability on another platform, or upgrading it, means reworking the integration. The cost of change stays high for the life of the system.

OMS puts a standard layer in between. It defines a Critical Abstraction Layer that sits between the mission software and the platform-specific bus. Mission software is built as Units of Replaceability that talk to the abstraction layer rather than to the platform. Because the layer is standard, a service written once can run on any platform that provides it.

OMS as the Critical Abstraction LayerMission software, built as Units of Replaceability, targets the OMS Critical Abstraction Layer rather than the platform. The layer sits between the mission software and the platform-specific avionics bus, so a service written once can run on any platform that provides the layer.MISSION SOFTWARE (UNITS OF REPLACEABILITY)Sensor serviceEW serviceC2 serviceOMS Critical Abstraction LayerPlatform-specific avionics bus
Spectral Autonomy
OMS puts a Critical Abstraction Layer between mission software and the platform, so software targets the layer rather than a specific avionics bus.

How it works

OMS uses publish-subscribe messaging and a set of standardized data exchanges: messages, bulk data transfers, special signals, and security information exchanges. It also defines tiered compliance, so a program can adopt OMS incrementally. A legacy system can meet a lower tier and interoperate at a basic level, while a new system built fully to OMS reaches the highest tier.

Where it sits

OMS is part of the software and interface family. It is the abstraction layer that carries UCI messages, and those messages are commonly transported over DDS. OMS is used inside larger reference architectures: AMS-GRA builds its mission-system messaging on OMS and UCI, and GARA applies OMS as one of the standards it references.

The software and interface stackMission software runs on top of the OMS abstraction layer, which carries UCI messages, commonly transported over DDS. FACE governs software portability alongside them, with no content overlap.FACEsoftware portabilityMission softwareUnits of ReplaceabilityOMSmission abstraction layerUCImessage schemaDDSpublish-subscribe transport
Spectral Autonomy
How the software family fits: OMS carries UCI, commonly over DDS, with FACE governing software portability alongside.

Where this fits

FAQ

What data exchanges does OMS define?
Messages, bulk data transfers, special signals, and security information exchanges, carried over a publish-subscribe pattern.
How is OMS different from UCI?
OMS is the abstraction layer and messaging pattern. UCI is the schema that defines the content of the messages that move across it. They are used and released together.
What is a Unit of Replaceability?
A modular piece of mission software or hardware that can be swapped independently because it connects through the OMS abstraction layer.
Who owns OMS?
The Air Force, through the Open Architecture Collaborative Working Group (OACWG).

Sources