How Innoslate Uses the Modular Open Systems Approach (MOSA)

SPEC Innovations has been a proponent of the Modular Open Systems Approach (MOSA) for years before the term was even used. 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) ‘ACQuipedia,’ “MOSA is to design systems with highly cohesive, loosely coupled, and severable modules that can be competed separately and acquired from independent vendors.” Some of the benefits of this approach are more flexibility, competition, conforming to standards, and reducing “vendor lock.” 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 law, specifically Public Law 10 USC 4401: Requirement for MOSA in major defense acquisition programs. It states, “A major defense acquisition program that receives Milestone A or Milestone B approval after January 1, 2019, shall be designed and developed, to the maximum extent practicable, with a modular open system approach to enable incremental development and enhance competition, innovation, and interoperability. Other defense acquisition programs shall also be designed and developed, to the maximum extent practicable, with a modular open system approach to enable incremental development and enhance competition, innovation, and interoperability.”

How does a tool like Innoslate help develop MOSA programs and products?

First, Innoslate is built on a MOSA architecture, shown in the diagram below.

     Figure 1. Modular Open Systems Approach (MOSA) Architecture Enables Architecture to Operations (DEVOPS)

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.” The Innoslate Core is the Java middle layer that manages the tables in SQL, including the schema extensions. The Innoslate REST APIs provide the means to communicate between the user interface (Innoslate “Plug-In” – written in JavaScript) and the Innoslate Core. 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 we use these APIs to work between our portions of the product, 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) the MOSA initiative and law implies.

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 the hybrid computer languages), designers can take a functional approach first and then use allocation to allocate the functions to different components. We can do this because 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 made and errors show up 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 meet any standards available. Innoslate also provides unique interface diagrams: Physical I/O Diagram, Layer Diagram, and Interface Control Diagram. Searching for standards that would support these diagram types led us nowhere. 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 by 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) provides a powerful design tool to aid in your quest for MOSA. With MOSA’s growing popularity and our many years of MOSA practice, Innoslate can take your system to the next level.

Discover how Innoslate can revolutionize your system. Get started with Innoslate today and unlock the potential of your team's productivity. Schedule a live tour now!