Open Mission Engine

Open Mission Engine (OMEN) | Area of Interest

Background and problem statement:

Aircrew operating in contested environments lack an integrated, in-flight common operating picture (COP) that combines threat awareness, tactical datalink fusion, and blue-force integration. This problem is especially relevant for large, high-value airlift and tanker aircraft that utilize avionics and mission systems that are optimized for more permissive operations. This requires crews to rely heavily on pre-mission planning products, voice updates, and aging platform-specific displays that cannot dynamically integrate with enterprise battlefield, intelligence, communications, and logistics networks, or ingest mission-relevant updates under degraded, disrupted, intermittent, or limited (DDIL) communication environments.

As operations evolve toward contested logistics and increased threat scenarios, this gap directly degrades aircraft survivability, limits dynamic retasking, and constrains the ability of commanders to project and sustain force.

Solution attributes:

In response to these challenges, DoW aircraft are adopting platform agnostic, open mission systems for networking and interoperability that offer enhanced connectivity and flexibility. These systems include, but are not limited to Software Defined Radios (SDRs), on-board compute and store with aircraft data bus interfaces [e.g., 1553], COTS display systems, software-defined networking (SD-WAN), and sensor/data integration subsystems. To fully capitalize on these emerging open system architectures, the Department seeks prototype solutions for a modular, open mission engine (OMEN) that powers a suite of new mission applications and plugins for aircrew operating in contested environments. This engine should enable rapid development, deployment, and sustainment of mission applications across approved airborne and mobile form factors. The first application on the platform will be an aviation Tactical Moving Map tool that improves in-flight situational awareness, threat understanding, and mission decision support under DDIL environments. The moving map tool will serve as a baseline for future mission capabilities. 

Proposed solutions should address three technical lines of effort (LOEs). Proposals should clarify which of the following LOEs are addressed in their solution.

LOE 1: Open Mission Engine and SDK 

A government-owned, modular application engine with an open Software Development Kit (SDK), published application interfaces (APIs), reusable high-fidelity commercial grade user interface (UI) components, and support for cross-platform deployment. Solutions should support scalable lifecycle management, configuration control, secure software delivery, observability, and operation in connected, disconnected, and DDIL environments. 

LOE 2: Tactical Moving Map Application 

A mission application that fuses relevant operational data into a single aircrew display, including blue-force awareness, threat and airspace overlays, mission updates, and route decision support. Solutions should emphasize usability, performance, offline resiliency, and suitability for operational aviation use. Solutions must demonstrate the ability to integrate legacy map phenomenology (i.e. KML, JSON, COT, XML, etc) and be future-proofed with an open software architecture baseline allowing for easy software integration and adoption across developer communities. A strong focus will be placed on the user interface/user experience (UI/UX) for seamless use in-flight during high-tempo and complex operations.

LOE 3: Data Integration and Interoperability 

A data integration layer that normalizes operational and aeronautical data through a language-agnostic Critical Abstraction Layer (CAL) and modular protocol adapters. Relevant sources include Cursor on Target (CoT) for TAK ecosystem integration, Universal Command & Control Interface (UCI) / J-series pathways aligned to the Department of the Air Force’s Battle Network (DAF Battle Network), Unified Data Library (UDL), and common aviation sources such as DAFIF, D-FLIP, NOTAMs, and related mission data services. Offerors should describe how their architecture ingests, normalizes, exposes, and sustains these data flows in a standards-based, extensible way. The government may furnish selected existing adapters, interfaces, data models, or reference implementations for portions of this stack (to be provided as needed in later phases). 

Key differentiators for proposals include speed to prototype, interoperability with existing DoD systems, compatibility with government DevSecOps and secure deployment pipelines, and ability to team and collaborate with government developers and other industry performers.

Offerors may also propose enabling capabilities that extend the operational utility, deployment, interoperability, management, and sustainment of OMEN and related mission services. Such capabilities may include, but are not limited to, enterprise service proxy and API mediation services; data proxy, local caching, and synchronization services that reduce demand on enterprise data sources while supporting disconnected, intermittent, and low-bandwidth operations; cloud-hosted or hybrid application services for compute-intensive processing, telemetry, and other mission support functions; and system administration, orchestration, and fleet management tools for configuration control, software distribution, observability, cybersecurity, identity and access management, and approved hardware/device management.

Such efforts should be clearly tied to the effective fielding, operation, and lifecycle management of mission applications within contested and DDIL environments, and will be considered for inclusion where they demonstrate clear relevance to mission needs and program objectives.

Upon the successful completion of the prototype project, the competitively awarded OT may result in the award of a follow-on production contract or transaction without the use of competitive procedures.