Open Mission Systems (OMS) in a Nutshell

OMS is a Government-Owned Architecture Specification

OMS is not an implementation specification. You will not find rules in the OMS
documentation on how to implement your system. OMS focuses on the interfaces
between software Services and hardware Subsystems, and how data is
exchanged across those interfaces.

What is OMS Compliance? OMS Frequently Asked Questions

OMS Compliance is the creation of a subset of a weapon system architecture 1. Is OMS “All or Nothing?” – NO. OMS offers a Tiered Compliance
designed with open interfaces and data exchanges in accordance with the OMS mechanism that allows a subset of Services and/or Subsystems within the
Standard. System to be OMS-compliant

OMS Promotes Interoperability and Reuse 2. Is OMS only for new subsystems and services? - NO. Use OMS
Use of the standard allows weapon systems, services, and Adapters to quickly reach OMS-compliance with little or no changes to
subsystems/payloads/sensors to interact and communicate using common data legacy hardware subsystems or software services
formats. This interaction can occur within or between weapon systems, between 3. Does OMS require contractors to disclose the inner workings
platforms in sub-surface, surface, air, or space domains, or between ground of OMS Subsystems and OMS Services? - NO. OMS only requires
segments. documentation and disclosure of your external interfaces and resources
required
OMS Provides a Set of Tools
The OMS Standard does not tell you what to build, nor how to build it. OMS 4. Does OMS guarantee “Plug and Play?” - NO. The OMS Standard
provides a standard set of tools so that anyone can use those tools to extend, enables logical “Plug and Talk” for rapid integration
modify, and/or replace what is currently fielded in existing systems. 5. Does Use of UCI equal OMS compliance? - NO. There are a
number of OMS technical and documentation requirements beyond the use
OMS Allows Rapid Integration of New Sensor of Universal Command and Control Interface (UCI)
Capabilities, Subsystems/Payloads and Services
If your program is OMS-compliant, an OMS-capable component may be 6. Are large UCI messages too big for high-performance
integrated and tested at a minimal cost. If your program has a large amount of systems? - NO. UCI has messages of all sizes, and even large
common operating picture data, OMS allows you to share it with more users in a messages can be compressed before transmission; many fields are optional
standardized format. OMS can also break down boundaries between sensors, 7. Does OMS eliminate the need for Systems Engineering? - NO.
allowing data sharing that would be challenging to implement individually. Systems Engineering work is required to employ OMS Services and
Subsystems
Use of OMS is Widespread and Growing
There are US Air Force, Navy, and Space Force programs that utilize OMS for 8. Is OMS only for Linux? - NO. OMS can run on any number of
their system architecture. Please contact the Open Architecture Management operating systems, such as Windows, Linux, Integrity, VxWorks, etc.; only
Office for a more complete list of programs. the Open Computing Environment (OCE) is required to be Linux
9. Is OMS just UCI? - NO. There are four valid OMS Data Exchanges:
OMS Can Be Expanded to Work in Multiple Domains and OMS Messages, Data Transfers, Special Signals, and Security Information
for Many Use Cases Exchanges
OMS has recently been expanded to new areas. Please contact the Open
Architecture Management Office to understand whether your application would 10. Is UCI XML? - UCI is defined in an XML Schema, but UCI messages do
benefit from OMS. NOT have to be transmitted as XML text string. UCI messages have been
encoded using multiple industry formats for transmission between nodes.
DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.
OMS in a Nutshell
Open Mission Systems (OMS)
Example – Integration of a new Automatic Target Recognition Example – Sharing of Common Operating Picture
service into an already OMS-compliant weapon system (COP) data between an air operations floor and a
space operations floor
• Weapons System has 3 OMS Subsystems/Sensors
• Air Operations Center connects and coordinates tasking for
o OMS SAR – produces NITF images and MTI entity tracks
two aircraft
o OMS EO/IR – outputs video with KLV
• Space C2 Center coordinates tasking for two space
o OMS IRST – produces LOBs and entity track messages
• The ATR software has been adapted to be an OMS Service systems
o ATR Software has been recompiled with provided mission • All ISR products are handled via OMS messages or data
package Critical Abstraction Layer (CAL) exchanges
o Reports health and status via OMS messages • Completion, status, and management of all tasking is
o Ingests tracks, video, LOBs, and NITF images handled via OMS messages
o Outputs new entity tracks that the ATR service has automatically
identified in the received products

Integration
1. Machine-to-machine common track, tasking, and ISR
product formats allow more robust COP for both centers
Integration
2. Both operations centers develop isolator services to
1. The ATR service will automatically receive new events from the OMS manage data exchanges between the two systems
Subsystem/Sensors via OMS messages and other OMS data exchanges 3. OMS does not dictate what data exchanges occur between
2. Once the ATR service has been installed on the OCE, the UI and the centers – that is based on program needs
Health and Status services need to be adjusted to support the new
service and its outputs
3. No changes are required to the existing sensors or VMS For More Information Please Contact: [email protected]
DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.