Table of Contents
Introduction: The Nightmare of the Stovepipe
Early in my career as a systems architect for military ground vehicles, I came face-to-face with a problem that was less an engineering challenge and more a self-inflicted wound.
The inside of our platforms was a nightmare of integration—a rat’s nest of proprietary cables, redundant black boxes, and incompatible hardware.
Every new radio frequency (RF) capability, whether for communications, electronic warfare (EW), or intelligence, came in its own dedicated, sealed-off system.
This approach, known as a “siloed” or “stove-piped” architecture, meant that systems from different suppliers couldn’t interoperate or even identify adjacent equipment.1
This created a cascade of critical failures.
Each vendor used their own “secret sauce” for design, locking us into their ecosystem and making integration a costly, time-consuming nightmare of custom engineering.3
The inability to share hardware led to a catastrophic proliferation of single-function boxes, consuming unacceptable levels of Size, Weight, and Power (SWaP)—precious commodities in any combat vehicle.2
This wasn’t just an inconvenience; it was a critical operational vulnerability.
The root of this technical chaos was a flawed acquisition doctrine that prioritized single-point solutions over a holistic, interoperable system design.
The emergence of standards like the Modular Open RF Architecture (MORA) is therefore not just a technological evolution; it is the physical manifestation of a revolutionary shift in military strategy toward a Modular Open Systems Approach (MOSA).
MOSA is a top-down mandate to abandon proprietary, closed systems in favor of open standards that foster competition, accelerate upgrades, and enforce interoperability from the start.4
It was a direct response to the systemic failures I and many others had wrestled with for years.
The Epiphany: A Lesson from Neurobiology
The path to a solution, however, required a conceptual breakthrough.
For a time, we were stuck trying to force a single, all-purpose communication network to handle every type of signal, from high-level commands to torrents of raw sensor data.
It was like trying to use a single type of road for both residential traffic and a high-speed bullet train.
The real “aha!” moment came not from an engineering textbook, but from the seemingly unrelated field of neurobiology.
Complex organisms do not rely on a single, monolithic information processing system.
They evolved a far more elegant and efficient solution: a dual nervous system.
- The Central Nervous System (CNS)—the brain and spinal cord—is responsible for deliberate, conscious thought, complex decision-making, and issuing high-level commands. It is immensely powerful but operates on a timescale of conscious thought, which is relatively slow.
- The Peripheral Nervous System (PNS) contains pathways like the reflex arc, which are responsible for instantaneous, reflexive actions and the high-speed, high-fidelity transmission of raw sensory data. It is optimized for speed and survival, often bypassing the brain’s slower, deliberate processing to trigger an immediate response.
This biological analogy provided a powerful new paradigm.
It revealed that the most robust and sophisticated information systems don’t use one mode of communication; they use two distinct, specialized modes that work in concert.
This is the fundamental principle behind MORA’s revolutionary dual-bus architecture.
Part 1: The Foundation of a Revolution – From VICTORY to MORA
The journey toward this new architecture began with the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) standard.
VICTORY was the foundational step, establishing a common, Ethernet-based network inside military vehicles called the VICTORY Data Bus (VDB).2
For the first time, it created a shared digital backbone where disparate systems could plug in and communicate.
However, VICTORY was a general-purpose solution.
Its design was optimized for “non-time critical messaging and management,” such as sharing GPS coordinates or system status updates.7
It was not equipped to handle the unique and demanding requirements of modern RF systems.
Specifically, it lacked the ability to support the “transport of large-volume signal data streams” and the “low latency control of the RF chain” that are essential for applications like wideband signals intelligence or real-time electronic warfare.2
MORA was developed specifically to overcome this critical limitation.
It does not replace VICTORY; it extends its scope, adding the specialized capabilities needed for the RF domain.2
The relationship is one of specialization and layering.
VICTORY provides the vehicle’s general-purpose “central nervous system,” but it lacked the “reflex arc.” MORA’s most crucial contribution was to add that missing, specialized pathway, creating the dual-bus system that mirrors the efficiency of a biological organism.
Part 2: Deconstructing the Dual-Bus Architecture: The System’s Two Nerves
Understanding MORA requires deconstructing its two distinct communication modes, each with a highly specialized role, just like the two parts of a nervous system.
The “Central Nervous System”: The VICTORY Data Bus (VDB)
The VDB is the network for command, control, and consciousness.
Its purpose is the reliable, non-time-critical management of the entire system.7
This is the pathway for deliberate, high-level instructions.
- Function and Purpose: The VDB handles tasks like device discovery (identifying what hardware is connected), configuration, high-level tasking, health and status monitoring, and the transport of lower-volume, processed data products.2
- Analogy in Action: This is the equivalent of the brain sending a command to the hand: “SDR, tune to frequency 101.5 MHz and report your status.” The command is complex and important, but it doesn’t require microsecond-level timing.
- Protocols and Standards: To ensure maximum interoperability, the VDB operates over a standard Ethernet network and uses common, well-understood protocols like IP, UDP, and device-level web services for management.2
- Concrete Use Cases:
- A central processor card discovers a newly installed MORA-compliant radio, like the Epiq Solutions VPX400, and automatically learns its capabilities to make it available to the rest of the system.1
- An operator uses a mission computer to send a command to a Direction Finding Engine, specifying parameters for a scan, such as frequency range, bandwidth, and duration.2
- The system transports a processed data product, such as a calculated Line-of-Bearing (LOB) on a signal of interest, from the sensor to a display for the operator to see.2
The “Reflex Arc”: The MORA Low Latency Bus (ML2B)
The ML2B is the network for raw sensation and instantaneous reaction.
It is a high-performance data highway designed for one primary purpose: to provide a “low latency transport mechanism” for the “large-volume signal data streams” that define modern RF operations.2
It is the “fat pipe” built for speed and fidelity.6
- Function and Purpose: The ML2B is exclusively for moving time-critical, raw signal data between RF components with the lowest possible delay.
- Analogy in Action: This is the nerve signal from a finger touching a hot stove. It’s not a command but a raw data stream—”HEAT! PAIN!”—that must travel as fast as possible to a processor (the spinal cord) for an immediate, reflexive response, without waiting for the brain’s slower deliberation.
- Protocols and Standards: This is a crucial distinction. The ML2B does not use the same general-purpose protocols as the VDB. It leverages a specific, locked-down implementation of the VITA 49.2 VRT (VITA Radio Transport) standard.2 VRT is a specialized protocol designed to packetize and transport digitized RF signal data (like IQ data) with essential context information like precision timestamps, frequency, and bandwidth, all in a highly efficient, low-latency format.
- Concrete Use Cases:
- Streaming raw, wideband digital RF data from a Radiohead (the antenna and tuner) to a Software Defined Radio (SDR) for real-time processing and analysis.
- Transmitting a high-fidelity, complex waveform from an SDR to an RF Conditioning and Distribution (RCD) unit for a precision Electronic Warfare (EW) jamming mission.
- Moving multi-channel digital receive data from several antennas to a Direction Finding Engine for instantaneous signal analysis and location.2
The Dual-Bus Architecture at a Glance
The distinct roles of these two communication modes are best summarized in a direct comparison.
Attribute | VICTORY Data Bus (VDB) | MORA Low Latency Bus (ML2B) |
Primary Function | Management & Control | Raw Data Transport |
Analogy | Central Nervous System (Deliberate Command) | Peripheral Nervous System (Reflex Action) |
Data Type | Low-volume, processed data, commands, status | High-volume, time-critical, raw signal data (e.g., IQ data) |
Key Requirement | Reliability, Interoperability, System Management | Low Latency, High Throughput, Data Fidelity |
Governing Standards | VICTORY, standard Ethernet/IP | MORA, VITA 49.2 (VRT) |
Typical Use Case | “Tune radio to frequency X.” “Report health status.” | “Stream raw spectrum data from antenna Y to processor Z.” |
Part 3: The Strategic Imperatives of a Dual-Bus System
The decision to implement two separate communication buses is not an academic exercise; it provides profound operational and strategic advantages that directly address the failures of older, single-bus architectures.
Performance Optimization & Avoiding Bottlenecks
By physically and logically separating the high-volume, time-sensitive data of the ML2B from the “chatty,” non-real-time management traffic of the VDB, MORA prevents critical RF data streams from being delayed or corrupted by routine status updates.
A single-bus structure forces all data into one pipe, creating a bottleneck where high-priority signals must compete with low-priority chatter.10
The dual-bus design ensures that the system can support the “varied latency and throughput constraints” of a complex RF environment, dedicating a high-speed lane for the data that needs it most.2
Enhanced Security through Segregation
The dual-bus architecture creates a powerful, inherent cybersecurity advantage.
The official specification notes that it provides a “natural boundary for potentially sensitive data”.2
The significance of this boundary can be understood by analogy to the Harvard computer architecture, which uses separate buses and memory for instructions and data to enhance security.11
In a Harvard system, an application running in the data space cannot easily modify the operating system running in the instruction space.
Applying this principle to MORA, a compromised application or device on the general-purpose VDB would have extreme difficulty accessing, manipulating, or spoofing the raw, high-fidelity signal streams on the physically and logically separate ML2B.
This segregation acts as a digital firewall, protecting the most mission-critical sensor data from interference.
System Resilience and Fault Tolerance
Drawing from the design principles of dual-bus uninterruptible power supplies used in data centers, the MORA architecture is inherently more resilient to failure.12
A fault or crash on one bus does not necessarily cripple the other.
For instance, if a management application on the VDB becomes unresponsive, the ML2B can continue to stream critical EW or signals intelligence data, allowing the system to “fail gracefully” or maintain its most vital functions during a disruption.
Future-Proofing and True Modularity
This separation of concerns is the key to long-term scalability and fulfilling the promise of MOSA.
A new, more powerful signal processing card can be developed to interface with the high-speed ML2B without requiring any changes to the VDB management software.
Conversely, a new management or data-fusion application can be deployed on the VDB without redesigning the underlying RF hardware.
This decoupling allows for independent, rapid, and cost-effective upgrades of different system components, ensuring the platform can evolve to meet future threats without a complete overhaul.1
Part 4: MORA in the Field – From Architecture to Application
MORA is not just a paper standard; it is a functioning ecosystem of hardware and software that is transforming vehicle capabilities.
MORA-compliant products from industry partners like Curtiss-Wright, Leonardo DRS, and Epiq Solutions are readily available as rugged, Commercial-Off-the-Shelf (COTS) solutions.1
The true power of the architecture is realized in its ability to enable multi-mission operations.
With MORA, hardware is no longer tied to a single function.6
An operator can use the VDB to dynamically re-task a shared hardware asset.
For example, a radio that was being used for voice communications can be repurposed in seconds to serve as a counter-IED jammer.
This is only possible because the flexible VDB can issue the new mission profile, while the robust ML2B can handle the completely different type of high-power data stream required by the new mission.2
This ability to share hardware is what ultimately solves the SWaP crisis.
Instead of dedicated, redundant boxes for every function, a platform can use a common pool of MORA-compliant SDRs, tuners, and processors.
Sharing the largest and most power-hungry components, like power amplifiers and antennas, across multiple missions results in “significant SWaP savings”.6
This directly resolves the core problem of the stove-piped nightmare.
Conclusion: A New Doctrine for the Electromagnetic Spectrum
MORA’s dual-bus architecture, best understood through the powerful analogy of a biological nervous system, is the cornerstone of its revolutionary design.
The two modes of communication are not redundant; they are highly specialized pathways—one for deliberate control and management (the VDB), and one for high-speed, reflexive data transport (the ML2B).
This elegant separation of duties is what allows MORA to deliver on the promise of a truly modular, open, and high-performance RF system.
This architecture is more than a technical specification; it represents a new doctrine for operating in and dominating the electromagnetic spectrum.
It is the enabler for creating military systems that are no longer brittle, monolithic, and proprietary, but are instead adaptive, resilient, interoperable, and perpetually evolvable.
When I look back at the chaotic “rat’s nest” that defined my early work, I see a system at war with itself.
Today, when I envision a MORA-enabled vehicle, I see a clean, logical, and immensely powerful system.
It’s a platform where new capabilities can be integrated as easily as apps on a smartphone, where precious hardware is shared with maximum efficiency, and where the vehicle’s “nervous system” is perfectly tuned to the relentless demands of the modern battlefield.
Works cited
- Epiq Solutions VPX400 Demonstrates MORA 2.4 Compliance, accessed on August 6, 2025, https://blog.epiqsolutions.com/epiq-solutions-vpx400-demonstrates-mora-2.4-compliance
- MODULAR OPEN RF ARCHITECTURE (MORA):, accessed on August 6, 2025, https://events.esd.org/wp-content/uploads/2019/08/Modular-Open-RF-Architecture-Standardizing-the-RF-Chain.pdf
- What’s the Difference between OpenVPX, OpenRFM, and MORA? | Microwaves & RF, accessed on August 6, 2025, https://www.mwrf.com/technologies/embedded/systems/article/21846151/whats-the-difference-between-openvpx-openrfm-and-mora
- MORA Compliant RF Capabilities – Curtiss-Wright Defense Solutions, accessed on August 6, 2025, https://www.curtisswrightds.com/capabilities/open-architectures/mosa/modular-open-radio-frequency-architecture
- Modular Open Systems Approach Architecture – New Wave Design, accessed on August 6, 2025, https://newwavedesign.com/mosa-open-architecture/
- MODULAR OPEN RF ARCHITECTURE: EXTENDING VICTORY TO RF SYSTEMS – GVSETS Document Management System, accessed on August 6, 2025, http://gvsets.ndia-mich.org/documents/VEA/2015/Modular%20Open%20RF%20Architecture%20-%20Extending%20VICTORY%20to%20RF%20Systems.pdf
- What is MORA | Modular Open RF Architecture? – everything RF, accessed on August 6, 2025, https://www.everythingrf.com/community/what-is-mora-modular-open-rf-architecture
- DISTRIBUTION STATEMENT A: Distribution is unlimited, accessed on August 6, 2025, https://peoiews.army.mil/wp-content/uploads/2021/06/PM-EWC-CMOSS-Definition-document-v5_Distro-A.pdf
- SOSA’s rubber is meeting the road in rapid system development, accessed on August 6, 2025, https://militaryembedded.com/radar-ew/rf-and-microwave/sosas-rubber-is-meeting-the-road-in-rapid-system-development
- Difference between Single Bus Structure and Double Bus Structure – GeeksforGeeks, accessed on August 6, 2025, https://www.geeksforgeeks.org/computer-organization-architecture/difference-between-single-bus-structure-and-double-bus-structure/
- Computer Security: Part 5 – Dual Bus Architecture – The Broadcast …, accessed on August 6, 2025, https://www.thebroadcastbridge.com/content/entry/16767/computer-security-part-5-dual-bus-architecture
- Tech Byte #20 – The Benefits of Power Switching in Dual Bus UPS Designs – Climate Conditioning Company, accessed on August 6, 2025, https://climateconditioning.com/app/uploads/white-papers/Tech_Byte_20_The_Benefits_of_Power_Switching_in_Dual_Bus_UPS_Designs.pdf