MOSA Standards Gain Momentum in the Market

SOSA announces SOSA 1.0

If you are still trying to figure out what the 3rd “C” in C4ISR is, this is for you. Acronyms should not slow you down as they are prevalent and many still in use have lost their original meaning. An example that comes to mind is the VME Inter- national Trade Association that we now refer to as VITA. The ideas are to introduce you to some new standards, why they came about, and their importance to the segments of the market they address.

The idea of an open standard is nothing new and has throughout history been driven by the idea of inoperability, lowering costs, and broad- ening the availability to multiple sources. His- tory is littered with Open Standards that never reached critical mass or found themselves not advancing with the times. It is tempting to go through the history of architectures such as Mul- tibus, Versabus, VME, G64, Futurebus, Compact PCI along with the many others to review what precipitated their rise and fall, but we should probably look to the future.

The move today to an open standard is very similar to the needs of history, but with one important distinction. In the past, the vendor community would join ranks and create an open standard that they felt might best advance their companies profit motives. This created debates about connectors, CPU choices, and other fea- tures that were at times politically charged to advance a companies IP expertise. Today users within the Department of Defense and to a less- er degree the vendors are driven by the application to employ advanced architectures that are SWAP-C optimized.

This inverted style has challenged the norms and has created a whole new library of open standards described within MOSA or Modular Open Systems Approach. The idea is to address the applicational needs of the modern, joint domain battlefield with advanced open architectures that are defined and proven. To cherry-pick those that are optimized to the applicational needs of the market.

But before we get ahead of ourselves let’s look at the MOSA. MOSA is not by itself a technical standard. It should be thought of as a technical and acquisition strategy for the future warfighter. A few years ago, the DoD issued a memorandum entitled “Modular Open Systems Approaches for our Weapon Systems is a Warfighting Imperative.” Within the memo, it described how vital to our success the use of open standards would be. It went on to mandate that MOSA support- ing standards be included in all future requirements for weapon systems. Now by itself, this is not too earth-shaking as it was vague on details and seemingly stated the obvious advantages of adopting an open architecture for defense compute platforms. But things accelerated quickly as several supporting standards began to address the specific applicational needs. These are:

• SOSA – The Open Group Sensor Open System Architecture
• FACE – Future Airborne Capability Environment
• VICTORY – Vehicular Integration for C4ISR/
• EW Interoperability
• CMOSS – C5ISR/EW Modular Open Suite of Standards
• GVA – Generic Vehicle Architecture
• HOST – Hardware Open Systems Technologies
• MORA – Modular Open Radio Frequency Architecture
• OMS/UCI – Open Mission Systems/Universal Command and Control Interface

In developing MOSA and the underlying standards, starting from a white sheet of paper to re-create the wheel was not seen as a winning strategy. What was decided is that they would draw upon industry standards already in existence to rally the best possible. This strategy seemed sound enough when determining an interconnect, but in addressing a bus architecture or form factor, the political landscape had the potential to grow exponentially. It is unclear how disputes about future iterations of a standard will be decided. Will the MOSA Technical working groups mandate future feature sets to the underlying standards group, or will a harmonious relation emerge?

On the other side of the equation, is the adoption across all services. The needs of the Space Force are significantly different attributes than those of the Navy. Will the ability of the stan- dards to draw from a plethora of proven standards take the day, or will this be their downfall?

The idea that the delta of applicational needs from one space to other leads to such a diluted standard as to leave it inconsequential. In nu- merous conversations on the topic, there was no clear consensus. It was clear that the DoD was incorporating MOSA compliance into RFQs, but it wasn’t clear whether the standard definitions would meet the array of applications that need to be addressed.

The importance of SOSA

Sensor Open Systems Architecture recently released SOSA 1.0 this past November. Defining a common technical standard defines common software and hardware components for seniors processing systems at the edge. The standard provides a hardware foundation for the next gen- eration defense capabilities involving Artificial Intelligence and Machine Learning. In complimenting industry standards such as VITA’s Open VPX, SOSA has found numerous vendors who want to pursue opportunities that require SOSA compliance. Members of SOSA on next page.

Addressing Avionics with FACE

The Future Airborne Capability Environment addresses the same need for open standards to support inoperability for lower costs of imple- mentation. Focused specifically on the needs of Aircraft, FACE too has seen several vendors with previous avionics experience, rush to affirm their products followed the new specification.

Green Hills Software, for example, has added Intel® architecture to the certifications of con- formance for its INTEGRITY®-178 Time-Variant Unified Multiprocessing (tuMP™) RTOS to FACE Technical Standard edition 3.0. The certification covers both the Safety Base and Security profiles and includes verification for C, C++, and Ada support for both profiles. The INTEGRITY-178 tuMP RTOS was the first software component of any type to be certified conformant to edition 3.0, and this latest certification extends that commit- ment to open standard certification. Members of FACE on page 23.

In Conclusion Open architectures have ebbed and flowed throughout our history as technologies have evolved. For a standard to thrive it must meet the broadest possible set of applications with-out diluting its technical merit. It must meet the applicational needs of the market without costly and unnecessary features. This same course of action has occurred before with standards such as ATCA and VME, but not seemingly with the broader support that MOSA is enjoying. In each case, the life cycle of these standards was impact-ed by a different threat. In the case of ATCA, the specification was so broad and feature-rich, that the average sale price became prohibitive in the market. As for VME, the strength of knowing what it was and wasn’t allowed it to have a long and successful history, but in the end, it fell to the side in favor of technical advancements better suited to a new architecture.

The lofty goals of open standards of the past to become the Swiss Army Knife of the military has had their successes. The ambitious goal of MOSA to address the entire applicational needs of the military space has significant challenges that will be tested as commercial advancements may challenge their direction. Questions as to how systems will evolve at the edge, how Infer-ence-based architectures and Computational Storage will integrate, along with many others, all hang over the traction and longevity of MOSA.