Software Is Critical to the Modern Vehicle

Over the last 30-40 years the use of software within an automotive context — whether measured in terms of the number or complexity of functions — has gone from simple engine management systems to being all pervasive within the vehicle platform. And the increase shows no signs of slowing!

Hence the statement “software is critical to the modern vehicle” is, probably, not controversial.

The AUTOSAR Classic Platform has been developed in response to the increasing complex requirements of automotive software and can be characterized by support for hard real-time, high safety, low resource availability ECUs and is hence well suited to traditional automotive use cases. The Classic Platform remains the obvious choice for functional automotive ECUs — those ECUs directly connected to sensors and actuators that rely on the low-resource usage and real-time properties of Classic. However there are a number of clearly identifiable trends driving future growth of ECU development, and hence of E/E architectures, that can be summarized by the CASE requirements:

• Connectivity — Data collection for fault management and ADAS improvements, dynamic connectivity both on- and off-vehicle, real-time updates of road conditions, software updates over the air, …
• Autonomy — Driver assistance and highly autonomous systems using computer vision, sensor fusion, …
• Shared ownership — Broker services, Mobility as a Service, apps, …
• Electrification — New powertrain requirements, battery management, …

The CASE for Adaptive?

The CASE requirements driving development of next-generation automotive E/E architectures are promoting change in automotive ECUs at an ever increasing pace:

• Autonomy requires the processing of large data sets, e.g. for computer vision or the derivation of a real-world object model based on multiple sensor input. Large data demands intra-application parallelism to exploit the inherent concurrency in processing such data and to produce solutions in time. High performance computing requires the platform to support novel hardware architectures, e.g. heterogeneous processors, GPUs, many core, processor mesh architectures, etc. Such hardware requires that platform and programming language support if applications are to scale to be able to benefit from new HW and dynamic environments to which they are deployed.
• Connectivity, whether from the vehicle to the outside or vice-versa, requires both dynamic communication and the distribution of large data efficiently, e.g. ADAS results in large data sets, e.g. for image processing, that must be processed efficiently in parallel and communicated with ad-hoc partners.
• Dynamic high communication bandwidth resulting from new technologies, e.g. Ethernet, means communication bandwidth is not a limiting factor.
• Mobility as a Service demands flexible software that is secure but updatable to reflect new functional or regulatory requirements.

Thus the need for a new high performance, highly flexible platform supporting HPC, dynamic communication and incremental change — a new platform and not Classic.

Classic and Adaptive: A Comparison

It’s convenient to classify current automotive ECUs as either functional or infotainment ECUs.

The Classic Platform is ideally suited for functional ECUs. These are characterized by hard real-time (with deadlines potentially in microsecond range and where meeting all deadlines can be critical to correct operation of the ECU) with strong safety requirements — ASIL-D. They also typically have low resource availability (whether CPU, RAM or Flash) that requires static configuration for optimal usage.

In contrast, infotainment ECUs operate in a high resource environment, typically due to the requirements of the user interface. An infotainment ECU is generally not a real-time — deadlines, if they exist at all, can be in the 100’s of milli-seconds and not critical to the platform if it never happens at all as functionality is not vital to vehicle operation and/or safety. Finally, an infotainment typically running on an embedded PC running full-blown OS, e.g. Linux, rather than an automotive OS.

Adaptive AUTOSAR is designed to bridge the two worlds; it’s characterized by soft real-time (deadlines in the millisecond range and occasional missed deadlines are not catastrophic) and some safety requirements — AUTOSAR intends ASIL-B though implementations can choose to be conformant to higher ASIL. However unlike Classic it’s intended for a high resources environment using a multi-core, dynamic OS, e.g. QNX.

Implementations of an Adaptive Platform can be used through “planned dynamics” that limit dynamic aspects of the platform in favor of predictabilty. Planned dynamics might restrict dynamic memory allocation to the startup phase, pre-determine the service discovery process, fix core allocation or ensure access to pre-existing files in the file-system only.

A Replacement for Classic?

