# OUSD(R&E) Review of MOSA Tools and Practices # October 2022 Nadine Geier, Director, Systems Engineering, Office of the Under Secretary of Defense for Research and Engineering (OUSD(R&E)) # Background The National Defense Authorization Act (NDAA) of FY 2020 codified the use of Modular Open Systems Approach (MOSA) by requiring the Department of Defense (DoD) to incorporate MOSA into programs and to assess MOSA compliance. These requirements are identified in several documents, such as: 10 USC 4401: Requirement for modular open system approach in major defense acquisition programs; definitions • 10 USC 4402: Requirement to address modular open system approach in program capabilities development and acquisition weapon system design 10 USC 4403: Requirements relating to availability of major system interfaces and support for modular open system approach • DoD Directive 5000.1, Defense Acquisition System DoD 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs and Major Automated Information Systems • DoD Instruction 5000.2, Operation of the Adaptive Acquisition Framework • DoD Instruction 5000.88, Engineering of Defense Systems • DoD Instruction 5000.87, Operation of the Software Acquisition Pathway • DoD Instruction 5000.85, Major Capabilities Acquisition (MCA) • DoD Instruction 5000.82, Acquisition of Information Technology (IT) • DoD Instruction 5000.84, Analysis of Alternatives (AoA) DoD Instruction 5000.01, The Defense Acquisition System • DoD Instruction 5000.75, Business Systems Requirements and Acquisition (BSRA) • DoD Instruction 5000.86, Acquisition Intelligence (IC) • DoD Instruction 5010.44, Intellectual Property DoD Instruction 5137.02, Under Secretary of Defense for Research and Engineering (USD(R&E)) OUSD(R&E), Systems Engineering Guidebook The Services have responded and have made notable progress in incorporating MOSA processes into their respective programs; however, as the Department continues to progress in using MOSA, it seeks greater integration of MOSA standards into program development and transition to model-based systems engineering (MBSE). Although this paper does not include an exhaustive list, it provides a summary of MOSA best practices and tools. # Summary of MOSA Best Practices All Services have incorporated MOSA into their programs to some extent and they continue to expand MOSA integration. Each Service has taken its own approach, so as yet there is limited standardization across the Services. # 1. Vehicular Integration for C4ISR/Electronic Warfare (EW) Interoperability (VICTORY) The goals for developing the VICTORY architecture and standard specifications are as follows: • Improve upon current practices by eliminating, where possible, the practice of “bolt-on” systems. Reduce the size, weight and power (SWaP) and system cost impact of adding electronic systems to vehicles by using shared hardware computing resources and shared displays, as opposed to duplicating resources by dedicating displays to specific C4ISR/EW systems. Create a flexible framework for specifying the required functionality and interfaces of electronic components to simplify integration, enhance interoperability, create increased capabilities for the warfighter, and reduce life cycle costs. • Maximize C4ISR/EW portability by defining: o Open standard interfaces o Open data formats o Open protocols that can be used by vehicle communities. Support current and future information assurance (IA) requirements in U.S. Army ground vehicles. Document a set of shared IA hardware and software components, interfaces, and architectural patterns that enable a system integrator to build a “defense in depth” security design appropriate to a wide array of requirements and security levels. Provide an evolutionary approach toward network-centric C4ISR/EW, starting with interoperability with current systems, and providing a pathway for insertion of new capabilities and technologies. ![**Title Text:** 'VICTORY focuses on adopting/adapting/authoring, validating and managing a Single Authoritative Framework and Standards for vehicular integration' **Left Column (Green Blocks):** A vertical list of boxes labeled: * STRYKER * Abrams and Bradley ECPs * JLTV * CLOE * GCV * mFoCS and JBC-P * COE * Commonality * FACE * Others **Vertical Text:** Next to the green column: 'CONVERGING ON-GOING EFFORTS' **Main Flow Diagram:** A large green arrow points from the left column to the center area. **Central Blocks and Clouds:** 1. **Top Center Box:** * 'Develop Architecture' * 'Baseline common components & standard interfaces to be applied to any tactical vehicle platform' 2. **Top Right Cloud (connected by an arrow labeled 'Leading To'):** * Contains a network icon. * Text: 'Common Displays', 'Distributed Timing', 'Distributed SA', 'Application sharing', 'Etc.' 3. **Middle Cloud:** * Contains three books labeled 'IEEE', 'SAE', and 'MIL-STD'. 4. **Right Box (connected by an arrow labeled 'Available For' from the middle cloud):** * 'Adopt, Adapt and Creat Open Standards' * 'Accepted for publication by recognized standards body' 5. **Bottom Center Box:** * 'PEO/PM Implementation' * 'Strategize acquisition path forward' 6. **Bottom Right Cloud:** * Text: 'C4ISR', 'EW' * Contains images of military vehicles.](.mosa-tools-practices-2022/382b3e950a38834cf74138168e5d733d008e84cbaebc5974f8cd98697ec7dc6b.jpg) Figure 1: VICTORY Execution Strategy VICTORY uses a data bus-centric design. Data from sensors, the platform, and systems is published on the VICTORY Data Bus (VDB). In some cases, the publication on the VDB may be secondary to high-performance control or processing loops, but the data should be accessible from nodes attached to the VDB (in accordance with security requirements). Programs should avoid tight coupling of sensors and their processing functionality unless a performance requirement would otherwise be unattainable. Data from other types of buses (e.g., Controller Area Network [CAN]) should be published onto and accessed via the VDB. Configuration, control, status reporting, and fault management interfaces must be accessible via the VDB. This includes interfaces to the VDB components, C4ISR/EW systems, and platform systems. Message formats and protocols for all data, control, configuration, and status interfaces must be open. Applications should access data, control, configuration, status reporting, and fault management interfaces via the VDB interfaces. # 2. Sensor Open Systems Architecture (SOSA) The purpose of SOSA is to: Promote portability and create product families across the sensor, radar, signals intelligence (SIGINT), EW, electro-optical / infra-red (EO/IR) and communications community. Promote the development of reusable sensor components applicable to a broad class of sensors and host platforms. Include business processes to adapt the procurement to a MOSA reality, protect industry intellectual property (IP), and create incentives for industry to invest in broadly applicable technologies that can be applied to a variety of sensors. • Allow capabilities to be developed as components that are exposed to other components through well-defined (key) interfaces ![**Legend** * EM Wave * Physical Mounting * Power * Analog * Digital * Cable Connector **Blocks and Connections** * **Electromagnetic Environment** (Cloud shape): Two blue lines (EM Wave) extend downward to the 'SOSA Sensor Element' blocks in the middle and right sections. * **Non-SOSA** (Rectangle): Connected downward to **Pod (SOSA Host)** via four lines: Black (Physical Mounting), Purple (Power), Red (Analog), and Green (Digital). * **SOSA Sensor** (Orange text): A label outside an orange dashed box that encloses the sensor elements. * **SOSA Sensor Element** (Rectangle - Middle Group): * Connected horizontally to its right neighbor (**SOSA Sensor Element**) via Black, Purple, Red, and Green lines. * Connected downward to **Pod (SOSA Host)** via Black, Purple, Red, and Green lines. * **SOSA Sensor Element** (Rectangle - Right Group, Left): * Connected horizontally to its right neighbor (**SOSA Sens or Element**) via Black, Purple, Red, and Green lines. * Connected downward to **Platform (SOSA Host)** via Black, Purple, Red, and Green lines. * **SOSA Sens or Element** (Rectangle - Right Group, Right): Connected downward to **Platform (SOSA Host)** via Black, Purple, Red, and Green lines. * **Pod (SOSA Host)** (Rectangle): Connected downward to **Platform (SOSA Host)** via Black, Purple, Red, and Green lines. * **Platform (SOSA Host)** (Rectangle): Receives connections from the right-side sensor elements and the Pod. **Note** * 'NOTE: Elements and relationships shown are optional; omit unused elements and relationships'](.mosa-tools-practices-2022/89d3ed1ee275670c92312246deebe55d4ddd7a58c86393dfda530af66ca8cfa4.jpg) FIGURE 2: SOSA Systems Interface Description (SV-1) These objectives are accomplished through a SOSA Consortium which consists of Government stakeholders and industry participants. The SOSA Consortium includes five working groups: Architecture, Business, Electrical/Mechanical, Hardware, and Software. The Consortium defines requirements for SOSA conformance. # SOSA goals include the following: Open: Vendor and platform agnostic open modular reference architecture and business model. • Standardized: Software, hardware, and electrical-mechanical module interface standards • Harmonized: Leverage existing and emerging open standards scope • Aligned: Consistent with DoD acquisition policy and guidance • Cost-Effective: Affordable C4ISR systems including lifecycle costs • Adaptable: Rapidly responsive to changing user requirements # 3. Future Airborne Capability EnvironmentTM (FACETM) FACETM was developed to establish a standard common operating environment to support portable capability-based applications across DoD avionics systems, reduce life cycle costs and time to field, obtain industry and DoD program management endorsement, and facilitate conformance with standards to maximize interoperability among applications within the avionics system. ![This diagram is titled 'War-Fighting Platform' and depicts two parallel stacks of components connected to a bottom network. **Left Stack:** * **Top:** Two yellow rounded rectangles side-by-side labeled 'Portable FACE application'. * **Middle:** A green rounded rectangle labeled 'FACE Computing Environment'. * **Bottom:** A blue 3D rectangular block labeled 'Existing Computer Hardware'. **Right Stack:** * **Top:** A single yellow rounded rectangle labeled 'Portable FACE application'. * **Middle:** A green rounded rectangle labeled 'FACE Computing Environment'. * **Bottom:** A blue 3D rectangular block labeled 'New Computer Hardware'. **Bottom Connection:** * A horizontal blue cylinder at the very bottom is labeled 'Avionics Networks'. * Vertical lines connect the bottom of the 'Existing Computer Hardware' block and the 'New Computer Hardware' block directly to the 'Avionics Networks' cylinder.](.mosa-tools-practices-2022/f9d30cb8166de9f3ffe35d8a2f106b341b3b0711cdba0d7d71bcad377d03d193.jpg) FIGURE 3: FACETM Technical Strategy Program oversight is provided by a consortium of Government stakeholders and industry participants which provides: Openness Balance of interest Due process • An appeals process Consensus Enabler for consortium participation by US agencies • Foundation of consortium status under National Cooperative Research and Production Act # 4. Open Mission Systems (OMS) The Open Architecture Management Office (OAMO) maintains and manages the OAM Standards: OAM Standards include: o Open Mission Systems (OMS) Standard o Unmanned Aerospace Systems (UAS) Command and Control (C2) Initiative (UCI) Standard. Open Architecture Collaborative Working Group (OACWG) is the OAMO-selected and funded working group of industry participants that perform the day-to-day activities within the OAM program The Common Governance Board (CGB), which consists of OAMO and OACWG participants reviews, adjudicates, and prioritizes changes that impact the OAM Standards ![This diagram illustrates the architecture of an **OMS Mission Package**. **Central Component:** A yellow horizontal block at the center is labeled **OMS Platform's Abstract Service Bus (ASB) & Critical Abstraction Layer (CAL)**. It serves as the central hub connecting various services and capabilities. **Top Layer Connections (Bidirectional):** The central bus connects to the following blocks: * **OMS SAR** * **OMS EO/IR** * **OMS IRST** * **User Interface Service** (located inside a green box labeled **Operator Console**) * **Health and Status** (located inside a grey box labeled **Open Computingenvir.**) * **OMS ATR** (located inside the same **Open Computingenvir.** box) **Bottom Layer Connections (Bidirectional):** The central bus connects to the following blocks: * **Time** (located inside a grey box labeled **Core Capabilities**) * **Nav** (located inside the **Core Capabilities** box) * **Data Storage** (depicted as a cylinder) * **Air Vehicle Isolator** (located inside a blue box labeled **Isolation**) * **Stores Isolator** (located inside the **Isolation** box) **External System Connections:** * **Stores Management System** connects to the **Stores Isolator**. * **Vehicle Management System** connects to the **Air Vehicle Isolator**.](.mosa-tools-practices-2022/0e5247d4a6534228d090b0324884f7d133833c292d2e1b8be1ee751de856bd88.jpg) FIGURE4: OMS Example - Automatic Target Recognition The OMS provides requirements, architecture definition, detailed specifications and examples. It defines: OMS architecture and rules for compliance • OMS as a consensus-based, non-proprietary, open architecture for integrating subsystems and Services into airborne platforms OMS reference architecture which includes a set of architectural elements or building blocks, used to document the key interfaces required of OMS components # 5. C4ISR/EW Modular Open Suite of Standards (CMOSS) CMOSS consists of a suite of layered standards that are individually useful and can be combined to form a holistic converged architecture. It provides pools of sensors and processors available to multiple applications, facilitates rapid insertion of new hardware and software into systems and facilitates shared hardware to reduce SWaP requirements. ![Software Layer MORA Modular Open RF Architecture Functional Decomposition Hardware Layer OpenVPX VITA Open Standards, Open Markets Network Layer](.mosa-tools-practices-2022/f8221b74cdf180839bf3c503dae50186cf93c6c20a90a4a7718f61454732f37b.jpg) FIGURE 5: CMOSS Layered Standards Software Layer: o Enables portability of software applications across hardware platforms o Software framework selected based on mission area • Functional Decomposition: o Allows for sharing of radio frequency (RF) resources such as antennas and amplifiers o Defines interfaces between RF functions and components o Enables best of breed along with rapid component upgrades • Hardware Layer: o Enables capabilities to be fielded as cards in a common chassis o Common form factor including physical, electrical, and environmental specifications Network Layer: o Provides connectivity within the platform and defines interfaces between capabilities o Enables legacy systems to share Services within the converged architecture # 6. Hardware Open Systems Technologies (HOST) Navy Hardware Open Systems Technologies (HOST secure network implements open architecture. This device operates in real-time (or near real-time) without any latency generated from the open architecture design and without an increase in SWaP-C requirements. This server is capable of hosting traditionally developed software as well as software developed in accordance with the FACETM technical standard. The server is used as a surrogate to demonstrate component portability with an existing government HOST conformant computer, as well as to validate the design meets real time (or near real time) latency standards. HOST is intended to reduce the variability in existing standards (such as VME and OpenVPX) to enable portability of components within the computing architecture. ![The image displays a block diagram labeled **HOST Enclosure**. **Inside the HOST Enclosure:** * On the left, a list of **Resources** (General, Processing, I/O Processing, Image Processing, Data Storage) is connected by a bracket to a dashed rectangular box. * Inside the dashed box are vertical blocks labeled **Module 1**, **Module 2**, **Module 3**, and **Module N** (with ellipses indicating intermediate modules). * Double-headed arrows connect vertically from each module down to a horizontal line labeled **Transmission Components**. * A single arrow originates from the bottom of **Module 1**, extends horizontally to the right beneath the other modules, and points into a vertical rectangular block labeled **External Interfaces**. * Below the modules, a bracket labeled **Transmission Interfaces:** groups a list of items: **System Communication**, **System I/O Routing**, **External I/O**, **System Power Distribution**, and **System Utility**. **Outside and to the Right:** * The **External Interfaces** block points via a large arrow to a cloud shape labeled **Target System**. * To the right of the **External Interfaces** block, a bracket labeled **External I/O Transmission Interfaces** points to it.](.mosa-tools-practices-2022/556f1f372e369a3a3a404fb0819688e0f46e0a2e58a18f4a17f5c13c12e37a73.jpg) FIGURE 6: HOST Components # 7. Software Communications Architecture (SCA) The Software Communications Architecture (SCA) is an open architecture framework that promotes development of software defined systems by identifying the boundaries for software applications and their interactions with the physical hardware. The SCA facilitates portability, interoperability and configurability of software and hardware components used in embedded systems. ![Based on the provided flowchart, here is an accurate and concise description of the labeled blocks and their connections: **Top Layer (Non-CORBA Components)** * **RF**: A single block on the far left. * **Non-CORBA Physical Component**: Connected bidirectionally to the **RF** block and bidirectionally to the **Non-CORBA MAC Component**. * **Non-CORBA MAC Component**: Connected bidirectionally to the **Non-CORBA Physical Component**. * **Non-CORBA Security Component**: Located centrally in the top row. * **Non-CORBA I/O Component**: Located on the far right of the top row. **Middle Layer (Component/Adapter Blocks)** This layer consists of a horizontal sequence of blocks connected to the top layer and the framework layer below: * **Physical Component** and **Physical Adapter**: Connected to the **Non-CORBA Physical Component**. * **MAC Component** and **MAC Adapter**: Connected to the **Non-CORBA MAC Component**. * **Link, Network Components**: Appears twice in the row (once between the MAC adapters and the security block, and once between the security block and the I/O adapters). * **Security Adapter**: Appears twice, flanking the **Security Components** block. The **Non-CORBA Security Component** connects to this group (**Security Adapter**, **Security Components**, **Security Adapter**). * **I/O Adapter** and **I/O Components**: Connected to the **Non-CORBA I/O Component**. **Framework Layer** * **Core Framework IDL**: A long horizontal bar connecting the middle layer to the bottom stacks. * **('Logical Software Bus' via CORBA)**: Connected to the **Core Framework IDL**. **Connections (APIs)** Double-headed arrows connect the Middle Layer blocks to the **Core Framework IDL** via labeled APIs: * **Physical API** (between Physical blocks and Framework) * **MAC API** (between MAC blocks and Framework) * **LLC API** (appears twice, connecting the **Link, Network Components** blocks to the Framework) * **Security API** (between Security blocks and Framework) * **I/O API** (between I/O blocks and Framework) **Bottom Layer (Hardware/OS Stacks)** Two identical stacks of blocks connect bidirectionally to the **Core Framework IDL**: * **Left Stack (Secure):** * **CORBA ORB and Services (Middleware)** * **CF Services and Applications** * **Operating System** * **Network Stacks and Serial Interface Services** * **Board Support Package (Bus Layer)** * Labeled below as: **Secure Hardware Bus** * **Right Stack (Nonsecure):** * **CORBA ORB and Services (Middleware)** * **CF Services and Applications** * **Operating System** * **Network Stacks and Serial Interface Services** * **Board Support Package (Bus Layer)** * Labeled below as: **Nonsecure Hardware Bus**](.mosa-tools-practices-2022/32321b6588d36818a1d37c742dbf59f99f7e911220250d57dcc96635f7c4551a.jpg) FIGURE 7: SCA Components and Interfaces The SCA was originally developed by the U.S. military’s Joint Tactical Radio Systems (JTRS) to standardize the way in which Software-Defined Radios (SDR) for the U.S. armed forces were to be built. Since then, the SCA has evolved with the input of the international radio community. # Summary of MOSA Assessment Tools All tools appear to contain subjective or qualitative criteria. Some provide scalars to convert the qualitative assessments into quantitative outcomes. Of all the tools/processes studied, it appears the 1. Modular Open Systems Approach Program Assessment Tool (PART), Open Architecture Assessment Tool (OAAT) and open architecture, position, navigation and timing (OA PNT) provide criteria that align well with the criteria identified in policy and guidance. In addition, they are some of a few tools that attempt to quantify a program’s compliance with MOSA standards. # 1. Modular Open Systems Approach Program Assessment Tool (PART) PART was adapted from the former Office of Management and Budget Program Assessment Rating Tool and is referenced in the Army’s Modular Open Systems Approach (MOSA) Implementation Guide as their assessment tool. The MOSA PART presents a list of 24 questions for consideration and scoring. These will assist program managers and their teams by prompting consideration of MOSA planning, implementation, self assessment, and reporting. Each of these questions is scored and recorded in four categories: • Progress or Status (Planned, Achieved, or N/A) • Extent to which each is achieved (None, Little, Moderate, Large) • Rational or Explanation (Narrative of the status evaluation) • Supporting Evidence or Date The tool provides instruction on its use, provides prompts to assist with scoring and recording assessment justifications, and citations of objective quality evidence in support of the scoring. PART assists program managers to identify the degree of their MOSA implementations according to the Open Systems Joint Task Force five key MOSA pillars: Modular Design, Key Interfaces, Open Standards, Conformance, and Enabling Environment. # 2. Open Architecture Assessment Tool (OAAT) OAAT is an Excel tool designed to assist Navy program managers assess the openness of their programs. It aligns to the Open Architecture Assessment Model (OAAM) as approved by ASN (RDA) and provides a reproducible and objective method of conducting program assessments. Version 3.0 of the tool incorporates changes that streamline and clarify the questions to make them easier to understand, increase tool usability using modified answered selectors, and provide end users visibility into the OAAT score capping mechanism. The OAAT is used to assess a weapon system’s degree of openness in terms of the open architecture maturity of that specific weapon system program and its systems. Openness refers to both business and technical characteristics of weapon systems that support modular design, interoperability, and commercial standards. A higher degree of openness both supports weapon system programs in terms of competition for development and support, as well as facilitates rapid technology insertion. Specifically, the OAAT is an analytical tool that evaluates responses to a set of interrelated questions to provide program officers with an objective and evidence-based assessment of the degree that a program exhibits openness along two axes: Business/Programmatic and Technical. The degree to which openness is implemented is presented in terms of business/programmatic and technical criteria. The business/programmatic dimension criteria include questions that address: Open Architecture, Modular Open Design, Interface Design and Management, Treatment of Proprietary Elements, Open Business Practices, Peer Review Rights, and Technology Insertion. The programmatic questions refer to the processes and documentation employed to acquire and manage systems. # Business Areas Open Systems Approach Open Architecture Open Modular Design • Interface Design and Management Treatment of Proprietary Elements Open Business Practices • Peer Review Rights Technical Insertion Commercial Standards Compliance # Technical Areas • Design Tenet: Interoperability • Design Tenet: Maintainability • Design Tenet: Extensibility • Design Tenet: Composability • Design Tenet: Reusability • General Design Tenet The technical dimension criteria cover the essential OA design tenets of Interoperability, Composability, Reusability, Maintainability and Extensibility. The technical questions refer to the technical features of computing environments and application software. The technical areas measured are described below (Naval Open Architecture Enterprise Team, 2006): Interoperability: How readily can the program’s separate systems exchange information and appropriately use each other’s functional capabilities? Maintainability: What architectural characteristics address obsolescence and provide for timely technology refresh, fixes, and upgrades? Extensibility: Does the program follow a well-defined system engineering process for implementing capability extension? Composability: Are the program’s systems capable of being highly modular and having minimal dependencies (loosely coupled) so they can be readily combined with other modules to provide new types of functionality? Reusability: Are the assemblies that are candidates for reuse readily available, certified for reliability and performance, and easily obtained for reuse? MOSA: What is the program’s level of MOSA Compliance? The OAAT provides an OA Assessment Model (OAAM) that displays the program’s current state with respect to business and technical degrees of openness. Each of these areas (business and technical) is rated on a scale of 0 to 4. The scores for these two dimensions are plotted on the OAAM, which provides a graphical depiction of the current state of OA maturity and also identifies the progression toward higher levels of openness. The program manager then uses the results of the OAAT assessment to help improve the program with respect to Naval Open Architecture. Using the OAAM, a program’s degree of openness can be rated using the programmatic and technical levels as shown below. # Programmatic Levels • 4: Open and Net-Centric 3: Common • 2: Migrating to Openness 1: Connected 0: Isolated # Technical Levels • 4: Enterprise • 3: Common • 2: Layered and Open • 1: Layered • 0: Closed # 3. Key Open Subsystem (KOSS) Tool The Naval Air Systems Command (NAVAIR) has developed the Key Open Subsystems (KOSS) tool to evaluate which system components may be most susceptible to vendor lock because of proprietary interfaces. This tool offers one method for determining the most important subsystems/components for which the program office should seek license rights. The KOSS Tool can identify those important system components that may become obsolete or require upgrades more often than others. This tool can help a program to evaluate which key system components may prove most susceptible to the negative impacts of a vendorlocked situation. In short, if only one vendor can replace or upgrade those key components, that de facto monopolist may be able to exert excess negotiating leverage over replacement or upgrade prices. Furthermore, the monopolist vendor’s solutions may be inferior to those on the open market. To combat these problems, the KOSS tool may help the Government identify any key component interfaces that follow proprietary standards and should be modified to use open standards, thus ensuring that other qualified vendors can provide replacement components. By highlighting these key components, KOSS allows a program to focus its efforts on acquiring IP rights only for those highly volatile areas of the system and to conserve resources by disregarding IP for other, less important system components. # 4. Air Force Systems Engineering Assessment Model (SEAM) The primary purpose of SEAM is to promote the application and use of standard systems engineering processes across the Air Force and to improve the performance of these processes through continuous process improvement (CPI). AF SEAM was developed to support both self-assessment and independent validation of systems engineering process implementation. While the tool assesses the existence of SE process work products (i.e. CONOPS, plans, technical documents, etc.) it does not assess the outcomes delivered to the customer. SEAM is a Microsoft Excel model of systems engineering based on a set of best practices developed by representatives from Air Force acquisition programs. It is a self-assessment tool to ensure a consistent understanding of systems engineering, ensure core systems engineering processes are in place and being practiced, document repeatable systems engineering best practices across the Air Force, identify opportunities for continuous improvement, improve program performance and reduce technical risk. SEAM is not an appraisal of product quality or a report card on people or the organization. Air Force SEAM defines 10 standard systems engineering process areas, lists associated goals under each process area and provides associated specific and generic practices. These include: a. Configuration Management b. Decision Analysis c. Design d. Manufacturing e. Project Planning f. Requirements g. Risk Management h. Transition, Fielding and Sustainment i. Tech Management and Control j. Verification and Validation # 5. Open Architecture Position, Navigation and Timing (OA PNT) The U.S. military and civil position, navigation, and timing (PNT) community has long sought a standard, or open architecture to facilitate collection and dissemination of PNT data to augment or replace the current GPS timing/navigation standard. The PNT Chief Architect and Stakeholder Working Group define the DoD-level PNT Open System Architecture to: Define a common lexicon/definitions to guide DoD response to threats; development of strategy/doctrine; development of new capabilities; infrastructure improvements (e.g., modeling and simulation); and development of dependent systems (e.g., C2), training systems, tools, and the industrial base. Define DoD-level reference architecture to include data structure standard, interface control standard, DISR reference standards, Services and a capabilities baseline for a unifying vision for interoperability and integration of PNT capabilities across DoD. MOSA compliance is assessed via the OA PNT tool. OA PNT is an Excel-based Criteria Scoring Matrix similar to the OUSD (R&E) recommended process (see Tool 6). Programs or projects are scored on a 1-5 qualitative scale, with 1 being the qualitative minimum score and 5 being the qualitative maximum score. Major evaluation criteria include: a. Standard Characterization b. Architecture Characterization c. Services/Functionality d. Data Model Characterization These are further broken into several sub-criteria. # 6. OUSD (R&E) Recommended Process OUSD (R&E) has published “OUSD(R&E) Refines MOSA Assessment Criteria” in which it recommends a standardized, repeatable process that employs the 5 MOSA Pillars as the topmost criteria in a hierarchical structure: Establish Enabling Environment Employ Modular Design Designate Key Interfaces Select Open Standards • Certify Conformance OUSD(R&E) recommends using a Multi-Attribute Utility Theory (MAUT) for scoring. MAUT is a structured methodology designed to handle the tradeoffs among multiple objectives. Many MOSA models/tools used by the Services today use this process to provide a quantitative MOSA evaluation of their program(s). Although several COTS tools are available to conduct MAUT, a simple Excel spread sheet is often the preferred tool. The approach requires the reviewer to include all the pillars in an assessment. Criteria should be evaluated on a 0-5 scale to allow a quantitative scoring and life-cycle measurement in which 0 represents no/minimal capability and 5 represents total/maximum capability for that criterion. # Model-Based Systems Engineering Currently, the Department of Defense Architecture Framework (DoDAF) is used for development of Architectural Descriptions in the DoD. It also provides extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the Department. However, DoDAF relies on standalone (discipline-specific) models whose characteristics are shared primarily through static documents. This has led to a more formalized modeling practice of model-based systems engineering (MBSE). MBSE is the formal application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE moves toward a shared system model with remaining discipline-specific models providing their characteristic information in a mathematically rigorous format. All disciplines “view” a consistent system model. MBSE includes three core elements: a modeling language, a modeling method and a modeling tool. The modeling language defines the grammar for a modeling effort. The modeling method defines the framework and set of tasks for a modeling team. The modeling tool is the actual software used to coordinate and implement the MBSE model. MBSE employs the Unified Modeling Language (UML) or Systems Modeling Language (SysML). The Object Management Group® Systems Modeling Language (OMG SysML™) is a general purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. It provides graphical representations with a semantic foundation for modeling system: Requirements, Behavior, Structure and Parametrics. At this time, the CAMEO Systems Modeler (CSM) appears to be the modeling tool of choice. Models developed contain several structural diagrams (Block Definition Diagrams (BDDs) and Internal Block Diagrams (IBDs)) and dozens of State Machine Diagrams (STMs). CSM also includes hundreds of Activity Diagrams (ACTs) and multiple simulation execution environments for each instantiation requested. Acronyms
AADLArchitecture Analysis and Design Language
APIApplication Programming Interface
ASN (RDA)Assistant Secretary of the Navy for Research, Development, and Acquisition
CI/CDContinuous Integration/Continuous Delivery
CSMCAMEO System Modeler
DASDefense Acquisition System
DISRDefense Information Technology Standards Registry
DoDAFDepartment of Defense Architecture Framework
FIPSFederal Information Processing Standard
IPIntellectual Property
JTRSJoint Tactical Radio Systems
MAUTMulti-Attribute Utility Theory
MBSEModel-Based Systems Engineering
MOEMeasure of Effectiveness
MOPMeasure of Performance
MOSAModular Open Systems Approach
MOSWGModular Open Systems Working Group
NDAANational Defense Authorization Act
NDIANational Defense Industrial Association
OAOpen Architecture
OpenVPXOpen VME, PCI-X
OSAOpen Systems Architecture
OSJTFOpen Systems Joint Task Force
OUSD(R&E)Office of the Under Secretary of Defense for Research and Engineering
PCI-XPeripheral Component Interconnect eXtended
SESystems Engineering
PNTPosition, Navigation, and Timing
RFRadio Frequency
SWaPSize, Weight and Power
UMLUnified Modeling Language
VMEVirtual Machine Environment
# References 10 USC Section 244, “Undefinitized Contractual Actions.” 10 USC 2446a, “Requirement for Modular Open System Approach in Major Defense Acquisition Programs.” 10 USC 2446b, “Requirement to Address Modular Open System Approach in Program Capabilities Development and Acquisition Weapon System Design.” 10 USC 4403, “Requirements Relating to Availability of Major System Interfaces and Support for Modular Open System Approach.” Architecture Committee Meeting. MOSA Metrics Sub-Committee, NDIA Systems Engineering Architecture Committee, March 2022. Burnside, Bruce. “Enabling Modular Open Systems Approach (MOSA).” Tiger Team report, March 2021. CAMEO Systems Modeler User Guide v18.1, No Magic, Inc. 2015 CMOSS - C4ISR/EW Modular Open Suite of Standards, Curtiss-Wright, April 2019 Conway, Melvin E. “How Do Committees Invent?” Datamation 14(5):28–31 (April 1968). DoD Directive 5000.01, The Defense Acquisition System (DAS). Office of the Under Secretary of Defense for Acquisition and Sustainment, September 9, 2020. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/500001p.pdf DoD Directive 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs. Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics, April 5, 2002, https://www.acqnotes.com/Attachments/DoD%20Directive%205000-2-R-new.pdf. DoD Instruction 5000.02, Operation of the Adaptive Acquisition Framework. Office of the Under Secretary of Defense for Acquisition and Sustainment, January 23, 2020. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500002p.pdf DoD Open Systems Architecture Contract Guidebook for Program Managers. Version 1.1. DoD Open Systems Architecture Data Rights Team, May 2013. https://acc.dau.mil/osaguidebook. Engineering of Defense Systems. Office of the Under Secretary of Defense for Research and Engineering, 2022. FACE 101, NAVAIR Public Release 2013-920, March 2019 Implementing Modular Open Systems Approach in Army Acquisition Programs and Middle Tier of Acquisition Efforts. Policy Memorandum. Department of the Army, Office of the Assistant Secretary of the Army, Acquisition, Logistics, and Technology, March 2020. Model-based Systems Engineering (MBSE) 101, INCOSE International Workshop, January 2014 Modular Open Systems Approach (MOSA) Implementation Guide. Version 1.1. Office of the Chief Systems Engineer, ASA(ALT)/OCSE, June 2020. Modular Open Systems Working Group (MOSWG) Meeting. Slides 25-34. Office of the Executive Director for Systems Engineering and Architecture, February 2022. Modular Open Systems Approach (MOSA) Reference Frameworks in Defense Acquisition Programs. Office of the Under Secretary of Defense for Research and Engineering, May 2020. https://ac.cto.mil/wp-content/uploads/2020/06/MOSA-Ref-Frame-May2020.pdf Naval Open Systems Architecture Questionnaire and Guidance. Open Architecture Enterprise Team, June 2014. OMS/UCI Overview, Booz|Allen|Hamilton, November 2017 OUSD(R&E) Refines MOSA Assessment Criteria. May 2022 Sensor Open Systems Architecture (SOSA), Booz|Allen|Hamilton, January 2018 SOSA, CMOSS, HOST and Military Open Standards, Electronic Design February 2019 Vehicular Integration for C4ISR/EW Interoperability (VICTORY), Framework Product Development, Maturation, Approval and Compliance Verification Process, Standards Support Office, March 2016. [🔗 Link to the original document](.mosa-tools-practices-2022/mosa-tools-practices-2022.pdf)