Modularity has become a requirement rather than a preference. Major defense acquisition programs are expected to use a Modular Open Systems Approach, and sensor programs across the services increasingly point to the Sensor Open Systems Architecture. Both are written at the level of the program. Both land, in the end, on the team that designs, builds and integrates the system.
This note describes what each asks of that team, in plain terms, and where AI fits.
MOSA: modules, and the interfaces between them
The Modular Open Systems Approach asks for a system built from modules that can be added, removed, replaced or upgraded independently, joined by interfaces that are open, published and governed by standards rather than by one vendor's design. The aim is a system the government can compete, upgrade and sustain over decades without being locked to whoever built the first version.
For an integrator, that turns into concrete work:
- Decide where the module boundaries are, and write down why. A boundary drawn in the wrong place is expensive to move later.
- Define every interface between modules precisely enough that a different team could build either side of it: messages, timing, formats, behaviour when something fails.
- Prefer published standards for those interfaces where they exist, and publish the ones that do not.
- Test the interfaces, not only the modules. Integration problems hide in assumptions about the seam; the seam needs its own tests from the first sprint.
- Hand over the interface definitions as deliverables, owned by the government, so the next competition starts from them.
SOSA: the same discipline, for sensors
The SOSA Technical Standard, developed through The Open Group with government and industry, applies modular open systems thinking to sensors: radar, electronic warfare, communications and electro-optical systems. It defines common architecture and interfaces for the hardware, software and electrical layers, so that a processing card or a sensor module from one supplier can work in a system built by another.
For an integrator building or modernizing a sensor system, the standard shapes the choices at every layer: which modules and form factors are used, how data moves between them, how the system is configured and managed. Where a program calls for SOSA, conformance has to be planned from the first design review, because it constrains decisions that are hard to reverse later.
Where AI fits
AI adds a module to the system, and the same rules apply to it. A model or an agent should sit behind a defined interface: what data it takes, what it returns, how it signals uncertainty, what happens when it is unavailable. That makes it testable like any other module, replaceable when a better model arrives, and auditable, because every input and output passes through a seam that can be logged.
Treated this way, AI stops being a pilot bolted onto the side of a system and becomes a part of it, built to the same open architecture as the sensors and software around it.
What to ask an integrator for
- A written module and interface plan, with the reasoning for each boundary.
- Interface definitions as deliverables, in the program's name.
- Interface tests that run continuously, not only at integration events.
- For sensor programs, a plan for SOSA conformance at each layer, scoped up front.
- For AI, a defined interface, an evaluation plan against the mission, and an audit trail.
Working with us
Vonar AI designs and integrates systems to a modular open systems approach, integrates sensors to the SOSA Technical Standard where a program calls for it, and implements AI inside the systems it builds. Tell us what you're working on.