INTERVIEW  Gerardo Pardo, CTO of RTI

Faster than MQTT, smarter than SOME/IP, and safer than ROS 2? Gerardo Pardo, the architect behind DDS and CTO of RTI, believes that a truly software-defined vehicle (SDV) begins with a data-centric architecture. From over 10 global OEMs to next-generation platforms ranging from XPENG to aerospace systems, DDS is increasingly being adopted as the core communication technology. At the same time, RTI is contributing to the evolution of key industry standards such as AUTOSAR and SOAFEE. Could DDS become the foundational infrastructure driving SDV innovation? AEM sat down with CTO Pardo to explore the forces behind this shift—and where it’s headed next.

written by Sang Min Han_han@autoelectronics.co.kr

Gerardo Pardo, CTO at RTI since 1998, led the development of RTI Connext DDS. Gerardo leads standardization efforts, authoring numerous DDS-related standards and chairing revision task forces. He co-founded and co-chairs the Data-Distribution SIG within OMG and serves on the OMG board of directors. With expertise in security, middleware, and publish-subscribe systems, he has led multiple research grants, holds patents, and has published extensively on real-time and secure distributed systems.

한글로보기





RTI is widely recognized as a leader in DDS-based middleware. While alternative technologies such as SOME/IP, MQTT, and
ROS 2 exist, what are the core technical advantages of DDS in the context of SDV architectures? What differentiates DDS from these alternatives?
Pardo        DDS stands out in the SDV landscape due to its unique combination of real-time performance, data-centric design, and architectural flexibility. These core technical advantages differentiate it from alternative technologies like MQTT, SOME/IP, and ROS 2. 
DDS offers advantages over MQTT primarily due to its data-centric design and brokerless architecture. Unlike MQTT, which is message-oriented and simply delivers payloads without understanding their content or managing their lifecycle, DDS treats data as part of a shared global space. It understands schemas (IDL/XTypes), enforces QoS contracts, and maintains stateful information such as the last known value, key fields, time-series updates and lifespans. 

DDS utilizes a peer-to-peer architecture, allowing messages to flow directly from publishers to subscribers. This contrasts with MQTT's reliance on a centralized broker to relay every message. As a result, DDS achieves lower latency and significantly higher throughput that scales with the number of nodes, while MQTT's performance is constrained by its broker, which also introduces a single point of failure. DDS inherently avoids this bottleneck and is more robust. 

DDS also excels in transport adaptation, leveraging multiple mechanisms to deliver desired performance and QoS. It can use shared memory for intra-process or intra-host communication, and UDP and multicast (even for reliable flows) to avoid TCP's head-of-line blocking and enable better latency predictability. Moreover, DDS can run on TSN (Time-Sensitive Networking), utilizing traffic reservation and prioritization features to guarantee bounded end-to-end latencies. These capabilities are crucial for real-time control and high-bandwidth data flows (e.g., video or LiDAR) operating over a shared vehicle network. 


How does it compare to SOME/IP or ROS 2? 
Pardo        DDS is a complete middleware stack, handling discovery, reliability, large message fragmentation, type compatibility checking, deployment over various transports (including Wide Area Network), and security. In contrast, SOME/IP is a lower-level protocol that relies on UDP for best-effort real-time (unreliable) and TCP for reliable traffic (non-real-time). This creates limitations, such as the inability to have real-time flows that are reliable or messages larger than 64KB (the largest UDP datagram). 

DDS's data-centric model provides greater flexibility and capability through rich type modeling and introspection, content filtering at the middleware level, and configurable QoS policies for latency, reliability, deadlines, and more. Crucially, SOME/IP lacks integrated security, forcing secure communication to rely on external components or OEM-specific extensions. This makes it harder to reason about and certify system-wide security behavior. 