The Adaptive Platform does not replace Classic… instead AUTOSAR expects that Adaptive and Classic Platform instances will co-exist within a vehicle as the platforms address different problem spaces. Adaptive ECUs support dynamic communication and high performance through highly parallel architectures combined with dynamic software change for application independent updates whereas Classic ECUs support high safety, real-time software within severely resource constrained ECUs.

However, Adaptive and Classic Platform share a common Foundation containing core elements for both platforms such as core requirements, SOME/IP middleware, etc. The Foundation makes interoperability between Classic and Adaptive possible; for example, providing a way to connect the signal-based communication of Classic with the service-oriented communication of Adaptive.

AUTOSAR also includes additional elements that support the use of the two platforms. The Adaptive Platform includes a Demonstrator (APD) build in conjunction with specification to validate the platform in conjunction with development of the specification. The Classic Platform includes an Acceptance Test (AT) suite and pre-defined Application Interfaces (AI).

Classic or Adaptive? Can I have both?

The Foundation defines AUTOSAR requirements; some are common to both Classic and Adaptive whereas others are unique to one platform.

For example, the core AUTOSAR requirement to support deeply embedded systems applies to Classic only, whereas the requirement to support high-performance computing applies to the Adaptive Platform only. Neither says that Classic cannot support high-performance nor Adaptive deeply embedded just that the strengths of the respective platforms are different.

To exploit the strengths of the Adaptive and Classic platforms a single system can consist of both types of ECUs and AUTOSAR provides a standardized software interface, e.g. for communication and persistent storage. So while Classic and Adaptive provide for portable software between different platform implementations those platforms can use completely different approaches as exemplified by the signal-based communication of Classic and the service-oriented communication of Adaptive.

Classic is intended for low-resource ECUs so it has much simpler hardware requirements than Adaptive; a single address space requires no virtual addressing, however, in Adaptive the more sophisticated isolation between applications requires MMU support. Additionally, the Classic Platform is completed statically configured; all tasks, signals, etc. must be defined at configuration. In contrast, Adaptive supports dynamic communication and concurrency giving higher flexibility for applications to respond to their environment or scale to adapt to the deployment machine. That flexibility comes at a cost, however. In Classic, applications are executed directly from Flash but in Adaptive they must be loaded from a filesystem into RAM. This does mean that Adaptive can support incremental change of the software without reflashing the entire ECU.

So is Adaptive just a dynamic RTE? Yes… and no! In the Classic Platform the RTE performs two roles; scheduling of application SWCs and communication between application SWCs. These roles exist within the Adaptive Platform (OS/Execution Management and Communication Management respectively) but there is no direct analogue of the RTE in Adaptive Platform.

RTA-VRTE

The development of AUTOSAR Adaptive Platform is motivated by requirements for high-performance computation and high-bandwidth communication required by forthcoming automotive systems. The Adaptive Platform fills the niche between deeply embedded (Classic) and soft/non-realtime (infotainment) ECUs by opening up the design to dynamism both in the software set on a machine and in the capabilities of the software. The Adaptive Platform has introduced the idea of “planned dynamics” to provide constraints on dynamism to be better suited to the automotive use-case.

Adaptive AUTOSAR is an excellent building block that augments the solid foundation of the Classic Platform with support for a flexible high-performance computation. However, Adaptive AUTOSAR does not (yet) address all the issues that are relevant for the creation of E/E architecture resulting from the long-term challenges. Hence ETAS, together with Bosch, is building the RTA-VRTE product to address the challenges. RTA-VRTE derives from and extends the Adaptive Platform providing functional extensions for a rich and expressive environment for software execution including vehicle-specific functionality for diagnosis, lifecycle management., etc. RTA-VRTE will include a hypervisor that enables support of the Classic/Adaptive-mixed use case, e.g. a high-performance micro-processor using the hypervisor for isolation of CP/AP domains. Here the RTA-VRTE’s hypervisor supports the domain controller type-ECU where multiple ECU functionality is aggregated onto a single HPC node.

An Early Access Programme is available for RTA-VRTE that provides a combined support and Adaptive training package with access to RTA-VRTE development releases in a simple “ready-to-go” development environment as a virtual machine containing the development/build environment and a selection of example applications for QNX/Linux based target virtual machines. Contact ETAS for more information and availability.