RIMAOS2C: Hybrid Middleware for Autonomous Vehicles

• RIMAOS2C is a service discovery-based hybrid middleware that dynamically selects intra-, inter-, and cross-chip communication protocols to optimize data throughput and reduce latency in robotic systems.
• It employs multi-level service discovery with isolated domains and a shared-memory-centric Message Bridge to minimize redundant transmissions and reduce scheduling jitter.
• Evaluations in autonomous vehicles demonstrate 36–40% throughput improvements and significant callback jitter reduction, ensuring reliable performance under high-load conditions.

Searching arXiv for the specified paper and closely related middleware context. arXiv search query: (Sang et al., 31 Jul 2025) RIMAOS2C is a service discovery-based hybrid network communication middleware for distributed robotic systems, introduced to address communication diversity, data-transmission efficiency, and scheduling determinism between Orin computing units in large-scale L4 autonomous vehicle deployments. It combines multi-level service discovery multicast with a shared-memory-centric Message Bridge and a transport layer that dynamically binds topics to shared pointers, POSIX shared memory, DDS-RTPS over UDP, or TCP-based ZeroMQ over Ethernet or PCIe. In evaluation on L4 vehicles and Jetson Orin domain controllers, it was reported to eliminate message redundancy in a two cross-chip subscriber scenario, improve large-data transmission efficiency by 36 to 40 percent, and reduce callback latency variation by 42 to 906 percent (Sang et al., 31 Jul 2025).

1. Architecture and design objectives

RIMAOS2C is organized as a three-layer software architecture. The Application Layer exposes Publish/Subscribe, Client/Service, and Action interfaces, so application developers do not need to manage low-level sockets or shared memory regions directly. The Node Layer implements automatic service discovery, node-status management, topic routing, and the Message Bridge. The Transport Layer contains multiple pluggable communication modules: shared pointers, POSIX shared memory (SHM), DDS-RTPS over UDP, and TCP-based ZeroMQ, with both physical Ethernet and PCIe virtual channels (Sang et al., 31 Jul 2025).

The stated design goals are fully dynamic selection among intra-process, inter-process, and cross-chip communication with zero user modification; hybrid transport, using DDS over UDP for lightweight low-latency traffic and ZeroMQ over TCP or PCIe for high-throughput large topics; elimination of redundant cross-chip transmissions when multiple subscribers are located on the same target chip; centralized cross-chip distribution into shared memory to stabilize scheduling and minimize callback jitter; and compatibility with existing CyberRT tooling such as cyber_monitor and cyber_recorder. Taken together, these goals define RIMAOS2C not as a single transport replacement but as a coordination framework for transport selection and message distribution.

2. Multi-level service discovery and topic scoping

A central mechanism in RIMAOS2C is multi-level service discovery multicast. Traditional ROS2 and CyberRT are described as using a single multicast domain for all topics, whereas RIMAOS2C divides discovery into two isolated networks: Chip-Local Discovery, using a 127.0.0.1 multicast group for intra-chip or intra-process endpoints, and Vehicle-Area Discovery, using a 192.168.1.x multicast configuration for inter-chip endpoints (Sang et al., 31 Jul 2025).

This separation is used in conjunction with topic-class-specific discovery behavior. Small-message topics, exemplified by localization data in the 1 KB to 100 KB range, can be assigned to one multicast group, while large-message topics, exemplified by raw camera images of several MB, can be assigned to another. The paper states that this avoids name-collision and topic-flood issues when the Message Bridge republishes into SHM on a peer Orin. The service-discovery stack broadcasts and listens on both multicast addresses while keeping them logically separate, and DDS continues to perform its normal UDP multicast handshake within the correct scope whenever nodes appear or disappear.

The resulting properties are explicitly identified as flexible, zero-touch protocol binding determined by node location, topic size, and QoS; preservation of toolchain compatibility because users are not forced to rename topics; and scalability to additional network segments or new chips by extending the discovery domains. A plausible implication is that discovery scope is treated as a first-class control surface for both transport binding and namespace hygiene.

3. Message Bridge and shared-memory-centric forwarding

The Message Bridge is the core mechanism for cross-chip efficiency. It is described as a three-phase node. In the local ingestion phase, it subscribes via SHM to one or more locally published topics. In the transport phase, it packages the collected data into a ZeroMQ multipart message over TCP or a PCIe virtual channel, or into DDS for control traffic and small payloads. In the remote distribution phase, it republishes the received data into local SHM on the target chip so that any number of local subscribers can read from the same shared-memory buffer (Sang et al., 31 Jul 2025).

Because SHM functions as the universal bus on each chip, the Message Bridge converts what would otherwise be $N$ separate cross-chip unicast streams into a single outbound transfer followed by $N$ SHM reads. The paper gives a concrete example: if both Sub3 and Sub4 on Orin B1 request the same topic from Orin A2, only one ZeroMQ packet is forwarded across the 10 GbE switch or PCIe link, after which the message is fanned out locally through SHM.

Three consequences are emphasized. First, message redundancy is reduced because there is one cross-chip packet per topic rather than one per subscriber. Second, distribution is centralized, so statistical scheduling variance on Orin cores is bounded by the single Bridge republish event. Third, resource accounting is simplified because only one network socket per topic per chip is required. In operational terms, the Message Bridge is the mechanism that couples transport reduction, local fan-out, and scheduling regularization.

