These two military-focused architectural standards provide approaches to system-level development and sensor-centric designs.
The military services have long had a dilemma with respect to technical standards and the long-term viability and compatibility of associated systems. On one side, they would like to be able to leverage the latest, newest technologies for the performance and cost benefits that they bring (at least in theory), ranging from large-scale developments down to basic components such as the latest graphics processing unit (GPU) IC or even the ubiquitous USB interface in its many forms.
Further, the push for the use of commercial off-the-shelf (COTS) components and subsystems is certainly a recognition of the impact of fast-moving technical advances and the potential advantages of adopting and adapting mass-market technologies.
On the other hand, the reality is that fielded military systems have a very long lifetime. This must be maintained and even extended long after almost any non-military user would have marked it as “obsolete” and scrapped it while replacing it with something newer. There are many reasons for this long life, including realities of military deployment, costs, ongoing training needed to use and maintain a system, understanding of what the system can/cannot do in reality, and the rotating nature of the military staff and need to pass on of associated knowledge to replacement personnel.
Consider the B-52 Stratofortress long-range bomber, introduced in 1952, with the last one rolling off the assembly line in 1962 (Figure 1). Although “common sense” says they should all have been scrapped by now, about 70 are still in active use out of the approximately 750 built (References 1 and 2).
The current plans are to keep B-52s flying until at least 2040 and perhaps longer while implementing major upgrades in engines, avionics, weapons systems, and more (References 3 and 4). Keeping these aircraft flying even involves scavenging parts from retired ones; if none are available, it requires getting form, fit, and functionally identical replacement parts and circuit boards made.
Consider this: while an obsolete mechanical subsystem or assembly can be re-created piece by piece—admittedly at a significant cost—the same is often not possible for the electronics. When replacement parts such as ICs or processors are no longer available, the choices are limited and often painful.
For example, the U.S. Air Force recently contracted to redesign and remanufacture the AN/ASK-7 data-transfer system for the B-52 bomber aircraft. The existing unit cannot simply be upgraded or modernized because the system has serious obsolescence issues (Reference 5). The contracted vendor will therefore have to design and produce a 100% form, fit, functionally equivalent drop-in replacement for the legacy unit but use new, available parts.
Another example—and there are many more—of an important and long-lived standard is MIL-STD-1553, a military standard first published in 1976 by the United States Department of Defense that defines the mechanical, electrical, and functional characteristics of a serial avionics data bus (Reference 6). It has also become widely used in commercial aircraft and even spacecraft, including the James Webb Space Telescope (JWST), launched in 2021. Despite its age, along with an option under a modified version of the standard for a fiber-optic version, the much-older wired version is still widely used.
DoD Goes MOSA
Q: What is MOSA?
A: The Department of Defense’s Modular Open Systems Approach (MOSA) standard (Reference 7) is not a technical standard in the conventional or usual engineering sense. Instead, it is an acquisition-and-design strategy and framework that prioritizes using open standards-based technology.
Q: What are its objectives?
A: Its intention is to encourage the design of systems with highly cohesive, loosely coupled, and severable modules that can be separated completely and acquired from independent vendors. It allows DoD to acquire warfighting elements, including systems, subsystems, software components, and services, with more flexibility and competition. Further, it implies the use of modular open-systems architecture via a structure in which system interfaces share common, widely accepted standards and for which conformance can be verified (Figure 2).
Q: What is driving the MOSA adoption?
A: Many factors, but the dominant ones are these:
- The National Defense Authorization Act required implementation of MOSA for major DoD acquisitions by 2019.
- The DoD is implementing it on major defense acquisition programs. The rapid evolution is driving this in technology, as well as threats that require much faster cycle time for fielding and modifying warfighting capabilities. The belief is that MOSA can accelerate and simplify incremental deliveries of new capabilities into systems.
The MOSA framework
Q: What is the MOSA “methodology” for acquiring and developing a technical solution?
A: It involves four major stages (Figure 3):
- identifying modularity objectives
- defining the appropriate modules
- evaluating the “quality” of the solution
- assessing the return on investment (ROI) and cost impact
Q: Is MOSA a conventional technical standard?
A: No, it is an approach to doing technical and I.P. design in the context of a business arrangement. It involves the business aspects of “openness”, including Intellectual Property (I.P.) and Data Rights (D.R.). It balances the Government’s desire to own the technical baseline with the contractors’ need to create IP and profits. It also involves the technical aspects of openness, where the interfaces among system elements are based on standards well-defined and fully disclosed.
Q: What about modularity?
A: MOSA insists on modularity in the design, with an architecture partitioned into modules. This also implies:
- a disciplined definition of functional partitions;
- minimizing inter-partition dependencies;
- loose coupling where the functionality can be easily broken away from the rest of the architecture to enable change;
- open interfaces to ease connection of the Modules to each other;
- and “technology insertion opportunities”, which will allow ease of changes, focusing on critical and most quickly changing areas.
Q: This all sounds good, but how do you know you are there in the MOSA process?
A: The MOSA approach also mandates a systematic, quantitative approach to validating and assessing the intended architecture and design approach. This includes:
- coupling, the degree to which the elements inside a module belong together
- cohesion—the relationship of or degree of dependence of one module to another module
Q: All this sounds like a good idea, but how does it translate into an actual design situation?
A: The next part of this article addresses this issue via SOSA, the Sensor Open Systems Architecture.
E.E. World Related Content
- Module speeds security integration of OpenVPX MOSA-based systems
- Distributed, ruggedized computing modules target defense apps
- 3U/6U OpenVPX computer boards, peripherals, ATR-style chassis target defense apps
- Raspberry Pi-based computer meets mil standards for defense and aerospace apps
- The rugged 3U OpenVPX processor module provides hardware-accelerated graphics
- Mission computer sports 6th gen Intel atom MCU for deterministic Ethernet networking
- Development kit covers SOSA-aligned chassis management
- SOSA-aligned powerPC SBC handles real-time data processing in military/defense apps
- 3U development platform handles SOSA 1.0 and CMOSS designs
- 6U tall 19” rack mount chassis designed for 3U Open VPX and SOSA aligned boards
- MIL rugged rackmount SOSA-aligned chassis features advanced cooling
- T.E. Connectivity’s interconnect solutions align with SOSA Consortium technical standard
- 3U and 6U VPX boards follow SOSA technical standard
- Graphic output boards aligned with VITA 65, SOSA technical standards
- SOSA-aligned 3U VPX processor blade carries an 11th-generation Intel Core i7
- 3U VPX FPGA board aligns with SOSA technical standard
- Single-phase 85-264-Vac input/28-Vdc output supply module meets SOSA standard
- 3U VPX Ethernet switch meets SOSA technical standard
Historical and standards-related
- Boeing, “Historical Snapshot: B-52 Stratofortress”
- Boeing B-52 Stratofortress Association, “The Story of the Boeing B-52 Stratofortress”
- The Wall Street Journal, “S. Pushes to Keep B-52 Bombers Going as Pressure From China Grows” (Oct. 17, 2022)
- The Wall Street Journal, “For Wars of the Future, Pentagon Looks to Distant Past: The B-52” (Jan. 24, 2021)
- Military & Aerospace Electronics, “Parts obsolescence forces redesign and remanufacture of AN/ASK-7 data-transfer avionics for B-52 bomber”
- Wikipedia, “MIL-STD-1553”
- Department of Defense, May 2020, “Modular Open Systems Approach (MOSA) Reference Frameworks in Defense Acquisition Programs”
- Curtiss-Wright, “Modular Open Systems Approach (MOSA) Solutions”
- Trenton Systems, “Cost-effective, MOSA-aligned compute solutions for U.S. DoD and Allies”
- Practical Software & Systems Measurement, “Modular Open Systems Approach (MOSA)”
- Mobility Engineering, “Designing Rugged SWaP-Optimized MOSA Solutions for UUVs”
- Mobility Engineering, “MOSA Enclosure Design for Military Systems”
- Mobility Engineering, “What System Designers Should Know About MOSA Standards”
- The Open Group SOSA™ Consortium
- Mobility Engineering, “The Inside Story – SOSA: Sensor Open Systems Architecture”
- VITA Technologies, “Sensor Open Systems Architecture (SOSA): Enabling the next generation of flexible and adaptable radar systems”
- Military Embedded Systems, “Sensor Open Systems Architecture (SOSA): Enabling the next generation of flexible and adaptable radar systems”
- Military Embedded Systems, “Leveraging the Sensor Open Systems Architecture (SOSA) for radar applications”
- Military-Aerospace Electronics, “The official Sensor Open Systems Architecture (SOSA) standard is out; so now what?”
- Military-Aerospace Electronics, “At long last, SOSA open-systems standards guidelines officially released; now comes compliance testing”