MOSA is a major initiative of the Department of Defense (DoD), and it has been codified into law. According to the Defense Acquisition University (DAU )'s ACQuipedia, “MOSA is to design systems with highly cohesive, loosely coupled, and separable modules that can be competed separately and acquired from independent vendors.”
DAU sees MOSA as “an integrated business and technical strategy to achieve competitive and affordable acquisition and sustainment of a new or legacy system or component over the system life cycle.”
In addition to this being a good idea, it’s the law, specifically Public Law 10 USC 4401. Any major defense acquisition program approved at Milestone A or B after January 1, 2019, must be built using a modular, open-system design whenever reasonably possible, so that the system can evolve incrementally and better support competition, innovation, and interoperability. All other defense acquisition programs are also expected to use this modular open system approach to the greatest extent feasible to achieve the same benefits.
Systems engineering leverages MOSA as a foundational enabler and core technical strategy.
Design Philosophy & Strategy: MOSA outlines the "what"—emphasizing modularity and open standards—while Systems Engineering delivers the "how" by guiding implementation across the system lifecycle.
Architecture Definition: Systems engineers establish the system architecture, ensuring that MOSA’s principles require open, well-defined interfaces between modules (e.g., using FACE for software or VPX for hardware), thereby enhancing interoperability and enabling future upgrades.
Lifecycle Management: Through careful sustainment planning, Systems Engineering benefits from MOSA’s support for easier component replacement, streamlined upgrades, and seamless integration of technologies from multiple vendors, thereby reducing costs and boosting agility.
Requirements & Implementation: System engineers translate MOSA objectives into actionable technical requirements, capturing these steps in the Systems Engineering Plan (SEP) to ensure modularity and openness are built in from the outset.
Tools & Methods: Digital Engineering and Model-Based Systems Engineering (MBSE) tools are instrumental for visualizing, managing, and verifying MOSA implementation, thereby simplifying the integration of modular designs.
Figure 1. Modular Open Systems Approach (MOSA) Architecture Enables Architecture to Operations (DEVOPS)
MS SQL Server: Innoslate’s bottom layer is an SQL database, which currently supports Microsoft SQL Server and PostgreSQL. Any user with access to this database can retrieve their data at any time without a “data lock.”
Innoslate Core: The Innoslate Core is the Java middle layer that manages SQL tables, including their schema extensions.
REST APIs: The Innoslate REST APIs provide a means of communication between the user interface (the Innoslate “Plug-In” written in JavaScript) and the Innoslate Core.
Plug-Ins: These same APIs are open to others to create their own “plug-ins,” as illustrated by the MDEE O&S Plugin UI shown in Figure 1.
Since Innoslate uses these APIs to connect our product components, the users of these APIs can rest assured that we will not be deprecating them anytime soon. Having consistent, open APIs enables the kind of modular software interoperability (data modularity) that the MOSA initiative and law imply.
The second way Innoslate supports the MOSA goals is by using it as a design tool for MOSA-like behavior. Since Innoslate supports both Object (SysML) and Functional analyses (we believe designers need both, as we have seen in hybrid computer languages), designers can take a functional approach first and then use allocation to map functions to different components. Innoslate is based on a hybrid object/functional language, the Lifecycle Modeling Language (LML).
Functional allocation occurs when we establish the “performed by” relationship between Actions (functional elements) and Assets (physical elements). An Asset can be hardware, software, operators, recipients of information, artificial intelligence (aiWARE), and more. Actions exchange Input/Output entities that define part of the interface between Assets. Conduits between the Assets define the physical transfer layer of the interface (Conduits have attributes of capacity and latency). When combined with the size of the Input/Output entities, Innoslate’s simulators will add the transmission delay to the results using the formula below.
Unit checks are automatically run, and errors appear in the simulator console dialog. You can find out more about this in the Innoslate Help Center.
Systems Engineering has always strived to maintain simple interfaces and to meet any available standards. Innoslate also provides unique interface diagrams: Physical I/O Diagram, Layer Diagram, and Interface Control Diagram. We looked at how others often modeled interfaces using drawing tools like Microsoft PowerPoint and Visio, and used those diagrams as a basis for the diagram in Figure 2.
In Figure 2, we can see how the main Conduit (Payload/Bus Interface) is decomposed into different data harnesses and the physical interfaces. The gold Input/Output entities indicate a mismatch between the I/O size units and the Conduit capacity units. The gold exclamation mark (!) in the top right corner provides a dropdown with more information:
Figure 2. Diagram in Innoslate
Innoslate helps you with MOSA in two ways:
1) Its own software architecture enables greater tool and data interoperability, and
2) It provides a powerful design tool to aid in your quest for MOSA. With MOSA’s growing popularity and our many years of experience with MOSA, Innoslate can take your system to the next level.
.svg)
.svg){kind=small}
Steven Dam : 3/27/23 2:20 PM
Most of the community thinks the term “Agile” refers to Agile software development and the “Agile Manifesto.” The Agile Manifesto (Figure 1) is the...
.svg){kind=small}
Andy Tapia : 9/11/24 11:48 AM
In today’s business landscape, organizations are constantly seeking a competitive edge that enhances their efficiency and quality to drive new...
Andy Tapia : 11/4/24 11:38 AM
Data-driven decision-making (DDDM) is emerging as a new beneficial approach for organizations trying to navigate the complexity and uncertainty of...
