Trends Driving the Future of Automotive Development: Part Two

AUTOSAR: Overview and Use in the Automotive Industry

Electric Vehicles (EVs), autonomous driving and connectivity are transforming the automotive industry in a major way as we continue to develop more advanced systems and venture into the future. To accommodate these changes, the automotive Original Equipment Manufacturers (OEMs) and Tier 1 suppliers anticipate that various Electronic Control Units (ECUs) that make up a standard car will become more complex, adding more time to their design and test periods.

This is the second post in a two-part blog discussion where we will learn more about how the requirements in automotive ECUs are evolving as the industry undergoes significant advancements. In part one, we discussed automotive market trends and the architecture of the AUTomotive Open System ARchitecture (AUTOSAR). This final post will take a look at how ISO 26262 functional safety and security standards are integrated with the AUTOSAR.

ISO 26262 Functional Safety

Any automotive ECUs that are safety critical must be developed and certified following the ISO 26262 functional safety standards. The ISO 26262 design process requires several steps. First, the ECU designer needs to identify various hazards and safety goals at a vehicle level. These are then translated into safety requirements and mechanisms at the system level. This is further broken down into hardware safety features or diagnostic software to remove any intolerable risk in case of a fault.

The AUTOSAR Basic Software (BSW) contains various safety mechanisms and measures to ensure the ISO 26262 functional safety requirements are met. Even so, the safety mechanisms in AUTOSAR are constrained to preventing interference between the software components, which are related to timing, execution and information exchange.

The AUTOSAR stack has basic interfaces to run diagnostic routines for the CPU, Flash and RAM to authenticate application integrity. It also offers support for Cyclic Redundancy Checks (CRCs) that can be used to diagnose communication errors.

Any other diagnostic software routines particular to the application and device peripherals must be added to the BSW as complex drivers.

Suppose that you have a complex driver to set up Fail Safe Clock Monitor (FSCM) to monitor the clock integrity and automatically switch to the backup oscillator when the primary oscillator fails. In this instance, a complex driver is crucial to take advantage of the hardware safety features of a functional safety ready or a functional safety-compliant Digital Signal Controller (DSC). Controller vendors offer ISO 26262 functional safety packages with diagnostic libraries which can be incorporated into the AUTOSAR BSW by wrapping them into a complex driver.

The AUTOSAR BSW has a module called the Hardware Test Management Start-up and Shutdown (HTMSS) that works together with the Microcontroller-Specific Test Package (MSTP). Figure 1 shows more detail about the interaction between HTMSS and MSTP.

The HTMSS provides a means for the application software components to interact and schedule diagnostics available in the MSTP. The MSTP is a configurable diagnostic routine created by leveraging the diagnostics library offered by the DSC or Microcontroller Unit (MCU) vendors. However, this is not part of the AUTOSAR BSW. The MSTP and HTMSS are vital for running diagnostics during startup and shut down of an ECU as mandatory for the defined target functional safety goals.

Figure 1: HTMSS and MSTP Interaction

At Microchip, we offer a broad portfolio of ISO 26262-compliant/ready dsPIC33 DSCs. Our controllers integrate updated hardware safety features with support collateral so your design can be ISO 26262 Automotive Safety Integrity Level (ASIL) B compliant. You can reach the higher ASIL C and D levels through decomposition. In addition, we offer comprehensive ISO 26262 functional safety packages for dsPIC33C DSCs that include diagnostic libraries, functional safety compilers and supporting collateral for ISO 26262 certification. Our devices allow you to simplify safety certification for your automotive designs and provide highly reliable features to conquer design challenges.

Security

AUTOSAR focuses heavily on security, including several building blocks to implement your security use cases such as secure boot, secure firmware upgrade, secure on-board communication, node authentication and more. The primary security feature is provided by the Crypto Stack, which has access to cryptographic primitives and key management.

Secure Onboard Communication (SecOC) is a secure communication protocols defined by the AUTOSAR organization. SecOC is an open standard and is ideal for secure communication between ECUs over a CAN and LIN network. The AUTOSAR BSW incorporates secure diagnostics and intrusion detection use cases. Additional use cases, such as secure firmware updates, can be implemented using the Crypto Stack.

Figure 2 shows the layered view of the Crypto Stack of the AUTOSAR BSW. The AUTOSAR divides the cryptography into three layers: the service layer, hardware abstraction layer and Microcontroller Abstraction Layer (MCAL). The service layer includes the Crypto Service Manager (CSM). The application components will work together with the CSM to access the underlying crypto library, the Hardware Security Module (HSM) and schedule cryptographic functions.

The Crypto Stack can be configured to utilize the hardware cryptographic features available on the DSC or external cryptography devices like an external HSM. The AUTOSAR stack can integrate the use of that external HSM by using the Serial Peripheral Interface (SPI) MCAL and the appropriate Crypto Driver from the HSM vendor.

Figure 2: Layered View of Crypto Stack

Automotive OEMs widely recognize the recommended approach of using an external HSM paired with any of our scalable security-enabled dsPIC33C DSCs to implement robust security. These dsPIC33C DSCs offer hardware security features that complement an external HSM, such as immutable secure boot, One Time Programmable (OTP) Flash and debug disable to implement robust security solutions.

External HSMs support security islanding where the secure key storage memory is independent of the main memory of the application and AUTOSAR stack, reducing the security risk compared to an MCU that stores the keys in its internal memory. An ECU platform designed with an external HSM paired with a security enabled DSC family may be simpler to scale as you can add or remove the HSM or move within the DSC family based on memory and feature requirements.

Additionally, HSMs are available with pre-certified Federal Information Processing Standards (FIPS) and Joint Interpretation Library (JIL) High rating. This means your design can also be developed to a high level of security.

We offer many robust security solutions to protect embedded systems in your automotive designs. Our dsPIC33C DSCs work together with our TrustAnchor100 (TA100) CryptoAutomotive™ security ICs to fulfill your expectations and meet security requirements.  

The change in the market clearly shows that AUTOSAR, ISO 26262 functional safety and security are now critical for automotive ECUs. There is now a comprehensive support ecosystem to help designers, encompassed by software vendors, system integrators and tools. The typical ecosystem for an automotive DSC or MCU needs comprehensive AUTOSAR support, ISO 26262 functional safety packages and security libraries. A broad ecosystem like this can significantly support designers and makes it the easiest way possible to build automotive ECUs which utilize the best practices of AUTOSAR software along with functional safety and security.

To learn more about our offerings, visit our automotive dsPIC33C DSC web page or contact your local sales office for more details.