Nelson Alexander

The automotive industry is undergoing a tremendous change driven by electric vehicles, autonomous driving, and connectivity. Due to the changes, the automotive OEMs and Tier 1 suppliers expect various Electronic Control Units (ECUs) that make up typical cars to become more complex while taking longer to design and test. For a long time, OEMs have been using the AUTomotive Open System ARchitecture (AUTOSAR), which is a standardized software architecture used in real-time application ECUs.

AUTOSAR addresses the complexity by making the ECU software architecture modular and reusable. It offers advantages like making an ECU platform scalable across multiple vehicles and reducing design time. For these reasons, there is a push from OEMs for more ECUs to be AUTOSAR compliant. As the industry switches to electric vehicles, the ECUs for E-compressor, On-Board Chargers (OBC); DC-to-DC converters, Battery Management Systems (BMS), Advanced Sensor nodes, etcetera, are implemented with AUTOSAR.

The trend for electrification is increasing both the electronics and software systems in a vehicle, which also increases the number of potential failure points. For this reason, the focus on ISO 26262 functional safety for electrical and electronic systems used for series production road vehicles has increased.

Related:Microchip Single-Chip Controller Drives Amazing Automotive Touch Screens as Large as 40 Inches

Focus on functional safety is also from OEMs adopting strategies like zero defects and minimization of all roots of error. Over a period, OEMs are requiring systems that were Quality Managed (QM) to move to ASIL A and systems that have ASIL A requirements to move up to ASIL B, C, and D.

Security is also becoming important with the growing number of connected vehicles. The connected vehicles enable OEMs to easily implement firmware Over-The-Air (OTA) updates to avoid recalls and easily deploy fixes or upgrades.

The connectivity and the support for firmware updates potentially expose more attack vectors. Hence, ECU designs are required to implement advanced security to offer protection from attacks by malicious agents. Safety and security are becoming interdependent, as for a system to be functionally safe, it must also be secure.

1) AUTOSAR Architecture

AUTOSAR has a layered system architecture to support modularity. Figure 1 shows a conceptual diagram of the AUTOSAR architecture. At the bottom is a physical Digital Signal Controller (DSC) or a microcontroller (MCU) and above this is the Basic Software (BSW).

The BSW is further divided into the service layer, ECU abstraction layer, and Microcontroller Abstraction Layer (MCAL). The BSW is standardized in the AUTOSAR definition, which enables it to be modular and reused across various types of ECUs. The AUTOSAR BSW supports communication protocols including CAN/CAN FD, LIN, and Ethernet via communication drivers, hardware extraction, and services modules. Above this is the Run-Time Environment (RTE) layer, which provides a standardized interface for an application to access the underlying layers and facilitates communication between the upper application components, scheduling the BSW, managing resources and instances of the BSW.

The BSW also has a standard interface to use security features like cryptography peripherals, trust anchors, and external Hardware Security Modules (HSM). Setting up the AUTOSAR stack essentially involves configuring the BSW and RTE as per your ECU design requirements. At the top, the application layer is segmented into AUTOSAR Software Components (SW-C). The application layer will be composed of many software components, each contributing to a feature of an ECU.

The AUTOSAR architecture also supports ‘complex drivers,’ which can be used to interface non-standard drivers with the AUTOSAR BSW. The complex drivers offer ways to expand the capabilities of the BSW that are not in the AUTOSAR definition and enable the application layer’s software components to interface with a DSC’s peripherals and system resources.

The complex drivers are meant to be used to implement time-critical and low-overhead drivers that need a deterministic and real-time response. The complex drivers are ideal to implement functions like motor control, digital power, robust touch functions, and advanced sensing and control designs.

When migrating from a bare metal or non-AUTOSAR application to an AUTOSAR-based design, the complex drivers enable leveraging application-specific proprietary algorithms and software functions that are not covered in the AUTOSAR specification. You can repurpose these functions from your bare-metal design and implement them as a complex driver to reduce development efforts.

The standardization of the interface between the layers and the behavior of the stacks allows components to be bought off the shelf from different vendors. This is an advantage as you can get components for your stack from different domain experts.

For example, the MCALs can be procured from MCU or DSC vendors who have the best insight into the internal working of their devices. Applications using AUTOSAR can be developed faster and with confidence that the BSW has been well tested and proven. Different AUTOSAR components from different vendors that adhere to the standard can be readily integrated.

As AUTOSAR compliance is an important requirement in automotive designs, in order for a DSC or an MCU family to be selected, it must offer scalability in terms of the CPU performance, memory, peripheral set, and the associated development ecosystem. A preferred controller family must enable a platform development comprising of bare-metal and AUTOSAR-based designs and offer easy scalability from bare metal to AUTOSAR while leveraging most of the development investment.

A typical ECU platform design can benefit from using a DSC or an MCU architecture that offers the same high-performance core, device architecture, and peripheral modules but scales with memory and the actual peripheral set. This simplifies reusing the AUTOSAR stack across various ECU configurations as the core, peripherals and the ecosystem remains the same.

