AUTOSAR Design Tips for Automotive Applications

Automotive OEMs are developing AUTOSAR-based electronic systems to cope with the increasingly complex software in modern cars. AUTOSAR simplifies the development process and makes ECU software reusable. Since AUTOSAR was launched in 2004, this innovative and cutting-edge technology has been tested in many research projects; now, AUTOSAR has begun to enter the real implementation stage through productized ECUs. AUTOSAR software represents the current state of the art and ensures continuous technological progress through continuous version updates.

The automotive industry is facing a new era. More and more complex automotive functions make the development of automotive electronics more and more complex. Customers' functional and personalized requirements for products, as well as the increase in non-functional requirements such as diagnosis, have further increased the complexity of the ECU development process. Automobiles, especially high-end luxury cars, have more than 1,000 software functions, several in-vehicle bus networks, and more than 70 ECUs. Due to the diversity of hardware platforms in the field of automotive electronics, ECU software development is heavily dependent on hardware and system configuration. Every change in the relevant constraints will lead to rewriting the program or modifying the software.

In order to reduce the complexity of ECU software development, AUTOSAR development members provide a set of proven software architectures as the basis for developing reusable applications. The open system architecture standard AUTOSAR is jointly developed by automotive OEMs, parts suppliers, and companies in the software, semiconductor and electronics industries around the world. AUTOSAR allows users to avoid the growing development costs caused by adopting proprietary solutions.

AUTOSAR divides the electronic architecture into several layers and modules. While defining the interface, AUTOSAR also defines software components and easily exchangeable hardware platform standards. AUTOSAR development members not only provide specifications for basic software modules, but also provide methods for developing distributed system applications. This method starts with model-based software and distributed system descriptions and ends with automatic code generation and repeatable testing. This method simplifies the use of tool chains.

Three years after AUTOSAR was introduced, the AUTOSAR development team released version 2.1 in 2007. At this point, the development of AUTOSAR has reached a stable stage. Several different development projects have tested the practicality of AUTOSAR. In the commercial field, the "AUTOSAR Evaluation System" has been completed. Now, AUTOSAR is ready to enter the production ECU.

In order to achieve the goal of AUTOSAR, that is, to achieve the separation between application and basic modules, automotive electronics are abstracted into several layers. The connection with the actual microcontroller, that is, the physical basis, is abstracted into the microcontroller abstraction layer for mapping the functions and peripheral interfaces of the microcontroller. The microcontroller abstraction layer defines the memory interface, I/O driver interface and communication connection interface, and can also simulate some functions that the microcontroller cannot provide. The second layer is the ECU Abstraction Layer. This layer provides drivers for peripheral devices for the ECU based on the ECU-related hardware. The third layer is the Services Layer. This layer provides various services, such as network services, memory management, network communication and operating system. The service layer is largely independent of the hardware system. The fourth layer RTE truly realizes the separation between application and basic software. RTE is responsible for handling application integration and data exchange between application and basic software modules. The existence of RTE is the basis for truly realizing application reuse. Because RTE predefines the relevant interfaces, developers can develop application software without knowing anything about the hardware and apply this software to any ECU that complies with the AUTOSAR standard.

The Virtual Functional Bus forms the basis for the configuration of these layers. With this virtual bus, all automotive electronic communication components can be abstracted and use predefined ports; for the Virtual Functional Bus, there is no difference between internal ECU communication and external bus communication. This difference will only be reflected after the system layout and the specific functions of the ECU are finalized. The software components themselves are not concerned with this difference, so they can be developed independently. Software components are divided into several executable units, i.e. running entities. When a certain specified event occurs, the corresponding running entity will be triggered. Such an event may be a new sensor signal or a periodic timing. The formal description of the electronic system from the perspective of the Virtual Functional Bus ultimately defines the interface of the relevant software components. Therefore, the application software can be developed independently of the specific ECU.

RTE enables access to I/O, memory and other basic services. Using model-based description, RTE can be customized for a specific ECU, which can adapt to different requirements and save resources.

method

While defining the ECU software architecture, the AUTOSAR standard also defines the method for developing AUTOSAR systems. Compliance with a confirmed development process is an important prerequisite for developing software. Deficiencies in the requirements list will be discovered early in the development process, and the reuse of software components simplifies the development process, making the entire system more reliable. However, this approach also allows a certain degree of freedom: for example, users can decide whether to use a top-down or bottom-up development process.

The purpose of AUTOSAR is to provide general support for the software development process through tools. Mature tools are used for the structured realization and corresponding management of requirements, and to establish corresponding configurations.

The first step consists of the formal description of the three main aspects: software (software components), ECU (ECU resources) and system constraints. Appropriate editing tools are used to create the complete system description.

The system configuration serves as the basis for ECU configuration, and users can use configuration tools to generate basic software components based on the ECU configuration. At the end of the development process, there are a variety of generation tools that can be used to generate RTE and basic software. All design and configuration data in the development process are saved in a unified file format. For this purpose, AUTOSAR defines an XML-based file format. On the one hand, the unified file format ensures the versatility of the development process; on the other hand, it simplifies the seamless integration between development tools.

transplant

AUTOSAR's software architecture is not a single module, it includes a large number of standard modules with complete interface definitions. This makes AUTOSAR migration very easy, even between projects; in addition, standard AUTOSAR modules and private software modules can be used simultaneously in one project.

In order to achieve such a migration, the existing software architecture must first be compared with the AUTOSAR architecture. By analyzing the overlapping functions and integration options, it is decided which modules can be retained and which modules should be replaced by standard software modules.

Therefore, it is a very wise choice to introduce a separation layer between the application and the basic software. A feasible approach is to prepare the application and AUTOSAR software components early in the migration process and integrate them together through RTE. Under the RTE, a dedicated modification layer is used to provide an interface for the existing basic software, as shown in Figure 3.

If a part of the existing basic software needs to be replaced by AUTOSAR basic software, the focus is on using unified tools. Vector provides suitable tools that can be used to configure private software modules. Non-AUTOSAR modules can be gradually replaced by AUTOSAR modules, thus avoiding the risk of tearing down the entire architecture or the huge workload of rewriting modules.

prospect

The release of AUTOSAR 3.0 marks the further improvement of the AUTOSAR standard. The companies involved in the standard formulation are committed to making continuous efforts to achieve the goals of AUTOSAR. The various ideas currently introduced will be implemented in the future AUTOSAR 4.0 version.

Tool vendors have also put forward some ideas related to AUTOSAR. Vector's AUTOSAR development team is working to make AUTOSAR-based ECU development more convenient and easier. A typical example is a test tool for AUTOSAR application components running on a PC, which can also serve as a simulation environment for AUTOSAR-compliant ECUs. This makes it easier to test the implementation code of AUTOSAR software components on a PC. Widely used standardized tools (such as Vector's CANoe) can be used for test implementation, visual testing, and test report generation. Vector supports the entire development process with a full set of AUTOSAR basic software components and a common design and development tool chain.

Vector's AUTOSAR solutions have been proven in several projects, with mature products compliant with AUTOSAR 2.0 and 2.1 (products compliant with AUTOSAR 3.0 will be available in the second quarter of 2008).

Summarize

AUTOSAR is becoming a reality. Many OEMs plan to adopt AUTOSAR in their next models. Vector provides a complete solution for AUTOSAR, including AUTOSAR software components and development tools. This not only supports pure AUTOSAR system development, but also supports the gradual migration of existing systems to AUTOSAR.