| For Access Request Instructions for the latest UMAA 6.0 Distribution Statement D release, Click HERE |
The Unmanned Maritime Autonomy Architecture (UMAA – pronounced “you-muh”) is a PEO USC PMS 406 initiative to promote the development of common, modular, and scalable software for Unmanned Maritime Vehicles (UMVs) that is independent of a particular autonomy implementation through the use of standard components. UMVs include both Unmanned Surface Vehicles (USVs) and Unmanned Underwater Vehicles (UUVs). While targeting the maritime domain, many of the interfaces accommodate ground and air domains where applicable.
The underlying objective is to reduce cost for subsequent Navy acquisition programs and accelerate autonomous systems getting out to the fleet. UMAA leverages prior standards work. This includes using the Unmanned Systems (UxS) Control Segment (UCS) Architecture as a framework under which to develop data models and design artifacts. This work began under the UCS Multi-Domain Extension (MDE) which sought to incorporate maritime requirements. In addition, cross domain work done as part of the SAE AS4 Joint Architecture for Unmanned Systems (JAUS) committee is leveraged. UMAA does not purport to supplant existing autonomy solutions, but rather to define how autonomy solutions need to evolve into a standardized component architecture, with each component consisting of a set of services with standard interfaces that may be developed independently similar in concept to a hardware LRU (line replaceable unit). This emables the Navy to transition from the closed vertical solutions of today to component-based development. UMAA addresses the on-board autonomy software and does not address the external command element.
While not specifying a single homogeneous software architecture for all vehicles, UMAA does specify implementation of a component architecture. UMAA requires use of the Object Management Group (OMG) Data Distribution Service (DDS) as a core feature to enable a loosely coupled, but explicitly specified, component architecture. UMAA specifies associated protocols on top of DDS to enable components to interact in a defined manner.
The hyperlinked documents listed below are all available as public release documents and may be freely distributed. The latest UMAA 6.0 ICD and IDL documents listed below were previously released as Distribution Statement D in December 2023. There is no change in the Distribution Statement A June 6 release. The gap in time simply reflects the time for the public release process. The previously released Distribution Statement A versions (UMAA 3.1 and UMAA 5.2.1) are also included for reference but they are superseded by the UMAA 6.0 release. Other extensive supporting information may be found on the Distribution Statement D UMAA website. The Component Definitions document below in the first entry of the table is necessary so that a contractor can know what services are required in a component that an acquisition program requests. The component services may be distributed across the multiple ICDs, but a specified component must only support those services as defined in the Component Definitions document. Other user defined components (non-UMAA or proposed for UMAA) should maximize use of applicable UMAA defined services per the Compliance Specification requirements.
Access to this website may be acquired by following the instructions at the link below this paragraph. As the UMAA website is updated regularly, it’s availability will remain limited as it is not practical for it to be continually reviewed for public release. However, the major documents will continue to appear here when released by the government. DoD contractors are encouraged to obtain access to the website for significant supporting information.
| Title | Description |
| AAC Products Terms of Use (TOU) Agreement | Required industry document to be filled out and sent to PMS 406 to receive access to the Distribution Statement D industry pages. |
| UMAA Compliance Specification (T0300-BE-IDS-010 Rev 1) | This document defines the requirements for compliance with the UMAA standard. |
| UMAA Architecture Design Description (ADD) | This document provides the functional breakout of the Unmanned Maritime Autonomy Architecture |
| UMAA Board Charter | Defines the charter of the PEO USC PMS 406 Unmanned Maritime Autonomy Architecture Board (UMAAB) and its responsibilities to develop UMAA. |
| UMAA Governance | This defines the UMAA board function and work products as defined by the deliverables set out in the PMS 406 UMAA Board Charter. It establishes the operating procedures for all UMAAB activities related to these work products. |
| UMAA IDL Terms of Use Agreement | Terms of Use for the public release software IDL on this web page |
| Document | Description | Version 3.1 | Version 5.2.1 | Version 6.0 |
|---|---|---|---|---|
| Component Definitions | The Component Definitions document defines the services provided and consumed by each standalone component. The component definitions capture the Government’s desired services for each component in a specific acquisition. | N/A | N/A | Comp Defn 1.0 |
| Engineering Operations (EO) ICD | The services and their corresponding interfaces covered in this ICD encompass the functionality to interact with the Hull, Mechanical & Electrical (HM&E) systems of a UMV. | EO ICD 3.1 | EO ICD 5.2.1 | EO ICD 6.0 |
| Maneuver Operations (MO) ICD | The services and their corresponding interfaces covered in this ICD encompass the functionality to control and maneuver an UMV. | MO ICD 3.1 | MO ICD 5.2.1 | MO ICD 6.0 |
| Mission Management (MM) ICD | The services and their corresponding interfaces covered in this ICD encompass services that support performing the overall mission and managing the vehicle in its operating environment. | MM ICD 3.1 | MM ICD 5.2.1 | MM ICD 6.0 |
| Situational Awareness (SA) ICD | The services and corresponding interfaces covered in this ICD encompass the functionality to provide situational awareness for UMV. | SA ICD 3.1 | SA ICD 5.2.1 | SA ICD 6.0 |
| Sensor and Effector Management (SEM) ICD | The services and their corresponding interfaces covered in this ICD encompass the interaction with sensors and effectors that are often referred to as payloads but can also be organic to the vehicle. | SEM ICD 3.1 | SEM ICD 5.2.1 | SEM ICD 6.0 |
| Support Operations (SO) ICD | The services and corresponding interfaces covered in this ICD encompass the functionality to provide overall software support operations for a UMV. | SO ICD 3.1 | SO ICD 5.2.1 | SO ICD 6.0 |
| Communications Operations (CO) ICD | The services and corresponding interfaces covered in this ICD encompass the functionality to provide message traffic buffering and transport over radios to off-board entities. | N/A | CO ICD 5.2.1 | CO ICD 6.0 |
| Experimental Services (EXP) ICD | This document defines a set of experimental services as part of the UMAA that are not required to satisfy UMAA compliance, but are provided to industry for feedback. It provides services that are in an experimental state and are in the process of being developed. | EXP ICD 3.1 | EXP ICD 5.2.1 | EXP ICD 6.0 |
| Interface Definition Language (IDL) zip file with experimental services | This software IDL file provides compile-able software interface definition and may be used in conjunction with the associated license file which must be kept in the code repositories where used. | IDL with EXP 3.1 | IDL with EXP 5.2.1 | IDL with EXP 6.0 |
| Interface Definition Language (IDL) zip file without experimental services | N/A | IDL without EXP 5.2.1 | IDL without EXP 6.0 |
Further information can be obtained by emailing sean.p.allen22.civ@us.navy.mil.