While ROS 2 uses DDS internally, it introduces an abstraction layer that presents several drawbacks. This layer provides limited access to real-time configuration, hiding or making it difficult to reach most DDS QoS settings, which reduces control over latency, reliability, and timing. ROS 2 also has a restricted type system; its messages are simpler and less expressive than DDS IDL/XTypes, limiting features like key fields, versioning, and optional members. 
Furthermore, the ROS 2 middleware layer adds complexity and overhead, increasing code size, introducing indirection, and reducing determinism and scalability. Finally, there's no end-to-end certification with ROS 2. While it can run on a safety-certified DDS implementation (like RTI Connext® Cert), the ROS stack itself is not certified, which compromises functional safety in regulated systems. 


So why is DDS important for SDVs? 
Pardo        In summary, compared to MQTT, SOME/IP, and ROS 2, DDS provides more built-in capabilities to the application layer. Applications don't need to implement reliability, type checking, discovery, or filtering, as these are handled by the middleware. Real-time behavior and fault tolerance are enforced at the middleware level, and security and QoS are deeply integrated, not bolted on. This results in simpler, more robust, and more secure real-time systems with less application-layer complexity. 

For SDVs, this is critical because autonomous systems require real-time access to dynamic world models (e.g., sensor fusion, object tracking), as well as other less time-sensitive flows within the same vehicle network. They also demand robust security and certification. DDS's data-centric model, comprehensive QoS, and full support for data types, security, and certification enable these capabilities out-of-the-box, without requiring developers to build them from scratch.




RTI Connext Databus Architecture Overview 



RTI embraces service-oriented architecture (SOA) while strongly advocating for a data-centric architecture (DCA). In the era of software-defined vehicles, what does this “data-centric” approach mean, and what strategies is RTI pursuing to realize this vision? 
Pardo        A data-centric architecture (DCA) can be seen as a specific kind of service-oriented architecture. One where there are "services" revolving around data interactions: access to a global data space, publish/subscribe semantics, lifecycle management, and ownership of data. These are the foundations. Request/reply type services can also be offered on top of the same foundation (DDS-RPC). Instead of jumping to APIs or interfaces, the system starts with an understanding of dataflows and services and builds communication patterns around that. 

This approach brings several benefits: 
▶ Supports both publish-subscribe and request-reply: One-to-one, one-to-many, and even one-to-many repliers for a single request. 
▶ Unified discovery: Services and topics are automatically discovered—no need for separate registries or configuration. 
▶ QoS-aware request/reply: Timeouts, deadlines, reliability, and priority can be configured per request and per response. 
▶ Observability: Since requests and replies are modeled as data, they can be logged, inspected, filtered, or replayed like any other data sample. 

For software-defined vehicles (SDVs), this model is a natural fit. These systems demand capabilities such as: 
▶ Real-time access to shared sensor and actuator data via a publish-subscribe mechanism 
▶ Configuration, diagnostics, and control through request-reply APIs 
▶ Support for both high-bandwidth data streams and low-frequency control messages 
▶ Runtime introspection and enforcement of safety constraints 
▶The ability to add new vehicle functions post–Start of Production (SOP) 
▶ Assurance that dataflow requirements are met across a range of vehicle platforms 
▶Seamless dataflow, regardless of whether functions run in the cloud or within the vehicle 

RTI sees the data-centric architecture as the unifying layer for all these needs. It allows modular system composition around shared data and service contracts while ensuring that security, safety, and real-time behavior are enforced at the data level—not just at the API level.  
This provides a scalable, flexible, and safety-aligned foundation for building SDVs that can evolve over time without re-architecting core communication. 


Would you say that DDS is becoming the de facto standard for SDVs?
Pardo        Definitely, especially when you look at newer SDV-focused developments and standards that are starting from a software-defined perspective. Even traditional automotive architectures rooted in AUTOSAR are moving in this direction. Both AUTOSAR Classic and AUTOSAR Adaptive have now formally added DDS support, which is a strong signal that the ecosystem is shifting toward a more data-centric approach. 

At the same time, we’re seeing many new SDV platforms and architectures adopting DDS directly as the integration framework, bypassing legacy stacks to achieve better agility, modularity, and real-time performance. These systems value the ability to support high-bandwidth sensor data, low-latency control loops, and cloud-edge integration within a single, scalable communication model. 

So while DDS may not be universal (yet), it is quickly becoming the de facto standard for modern, modular, and safety-aware SDV architectures.


RTI is known to be actively involved in initiatives such as AUTOSAR Adaptive,  SOAFEE, and ROS 2. How is RTI contributing to standardization and interoperability efforts across the SDV ecosystem. 
Pardo        RTI is helping these efforts and the adoption of DDS in two main ways: 

1. Direct data-centric integration: 
a. In some efforts, application requirements are mapped directly onto DDS concepts such as Types, Topics, Services, and QoS policies. 
b. This approach enables a more agile and performant architecture while maintaining openness and interoperability. 
c. RTI contributes here by helping these initiatives design clean data-centric models that align with system goals, enabling flexible and scalable integration without unnecessary overhead. 

2. Framework-layer abstraction on top of DDS. Other initiatives, like AUTOSAR and ROS 2, define an additional software framework on top of DDS. These layers may: 
a. Expose only a subset of DDS features. 
b. Introduce new abstractions (e.g., services, components) for consistency across platforms. 

In these cases, RTI plays an advisory and educational role—guiding them on how to use DDS correctly and efficiently under the hood as well as the data-centric features that matter most for real-time safety and performance use cases. RTI also advises on ways to extend the framework, if necessary, to expose more data-centric capabilities. 

This guidance ensures that even when DDS is abstracted behind another layer, it’s used in a way that preserves its core strengths. And when some data-centric capabilities are hidden or omitted, RTI works to ensure that the consequences are clearly understood—particularly around trade-offs in latency, determinism, scalability, and observability. 
RTI’s broader goal across all of these efforts is to promote interoperability without sacrificing the flexibility, performance, and architectural integrity that SDVs require. 


RTI’s Connext product suite is widely used in safety-critical industries such as healthcare, defense, and aerospace. In the automotive domain, how does RTI’s DDS technology meet the stringent functional safety requirements, particularly for ASIL-D applications? 
Pardo        RTI has a rigorous software development, testing, and release process to ensure the quality and reliability of its products—an essential foundation for use in safety-critical systems. 
To meet the various deployment scenarios, RTI offers multiple implementations of its core DDS libraries, including: 
▶ Connext Pro for enterprise-class and cloud-connected systems. 
▶ Connext Micro for resource-constrained embedded platforms. 
▶ Connext Cert for systems requiring formal functional safety certification. 

For automotive applications targeting ISO 26262 ASIL-D, RTI provides Connext Cert, which is specifically developed and documented to meet the highest automotive safety integrity levels. It includes a safety manual, development artifacts, and certification evidence that can be directly used in the safety case for ASIL-D systems. 

RTI also supports ISO 21434 for cybersecurity in road vehicles. Connext Cert incorporates features and documentation needed for secure communication in safety-critical systems, including authentication, encryption, and fine-grained access control, ensuring both functional safety and cyber resilience. 
This strategy allows automotive developers to reuse a consistent software stack across non-safety, safety-related, and cloud-connected components—while maintaining compliance with industry standards and minimizing integration and validation overhead. 







Connext Drive Framework



Some critics claim that DDS is too heavyweight or complex. How does RTI respond to these concerns, and what efforts have been made to improve developer experience and ease of integration?       
Pardo        Similar concerns have been raised many times in the past: Using high-level languages instead of assembly, adopting multi-threaded OSes like Linux or QNX instead of going bare metal, or using TCP/IP instead of simpler fieldbus protocols. In each case, as processing and memory resources caught up, the benefits of general-purpose, extensible technologies outweighed the initial complexity. Middleware is going through the same evolution.
 
In the context of SDVs, users want to deliver value through software. They want the ability to update, evolve, and scale that software over time. To enable that, you need the right infrastructure, and that includes a capable and flexible middleware layer. RTI Connext provides this foundation. 

That said, we recognize that with capability comes complexity, especially when developers are learning to configure QoS, understand data-centric patterns, and navigate DDS APIs.
 
To address this, RTI has made significant investments in improving developer experience and reducing the learning curve. One of the major initiatives is Connext AI, which brings AI-driven tooling into the development workflow. This tool helps developers learn and navigate APIs more easily, generate correct QoS configurations (from natural language or visual input) and understand the impact, as well as prototype and refine communication models quickly.
 
Connext AI is available at no cost to all RTI users and is designed to accelerate adoption and reduce time-to-deploy, especially in fast-paced, safety-aware SDV environments.
 
Ultimately, the goal is not to hide complexity entirely, but to make it manageable and accessible, so that developers can leverage the full power of DDS without being overwhelmed by its depth. 


Beyond in-vehicle systems, edge-to-cloud integration is becoming increasingly important in the SDV era. What is RTI’s strategy for enabling seamless, secure, and scalable communication between the vehicle, the edge, and the cloud?
Pardo        Indeed, we believe that embedded systems are no longer isolated. They are evolving into edge systems that are increasingly cloud-connected. In the SDV era, this connectivity might be continuous (for services like predictive maintenance or OTA updates), or intermittent (due to network availability or cost constraints). But even minimal cloud connectivity is essential to collect telemetry, manage software updates, and enable fleet-level intelligence. These cloud-integrated workflows are becoming central to how vehicle OEMs deliver value to users and generate ongoing business. 

RTI Connext already provides key technologies for secure, high-performance edge-to-cloud integration. For example: 
▶ RTI Real-Time WAN Transport enables efficient communication over public networks, even under high-latency or lossy conditions. 
▶ RTI Routing Service allows data to be selectively forwarded, transformed, and bridged between domains, including between vehicles, edge nodes, and cloud-based 
systems. 

Together, these tools enable developers to connect SDV platforms with cloud-native applications without sacrificing real-time behavior, scalability, or security. 

That said, our strategy goes beyond tooling. We're actively building a more comprehensive edge-to-cloud solution that improves scalability across large distributed systems, provides deeper integration with popular cloud platforms and offers better observability, configuration, and lifecycle management.
 
While we’re not ready to publicly announce the full scope of these developments, we encourage those interested to reach out directly. We’re happy to share the details, and in many cases can offer early access to these capabilities. 





Connext Drive Architecture Stack



Do you envision SDV architectures moving toward fully centralized compute models in the future, or do you think hybrid distributed models will continue to play a key role? How does RTI’s middleware adapt to support both centralized and distributed computing environments?  
Pardo        It depends on the system. If you’re thinking about SDV architecture in the context of passenger vehicles, then yes, there’s a clear trend toward centralized compute models. This helps reduce hardware costs, simplifies wiring and deployment, and makes it easier to manage software across the vehicle lifecycle. 

But if you broaden the scope to include vehicle-like systems, such as, construction equipment, mining vehicles, trains, ships, aircraft, or spacecraft, then distributed architectures will continue to play a key role. These platforms often have physical constraints, functional partitioning, and operational safety requirements that make decentralization the more practical and reliable choice. 

Regardless of how computation is organized within a single platform, vehicles will still need to communicate with other vehicles, infrastructure, and cloud-based services. From a broader system-of-systems perspective, the global architecture remains inherently distributed.
 
This is why supporting both centralized and distributed deployments is essential. It is also something Connext is fundamentally designed for. 

Connext enables this flexibility by supporting a data-centric architecture, where applications interact through publish/subscribe and request/reply patterns, independently of deployment topology. At runtime, Connext automatically discovers endpoints and selects the most efficient transport for each data flow: 
▶ If components are on the same compute node, Connext uses shared memory and zero-copy transfers for maximum performance. 
▶ If the data needs to go across a vehicle network, it uses optimized transport like UDP multicast. 
▶ If a large payload is sent to the cloud, Connext can apply compression or throttling, adapting to available WAN bandwidth and latency. 

