Automotive architectures increasingly carry sensor data, diagnostics, and software-defined vehicle traffic over constrained embedded networks. On 10BASE-T1S, developers must account for the link's 10 Mbps capacity, shared-medium access, and the effect of large transfers on time-sensitive traffic.
We tested RTI Connext Micro 4.3.0 on a physical 10BASE-T1S bus to answer a practical question: How does large-data communication behave on a bandwidth-constrained automotive network?
Connext Micro 4.3.0 supports Data Distribution Service (DDSⓇ) samples larger than the network’s maximum transmission unit (MTU) by fragmenting them for transport and reassembling them before delivery to the application. On a constrained link, asynchronous publishing and flow control is able to schedule transmission to reduce long bursts and preserve bandwidth.
10BASE-T1S is a 10 Mbps single-pair Ethernet technology designed for short-range, multidrop networks. Its shared bus can simplify in-vehicle wiring, but its bandwidth is much lower than conventional switched Ethernet.
The minimum transmission time of a 10 KiB application payload has a theoretical lower bound of approximately:
10,240 bytes × 8
─────────── ≈ 8.2 ms
10,000,000 bits/s
A 64 KiB payload requires at least 52.4 ms before accounting for DDS, UDP, IP, Ethernet, and possible VLAN overhead. During sustained large-data transmission, other applications and DDS discovery or reliability traffic must compete for the same 10 Mbps bandwidth.
10BASE-T1S commonly uses Physical Layer Collision Avoidance (PLCA) to coordinate access to the multidrop medium. DDS does not control PLCA, but it can control how its own samples are divided and scheduled.
In Connext Micro 4.3.0, synchronous publishing is the default: the DDS DataWriter operation DDS_DataWriter_write() can block, and the fragments of a large sample may be sent without interruption, potentially disrupting other network traffic and reducing network determinism through intermittent spikes whose duration depends on the sample size. In contrast, with asynchronous publishing, DDS_DataWriter_write() only queues the sample for transmission and returns. A Micro background task uses a flow controller to meter when queued fragments are sent, limiting uninterrupted link occupancy and creating more opportunities for other network traffic.
The leaky-bucket token flow controller meters when queued data is eligible to be sent, but it does not change the configured fragment boundary. You can configure its token rate from the bandwidth budget and validate it with other bus traffic. Actual interleaving still depends on the operating system, DDS resources, other writers, PHY behavior, and PLCA settings.
Our testbed used two Raspberry Pi 4B systems as publishers and an x64 Linux system as the subscriber. One publisher generated a 32-byte sample at 100 Hz, representing frequent, time-sensitive control traffic. The other published a 64 KiB sample at 1 Hz, representing less frequent sensor, diagnostic, or application data. All systems shared the same physical 10BASE-T1S bus and used Connext Micro 4.3.0 with reliable communication.
This mixed-traffic scenario is more representative of the automotive use case than continuously writing large samples to the bus. The challenge is not simply reaching maximum throughput; it is transferring the large sample without creating a long burst that disrupts the frequent small-sample traffic.
We compared packet timelines from two separate test runs: synchronous publishing (“Sync OS Frag,” first row) and paced asynchronous publishing (“Async DDS frag,” second row). Each run included one 64 KiB publisher and one 32-byte publisher at 100Hz. In the synchronous test, the sample was fragmented and all fragments were sent before the write operation returned. With DDS fragmentation and asynchronous publishing, the DDS_DataWriter_write() operation returned after queuing the sample, and a background publisher sent the fragments over time using flow control. The runs were launched separately, so their timers were not synchronized and the samples were written at different times.
These captures describe this test configuration rather than a general guarantee. They demonstrate the trade-off: sending all fragments without flow control minimizes large-sample latency, while flow control can reduce burstiness and ensure that one DDS_DataWriter cannot prevent other DDS_DataWriter instances from publishing samples in a timely manner.
For large DDS samples:
Connext Micro 4.3.0 provides the fragmentation and scheduling mechanisms needed to write large DDS samples over 10BASE-T1S. The remaining task is a system-engineering decision: users simply choose fragment, resource, and pacing settings that match the latency and bandwidth priorities of the vehicle network.
For configuration details, please see RTI Connext Micro 4.3.0 documentation for sending large data.
About the author: