As modern vehicles become more complex and sophisticated, with hundreds of electronic control units (ECU) and thousands of lines of code, standardizing the software architecture and interfaces has become ever more critical. Automotive Open System Architecture (AUTOSAR) standard was primarily formed to address this challenge. Therefore, understanding the basics of AUTOSAR is essential for professionals in the automotive industry. This article will introduce AUTOSAR, respective of its definition, architecture, software components, and explore the benefits of AUTOSAR.
WHAT IS AUTOSAR?
AUTOSAR, which stands for Automotive Open System Architecture, is an open and standardized software architecture for developing software in the automotive industry. It was initiated in 2003 by a consortium of automotive manufacturers, suppliers, and tool developers to develop a common platform for automotive software development. AUTOSAR aims to standardize the software architecture and interfaces, providing a common platform for developing embedded software for vehicles.
WHY WAS AUTOSAR CREATED?
AUTOSAR was formed to solve the following purposes.
・Hardware Abstraction:
In the market, there are a variety of microcontrollers with distinct designs created by various manufacturers. In the case of software developers tasked with application-level development in the Electronic Control Unit (ECU), a significant amount of time was being spent on comprehending and setting up the microcontroller. However, AUTOSAR offers a solution through hardware abstraction. This is achieved by providing a software module called the Microcontroller Abstraction Layer (MCAL), which makes the Basic Software (BSW) and the application layer free from dependence on the microcontroller. As a result, software developers now can concentrate on building the application itself rather than being concerned with configuring the microcontroller.
・Basic Software (BSW) standardization:
The Basic Software (BSW) is responsible for performing fundamental tasks of the Electronic Control Unit (ECU), including Communication, Memory Mapping, Input/ Output (I/O), Device Drivers, and System. Prior to the advent of AUTOSAR, software developers in the automotive industry devoted significant effort to implementing and optimizing components that corresponded with the microcontrollers used in ECU design. However, these efforts didn’t add any value to the customer and suppliers would bill the OEM for each new configuration change. AUTOSAR resolved this issue by standardizing the BSW system, enabling software developers to concentrate on customer-oriented features and functionalities, thereby enhancing competitive value and software quality.
・Standardization of exchange formats:
Before implementing AUTOSAR, every supplier to the OEM developed products independently, leading to a significant number of compatibility issues since OEMs worked with different suppliers for different products. However, AUTOSAR has addressed this issue by standardizing the specification of exchange formats. This standardization now permits for the smooth integration of different products from various suppliers in a smooth way.
・Reusubility of functions‗Across vehicle networks and across OEM boundaries
One of the major obstacles faced by OEMs was the considerable effort required to add a new function to an existing ECU. For example, if an OEM wanted to add a tire pressure monitoring system along with the brake ECU, then OEMs had to put in a lot of effort to make it happen. However, AUTOSAR has streamlined the process of reusing functions, minimizing the effort required. Additionally, AUTOSAR has enabled the partitioning and relocation of functions, further enhancing its efficiency.
・Interface Standardization
Typically, the development process of an individual module in Automotive electronics involves utilizing tools like MATLAB or RHAPSODY to build the smallest possible model, with MATLAB generating the C code. To add a new feature, a small piece of handwritten code would be integrated into the model. However, prior to AUTOSAR, implementing such small improvements to existing models was challenging due to a lack of standardized interfaces. AUTOSAR has addressed this issue by rendering the hardware independent of the software. This has facilitated model-based development as the code generated from the model is hardware-agnostic and focuses solely on the functional aspect, streamlining the process for OEMs and reducing the interface proliferation between OEMs and suppliers. Moreover, different components from various suppliers can be utilized interchangeably to meet OEM requirements, enabling module reusability.
BENEFITS OF USING AUTOSAR
The standardization of software architecture and interfaces in AUTOSAR provides several benefits for the development of embedded software for vehicles:
・Increased re-use of software: AUTOSAR provides a standardized software architecture that enables the reuse of software modules across different vehicle platforms and manufacturers.
・Increased design flexibility: AUTOSAR’s modular and scalable architecture provides greater design flexibility and enables faster and more efficient development of software components.
・Clear design rules for integration: AUTOSAR defines clear design rules and standards for the integration of software components, which helps to reduce errors and improve system reliability.
・Reduction of costs for software development and service in the long term: The use of standardized software components and interfaces enables greater efficiency in software development, testing, and maintenance, resulting in long-term cost savings.
・OEM overlapping reuse of non-competitive software modules: AUTOSAR allows OEMs to reuse non-competitive software modules across different vehicle platforms, which can reduce development costs and time-to-market.
・Focused on protected, innovative, and competitive functions: AUTOSAR’s architecture provides a framework for developing innovative and competitive functions, while also ensuring that critical functions are protected and secure.
AUTOSAR ARCHITECTURE OVERVIEW
The AUTOSAR architecture is divided into three layers: the application layer, the runtime environment layer, and the basic software layer.
・The Basic Software constitutes of the microcontroller abstraction layer, ECU abstraction layer, services layer, and complex drivers.
・The Runtime environment functions as the interface that links the application with the Basic Software.
・The application layer is designed for a particular application, such as an airbag application.
Figure 1: The AUTOSAR Architecture including BSW sub-layers
※Layer 1: The Basic Software (BSW)
Microcontroller Abstraction Layer
The microcontroller software layer serves as the lowest layer of the Basic Software, enabling higher software to operate independently of the microcontroller.
As a software engineer, it can be quite challenging to comprehend the intricacies associated with the microcontroller, such as drives, GPIO, I/O, and A/D functions. All we need to do is call interrupts when necessary, and this is accomplished through the microcontroller abstraction layer, which develops a set of libraries or functions. These libraries can be invoked when required, and they will execute the task.
Different semiconductor industries create microcontrollers, and the method of accessing GPIO may vary between manufacturers. However, the GPIO components perform the same function. Therefore, if the microcontroller manufacturer provides a standardized format library to access GPIO, we can access it instead of trying to understand the microcontroller, saving us significant time and effort (with a focus on configuration).
Additionally, the semiconductor industry is the best entity to implement this abstraction since they possess superior knowledge of the microcontroller as they are the ones developing it.
ECU Abstraction
The ECU Abstraction layer provides an interface for the drivers of the Microcontroller Abstraction Layer, enabling higher software layers to operate independently of the ECU hardware layout while also providing access to I/O signals.
The same microcontroller can be used to build numerous ECUs, such as those controlling four, six, or twelve cylinders. If we must develop the BSW for a specific ECU, like one managing twelve cylinders, we may need to provide various implementations of the final services that these ECUs are designed to provide. For example, if we must drive the current for multiple actuators, we want to have available functions with current arguments at the upper level, and it is the responsibility of the BSW to manage the appropriate microcontroller threshold layer to implement the directive.
The ECU abstraction layer is designed to deliver ECU-specific services to the upper layer. Multiple manufacturers can implement the same service in different ways, and software components can be implemented in a single ECU or distributed among multiple ECUs. From an application standpoint, how the services are implemented is immaterial; we only expect the services to be available.
Service Layer
The Services layer represents the uppermost layer of the Basic Software. This layer is responsible for executing the operating system, diagnostic services, and other high-level services that are generally hardware independent. It handles essential functions such as managing the buffer and memory, scheduling application tasks based on specific policies, and booting. Furthermore, it provides fundamental services for both the application and the basic software modules.
Complex Device Driver
This is a component of the BSW that serves as a hub for standardization. Using the wrapper facilitates the reuse of code, including legacy code. It can be challenging to reuse code in the ECU abstraction layer since this is a monolithic piece of code that is difficult to modify. As a result, the standardization of code and the creation of a centralized location for it are highly beneficial.
※Layer 2: The Runtime Environment Layer(RTE）
The RTE functions as the connection point between the application and the BSW. The application layer communicates with the BSW by utilizing the RTE, which enables AUTOSAR software components to be independent of any specific ECU mapping.
※Layer 3: The Application Layer
The application layer is composed of software modules designed to create a specific application, and it represents the software that OEM is willing to invest in. To safeguard the intellectual property, some OEMs may develop certain applications themselves. For example, Ferrari may create proprietary algorithms to optimize the power of their engines, which they may choose not to share.
AUTOSAR Software Components
Figure 2: Description of Software Component at three levels
The Virtual Functional Bus represents the highest level of description, where software components are described using data types, port interfaces, port prototypes, and connections between them. This level expresses the fundamental communication properties and relationships of components. It also defines software components, composition, and interfaces.
The Middle level allows for the behavior description of a given AtomicSwComponentType. This is known as SwcInternalBehavior and is expressed using AUTOSAR RTE concepts and schedulable units, such as Runnable Entities. For example, the behavior specifies which RunnableEntity is activated because of invoking a specific ClientServer-Operation.
The Lowest and most concrete level of description specifies the implementation of a given behavior, with the schedulable units of such behavior mapped to code. The two layers above constrain the RTE API offered by a component, and the implementation utilizes this API. More specifically, the behavior’s Runnable Entities are mapped to either source code or object code.
Reference Link:
20-11-2024