The key advantage is that these decisions are made at deployment and configuration time—without changing application code. This enables the same software components to be reused across centralized ECUs, distributed compute nodes, and cloud-connected edge systems, supporting a wide range of SDV and mobility use cases. 

Because of this, Connext provides the abstraction and runtime intelligence needed to support both architectural styles, making it a future-proof choice as SDV systems continue to evolve. 


How does RTI support OEMs and Tier 1 suppliers in accelerating and streamlining the software development cycle for SDVs?
Pardo        RTI supports OEMs and Tier 1 suppliers in accelerating and streamlining SDV software development through the RTI Connext Drive framework, which was specifically designed to address the unique challenges of building SDVs. 

Connext Drive includes more than just core middleware. In addition to the Connext Core SDKs—both Pro, for high-performance and feature-rich platforms, and Micro, for resource-constrained ECUs—it provides a complete set of tools and integrations to simplify the development lifecycle: 
▶ Development and Deployment Tools. These include tools for visual configuration, QoS tuning, system monitoring, record/replay, and automated testing.  
▶ Integration Kits for popular automotive platforms/ standards as well as access to open-source community components: AUTOSAR Classic and AUTOSAR Adaptive ROS 2. 
▶ Tools to support deployment over TSN networks. 

These kits reduce the time and risk involved in integrating DDS into existing automotive stacks, enabling developers to adopt a data-centric architecture without reinventing infrastructure.
 
Connext Drive also includes Support for Safety and Security. It supports systems up to ASIL-D (ISO 26262) and includes support for ISO 21434 cybersecurity standards. This is critical for enabling safe and certifiable deployments in production vehicles. 

Overall, RTI's approach is to deliver not just a communication library, but a complete, production-grade framework that helps OEMs and Tier 1s: 
▶ Accelerate development with pre-built components. 
▶ Simplify integration into heterogeneous environments. 
▶ Ensure scalability, safety, and security from the start. 

This enables teams to focus on delivering differentiated vehicle features, rather than building or maintaining the underlying infrastructure. 


Practical references often speak louder than theory. Could you share any publicly referenceable customer stories or collaborations? Are there any memorable insights from partnerships in specific regions or markets?  
Pardo        In automotive, RTI works with over 25 vendors who use its technology to accelerate their SDV programs. Today, RTI is in production with 10+ vehicle manufacturers around the world who rely on RTI software to design zonal, ADAS and telematics architectures as they evolve in the software-defined era. RTI technology provides OEMs with an essential component for a variety of reference platforms from leading Tier-1 suppliers and runs in over 1 million vehicles on the road today. 

More recently, RTI announced that XPENG has selected Connext Drive to provide the core communication technology for its next generation E/E vehicle architecture. Starting with the 2026 production models, Connext Drive will manage the complex data distribution in XPENG vehicles, supporting the company’s mission to create smarter, more efficient and future-ready vehicles equipped with the latest technologies. 

RTI’s communication framework allows automotive customers to manage risk, enhance scalability, and increase modularity and reusability while meeting the highest levels of safety and cybersecurity standards. Connext Drive meets all major software safety standards including ISO 26262 ASIL D, ISO 21434 and ASPICE CL1. 


RTI has established a strong presence in Europe and North America. What plans or organizational strategies are in place to expand into Korea and the broader Asia-Pacific automotive market?  
Pardo        RTI operates on a global basis and supports our diverse customer base - including leading automotive companies across the U.S., Europe, and the Asia-Pacific region - through both our headquarters and regional offices. In the Asia-Pacific region, our Singapore office plays a central role in supporting numerous automotive customers. Additionally, we have a growing team in China, reflecting our ongoing commitment to expanding our footprint in the region.
 
We are still in an expansion phase in Asia-Pacific and anticipate establishing more local coverage in several key markets to better serve our customers and meet increasing demand. Beyond our internal teams, RTI is also actively building a strong ecosystem of solution and integration partners. This helps ensure that we can deliver tailored support for regional and local markets while fostering innovation and scalability in our automotive solutions.