I’ve been into modular since I was a kid. I didn’t know it, but I was. Think Legos and Lincoln Logs. If you don’t know the latter, just Google it.

Anyway, I totally get – and love – what modularity is and how it works for my toys. After I became a software engineer, suddenly modularity took on a whole new – but related – meaning: Building blocks and reusability.

Building-block modularity for the DoD

In February of 2025, the Office of the Under Secretary of Defense for Research and Engineering published a guidebook for the U.S. Department of Defense (DoD) community. The goal of this document is to provide “information to help ensure programs incorporate a modular open systems approach (MOSA) as part of the defense acquisition program life cycle.” Entitled “Implementing a Modular Open Systems Approach in Department of Defense Programs,” you can find the complete guidebook here.

Real-time operating systems (RTOSs) play a vital role in the infrastructure of embedded systems. They provide deterministic, low-latency capabilities for data processing, communications, navigation, sensor-weapon control, autonomy, and more. An RTOS is also the critical connection between the system hardware and application software, the glue that holds the platform together so that it can perform as required.

There are several areas where an RTOS needs to support MOSA goals. Three of the most important are:

Modularity to allow reuse and incremental upgrades to both hardware and software
Abstracting software from hardware for portability
Managing a wide variety of data I/O to support various sensor configurations

Building block: RTOS modularity that allows reuse and incremental upgrades

Many RTOS solutions compile into a monolithic binary, but this approach is problematic when it comes to updating or changing any one component. For example, if you upgrade a sensor for improved performance, you will have to completely rebuild and retest the entire monolithic RTOS. With a modular RTOS, you only need to address the single software component needed to support the new sensor. You can reuse most of the executables without retesting, which accelerates upgrades to hardware components. Minimizing changes to the RTOS is the key to driving quicker updates to the warfighter.

Building block: Supporting a wide variety of hardware deployments

Software performance is dependent on the hardware. A well-designed RTOS can help abstract both the kernel and application software from individual hardware needs. By employing an abstraction library that is dynamically linked, the RTOS can run on a variety of hardware solutions without the need for modification. This method can vastly reduce costs through software reuse.

Building block: Abstracting I/O to enable rapid sensor upgrades

Across domains and platforms, there is a need for a wide variety of sensors. Applications require data from these sensors and this data can come in an assortment of formats and over different networks. One way an RTOS can handle this variability is by employing an I/O library.

Even in a simple upgrade situation, the I/O interface in a given software application can largely differ from the interface in the prior configuration. Managing this I/O volatility and the resulting software changes presents major challenges to developers and their software teams. An RTOS that uses I/O libraries enables modular updates and software portability across platforms.