AUTOSAR automotive open system architecture solution for OEMs

1. AUTOSAR Background

AUTOSAR is the abbreviation of AUTomotive Open Systems ARchitecture, which means automotive open system architecture in Chinese. It defines a set of distributed, function-driven automotive electronic software development methods and standardized software architecture solutions on electronic control units, so as to be applied to different automotive platforms, improve software reuse and reduce development costs. AUTOSAR is a global automotive software development alliance established by automotive OEMs and their first-tier suppliers. It was officially established in the summer of 2003 and started its main work in 2004. Its purpose is to control the complexity and diversity of automotive software. AUTOSAR includes 9 core members: BMW Groups, BOSCH, Continental, DAIMLER, Ford, GM, PSA Peugeot Citron, TOYOTA, and VOLKSWAGEN AG. At present, its members have exceeded 150. Among domestic OEMs, FAW and SAIC have joined. Hirain Technology has become the third company in China to join the organization after FAW and SAIC.

Since the launch of AUTOSAR, the value system in the entire automotive field, from the semiconductor industry, tool and software manufacturers, component suppliers to automobile manufacturers themselves, has given positive promotion to this standard. AUTOSAR development members released version 2.1 in 2007, which brought the development of AUTOSAR to a stable stage. Subsequently, the practicality of AUTOSAR was tested through several different development projects. Now AUTOSAR is ready to enter the product ECU, and the BMW Group has applied ECU (electronic control unit) that meets the AUTOSAR standard to the new BMW 7 series mass-produced models. It is expected that all core members of AUTOSAR will launch related products in 2010. In the commercial field, tool and software suppliers that support the AUTOSAR standard have launched corresponding tools and software, providing services such as requirements management, system description, software component algorithm model verification, software component algorithm modeling, software component code generation, RTE generation, ECU configuration, and basic software and operating system, to help OEMs achieve a seamless AUTOSAR system software architecture development process. The current AUTOSAR version is 3.1, and it is expected to release version 4.0 in the fall of 2009.

Since AUTOSAR advocates the principle of "cooperation on standards and competition on implementation", and its core idea is "unified standards, decentralized implementation, and centralized configuration", the adoption of AUTOSAR will bring great benefits to OEMs, which will give them more flexibility and greater rights in software procurement and control, because the standardization and openness of software systems will allow more software suppliers to enter the automotive electronics industry, giving them more choices, and the quality supervision of software will be improved accordingly, which is conducive to improving their product quality. However, it must be seen that there are still potential obstacles to the implementation of this standard in the entire industry, that is, resistance from some OEM manufacturers and large first-tier automotive suppliers, because they already have their own standards and architectures, and the adoption of AUTOSAR standards and their architectures may generate risks such as replacement costs and loss of control. Despite this, the standardization of automotive electronic software development methods and software architectures is an unstoppable development trend in the automotive industry, and no standard has gone further than the AUTOSAR standard. In view of this, domestic automotive OEMs must be prepared to deal with AUTOSAR, which is a challenge and an opportunity for them.

In the implementation of the AUTOSAR standard, OEMs will play a leading role. How should OEMs put forward requirements and use these software with standard functions and interfaces from different suppliers in their products? AUTOSAR has also formulated standards on methods and processes for this purpose, namely the AUTOSAR methodology. This article will focus on the interpretation of the AUTOSAR methodology and explain how OEMs should apply this standard in their product development and production processes.

2. AUTOSAR Technology Overview

AUTOSAR has three main planning goals. The first is to establish a layered software architecture that is independent of hardware. The second is to provide a methodology for implementing applications, including developing a seamless software architecture stacking process and integrating application software into the ECU. The third is to develop various vehicle application interface specifications as application software integration standards to facilitate the reuse of software components on different automotive platforms.

1. AUTOSAR Software Architecture

In order to achieve the goal of AUTOSAR, that is, to achieve separation between application and basic modules, the automotive electronic software architecture is abstracted into several layers, as shown in Figure 1.

Figure 1: AUTOSAR software architecture hierarchy diagram.

In order to distinguish between software dependency and hardware dependency, the basic software is divided into four layers: Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer and RTE (Runtime Environment). In addition to these four layers, there are also complex drivers in the AUTOSAR software architecture. Since the modules that operate complex sensors and actuators involve strict timing issues, this part is not standardized in AUTOSAR.

* The service layer provides system services including diagnostic protocols, storage management, ECU mode management, and operating system. Except for the operating system, the software modules of the service layer are platform-independent.

* The ECU abstraction layer abstracts the ECU structure (such as the connection between peripherals and ECU, etc.). This layer is related to the ECU platform but not to the microcontroller.

* The microcontroller abstraction layer includes microcontroller-related drivers (such as I/O drivers, ADC drivers, etc.).

