Trends Driving the Future of Automotive Development: Part One

AUTOSAR: Overview and Use in the Automotive Industry

Electric vehicles, 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.

In this two-part blog series, we will learn more about how the requirements in automotive ECU designs are evolving as the industry undergoes significant advancements. This first post will examine the trends in the automotive industry and provide an overview of the AUTOSAR architecture and how you can achieve scalability with AUTOSAR-ready dsPIC33C DSCs.

Market Trends and Background

As the industry moves towards electric vehicles, many ECUs are implemented with the AUTomotive Open System ARchitecture (AUTOSAR), including those for E-Compressors, On-Board Chargers (OBCs), DC-to-DC converters, Battery Management Systems (BMS), touch, lighting, advanced sensor and real-time control nodes and more. For many years, OEMs have been using AUTOSAR, which is a standardized software architecture utilized in ECU designs. To address the complexity, AUTOSAR makes the ECU software architecture modular and reusable. Some of its advantages include making an ECU platform scalable across multiple vehicles and reducing design time. As a result, there is a push from OEMs for more ECUs to be developed based on AUTOSAR platform.

The focus on ISO 26262 functional safety for electrical and electronic systems has increased. This is due in part to the trend for electrification, which is raising the number of both electronics and software systems in a vehicle, which also increases the amount of potential failure points. This focus on functional safety is also from OEMs adopting strategies such as zero defects and minimization of all roots of error. OEMs are requiring systems that were Quality Managed (QM) to move to Automotive Safety Integrity Level (ASIL) A, and systems that have ASIL A requirements to move up to ASIL B, C and D.

As the number of connected vehicles grows rapidly, security is also becoming exceptionally important. Connected vehicles enable OEMs to implement firmware Over-The-Air (OTA) updates. This helps to avoid recalls and easily deploy fixes or upgrades. However, the connectivity and the support for firmware updates can potentially expose more attack vectors. Therefore, ECU designs are required to implement advanced security to offer protection from malicious attacks. Safety and security are becoming codependent—for a system to be functionally safe, it must also be secure.

The focus on AUTOSAR, ISO 26262 functional safety and security drives the future of the automotive industry.

AUTOSAR Architecture

AUTOSAR uses a layered system architecture to support modularity.

Figure 1 shows a conceptual diagram of the AUTOSAR architecture. At the bottom, there is a physical dsPIC33C DSC. Above that is the Basic Software (BSW). The BSW is further divided into a service layer, ECU abstraction layer and Microcontroller Abstraction Layer (MCAL). Since the BSW is standardized in the AUTOSAR definition, it can 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 abstraction and services modules.

The BSW also has a basic interface to use security features such as cryptography peripherals, trust anchors and external Hardware Security Modules (HSMs).

Above the BSW is the Run-Time Environment (RTE) layer. This provides a standardized interface for an application to access the underlying layers and facilitates communication between the upper application components, BSW scheduling, management of resources and instances of the BSW. Setting up the AUTOSAR stack primarily involves configuring the BSW and RTE according to your ECU design requirements.

Finally, at the top, the application layer is split into AUTOSAR Software Components (SW-C). The application layer is made up of many software components, each supporting a feature of an ECU.

Figure 1: AUTOSAR Layered Architecture

“Complex drivers” are also supported by the AUTOSAR architecture and can be used to interface non-standard drivers with the AUTOSAR BSW. The complex drivers offer the means to enhance 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 intended to implement time-critical and low-overhead drivers that need a deterministic and real-time response. They are perfect to execute functions like motor control, digital power, robust touch functions and advanced sensing and control designs.

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

The standardization of the interface between the layers and the behavior of the stacks means that components can be bought off the shelf from different vendors. This is a huge advantage because you can get components for your stack from different domain experts.

For instance, the MCALs can be obtained from DSC or microcontroller (MCU) vendors who have the best understanding of the internal operations of their devices. Applications using AUTOSAR can be developed faster and with confidence that the BSW has been thoroughly tested and verified. You can combine various AUTOSAR components from numerous vendors that adhere to the standard.

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. This is because AUTOSAR compliance is a crucial requirement in automotive designs. A preferred controller family should 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.

These DSCs or MCUs should ideally offer the same high-performance core, device architecture and peripheral modules across the devices and scale with memory and the actual peripheral set. The ECU platform design can benefit greatly from using this. This simplifies the use of the AUTOSAR stack again across various ECU configurations since the core, peripherals and the ecosystem remain the same.

We offer several devices as AUTOSAR-ready dsPIC33C DSCs, including dsPIC33CH dual-core DSCs (90+100 MHz) and dsPIC33CK single-core DSCs. With our devices, you can look forward to superior quality, performance, safety and security for your systems.

To learn more, visit our AUTOSAR ecosystem. Browse our featured controllers to discover how they meet your needs. Keep your eyes out for part two of this discussion to learn more about ISO 26262 functional safety and security with AUTOSAR.