4. Supported communication modes and dynamic binding

RIMAOS2C dynamically binds topics to one of four communication protocols according to scope, message size, and communication context.

Protocol	Scope	Stated characteristics
Shared Pointer	Intra-process	Zero-copy function calls
POSIX SHM	Inter-process, same chip	Low overhead; sub-50 µs; messages up to a few MB
DDS-RTPS over UDP	Cross-chip, small messages	Chosen for topics $\le 100$ KB where latency dominates
ZeroMQ over TCP or PCIe virtual network	Cross-chip, large messages	Used for payloads $\ge 2$ MB for high throughput and to avoid DDS instability

The transport policy is explicitly hybrid. DDS over UDP is retained for lightweight, low-latency traffic, while ZeroMQ over TCP or PCIe is selected for large payloads. The paper further notes that PCIe channels exploit a virtual TCP/IP overlay provided by the NVIDIA Orin PCIe switch and achieve roughly $4\times$ the bandwidth of the 10 GbE port, with up to 40 Gb/s effective throughput cited as an example. ZeroMQ is characterized as always point-to-point, which avoids the “slow participant” problem associated with many-to-many DDS multicast. Multiple ZeroMQ ports and SHM keys may be instantiated per topic to separate priorities or flow-control classes (Sang et al., 31 Jul 2025).

An important interpretive point follows from these design choices: RIMAOS2C does not present a universal preference for one transport. Its binding logic is explicitly conditional. Small-message latency-sensitive traffic is left on DDS, while large-message throughput-sensitive traffic is shifted to ZeroMQ, and same-chip traffic continues to exploit SHM or shared pointers.

5. Scheduling determinism and quantitative evaluation

The paper attributes scheduling determinism in RIMAOS2C to two elements: shared-memory fan-out and isolation of service discovery domains. Shared-memory republishing is reported to reduce the variability introduced by multiple independent network reads and callback scheduling. Measured SHM read or write latency is given as approximately 20 to 40 µs. In high-load multi-subscriber scenarios, callback jitter per message for CyberRT’s DDS unicast is described as potentially large, at $\pm 50$ ms, whereas centralized SHM distribution is said to bound jitter to a few microseconds in the evaluation (Sang et al., 31 Jul 2025).

The performance results are reported on Jetson Orin domain controllers with CyberRT based on Fast DDS as the baseline. For IPC latency, SHM is reported at 5 to 20 µs for 1 KB to 100 KB messages. Fast DDS is reported at approximately 30 to 200 µs for messages up to 100 KB, but unstable beyond 2 MB, with frame loss unless the rate is reduced to 1 msg/s. Adjusted ZeroMQ latency is reported at approximately 500 µs for 2 MB and approximately 1,200 µs for 6 MB after subtracting SHM overhead.

For cross-chip latency, CyberRT is reported to outperform RIMAOS2C by about 10 to 20 percent for small messages of at most 100 KB, but for payloads of at least 2 MB, RIMAOS2C’s ZeroMQ over PCIe is reported as 2 to 3 times faster and fully stable. This distinction is central to the system’s evaluation: the reported benefit is not uniform across message sizes but depends on the small-message versus large-message regime.

In the multi-subscriber case, the paper describes a scenario with two subscribers on a remote Orin. There, RIMAOS2C uses one ZeroMQ transfer plus two SHM reads instead of two independent DDS unicast transfers, yielding a latency reduction of 36 to 40 percent. Callback stability is reported in Table II: the average callback time difference between two subscribers under CyberRT ranged up to hundreds of microseconds, whereas RIMAOS2C bounded it to under 10 µs, corresponding to a 42 to 906 percent improvement in scheduling consistency. These measurements ground the system’s claims about both efficiency and determinism.

6. Deployment in L4 autonomous vehicles and system significance

The deployment setting described in the paper is an L4 autonomous vehicle architecture in which each vehicle carries two domain controllers, each controller contains two Orin SoCs plus an MCU, a 10 GbE switch connects the controllers, and a PCIe switch connects the two Orins within each controller. Functional mapping is given explicitly: Domain A contains Orin A1 for LiDAR plus radar fusion plus localization and Orin A2 for visual perception; Domain B contains Orin B1 for prediction plus planning plus control and Orin B2 for data logging and storage (Sang et al., 31 Jul 2025).

RIMAOS2C was installed atop the standard NVIDIA Orin Linux BSP. No kernel modifications were required beyond granting user-space SHM permissions. ZeroMQ sockets were pinned to dedicated CPU cores to avoid context-switch jitter. In in-vehicle tests during highway and urban driving, the system reportedly showed no dropped messages and consistent end-to-end latencies even under peak sensing loads, including 6 MB LiDAR point-cloud frames at 10 Hz. The stated net result was a smoother perception-planning-control loop with tighter synchronization than a legacy CyberRT-only stack.

Within the scope of the paper, RIMAOS2C is presented as an approach for optimizing communication in distributed computing architectures for autonomous driving and, more broadly, for advancing the communication capabilities of robotic operating systems. A common simplification would be to treat it as merely a faster transport. The reported design and measurements indicate a narrower and more technical characterization: it is a service-discovery-driven middleware that combines transport specialization, scope-aware discovery, and shared-memory-based cross-chip fan-out. That combination, rather than any single protocol substitution, is the basis for its reported throughput gains, redundancy elimination, and callback-jitter reduction.