OAM Brochure

Download Brochure

OMS/UCI

Open Mission Systems/Universal Command and Control Interface


Open Mission Systems

  • The goal of the Open Mission Systems is to develop industry consensus for a non-proprietary mission system architectural standard that enables affordable technical refresh and insertion, simplified mission systems integration, service reuse and interoperability, and competition across the life-cycle. Industry and the Government have been working on solutions cooperatively to achieve these goals for several years with extensive testing and demonstrations.
  • OMS focuses on the interfaces between software Services and hardware Subsystems, and how data is exchanged across those interfaces. OMS is not an implementation specification.

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 Compliance is the creation of a subset of a weapon system architecture designed with open interfaces and data exchanges in accordance with the OMS Standard.
  • OMS Promotes Interoperability and Reuse. Use of the standard allows weapon systems, services, and subsystems/payloads/sensors to interact and communicate using common data formats. This interaction can occur within or between weapon systems, between platforms in sub-surface, surface, air, or space domains, or between ground segments.
  • OMS Provides a Set of Tools. The OMS Standard does not tell you what to build, nor how to build it. OMS provides a standard set of tools so that anyone can use those tools to extend, modify, and/or replace what is currently fielded in existing systems
  • OMS Allows Rapid Integration of New Sensor Capabilities, Subsystems/Payloads and Services. If your program is OMS-compliant, an OMS-capable component may be integrated and tested at a minimal cost. If your program has a large amount of common operating picture data, OMS allows you to share it with more users in a standardized format. OMS can also break down boundaries between sensors, allowing data sharing that would be challenging to implement individually.
  • Use of OMS is Widespread and Growing. There are US Air Force, Navy, and Space Force programs that utilize OMS for their system architecture. Please contact the Open Architecture Management Office for a more complete list of programs.
  • OMS Can Be Expanded to Work in Multiple Domains and for Many Use Cases. OMS has recently been expanded to new areas. Please contact the Open Architecture Management Office to understand whether your application would benefit from OMS.

Universal Command and Control Interface

  • The Universal Command and Control Interface establishes a set of messages for machine-to-machine, mission-level command and control for airborne systems. The UCI vision is to decrease acquisition and operational costs of manned and unmanned systems and enable interoperability.

Universal Command and Control Interface


Frequently Asked Questions

  • Is OMS "All or Nothing?" - NO. OMS offers a Tiered Compliance mechanism that allows a subset of Services and/or Subsystems within the System to be OMS-compliant
  • Is OMS only for new subsystems and services? - NO. Use OMS Adapters to quickly reach OMS-compliance with little or no changes to legacy hardware subsystems or software services
  • Does OMS require contractors to disclose the inner workings of OMS Subsystems and OMS Services? - NO. OMS only requires documentation and disclosure of your external interfaces and resources required
  • Does OMS guarantee "Plug and Play?" - NO. The OMS Standard enables logical "Plug and Talk" for rapid integration
  • Does Use of UCI equal OMS compliance? - NO. There are a number of OMS technical and documentation requirements beyond the use of Universal Command and Control Interface (UCI)
  • Are large UCI messages too big for high-performance systems? - NO. UCI has messages of all sizes, and even large messages can be compressed before transmission; many fields are optional
  • Does OMS eliminate the need for Systems Engineering? - NO. Systems Engineering work is required to employ OMS Services and Subsystems
  • Is OMS only for Linux? - NO. OMS can run on any number of operating systems, such as Windows, Linux, Integrity, VxWorks, etc.; only the Open Computing Environment (OCE) is required to be Linux
  • Is OMS just UCI? - NO. There are four valid OMS Data Exchanges: OMS Messages, Data Transfers, Special Signals, and Security Information Exchanges

Example

Integration of a new Automatic Target Recognition service into an already OMS-compliant weapon system

  • Weapons System has 3 OMS Subsystems/Sensors
    • OMS SAR - produces NITF images and MTI entity tracks
    • OMS EO/IR - outputs video with KLV
    • OMS IRST - produces LOBs and entity track messages
  • The ATR software has been adapted to be an OMS Service
    • ATR Software has been recompiled with provided mission package Critical Abstraction Layer (CAL)
    • Reports health and status via OMS messages
    • Ingests tracks, video, LOBs, and NITF images
    • Outputs new entity tracks that the ATR service has automatically identified in the received products

Integration

  1. The ATR service will automatically receive new events from the OMS Subsystem/Sensors via OMS messages and other OMS data exchanges
  2. Once the ATR service has been installed on the OCE, the UI and the 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

Example

Sharing of Common Operating Picture (COP) data between an air operations floor and a space operations floor

  • Air Operations Center connects and coordinates tasking for two aircraft
  • Space C2 Center coordinates tasking for two space systems
  • All ISR products are handled via OMS messages or data exchanges
  • Completion, status, and management of all tasking is handled via OMS messages

Integration

  1. Machine-to-machine common track, tasking, and ISR product formats allow more robust COP for both centers
  2. Both operations centers develop isolator services to manage data exchanges between the two systems
  3. OMS does not dictate what data exchanges occur between centers - that is based on program needs

Open Architecture Collaborative Working Group (OACWG)

Friendly, Knowledgeable OMS Subject Matter Experts!

  • BAE Systems
  • Boeing
  • Northrop Grumman
  • Lockheed Martin
  • Collins Aerospace
  • Raytheon Technologies
  • General Dynamics Mission Systems
  • Air Force LCMC
  • 76th Software Engineering Group
  • Air Force Research Laboratory

Questions?

Contact Us

Wright-Patterson AFB
Building 11, Area B
Wright-Patterson AFB, OH

If you have questions on OAM, OMS, or UCI, please fill out the form or email us: AFLCMC.XZ.OAMO@us.af.mil

Click here for a printable brochure!

Privacy & Security Notice External Link Disclaimer USA.gov No Fear Act
Current as of 30 June 2023