2) Functional Safety with AUTOSAR

Automotive ECUs that are safety critical need to be developed and certified according to the ISO 26262 functional safety standard. The ISO 26262 design process requires the ECU designer to identify various hazards and safety goals at a vehicle level, which is then translated into safety requirements and mechanisms at the system level. This is further decomposed into hardware features or diagnostic software to remove any unacceptable risk in case of a fault.

The AUTOSAR BSW has several safety mechanisms and measures that enable meeting the ISO 26262 functional safety requirements. However, the safety mechanisms in AUTOSAR are limited to preventing interference between the software components, which are related to timing, execution, and information exchange. The AUTOSAR stack has standard interfaces to run diagnostic routines for the CPU, Flash, and RAM to verify application integrity and supports Cyclic Redundancy Checks (CRC) that can be used to diagnose communication errors.

Additional diagnostic software routines that are specific to the application and device-peripherals must be added to the BSW as complex drivers. For example, you can 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 case, a complex driver is essential to take advantage of the hardware safety features of a functional safety ready or a functional safety compliant DSC. Controller vendors provide ISO 26262 functional safety packages with diagnostic libraries which can be integrated 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 interacts with the Microcontroller Specific Test Package (MSTP). Figure 2 shows more detail about the HTMSS and MSTP. The MSTP is a configurable diagnostic routine created by leveraging the diagnostics library offered by the DSC or MCU vendors, but this is not part of the AUTOSAR BSW. The MSTP and HTMSS are essential to run diagnostics during startup and shut down of an ECU as required for the defined target functional safety goals. The HTMSS provides a way for the application software components to interact and schedule diagnostics available in the MSTP.

Many controller vendors are now providing functional safety ready/compliant MCUs or DSCs with comprehensive functional safety packages offering diagnostic libraries, functional safety compilers, and supporting collateral for ISO 26262 certification.

 3) AUTOSAR Security

AUTOSAR has a heavy focus on security, including several building blocks to implement your security use cases. The core security feature is provided by the Crypto Stack which has access to cryptographic primitives and key management. AUTOSAR supports three secure communication protocols: Secure Onboard Communication (SecOC); Transport Layer Security (TLS); and Internet Protocol Security (IPsec).

SecOC is an open standard defined by the AUTOSAR organization and preferred for secure communication between ECUs which can be used over a CAN and LIN network. The AUTOSAR BSW implements secure diagnostics and intrusion detection use cases. Additional use cases like secure firmware updates can be implemented using the Crypto Stack.

Figure 3 shows more details of the Crypto Stack of the AUTOSAR BSW. The AUTOSAR divides the cryptography into three layers; the service layer, hardware abstraction layer, and MCAL. The service layer has the Crypto Service Manager (CSM). The application components will interact with the CSM to access the underlying crypto library, the HSM, and schedule cryptographic functions.

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

An external HSM paired with a security-focused MCU is a recommended approach as it can achieve better security and is widely accepted by automotive OEMs. 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.

External HSMs enable security islanding where the more secure key storage memory is separate from the main memory of the application and AUTOSAR stack. This reduces the security risk compared to an MCU storing the keys in its internal memory. An ECU platform based on an external HSM paired with a security-focused MCU family can be easier to scale as you can add or remove the HSM or move within the MCU family based on memory and feature requirements.

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

Conclusion

The market trend is clear that AUTOSAR, ISO 26262 functional safety, and security are no longer optional for automotive ECUs. There is now a considerable support ecosystem to help designers, which is comprised of software vendors, system integrators, and MCU vendors. The ideal ecosystem for an automotive DSC or MCU needs comprehensive AUTOSAR support, functional safety diagnostic libraries, ISO 26262-compliant compilers, collateral for functional safety certification, and security libraries. Such a comprehensive ecosystem greatly assists designers and makes it easier than ever to build automotive ECUs incorporating the best practices of AUTOSAR software along with functional safety and security.

Nelson Alexander is a Senior Marketing Engineer in Microchip’s 16-bit MCU business unit.

References

AUTOSAR, 2021, Layered Software Architecture, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

Microchip, 2022, AUTOSAR® Ecosystem for dsPIC33C Digital Signal Controllers,
https://www.microchip.com/en-us/solutions/automotive-and-transportation/automotive-products/microcontrollers-and-microprocessors/16-bit-mcus/autosar

AUTOSAR, 2021, Requirements on Runtime Environment, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SRS_RTE.pdf

AUTOSAR, 2021, Complex Driver design and integration guideline, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.pdf

AUTOSAR, 2021, Overview of Functional Safety Measures in AUTOSAR, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_EXP_FunctionalSafetyMeasures.pdf

AUTOSAR, 2021, Specification of Secure Onboard Communication, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SWS_SecureOnboardCommunication.pdf

AUTOSAR, 2021, Specification of Crypto Service Manager, https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SWS_CryptoServiceManager.pdf