Gasgoo Munich-Microsecond Latency, Zero-Loss Reliability: DDS Emerges as the New Cornerstone of Software-Defined Vehicles. As vehicles become smarter and more connected, traditional CAN/LIN buses and SOME/IP are struggling to keep up with the massive influx of sensor data, which demands low latency and high reliability. In this landscape, Data Distribution Service (DDS)—a technology long proven in defense and aerospace—is fast becoming a critical component for the next generation of in-vehicle communication middleware, steadily gaining favor among automakers.What exactly is DDS? What is its core value for the automotive sector? How is it currently being applied, and what challenges lie ahead? To answer these questions, Gasgoo Auto recently spoke with Kelvin Hor, Sales Director for Asia-Pacific at RTI (Real-Time Innovations), a leading global DDS provider. Here is what we learned.Kelvin Hor, Sales Director, Asia-Pacific, RTIWhy is DDS Accelerating into the Automotive Sector?DDS was originally used in fields like defense and aerospace, where data distribution reliability and real-time performance are paramount. Unlike traditional request-response communication, DDS employs a data-centric publish-subscribe model. Simply put, any node in the system—whether it is an autonomous driving domain controller, a zone controller, or a single sensor—only needs to declare what data it can publish and what it needs to subscribe to. DDS then automatically handles routing, scheduling, and transport management.More critically, DDS uses rich QoS policies—such as reliability and lifecycle—to flexibly configure communication quality. It can achieve microsecond-level end-to-end latency while ensuring critical control commands are "never lost." It also supports dynamic scaling, allowing new nodes to join without modifying existing code, which significantly reduces integration complexity.Regarding why DDS is entering the automotive space, Kelvin Hor points out that in the CAN/LIN era, signal locations and semantics were statically bound via protocols and databases, resulting in a relatively fixed system structure with clear boundaries. With the development of zone architectures and central computing, however, ECU counts are gradually declining, Ethernet has become the backbone network, and vehicle software systems are shifting from signal-driven to service-driven—significantly raising complexity. During this evolution, hardware boundaries are weakening. A single application function is often completed collaboratively by multiple computing nodes; for example, perception, fusion, and decision-making modules might run on different domain controllers or a central computing platform, forming a cross-domain distributed deployment. At the same time, the demand for flexible scheduling, dynamic scaling, and cross-node data sharing continues to grow.In this context, traditional communication methods based on static signal binding can no longer support system evolution. The data-oriented publish-subscribe mechanism, however, enables loose coupling for data distribution and dynamic discovery, making it better suited to complex software architectures. This is the core reason DDS is being gradually introduced into new automotive electronic architectures.From a market perspective, Kelvin Hor adds that the traditional automaker model—organizing project teams by vehicle model and tightly coupling hardware and software—struggles to meet the Software-Defined Vehicle (SDV) requirements for rapid iteration and cost reduction. Today, SDV platformization is becoming a trend, meaning a single platform supports all models from high-end to entry-level. Here, modularity and decoupling become rigid requirements.As communication infrastructure, DDS inherently possesses this decoupling capability. It can reduce software coupling and system complexity from the ground up, enhancing modularity. This helps automakers lower development costs, shorten R&D cycles, and accelerate time-to-market. This is the fundamental reason DDS is increasingly capturing the attention of automakers.DDS Synergizes with TSN for Deterministic Real-Time CommunicationTo further guarantee system architecture reliability and real-time performance, the synergistic application of DDS and TSN (Time-Sensitive Networking) is gradually becoming an industry consensus.The reason lies in the fact that while DDS excels at flexible data distribution and cross-platform interoperability, its QoS policies—such as latency budget and deadline—rely on the underlying network to provide real-time guarantees; it cannot achieve microsecond-level deterministic transmission on its own. Conversely, TSN can provide deterministic transmission (including low latency and time synchronization) over Ethernet, but it only operates at the network layer. It does not understand application semantics and cannot automatically identify which data requires priority processing.When used separately, there is a disconnect: "the upper layer has needs but the lower layer is unaware, while the lower layer has the capacity but the upper layer lacks an interface." Synergistic application is the key to breaking this barrier.Image Source: RTI"By combining DDS with TSN, you can leverage DDS for the flexible distribution of routine data while relying on TSN to guarantee microsecond-level, zero-jitter deterministic transmission for critical data. This allows the shared network to simultaneously meet high bandwidth, high real-time, and high safety requirements at the lowest possible cost, completely eliminating uncertainty and making the software-defined vehicle engineering-feasible for mass production," Kelvin Hor explained.Application Status and ChallengesIn terms of progress, DDS has expanded from intelligent driving domain controllers to full-vehicle communication infrastructure.Domestically, led by new forces like XPENG, some OEMs no longer view DDS as merely a data channel. Instead, they see it as a foundational communication platform for carrying future new businesses—including AI real-time inference, vehicle-road collaboration, and cloud collaboration. Additionally, technical standards are gradually improving. In 2024, China's first automotive DDS testing standard, T/CSAE 371-2024 "Test Methods for Data Distribution Service (DDS) for Intelligent Connected Vehicles," was published. This standard was led by the China Academy of Information and Communications Technology and jointly compiled by 16 organizations, including Great Wall Motor, FAW Group, Geely, Changan Automobile, BAIC, and Chery.In overseas markets, DDS is more often landing in mass production projects accompanied by functional safety certifications (such as ISO 26262 ASIL D). Especially for automakers with European export ambitions, this proven communication framework is being introduced early.Kelvin Hor added that by the first quarter of 2026, RTI Connext Drive products are set to be deployed in over 2 million production vehicles globally, covering multiple automakers. "We have already established cooperation or a foundation for cooperation with most domestic OEMs (including both new forces and traditional OEMs), and we are continuously promoting deeper exchanges. As platformization advances, related projects are gradually landing according to their own schedules."He believes China is a leading market for DDS in the automotive sector. "Some of our more forward-looking thinking will be prioritized for joint development and deployment with benchmark customers in China."Image Source: RTIWhile the prospects are broad, challenges are real—and often not limited to the technical level:First, organizational inertia. Kelvin points out that the biggest challenge often comes from misaligned perceptions across departments. DDS selection typically involves intelligent driving, cockpit, vehicle control, basic software, and even procurement departments. If these perceptions are not aligned, progress is easily hindered.Second, the migration from CAN signals to DDS data. In CAN communication, each signal has only a few bytes of location definition, whereas DDS requires clear data structures and semantics. This conversion involves not just toolchain adaptation, but also requires different teams to reach a consensus on "data models and semantics." Many projects get stuck in repeated refinement during this phase.Third, information security and response capabilities in extreme scenarios. On the software side, security vulnerabilities or performance issues under extreme traffic scenarios cannot be ignored. This requires repeated, professional technical verification, and demands that the supplier team possesses rapid response capabilities.Kelvin Hor stated: "There are indeed many entrants in the market right now, but the technical barrier in this field is not low. Through years of accumulation and technical verification, RTI has mature supply experience and a comprehensive response system, ensuring rapid innovation and mass production landing for customers. Furthermore, we have a deep understanding of middleware components, and many functions are opened through interfaces to help customers build the platform best suited for themselves."Gasgoo SummaryWill DDS become a "standard feature" for SDVs? From a technology trend perspective, the possibility is high. The deeper SDV goes, the more the entire car resembles a distributed real-time database—where all nodes are producing and consuming semantic data, rather than just sending point-to-point signals or calling interfaces. In this paradigm, the data-centric DDS is inherently more suitable for long-term architecture than the service-centric SOME/IP or traditional IPC.But "standard feature" does not mean a monopoly. The key differentiator lies in this: when system scale expands to hundreds of logical nodes, mixed safety levels, and cross-domain real-time constraints exist simultaneously, who can still guarantee development efficiency without sacrificing determinism? This is precisely the most interesting part of the DDS migration—it is not a simple technology replacement path, but a slow rewrite of the engineering system. Whoever can accumulate more landing scenarios will truly be able to dig a deep moat.
