For Software Engineers, this uncertainty also affects how we design and develop software for this expanding market. The goal is to create a hardware and software architecture that’s future-proof and can adapt to changing requirements. But how?
There’s a trend in the market to reduce the number of ECUs and add zonal controllers and central units. However, in many of today’s deployments, the software is highly coupled to those specific ECUs, in-board transports, or proprietary stacks. Migrating to a different approach can require a huge effort, unless you choose software carefully.
To make a next-generation E/E system adaptable, there are four main rules to follow:
Decoupling: A successful future-looking system should be built on a framework that abstracts the OS and hardware-specific details. This way, each software module is developed once and deployed effortlessly an infinite number of times. The key to success when decoupling is minimising the abstraction layer’s overhead, while transparently exploiting hardware and OS capabilities.
Flexibility: When designing a Level 2 vehicle, you want it to continue to behave as expected as you add Level 4 capabilities. The trick here is to define data interfaces so they can change, and they will. Fortunately, this step can be as “easy” as using a flexible data model.
Customisation: A cumbersome approach is using a different technology for each kind of data sent. This might seem to offer more performance at first, but it increases the complexity of the system and ties you to the hardware. A better option is a single solution that is transport agnostic and can simply be tuned to adapt to the different dataflows in your system, taking full advantage of the underlying technologies and optimising performance based on the data requirements. (Figure 2)
Integration: You probably have legacy systems that you want to keep, and there are many innovative technologies out there that you want to include. The key to success when integrating different systems is to achieve a balance between the features they provide, how mature they are and the complexity they add.
Building a system to last is not easy, you cannot be the best unless you design a system that can adapt and scale as you grow and handle unknown requirements as they evolve. And we have the best short-cut to that all-important finish line where your EV enters the market.
Figure 1: Distributed ECUs – Domain Centralization – Software Defined Vehicle: Computing centralization is a “must do” to increase functionality
Communications framework
RTI Connext Drive is an automotive-grade communication framework that’s based on the popular and proven Data Distribution Service (DDS) standard. It provides an abstraction layer that eases development by hiding hardware- and OS-specific configurations while, at the same time, it goes beyond that standard and provides key features to manoeuvre through the winding roads ahead.
As you develop a new architecture, the last thing you want is having to redo half of it whenever there’s a new board or OS you want to use. Your software should be as independent as possible and Connext Drive enables that.
Each module will define interfaces using standard Object Management Group (OMG) IDLs, creating a data-centric architecture. Connext will then automatically and dynamically connect those modules with compatible interfaces and requirements using a Discovery feature. Moreover, these interfaces generate platform-independent code for your programming language of choice. This architecture paradigm abstracts the point-to-point connections that Connext creates and integrates easily with well-known design tools.
This abstraction creates two additional advantages. First, your software could be deployed in any hardware, reducing time and costs. Second, Connext will take advantage of the underlying infrastructure transparently for you.
Figure 2: Dataflow in an electric vehicle system
Consider this example: Your first deployment uses multiple smaller ECUs connected over Ethernet. Here, Connext uses Ethernet and UDP to connect the modules. Then the next EV series includes a more powerful central GPU/ECU with shared memory, shifting to a zonal architecture. Just deploy several of those modules in the new GPU, and Connext will swap to shared memory transparently with no code changes.
Flexibility and adaptability
To reduce development effort, you should look to reuse your software modules for different EV series. For that, each module needs the ability to use either sophisticated sensors, when available, or simpler ones, if necessary. Besides, they must adapt to new functionalities and enable higher autonomy levels with minimum changes. Building on the data model, Connext Drive provides two key aspects to increase your EV’s software flexibility: first, the plug-and-play addition of new modules, and second, the ability to extend that data model.
The first aspect is provided thanks to data-centric design principles and the discovery capability as explained in the section above. The second aspect is provided thanks to the Extensible Types (DDS-XTypes).
When you define your data model, you want it to change and adapt to new data (from more sophisticated sensors) or new functionalities (from a new autonomy level). As in C++ or Java, with DDS-XTypes, you define your basic “class” and then create new “classes” inheriting from it. All those derived classes are potentially compatible with each other.
Figure 3: Datamodel
In Figure 3, our perceived object basic class contains the dark green fields. Each new advanced class adds one or more of the lighter green fields. This way, depending on the data available, the modules using that data, blue and orange boxes, will use only those fields that they understand and ignore the rest.
Dataflow Customisation
In an EV system, sharing data interfaces is not enough to shape the interchange since different data will have different requirements (reliability, latency, etc.). All modules need to agree on how to exchange data and Connext Drive provides over 20 Quality of Service (QoS) settings to help fine-tune communications. This way, a single connectivity solution can transfer any data, without requiring swapping technologies to achieve performance.
These QoS settings behave as a contract. When you create a reception module, you define your requirements: frequency, reliability, historical data, etc. Similarly, in the production module, you can define delivery period, persistency, repairing frequency, and more. When these modules discover each other, they exchange their contracts, and will only connect if their communication agreements are compatible.
This dataflow customisation transparently takes advantage of underlying technologies like Time-Sensitive Networking (TSN).
Figure 4: The DDS databus connects primary autonomy functions, such as sensor fusion and path planning, and shares a common data model across other systems and standards, including AUTOSAR Adaptive and ROS2
Integration
The automotive ecosystem is a huge and rich one. Many software and hardware solutions are available to ease development and accelerate productivity. That is why RTI is actively working in several automotive consortia (AUTOSAR, ROS 2, etc.) and collaborating with key market players (NXP, QNX, Vector, Elektrobit, etc.), with our goal being to facilitate integration and reduce development time.
This not only applies to in-vehicle communication but also our work in simulation and even gaming-engine companies to interconnect different business units easily. Imagine, for instance, having your in-vehicle data stored in a database without affecting the system’s real-time behaviour and then using that database in simulation or hardware-/software-in-the-loop testing. And this is just a small example -- the options are infinite, and the only limit is how far you want to pursue reusability and integration.
Conclusion
Using a data-centric framework that is not only standard but can also enable features like DDS-XTypes and customised dataflows allows the engineer to define a flexible and adaptable data model.
Our data-centric approach also enables different communication patterns like command and control, SOA, pub/sub, and more, making integration easier. This is why several standard organisations, including ROS 2 and AUTOSAR, have decided to use DDS as part of their frameworks. It’s also why over 200 automotive projects are relying on Connext as their communication solution.
Author details: Sara Granados Cabeza, PhD, is a Principal Field Application Engineer at Real-Time Innovations (RTI)
