Designing an Autonomous Vehicle for Real-World Performance

In the Automotive market, developing an autonomous vehicle comes with huge risk and uncertainty. There are several well-funded competitors pulling in different directions, the business model is unproven, and the technology is still under development. Most of the traditional automotive companies are moving their focus from hardware to software, while exploring new business models and creating their own solutions as they go. 

But software in an autonomous system is a complex problem. Increasingly, the automobile has become a network of interconnected computers - some of them are powerful CPUs, while others are low-end microcontrollers. Each of them processes data, makes decisions and/or competes for resources. When image and LIDAR processing, sensor fusion, driving control and teleoperations are included, the number of interactions grows and so does the complexity of the system.

The technologies required to solve this ever-growing problem need to be able to share data in real-time and handle large volumes of data with different priorities, sources and destinations, all while creating a robust solution that will not fail in ways that could result in an accident. This is another very important aspect of this new software adventure for both traditional and non-traditional automotive competitors -- building software in a safety-critical environment has a challenging list of requirements, and not all software solutions are up to the task. So, which autonomous vehicle software solutions are actually prepared to handle the wide-ranging requirements for building tomorrow’s vehicles?

The Four Connectivity Options in Today’s Market

One of the best ways to mitigate these risks is to ensure autonomous vehicle developers can rapidly innovate and adapt to changing market conditions and advances in technology. By selecting the right software platform strategy early in the development process, companies can ensure they have the right foundation to stay ahead of the competition. There are four different approaches to select such a technology:

The first option is to leverage cloud and enterprise technologies that were developed for large-scale systems and would fit in solutions like teleoperations. However, those solutions are not optimized for autonomous systems that need real-time response. Let’s imagine an autonomous driving scenario where you detect obstacles using LIDAR. In this case we need to minimize the latency between the LIDAR and the obstacle detection application. If we use a cloud-based solution, we add unnecessary latency for communication that might be running in the same ECU. Not to mention the amount of data being sent over what would most likely be a metered connection, back and forth. In addition, most of them have a server or broker-oriented architecture that creates a single point of failure and could cause a huge risk to the robustness of the system.

The second option is to build a solution from scratch. Auto manufacturers sometimes feel that their data-exchange requirements are so specialized that existing solutions cannot address them. They need multiple data flows that are very specific: small high-priority data like brake information or alarms, large streaming data needed in multiple locations, commands and responses, data needed only when based on given conditions, etc. But is that true? Are those scenarios so unique that they necessitate ad hoc implementation? Those scenarios are common not only to Automotive use cases, but also any real-world autonomous system (planes, trains and Aerospace and Defense vehicles, for example). So, creating a connectivity solution in-house could mean spending tons of resources in solving a problem that is not the company’s best-selling feature and that others have solved already. In most cases, the value proposition that automotive companies provide is not how to integrate software or how to achieve real-time networking performance - it more often resides in their high-level algorithms and features. And those unique algorithms and features are only able to add real value if when the underlying infrastructure is providing the necessary data in a timely manner.

The third approach is to pick one of the new automotive platforms like AUTOSAR Adaptive, ROS 2, Apollo, etc. and build a system around them. Although some of them are new or market-specific, these technologies are already part of the Automotive ecosystem and can provide useful resources for the thousands of people using them. For instance, you can find handy graphical applications in ROS to visualize video, radar and LIDAR. However, the problem lies in which one is the best selection. There are many aspects to consider: integration advantages (e.g., which one is the most used by my providers?), best performance and robustness, path to certification, security, etc. But once a solution is selected, what if the technology requirements change? It’s critical that whichever solution autonomous vehicle developers pick is one that will withstand any new future use cases in this evolving industry.

The fourth approach would be to use a foundational technology that is standard-based and proven in critical systems. Several of the automotive platforms mentioned above use the Data Distribution Service™ (DDS) Standard as their backbone. DDS has been used for decades in mission-critical projects in different markets, from Aerospace and Defense to Healthcare. This standard connectivity solution delivers:

• Real-time performance
• Fine-grained control of data, including real-time publisher-side filtering
• Quality of Service (QoS), which covers reliability, durability, deadline and liveliness
• Security, versatility and interoperability between vendors using a common wire representation, known as Real-time Publish Subscribe (RTPS)

