Consistent with the growing significance of safety and security for vehicle development, the development partnership AUTOSAR (AUTomotive Open System ARchitecture) published a further release of its specifications. The concepts introduced with Release 4.0 have added technical and functional improvements.
As functional safety is becoming one of the most important topics in automotive development, AUTOSAR addresses the topic of ISO DIS 26262 in Release 4.0 with a series of new features that allow both safety and non-safety applications to operate on the same controller. Additionally, AUTOSAR embeds several security-related features into its software architecture.
AUTOSAR paves the way for innovative electronic systems that further improve performance, safety, and environmental friendliness. By now AUTOSAR has become a de-facto standard for embedded automotive software architecture, but in its previous specification releases there was no explicit focus on safety and security applications. Thus AUTOSAR Release 4.0 contains a large number of new features that were demanded by the different applications of domains the AUTOSAR standard is covering. New concepts introduced in Release 4.0 have added technical and functional improvements and extensions to the main areas including functional safety, architecture, communication stack, methodology and templates, and application interfaces.
Because of the persisting trend of the increasing number of electronically controlled functions within an automobile, the amount of software in a car increases. The automotive industry answered the challenge of functional safety with elaborating the standard ISO DIS 26262, which targets avoiding these risks by providing feasible requirements and processes. Even though the terms safety and security go hand-in-hand, it is important to distinguish them. Safety means functional safety of a system, so that it behaves as specified with absence of unreasonable risk due to hazards caused by malfunctioning behavior, whereas security means the protection of a system against undesired access or usage.
Functional safety features
With Release 4.0, AUTOSAR substantially supports building automotive safety-related applications. This is an outcome of an extensive analysis of the guidance from ISO DIS 26262, which requests the detection and handling of safety issues like hardware faults at runtime, requirements on timing and logical order of execution of applications, communication protection of applications, data corruption, and wrong service calls.
AUTOSAR addressed those issues noted above via the following features:
Memory partitioning provides a fault containment technique to separate software applications from each other in order to avoid any data corruption between applications. This feature allows safety and non safety applications to be implemented on the same ECU.
Defensive behavior is a solution preventing data corruption and wrong service calls in the AUTOSAR basic software on microcontrollers having no hardware support for memory partitioning. In this way, the defensive behavior of basic software modules provides a low-cost efficient way to prevent fault propagation for applications with low and medium integrity levels.
Support for dual microcontroller architectures targets detection of faults in the core microcontroller by a secondary unit.
Program flow monitoring controls the temporal and logical behavior of applications by checking, at specified points of code execution, if the timing and logical order of execution requirements are met.
The end-to-end communication protection library is providing a state of the art safety protocol at application level to protect applications against the effects of faults within the communication link (e.g. random hardware faults or systematic faults within the software implementing the AUTOSAR communication infrastructure).
Time determinism and timing constraints modeling allow modeling and implementing proper and deterministic timing behavior of applications and basic software. They include synchronized time bases (i.e. a "global time") across ECU networks, synchronized execution and deterministic timing of application software components, as well as support for controlling the timing behavior and detection of timing violations at run-time. The AUTOSAR specification of timing extensions provides means to specify timing constraints like end-to-end (e.g. sensor-to-actuator or communication) delays, minimum/maximum execution times of runnable entities, or constraints on the triggering rate of events.
The AUTOSAR basic software provides modules to test hardware (e.g. RAM-Test, Core-Test) and to check the integrity of stored data (e.g. EEPROM Manager).
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.