[Understanding Automotive] What is AUTOSAR?

preface

AUTOSAR, which stands for Automotive Open System Architecture, is a platform widely used in the automotive software development field.

Initially, it was developed to facilitate collaboration among various automotive manufacturers and software suppliers worldwide by providing an open standard architecture for automotive software development.

 

To understand the process of developing the AUTOSAR Classic platform, two main aspects need to be grasped:

 

1. Understanding the basic concepts of AUTOSAR and its methodology for development.

2. Understanding the AUTOSAR toolchain and the development workflow using it.

 

AUTOSAR was conceived to efficiently develop and manage Electronic Control Unit (ECU) software in vehicles.

 

In the AUTOSAR Classic platform, the software architecture is divided into two main

- Application software (#ASW) : "Each OEM and supplier must develop the unique core functions of the control units."

- Basic Software (#BSW) : "The hardware-dependent parts or common functions."

 

*OEM stands for "Original Equipment Manufacturer," referring to the original manufacturer of a product. In the automotive industry, OEM typically refers to automotive manufacturers (such as Hyundai, Kia, BMW, among others) that design and produce vehicles independently.

 

*Supplier refers to a provider of goods or services. In the context of automotive development, suppliers are organizations or companies that collaborate with OEMs (Original Equipment Manufacturers) to develop specific functions for control units (ECUs). OEMs do not necessarily develop all the software themselves but rather collaborate with external suppliers or partner companies (referred to as suppliers here) to develop particular functions.

 

"The hardware functionalities needed by the application are provided in the form of services by the Basic software. This hierarchical separation allows application software to be reused across different ECUs, enhancing quality and efficiency. Additionally, the functions of basic software are also horizontally separated, leading to reduced development time and cost."

 

Now, let's delve into the basic concepts of AUTOSAR and its development methodology:

*Methodology - ARXML: ARXML stands for AUTOSAR XML and it is the standard document format based on AUTOSAR.

 

- In the context of AUTOSAR, applications encapsulate the unique functionalities of Electronic Control Units (ECUs) and are developed as Software Components (SWCs) within a virtual space called the Virtual Functional Bus (VFB). For instance, if we consider a Battery Management System (BMS) as an example, it might include functionalities such as reading current and voltage values and calculating remaining charge based on them. These functionalities can be developed as separate SWCs, such as Read_Curr_Current SWC, Read_Curr_Voltage SWC, and Cal_SOC_SWC.

 

- To ensure that these SWCs function properly together, their details need to be documented and shared. This is where ARXML (AUTOSAR XML) comes into play. ARXML is used to specify various details of SWCs, such as data types, bit sizes, signedness, byte order, and more. By detailing this information in ARXML files, developers can ensure that different SWCs can communicate effectively.

 

- Once the SWCs are developed and their details are specified in ARXML files, they need to be integrated with the Basic Software layer. The Basic Software layer provides the necessary services for the application layer to function properly. This integration is facilitated through a process called Configuration, where the details specified in the ARXML files are used to configure the Basic Software layer to support the required services. Once configured, the Virtual Functional Bus (VFB) is instantiated within the Basic Software layer, allowing the SWCs to interact with the underlying hardware.

 

Overall, ARXML plays a crucial role in AUTOSAR development by enabling the specification and sharing of SWC details, which in turn facilitates the integration and interoperability of different software components within the AUTOSAR architecture.

 

Methodology (referred to as MD for short)

 

From the perspective of MD, the overall development process of AUTOSAR can be summarized as follows: applications are developed either through modeling or hand-coding, while the necessary basics are developed through Configuration.

 

In the context of AUTOSAR, "Configuration" refers to the process of developing software components by selecting options using graphical user interfaces, such as dropdown menus and checkboxes, instead of manually coding them with a keyboard.

 

To understand MD (Methodology), let's differentiate between OEMs and Suppliers:

 

1. Designing Application Architecture (without considering Hardware and Basic Software).
2. Developing the overall network structure and design within the vehicle.
3. Transferring the Application Architecture model designed by the OEM to the Supplier. (In cases where the OEM directly generates code for applications, it can be shared in object form.)
4. The Supplier finalizes the Application Architecture design by adding its unique application to the application received from the OEM.
5. Separating detailed requirements for each target ECU within the entire system and delivering them to each Supplier accordingly.
6. Suppliers configure (build) the MCAL and Basic Software, including the OEM's requirements and applications, to run the application.
7. The configured content is generated into code through a generator for each module, compiled together with separately implemented application code, and then compiled into a final executable file for the target ECU.

Understanding the AUTOSAR toolchain and the development workflow utilizing it.

 

In the past, development was possible solely through hand coding, but as outlined in the MD, developing ECUs based on AUTOSAR requires various tools, which can be broadly categorized as follows:

• System and Application Architecture Design Tools
• Application Code Generation Tools
• Basic Software Configuration Tools Explaining the AUTOSAR development process using these tools briefly:

1. Software architecture modeling
2. Software functionality implementation
3. AUTOSAR Basic Software
4. Compilation followed by final ECU integration

 

Application and Basic Software can be developed independently, allowing for concurrent development. Each tool communicates using the AUTOSAR-based standard document format mentioned earlier, ARXML, to exchange information.

 

Here's an example of how application developers and Basic Software developers within a supplier company can collaborate:

Application Development Perspective:

1. Model the application architecture for the target ECU, incorporating OEM requirements, and export it to ARXML.
2. Import the application architecture model in ARXML format, implement internal logic, and generate corresponding code.

Basic Software Development Perspective:

1. Configure hardware functionalities (MCAL), OS, Memory, and other services required by the ECU. Import and configure communication data formats like DBC or Fibex. Upon receiving the ARXML from the application, perform configurations such as Event mapping and Service mapping based on it.
2. Once the Basic Software Configuration is complete, generate Basic Software code. Compile it along with the Application code generated from the application development perspective to create a .elf file that can be downloaded onto the target ECU.

source: https://blog.naver.com/mdstec_auto/222159700966