HomeEV ProductsAutomotive LightingGear Up for Your Future Automotive Development

    Gear Up for Your Future Automotive Development

    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 electric vehicles; 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. 

    Auto EV India Expo

    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).

    AUTOSAR’s architecture
    Figure 1. AUTOSAR’s architecture

    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, and 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, Fail-Safe Clock Monitors (FSCM), 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.

    HTMSS and MSTP interaction
    Figure 2. HTMSS and MSTP interaction

    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.

    Crypto Stack in layers
    Figure 3. Crypto Stack in layers

    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 ratings. These imply that the design can move on to development with a high degree confidence of in achieving its security goals. 


     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 has 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. 



    Nelson Alexander, Senior Marketing Engineer, Microchip Technology Inc.

    Himanshu Vaibhav
    Himanshu Vaibhav
    Himanshu Vaibhav is a distinguished Technology Journalist associated with and With expertise in researching, writing, and editing, he demonstrates a deep understanding of technology, particularly in the EV industry. His continuous updates on EV, Automotive, and E-mobility industries reflect his commitment to staying at the forefront of emerging trends.

    Related Post

    Most Popular

    Best Picks

    Simulation Tool Prevents Severe Issues in Various Automotive Scenarios

    Authors: Giusy Gambino, Alessio Brighina, Francesco Giuffre’, Filippo Scrimizzi, STMicroelectronics, Catania, Italy When conceiving and implementing cutting-edge solutions that can thrive in harsh automotive environments a... PRO, a new story about a professional board...

    Author: STMicroelectronics  The PRO redefines what it means to use professional tools destined for the Internet of Things by making the technology accessible to more than...

    STM32CubeMonitor 1.7, STM32CubeMonitor-UCPD 1.3, and STM32CubeMonitor-RF 2.12, more powerful...

    Author: STMicroelectronics STM32CubeMonitor 1.7 became more flexible thanks to new UI improvements in an effort to adapt to the many use cases it must handle. For...

    Driving the Future: Exploring Innovations in the Automotive Power...

    The global automotive power electronics market is set to achieve a valuation of US$ 6 billion by 2033, advancing at 4.1% CAGR from 2023 to 2033, as...

    Empowering Karnataka’s Electronics Industry: An Insightful Conversation with CLIK...

    Karnataka, a shining star in India's technological landscape, has earned international acclaim for its thriving electronics and IT sectors. Fuelled by a legacy of...

    Aimil Ltd.: Setting the Benchmark for Instrumentation Solutions at...

    Aimil Ltd., an ISO 9001:2015 certified company with a heritage tracing back to 1932, holds a prominent position as a leading provider of cutting-edge...

    Electrify Your Future: A Thriving Career in the E-Mobility...

    In an era where sustainability and innovation reign supreme, the E-Mobility sector has emerged as the driving force behind a transformative shift in the...

    X0115ML, the smallest SCR now supports a surge peak...

    Author: STMicroelectronics The X0115ML is our first compact silicon control rectifier (SCR) for ground fault circuit interrupters (GFCIs) and arc-fault circuit interrupters (AFCIs) that can withstand a...

    Exploring the Future of Electronics: Unveiling the Power of...

    In a recent interview conducted by technology journalist Himanshu Vaibhav of and, Dr. John W. Mitchell, President & CEO of IPC, discussed...

    Must Read