This post aims to provide an overview of the technologies that we foresee starting being deployed in series cars in 3 to 5 years from now, and highlight some of the drivers for these technologies. The post is geared towards networking technologies although we will start from the needs of applications/software. Caveat: let’s us keep in mind that “it’s difficult to make predictions, especially about the future” 😉 Remember, 10-12 years back, few of us had that vision of Ethernet as the future of high-speed in-vehicle communication and the future of FlexRay looked very bright!

The prominent automotive standard today is Autosar, which has been developed for the last 15 years with great efforts. It provides a comprehensive (though complex!) computing environment along with a development methodology for automotive electronics. If Autosar is today the de-facto standard, by far, not all ECUs in today’s cars are Autosar compliant.

Autosar Classic platform

The initial computing environment specified in Autosar is meant for real-time control tasks, it offers a well-defined task scheduling model allowing for the combined use of static-cyclic scheduling (i.e., table-drive scheduling) and Fixed-Priority Scheduling (FPS). Since the early 2010s, it also provided support for multi-core ECUs and safety requirements e.g., with memory protection, partitioning among tasks having different criticality levels and advanced mechanisms like making sure a task does not use up the CPU more than it should. However this Autosar platform is fully static in the sense that new tasks cannot be spawned at run-time, and the flexibility comes mostly from predefined mode changes.

This does not suit the needs of applications requiring dynamicity, stream-based communication (e.g., audio, video), off-board communication for infotainment or Over-the-Air (OTA) update, and the support of a variety of technologies coming from general-purpose computing (e.g., hypervisors with Linux or Android in virtual machines, etc).

Autosar Adaptive platform and SOA

This led to the creation of a new platform called Adaptive Autosar (vs the Classic Autosar). Adaptive Autosar relies on a standard POSIX environment. Beyond the mere scope of Posix’s scheduling features (e.g., a round-robin scheduler and a fixed-priority scheduler), the ability to guarantee a minimum percentage of the CPU time to a group of threads making up a software container, like offered by QNX Adaptive Partitioning Scheduler (APS), can prove very useful to guarantee the execution behavior in a setting where the software will be updated over the vehicle’s lifetime.

Importantly, Service-Oriented-Architecture (SOA), a game changer in the automotive industry, can be developed on top of Adaptive Autosar.  SOA facilitates the implementation of partial over-the-air (OTA) software update  as well as  the deployment of new “aftermarket” services creating new revenue streams for OEMs and third-parties, and more value for the end-customers. SOA allows for the execution of services into the cloud, depending on the availability and quality of the connectivity, or possibly to interact with the road infra-structure and neighboring vehicles. Considering only the in-vehicle computing platform, another crucial advantage of SOA is that services, as long as performance, safety and security constraints are met, can in principle be located anywhere within the vehicles allowing for better ressource-usage optimization and more flexibility in defining vehicle variants.

Foreseable networking technologies

This leads it to the last part of this post about the technologies we foresee will be deployed in many series cars in a few years from now, let’s say in 5 years from now:
  1. Combined use of classic and adaptive Autosar ECUs, with still non-Autosar ECUs in many cases,
  2. An Ethernet TSN backbone with SOME/IP as the main protocol for SOA. Alternatively, the DDS middleware, which is making its way into Autosar may be chosen by some although how to map the very flexible timing QoS that can defined in DDS to TSN mechanisms is a question that still needs to be addressed (see this presentation).
  3. For audio/video transmissions, it is likely that different solutions will co-exist: LVDS, Ethernet TSN with AVB/CBS, MOST, etc.
  4. Legacy buses will remain widely used: CAN (FD), LIN and FlexRay. The latter will progressively disappear, replaced by TSN protocols, possibly by the time-triggered IEEE802.1Qbv protocol. Some OEMs will start introducing 10BASE-T1S, standardized in IEEE802.3cg, a low-cost 10Mbit/s bus-based implementation of Ethernet, which is a building block towards the vision of an “all IP car” (see this presentation).
  5. In Ethernet TSN networks, safety and security will be enforced by a combination of mechanisms such as IEEE802.1CB (frame replication), IEEE802.1Qci (traffic policing), the proper use of priorities to “segregate” security/safety-critical streams and non-critical/less-trustworthy streams, and security policies implemented in switches (e.g. with deep-packet inspection) and gateways.
  6. In terms of timing QoS, TSN already offers a wealth of possibilities, with 8 priority levels and shaping mechanisms (in IEEE802.1Qav, Qch and in the upcoming Qcr). An open question at this time is the extent to which the time-triggered IEEE802.1Qbv protocol will become popular. Indeed, disregarding hardware and software components, the need for clock-synchronization is in itself a disadvantage because of the complexity it brings and the coupling it introduces between tasks and messages (see this presentation), and between OEM and ECU suppliers. On the other hand, time-triggered communication simplifies the design of applications with stringent timing and dependability constraints, and allows a better understanding of the dynamic behavior of the network.

Points 1-4 of this picture are in line with the FACE architecture by Renault group (see this presentation) or the centralized architecture by Volvo. In our view, this is good baseline set of technologies to consider, knowing that specialized needs may require specialized technological solutions not listed here.

And what about processors & ECUs ?

A first trend is the increasing use of powerful System-on-Chips (SoCs) with a large diversity in the number of cores and specialized co-processors. A very good illustration is BMW’s Autonomous Vehicle roadmap which relies on 3-core (Aurix), 8-core (Intel Denverton), 9-core (Renesas R-Car) and even 24-core processors (Intel Xeon). Because of the move to SOA, those processors should be as general-purpose as possible to be able to execute efficiently diverse kinds of services, to be usable in different contexts and functioning modes. This processor should also support virtualization, to offer a consistent computing environment to the application and allow the migration at run-time of functions from one ECU to another.

Is this picture in line with your understanding of how automotive in-vehicle networking technologies are going to evolve and the drivers for it?  Do you see any important pieces of the puzzle missing?