* The RTE layer is responsible for the communication between AUTOSAR software components (i.e., application layer) and between software components and basic software. The basic software below the RTE layer is invisible to the application layer and must be accessed through the RTE. It separates software components from their dependence on the underlying software and hardware platform, thus achieving separation between application programs and basic software.

2. AUTOSAR Methodology

AUTOSAR defines a set of common technical methods for the development process of automotive electronic software systems that meet the standard. This method is called AUTOSAR Methodology. As the planner and designer of vehicle system functions, automotive OEMs need to understand and master the development process provided by AUTOSAR in order to lead and promote the development process of systems that meet the AUTOSAR standard.

[page]

The design and development process of automotive electronic software systems compatible with the AUTOSAR standard is shown in Figure 2.

Figure 2: AUTOSAR system design and development process.

The main steps can be divided into two stages:

The first stage is the system configuration stage, which belongs to the system-level design decision-making work. The first step is to write the system configuration input file, which is an XML file. The description term of the application software in AUTOSAR is software components (Software Components). This file will determine the software components (that is, what functions the system has) and hardware resources (ECU) that need to be used, as well as the constraints of the entire system. AUTOSAR provides a series of templates (software component templates, ECU resource templates and system templates) and standard information exchange formats, based on which tool vendors can provide corresponding tool support to simplify the work of system design. In the end, system designers only need to use tools to fill in or edit the corresponding templates to export the system configuration input file.

The system configuration input consists of three parts. The first input is the software component description, which defines the interface content of each required software component, including data types, ports, interfaces, etc.; the second input is the ECU resource description, which defines the resource requirements of each ECU, such as processors, external devices, memory, sensors and actuators, etc.; the third input is the system constraint description, which defines the mapping relationship between bus signals, topology structures and software components.

The next step in the system configuration phase is to generate a system configuration description file, also an XML file, from the preliminary system configuration input file with the help of the system configuration generator. This is the final work result of the system configuration phase. This file will contain all system information, including mapping software components to related ECUs (this mapping needs to take into account the needs of components, component connections, resource requirements and constraints, and sometimes also factors such as cost), as well as the communication matrix (the network structure, timing and content of network data frames of the entire vehicle).

The second stage is the configuration of the ECU. This stage needs to be done for each ECU in the system. First, the system configuration description file, the result of the first stage, is used to extract the system configuration description information related to each ECU. The extracted information includes the ECU communication matrix, topology, and top-level function combination (based on which all software components that need to be mapped to the ECU are generated), which will be placed in another XML file. The work of extracting information can be done with the help of tools. Then enter the actual work of ECU configuration. This step is responsible for adding the information required for specific applications to the input objects, such as task scheduling, necessary BSW modules, BSW configuration information, and runnable entities assigned to tasks. The result of this step is placed in the ECU configuration description file, which contains all the information required for the specific ECU. The last step is to generate the executable program for the specific ECU. This step will build the basic software settings of the ECU and integrate it with the application software based on AUTOSAR components according to the configuration information in the ECU configuration description file, and finally generate the executable code of the ECU.

In addition, it should be noted that the design process of the AUTOSAR system uses the concept of Virtual Functional Bus. The Virtual Functional Bus abstracts the communication between AUTOSAR software components and the communication between software components and basic software, and uses pre-defined standard interfaces. For the Virtual Functional Bus, there is no difference between internal ECU communication and external bus communication. This difference will not be reflected until the system layout and the specific functions of the ECU are finalized. The software components themselves do not pay attention to this difference, so we can develop software components independently. In the process of system implementation, the functions represented by the Virtual Functional Bus are finally reflected in the generation of RTE.

3. Standardized application interface

The premise for realizing communication between AUTOSAR software components (i.e., applications) and between software components and basic software through RTE is that the software components must have standard AUTOSAR interfaces. At present, AUTOSAR version 3.1 has defined standard interfaces for some typical automotive electronic application areas (power, body/comfort, and chassis). AUTOSAR divides the systems in these areas into several modules according to functional logic. These modules can be regarded as a software component or a combination of multiple software components. The interfaces of these functional software components are clearly defined, and the content of the defined interfaces includes name, meaning, range, data type, communication type, unit, etc. Application software developers need to apply these interface definitions when designing and developing software components.

Here, the interface definition of the software component of the wiper management of the body/comfort system is taken as an example, as shown in Figure 3:

Figure 3: Interface definition of a software component.

illustrate:

The WiperWasherManager component has two interfaces, CmdWashing and StaWasher. In the figure, WWManager is represented as an instance of the WiperWasherManager software component. The following information is defined for the CmdWashing interface:

1) The CmdWashing interface is provided by the WiperWasherManager component, and its data content is used by the Activation interface of the FrontWasher component.

2) CmdWashing contains a "Command" data element.

3) The data type of "Command" is "t_onoff".

4) "t_onoff" belongs to "RecordType", which describes general on/off information.