DDS is designed to allow easy integration of different technologies so, maybe, there is one last option: Integrate one or more of the above, using each one where it makes the most sense to achieve the critical requirements of your system, without reinventing the wheel.

Layered Databus Architecture

An autonomous vehicle is not a single isolated system. It is a system of systems that combines different hardware and software solutions, business logic, markets, vendors, business models and more. It requires a unique architecture, one that enables real-time performance at the edge while integrating different operational domains and enabling interoperability across components built by various companies, even competitors. It must be a secure solution to protect not only against malicious attacks, but also to protect business logic. In addition, it is very important that this architecture is able to handle a large number of participants in the system. In other words, it needs to be scalable. Finally, this solution needs to be (at least partially) certifiable, since many subsystems will require certifications, such as ISO 26262.

Figure 1: Automotive layered databus architecture

In Figure 1, we introduce a layered databus architecture that addresses the requirements above, and more.

First of all, this architecture enables the creation of different isolated operational domains. Each of these domains can contain a DDS databus that enables the exchange of data within that domain. That data can be configured so that only the components that need the data will receive it, reducing the resources wasted in unnecessary data transfer. This in-domain communication is highly configurable, thanks to the over 20 QoS properties available. These properties enable different use cases, such as: high-throughput large data; low-latency data; reliable or best effort; fault tolerance; and more. This allows us to achieve the edge performance that is needed.

Because DDS is a standard, it provides an easy way of defining standard data models which would be shared by different competitors. But at the same time, it allows those data models to expand to add specific details that make the vehicle unique, by using Extensible Types. And, since DDS is already used by automotive standard technologies, auto manufacturers can take advantage of any parts of AUTOSAR or ROS that are needed with minimal changes. In addition, when data is needed between different domains, it is automatically relayed based on its content using a software gateway (a DDS-based tool). In that gateway, we can perform transformations and adaptations so the data obtained in one domain can be understood in other layers. For instance, when the data is transferred outside the car, we can add a unique identifier (e.g., a license plate number), or transform the speed into a different metric system. This enables integration and interoperability across operational domains.

Figure 2: In an autonomous vehicle, it is not enough to secure just the system, host or the network. The DDS Standard enables dataflow security which secures the data itself, protecting the data while enabling high performance and scalability.

Fine-grained security, as defined in the DDS standard, allows the system to authenticate, control access, encrypt and tag data, and log all unsuccessful interactions. All of these are independent of the transport security options. This allows developers to apply different security configurations to each of the operational domains. On one hand, in high-performance, in-car communication, developers shouldn’t waste time and resources encrypting all data, but they should control the diagnostic ports. For instance, when connecting a known application, this ensures that it only reads some pre-agreed information, but it can never maliciously inject data. On the other hand, when exchanging some data over the internet with the teleoperations unit, it’s critical to use a secure transport and encrypt everything. This architecture protects the system against attacks in an efficient way, and prevents other vendors or external applications from receiving or sending data they should not.

Finally, this architecture isolates those parts of the system that need a higher certification level. It’s very likely that there will be a hybrid system with some parts using up to ASIL-D (such as vehicle control), while others are not certified at all – l (such as teleoperations). This architecture enables the use of the same connectivity solution and design pattern for all of them, but adds the ability to deploy different implementations depending on the safety requirements. And at the same time, it allows you to exchange data safely across different certification levels, thanks to end-to-end QoS settings like deadline, liveliness, or reliability.

Many of the world’s top automotive companies are selecting this standard-based path because they do not want to be tied to just one approach. It’s important to select a future proof architecture that integrates different technologies and standards, provides a secure and certifiable solution, scales to hundreds of thousands of data points, performs in real-time and can evolve to accommodate unknown future needs. This is the automobile of the future.

About the author

Sara Granados Cabeza has over 10 years of experience in software development, middleware, hardware programming and computer vision. She joined RTI in 2011 as a Software Engineer on the RTI Tools team, where she developed the RTI DDS Toolkit for LabVIEW and the C/C++ Distributed Logger. For the past few years, Sara has been the Field Application Engineer in the EMEA region, where she helps customers integrate RTI Connext DDS in their systems.

Sara graduated with an MS degree in Computer Engineering and obtained her Ph.D. in Computer and Networking Engineering (Cum Laude), both from the University of Granada, Spain.