Automotive Open System Architecture (AUTOSAR) is a standardized software development architecture used among automotive Original Equipment Manufacturers (OEM) and Tier 1 suppliers. Many of today’s ECUs are no longer straightforward to design or test due to new challenges brought by electric vehicles, autonomous driving, and connectivity. These major shifts result in the need to simplify complexities with the help of AUTOSAR. AUTOSAR allows ECU software components to be modular and reusable, offers a scalable ECU platform for multiple vehicles, and results in a shorter design time. These benefits drive OEMs to call for more AUTOSAR-compliant ECUs. For example, in an electric vehicle; the ECUs for E-compressors, On-Board Chargers (OBC), DC-to-DC converters, robust touch Human-Machine Interface (HMI) nodes, and advanced sensor nodes are now being implemented with AUTOSAR.
AUTOSAR architecture layered for modularity
As depicted in Figure 1, AUTOSAR has a layered system architecture to support modularity. Its bottom layer is a physical Digital Signal Controller (DSC) or a microcontroller (MCU) followed by the Basic Software (BSW), which is split into the service layer, ECU abstraction layer, and Microcontroller Abstraction Layer (MCAL). The layer above is the Run-time Environment (RTE) layer that ensures applications have a standardized interface to the lower layers while being able to interact with the upper application components and manage resources, schedules, and instances of the BSW. The application layer forms the uppermost layer and comprises numerous Software Components (SW-C) that perform functions pertaining to specific features of an ECU.
The AUTOSAR-standardized BSW supports various communication protocols including CAN/CAN FD, LIN, and Ethernet with the help of communication drivers, hardware abstraction, and service modules and is designed to be modular and reusable by many types of ECUs. The BSW also consists of a standard interface to support security features like cryptography peripherals, trust anchors, and external Hardware Security Modules (HSM).
An automotive software framework with scalability and reusability advantages
In an AUTOSAR stack, you need to leverage complex drivers to implement time-critical and low-overhead drivers to achieve real-time response. They are supported by the AUTOSAR architecture to interface non-standard drivers within the AUTOSAR BSW. This helps expand the capabilities of the BSW that are not defined by AUTOSAR. Software components of the application layer can also use complex drivers to interface with DSC’s peripherals and system resources. Complex drivers can support functions like motor control, digital power, robust touch functions, and advanced sensing and control designs.
As you move from a bare-metal or non-AUTOSAR application to an AUTOSAR-compliant design, the application-specific functions can be implemented as complex drivers which reduces development efforts during such migrations by repurposing functions from existing bare-metal design. Complex drivers can also be used to run proprietary algorithms and software functions that fall outside the scope of AUTOSAR specifications.
Another key aspect to consider is the standardization of the interface between the layers of the AUTOSAR architecture, which is considered a significant advantage. Engineers can pick different components of the stack readily from different vendors. Engineers can then incorporate these components easily as all of them comply with the AUTOSAR standard. Another advantage is that applications can be built on the AUTOSAR platform rapidly.
To make your AUTOSAR effort reusable the preferred controller family should be scalable in CPU performance, memory, peripheral set, and have an automotive development ecosystem. Another advantage can be gained if the development ecosystem supports both bare-metal and AUTOSAR-based designs, which will allow switching between the two in your platform according to performance and cost goals. Reusability of the AUTOSAR stack becomes easier across ECU configurations when the selected DSC or MCU families offer the same core, peripherals, and ecosystem.
Increased focus on security and functional safety in connected vehicles
In connected vehicles, it is relatively simple for OEMs to deliver firmware over-the-air (OTA) updates enabling the requirements of continuous improvements to vehicular performance and features. This helps prevent costly recalls and deploy fixes and upgrades as necessary. However, the advantage of easy updates and increased connectivity raise security concerns as the attack surface is expanded. Advanced security needs to be implemented in ECU designs to shield vehicles from attacks by malicious agents. Safety and security are becoming interdependent and a system must be secure to function safely.
Electrification development has increased the number of electronic and software components used. This in turn creates more vulnerabilities and potential failure areas. ISO 26262 functional safety standard has therefore taken on greater significance in electrical and electronic systems in series productions of road vehicles. In addition, OEMs are looking for zero defects as well as error minimization at the root cause and will eventually require systems with strengthened safety assurance. For example, the systems designed with Quality Management (QM) process will need to move to ASIL (Automotive Safety Integrity Level) A while those currently designed with ASIL A level will scale up to the higher ASIL B, C, and D levels.
What will it take to achieve functional safety?
Safety-critical automotive ECUs must be developed and certified as per the ISO 26262 functional safety standard. This entails the identification of hazards and safety goals when designing a vehicle, followed by defining safety goals and mechanisms applicable within the system. Hardware features or diagnostic software are subsequently designed and developed to mitigate any unacceptable risk associated with a system fault.
AUTOSAR support for functional safety:
The BSW in the AUTOSAR architecture provides a standard interface that accommodates safety mechanisms and security requirements of ISO 26262. These safety mechanisms help prevent interference between software components that are specific to the timing, execution, and exchange of data. AUTOSAR’s stack uses standard interfaces for performing diagnostics for its CPU, Flash, and RAM and verifying application integrity. These interfaces also support Cyclic Redundancy Checks (CRC), which are used to detect and diagnose underlying causes of communication errors.
Nonetheless, these measures are limited to generic use cases. In other scenarios, complex drivers may be required to be added to the BSW in the form of diagnostic software routines for specific applications and device peripherals. For example, a Fail-Safe Clock Monitors (FSCM), which are of great help for checking the clock’s integrity and provide an automatic switch to the backup oscillator in the event the primary oscillator fails. Such peripherals should be implemented using complex drivers, which leverage the hardware safety features of a functional safety-ready or compliant DSC. In addition, ISO 26262 functional safety packages are now offered with diagnostic libraries by controller vendors. These libraries can be integrated as complex drivers and added to the BSW.
The AUTOSAR BSW is comprised of the Hardware Test Management Start-up and Shutdown (HTMSS) module that interacts with a set of diagnostic routines known as the Microcontroller Specific Test Package (MSTP) (See figure 2). The former facilitates interactions between software components and schedules diagnostics performed via the MSTP. The latter leverages the diagnostic library provided by controller vendors but needs to be configured separately into the AUTOSAR BSW. Together, the two perform core functions required to run diagnostics whenever an ECU starts or shuts down. The diagnostics serve as part of the functional safety mechanism.
Many controller vendors are providing functional safety-ready and compliant MCUs or DSCs with comprehensive functional safety packages, which offer diagnostic libraries, functional safety compilers, and supporting collateral for the ISO 26262 certification.
Robust Security
AUTOSAR supports Secure Onboard Communication (SecOC) – an open standard used for secure communication between ECUs over CAN and LIN – along with two more secure communication protocols, namely Transport Layer Security (TLS) and Internet Protocol Security (IPsec).
The core security aspects in AUTOSAR are covered by the Crypto Stack (figure 3). With its access to cryptographic primitives and key management, it can be used to deploy secure firmware updates and other secure use cases.
Here, cryptography is split across the service layer, hardware abstraction layer, and MCAL of the AUTOSAR architecture. The Crypto Stack can be designed to use hardware cryptographic features in the DSC or an external cryptography device such as an external HSM that fortifies security around sensitive data. The AUTOSAR stack can make use of the external HSM with the help of the Serial Peripheral Interface (SPI) MCAL and Crypto Driver as provided by the respective vendor.
The Crypto Service Manager (CSM), which is in the service layer, provides the interface to the application components for accessing the crypto library and HSM and scheduling cryptographic functions.
A popular strategy used by OEMs is to combine an external HSM with a security-focused MCU family. The advantage of this approach is the scalability of the ECU platform. When an external HSM is paired with such an MCU family, the HSM can be added or removed per the security goals and allow you to move within the MCU family as per memory and feature requirements. The secure MCU complements an external HSM with features like immutable secure boot, One Time Programmable (OTP) Flash, and debug disable to implement robust security solutions.
Many external HSMs come with pre-certified Federal Information Processing Standards (FIPS) and Joint Interpretation Library (JIL) High rating. These imply that the design can move on to development with a high degree confidence of achieving its security goals.
Conclusion
Automotive suppliers are developing their ECUs for AUTOSAR-compliance and ISO 26262-certification to remain market-relevant, but this increases the design complexity of ECUs. In response, a great deal of support for designers have become available in the market enabled through the ecosystem of software vendors, system integrators, and microcontroller vendors. Designers can benefit from selecting a DSC or MCU family that offers a comprehensive automotive ecosystem supporting AUTOSAR, functional safety diagnostic and security libraries, ISO 26262-compliant compilers, collateral for certification, and other sources to build robust and scalable ECU designs.
Author: Nelson Alexander, Senior Marketing Engineer, Microchip Technology Inc.
