The United States Department of Defense defines Modular Open Systems Approach (MOSA) as “a technical and business strategy for designing an affordable and adaptable system. A MOSA is the DoD preferred method for implementation of open systems, and it is required by United States law.” Title 10 U.S.C. 4401(b), states “all major defense acquisition programs (MDAP) are to be designed and developed using a MOSA that –
(1) Employs a modular design that uses modular system interfaces between major systems, major system components and modular systems;
(2) Is subjected to verification to ensure that relevant modular system interfaces comply with, if available and suitable, widely supported and consensus-based standards; or are delivered pursuant to the requirements established in FY21 National Defense Authorization Act Section 804 (a)(2)(B), including the delivery of-
Software-defined interface syntax and properties, specifically governing how values are validly passed and received between major subsystems and components, in machine-readable format;
A machine-readable definition of the relationship between the delivered interface and existing common standards or interfaces available in Department interface repositories; and
Documentation with functional descriptions of software-defined interfaces, conveying semantic meaning of interface elements, such as the function of a given interface field;
(3) Uses a system architecture that allows severable major system components at the appropriate level to be incrementally added, removed, or replaced throughout the life cycle of a major system platform to afford opportunities for enhanced competition and innovation.
(4) Complies with the technical data rights set forth in 10 U.S.C. 3771-3775.”
A key question is: How effective is MOSA in practice? Modularity is generally beneficial. Integrating complex systems is often the most challenging and costly aspect of development. Modularity can mitigate integration complexity, and although it may increase initial design costs, these are typically outweighed by long-term savings. Ongoing costs such as inspection, maintenance, and upgrades can be substantial. Systems engineering emerged in the mid-20th century as a response to the growing complexity of scientific and technical systems. While individual subsystems can be easily tested, many defects only surface during integration or system-wide testing. Integration failures often result from unforeseen interactions between components, which may not be identified during the design phase. Many issues only become apparent in real-world deployment, and fixing them can be costly. Modular design involves two key principles:
(1) A deep understanding of the system is necessary to accurately define the interfaces between subsystems and their interactions.
(2) Subsystems must be manufactured to meet the specified interface tolerances.
Modular design can be simple. For example, interchangeable screws on an assembly line are modular, as long as they adhere to the standardized interface. By achieving these two principles, subsystems can be designed independently, and integration becomes straightforward. This allows for flexibility, as any screw can be used with any screw head without compromising the system’s functionality.
A key goal is to create interchangeable components, like screws with identical thread pitch and holding strength. Modularity can also emerge naturally from well-designed systems, indicating thorough testing and iterative design processes. Modularity is prevalent in unexpected places:
(1) Cartridge-based firearms are modular in terms of ammunition compatibility. A single rifle can fire various rounds, as long as the cartridges adhere to the interface standards, including physical dimensions and propellant energy. This enables switching between different types of ammunition, from black powder and lead bullets to modern high-performance rounds.
(2) Fuzing allows for modularity in the application of bombs and shells. Quick fuzes are effective against light structures, delay fuzes are suitable for heavy structures and lightly armored vehicles, and proximity fuzes excel against aircraft and trenchworks. The same gun and shells can be used for multiple purposes by simply changing the fuze.
The concept of modularity has been successfully applied to modern military combat equipment:
Most Western Main Battle Tanks (MBTs) utilize bolt-on modular armor. The Abrams, Challenger 2, and Leopard 2 can remove their additional armor for transportation. In contrast, Russian MBTs often have semi-permanent ERA/NERA installations, requiring significant effort to replace. Remote Weapon Systems (RWS) exemplify modularity, accommodating various weapons from light machine guns to anti-tank missiles while sharing a common remote control and sights.
Modularity is beneficial, but it doesn’t provide a complete solution. Sometimes, specific modularizations may not yield the desired results. However, this doesn’t necessarily indicate failure. Well-engineered systems often reveal limitations through exceptions to modular design. Physical interfaces, especially in mass-critical military applications, are costly. Reusable modules require interface geometry and connections on both modules, often doubled for redundancy. Tight integration can reduce mass and part count. A more practical approach involves using mostly off-the-shelf components (bearings, bolts, inserts, FPGAs) and connecting them with a few custom parts.
Modularity has limitations, but that doesn’t negate its value. System-level phenomena arise from the entire system, not individual components. Software modularity, while helpful, doesn’t address all challenges. Network components (physical medium, hardware, software) are modular, allowing for flexibility in connections and upgrades. However, network security is a system-level issue that cannot be solved with a single module. A comprehensive approach, considering all network components, is necessary for effective security.
Standards define the limits of what is required, permitted, or prohibited. Innovation thrives within these boundaries but diminishes outside them. Any boundary restricts choices, leading to suboptimal outcomes, except for interchangeability. Consider a programming language that forbids loop structures (for, while) in favor of standardized if/then structures. While this might enhance if/then usage and potentially lead to new syntax variations, it ultimately limits the range of possibilities and can make programs less efficient and less optimized, despite improving interchangeability.
Modularity is a complex trade-off, not a simple good or bad concept. Historically, modularity has been advantageous due to its flexibility and long-term cost reduction. Designing a component once and using it repeatedly in production outweighs the initial design costs, especially when considering large-scale deployment.