Introduction
The automotive industry is swiftly evolving to meet the demands for more personalized, secure, and comfortable vehicles. However, this transformation also introduces challenges. The proliferation of automotive hardware and software entities like modern ECUs and sensors and Connected Vehicle Technology (CVT) escalates the sophisticated commuting experience along with the system complexity. Also, the advent of highly automated driving, coupled with the requirements for Car-2-X communication (X- infrastructure, pedestrians, or other vehicles) and software over-the-air (OTA) updates, establishes new benchmarks for software platforms in next-gen ECUs, leading to intricate in-vehicle software systems. That said, it’s evident that today’s high-end cars host over 100 million lines of code across 80 ECUs, making automotive software complex. To manage this complexity and enhance efficiency, OEMs collaborated to establish Automotive Open System Architecture (Full form of AUTOSAR) in 2003—a standardized software architecture for vehicles.
What is AUTOSAR?
AUTOSAR is an open-source, standardized software architecture for standardizing connections between application software and essential vehicle functions. AUTOSAR offers inherent advantages in handling the growing complexities within in-vehicle settings. It ensures seamless integration and function exchange among sophisticated ECU networks, exerting control across the entire product lifecycle.
This structured and open-source platform simplifies collaboration between automakers and suppliers, reducing development timelines while enhancing software quality. AUTOSAR’s layered structure simplifies complex software setups, fostering modularity and scalability and ensuring safety in the ever-evolving automotive realm.
Formed by a consortium including prominent automakers and suppliers like Daimler, Ford, BMW Group, Continental, BOSCH, General Motors, PSA Group, Toyota, and Volkswagen, AUTOSAR represents a global collaborative initiative aiming to standardize software architecture, encourage reuse, and promote interoperability throughout the automotive domain.
What is the need for AUTOSAR?
AUTOSAR is a global development partnership of suppliers, vehicle manufacturers, and other semiconductor, electronics, and software companies. In modern automobiles, numerous parts are supplied by different companies, known as Tier 1 companies, to Original Equipment Manufacturers (OEMs) like Volkswagen and BMW. As mechanical components evolve into intelligent entities with embedded Electronic Control Units (ECUs) for enhanced control and efficiency, the need arises for a standardized communication method among these ECUs.
Before AUTOSAR’s inception in 2003, OEMs would instruct vendors to build and ship ECUs based on specific requirements. However, this process led to challenges when changing vendors or OEMs, necessitating repetitive teaching of ECU architecture and functionality. The lack of a standardized approach resulted in unnecessary time, cost, and potential bug-related complications.
AUTOSAR layered architecture emerges as a solution to these challenges. By introducing a standardized software development infrastructure, AUTOSAR software addresses the complexities of diverse ECUs, fostering seamless communication and mitigating the drawbacks of traditional approaches. This approach streamlines the development process, enhances reliability, and reduces expenses associated with software integration in the dynamic automotive landscape.
Types of AUTOSAR
The initial version of the AUTOSAR architecture was introduced in 2006, now referred to as AUTOSAR Classic. In 2017, a distinct AUTOSAR standard, Adaptive, was established to meet the requirements of connected vehicles and applications related to autonomous driving.
AUTOSAR Classic:
AUTOSAR Classic is a standardized automotive software architecture designed for applications with stable requirements. It provides a set of predefined modules, ensuring consistency in software development for Electronic Control Units (ECUs).
Example: In a traditional engine control system, AUTOSAR Classic ensures uniform communication between various ECUs for ignition timing, fuel injection, and emission control.
AUTOSAR Adaptive:
AUTOSAR Adaptive is a flexible automotive software framework suitable for dynamic and complex systems, especially those involving connected and autonomous driving applications. It allows for customizable configurations to adapt to evolving requirements.
Example: In an autonomous vehicle, AUTOSAR Adaptive facilitates the integration of advanced sensors, control systems, and communication modules. It enables the car to dynamically adjust its behavior based on real-time data, such as adapting to changing road conditions or interacting with other connected vehicles.
AUTOSAR Architecture
AUTOSAR layered architecture mediates between application software and hardware systems.
The structure includes three primary layers: the top-tier Application Layer, followed by the Run-Time Environment; the third layer encompasses Basic Software (BSW), and the bottom layer represents the hardware unit, the Microcontroller.
Application Layer
The application layer lies at the top layer of AUTOSAR’s architecture. It houses the application code for executing specific tasks within the Electronic Control Unit (ECU). This layer hosts various Software Components (SWCs) or application blocks, each catering to distinct functionalities like managing power windows, measuring temperature, etc. These SWCs are designed based on the specific needs of the ECU, providing a flexible framework to accommodate various features.
For example, the application layer manages security by interfacing with sensors and actuators, sending signals to lock or unlock doors based on user commands. It also triggers alarm systems upon detecting unauthorized access and activates immobilizers in case of theft attempts, enhancing overall vehicle safety. The Application Layer in AUTOSAR also manages the Infotainment System, handling audio/video playback, navigation, and connectivity features. It uses standardized interfaces to coordinate functions like media control and user interactions, interfacing with lower layers such as RTE and BSW for task coordination and service access.
RTE Layer
The runtime environment (RTE) within the AUTOSAR architecture is situated beneath the application layer. This crucial AUTOSAR layer acts as a communication intermediary, managing data flow between diverse components. RTE ensures seamless data transfer via data buffers and port interfaces within the same ECUs and different ECUs, as well as between the application and basic software layers. This intricate process ensures efficient communication across the entire AUTOSAR architecture, contributing to the seamless operation of the overall system.
For example, in an Adaptive Cruise Control system, the RTE ensures seamless data exchange between components like the sensor interface, distance control, and vehicle interface while handling synchronization and error detection for real-time responsiveness. The RTE enhances the modular and standardized architecture of AUTOSAR, streamlining the development of complex automotive systems.
BSW Layer
BSW refers to the software layer that provides essential services and functionalities to enable the development and operation of applications on electronic control units (ECUs) within a vehicle or other embedded systems.
The BSW typically includes standardized software components and modules that handle communication, diagnostics, memory management, and hardware abstraction tasks. These components form a crucial part of the software architecture in embedded systems, allowing developers to build applications without directly managing the complexities of hardware-specific details.
The BSW is organized into layers, including the
- Service Layer
- ECU Abstraction Layer
- Microcontroller Abstraction Layer.
Each layer serves a specific purpose in abstracting and managing different aspects of the hardware and software interaction within the embedded system. BSW helps streamline development, enhance portability, and promote code reuse across different automotive or embedded applications.
Service Layer: At the top of the BSW architecture is the Service Layer. This layer remains unaffected by the activities of the underlying layers and serves as the bridge between the application layer and the microcontroller. Its primary function is to provide diverse services, including network and memory services to/from the application layer to/from the microcontroller. The Service Layer acts as a key point for communication, ensuring smooth exchanges between the application layer and the microcontroller.
ECU Abstraction Layer: Positioned as the second layer, the ECU Abstraction Layer manages Electronic Control Unit (ECU)-related functionalities. This encompasses activities such as memory operations, input-output, etc. The term abstraction is fitting as it conceals the intricate details of ECU configuration, such as ports and hardware peripherals, from developers. Instead, it offers Application Programming Interfaces (APIs) that enable developers to interact with the ECU directly, establishing a connection with the microcontroller.
Microcontroller Abstraction Layer (MCAL): The final layer, called AUTOSAR MCAL, is the Microcontroller Abstraction Layer. This layer assumes responsibility for the hardware connection, specifically with the microcontroller. It houses software drivers that facilitate communication with the microcontroller for various operations. Being an abstraction layer, AUTOSAR MCAL shields its low-level functionalities from the upper layers, such as the application and RTE. This independence allows it to operate efficiently, ensuring a robust connection between the software and the underlying hardware.
How does the BSW Layer help?
For instance, in a car, think of BSW as a helpful assistant that makes sure different car parts can talk to each other. For example, in the Automatic Brake System (ABS), BSW helps the sensors and brakes communicate smoothly. It also checks if everything is working well (Diagnostics) and keeps track of important information like how the brakes should behave (Memory Services). BSW’s Microcontroller Abstraction Layer (MCAL) helps the car’s computer understand and control things like wheel sensors and brakes, ensuring they work together correctly and safely.
These three layers within BSW ensure a standardized and consistent architecture across different microcontrollers and ECUs. This standardization enables the seamless incorporation of additional software onto the MCAL or integration of new ECUs without complexity, facilitating an efficient process.
In a nutshell, AUTOSAR significantly influences the future of automotive software development by providing a standardized and adaptable framework. This framework fosters innovation, collaboration, and the implementation of cutting-edge automotive functionalities. The transition to Adaptive AUTOSAR software further positions it to meet the evolving needs of a connected and autonomous automotive industry.
At SRM Tech, we assist automotive OEMs, Tier I and Tier II suppliers with various AUTOSAR-related solutions. Our services include developing, integrating, and validating AUTOSAR basic software modules, incorporating AUTOSAR from tool suppliers, and upgrading platform software to new AUTOSAR versions according to specifications.
Connect with us to explore more on how our Automotive Engineering Services further your automotive software development for enhanced automobile offerings.