Application software developers should be aware of the importance of designing application software for the AUTOSAR runtime environment (RTE) interface, and introduce the AUTOSAR application layer interface into actual projects as early as possible to prepare for the reusability of application software, thereby optimizing the entire software development process.

3. Design, Application and Implementation

Still taking the design of the external vehicle light control system in the body/comfort area as an example, this example only involves the implementation of the flashing control function of the turn signal.

[page]

In the system configuration phase, the first step is to collect the system configuration input content. First, collect the software components required to implement the function. As shown in the right frame of Figure 4, a total of 5 software components are used in this system. Write the description file of each software component according to the software component template provided by AUTOSAR; then clarify the ECU resources used in the system and form an ECU resource description file. As shown in the upper left frame of Figure 4, there are 3 types of ECUs; finally, the description file of the system constraints describes the network topology of the system. Generally, OEMs need to provide software component descriptions and system constraint description files for parts suppliers to use when developing ECU systems.

Figure 4: System configuration input.

The generation of the above description files is supported by special tools (such tools are collectively called AUTOSAR description file editors), and users only need to fill in the specified content into the tool.

The generation of software component description files requires obtaining information about each software component's interface, behavior, direct hardware interface (I/O), and operating performance requirements (memory, power consumption, timing, etc.). The software component description file itself will contain four parts:

* General characteristics: name, manufacturer, etc.

* Communication properties: port, interface

* Internal structure: sub-components, connection relationships

* Required hardware resources: processing time, scheduling, memory size and type, etc.

Before generating the ECU resource description file, you need to obtain information about each ECU about sensors and actuators, hardware interfaces, hardware properties (memory, processor, power consumption), connections and bandwidth. The ECU description file itself will contain 7 parts:

* General characteristics: name, manufacturer, etc.

* Temperature (self, ambient, cooling/heating)

* Available signal processing methods

* Available programming skills

* Available hardware: microcontroller, architecture (e.g. multiprocessor); memory, interfaces (CAN, LIN, MOST, FlexRay), peripherals (sensors/actuators), connectivity (e.g. number of pins).

* Basic software modules for microcontrollers under RTE

* Signals from pins to the ECU abstraction layer

Before the system constraint description file is generated, information about the entire system is required, such as the bus system, protocol, communication matrix and properties, functional clusters, and functional deployment (distribution to ECUs); the system constraint description file itself will contain 3 parts:

* Network topology: buses (CAN, LIN, FlexRay), connected ECUs, gateways, power supplies

* Communication (for each channel): communication matrix, gateway table

* Mapping of software components

After the system configuration input described above is collected, the system configuration tool is used to export the system configuration file. This step determines which software component runs on which ECU. It generates the ECU configuration description and also generates the communication matrix within the system, as shown in Figure 5.

Figure 5: System configuration results.

[page]

After the above work is completed, the next step is to enter the ECU configuration stage. The configuration information of each ECU is extracted from the system configuration file, including the ECU communication matrix, topology, and top-level function combination (that is, the combination of all software components that need to be mapped to the ECU). In addition, more specific configurations of the main parts of the AUTOSAR basic software are required, such as RTE configuration, OS configuration, MCAL (microcontroller abstraction layer) configuration, and communication protocol stack configuration. The configuration of these software components currently has corresponding tool support, and compilable header files are directly generated for the integration of ECU system software. Before generating the ECU executable program, it is necessary to obtain the code of the relevant software components and basic software, and then compile them with the configuration header file of the above basic software, and finally generate the ECU executable program. As shown in Figure 6.

Figure 6: ECU configuration and executable program generation.

In summary, the entire system design and development process can be represented by Figure 7. It should be noted here that this process may require multiple iterative modifications to achieve the optimal result.

Figure 7: System design and development process.

IV. Conclusion

AUTOSAR is becoming a reality. Establishing such a standardized platform and implementing standardization will shorten the development and testing time of new products, thereby helping companies achieve rapid market response. Many OEMs plan to adopt AUTOSAR in their next models. Many tool and software suppliers in the market have launched tools or software support that meet the AUTOSAR standard, which can provide complete and seamless solutions for the design and development of AUTOSAR systems.

AUTOSAR is a huge leap forward in the process of standardization of automotive electronic software platforms. We need to learn and understand it. However, we must also see that it takes a long time to break the traditional software development platform in the entire automotive industry. We can build a hybrid platform of AUTOSAR and traditional software in the early stage according to user needs and goals. This is a feasible method to achieve a smooth upgrade to AUTOSAR. In this process, the focus is not simply on use, but understanding the concepts and ideas of AUTOSAR is the most important, because it will bring far-reaching changes to the workflow and business model of automotive electronic software development.

References

1. AUTOSAR SPECIFICATIONS Release3.1: Specification document released by AUTOSAR official website

2. 《03_AUTOSAR_Tutorial.pdf》: AUTOSAR official website file