“AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of automotive interested parties founded in 2003. It pursues the objective of creating and establishing an open and standardized software architecture for automotive electronic control units (ECUs) excluding infotainment. Goals include the scalability to different vehicle and platform variants, transferability of software, the consideration of availability and safety requirements, a collaboration between various partners, sustainable utilization of natural resources, and maintainability throughout the whole "Product Life Cycle"” --Wikipedia

These are the official definitions of AUTOSAR, an open system architecture for standardized software design and cross-Hardware platform applications.

In the development of automotive electronics, due to the demand of price, reliability and speed, a large number of embedded systems are used, but there is also no certain standard for software design. When the system becomes more complex, it is more difficult to design, maintain and upgrade. Therefore, advocating standardization of automotive software has always been the demand and aspiration of the automotive industry. From early OSEK/VDX to recent AUTOSAR, these requirements are products.

 

AUTOSAR (Automotive Open System Architecture) was founded in 2003. It is composed of car factories, parts suppliers and development tool manufacturers. It has 162 members and aims to standardize automotive software. It integrates the original OSEK/VDX and is active. The current version has been updated to 4.2.

 

AUOSAR is characterized by the use of middleware to isolate the impact of hardware replacement, as shown in Figure 1; Previous embedded system development often relied on hardware-provided firmware or letter libraries for program writing, such as the left side of Fig. 1, so that when hardware changes, existing software must be rewritten. AUTOSAR defines a standard interface between hardware and software for which the software is written and the hardware is obligated to provide it. Therefore, when the hardware needs to be replaced, the original software program can be modified without modification through the standard interface defined by AUTOSAR, as shown on the right side of P1.

Re-use and interchangeability of software are achieved through the definition of standard interfaces. In addition to the existing developed software being free from hardware limitations and increasing re-use, between the OEM and supplier, suppliers have increased the number of suppliers the car manufacturer can choose from, and in contrast, the market for suppliers has expanded. This is what AUTOSAR emphasizes as "Cooperate on standards, compete on implementation" - a smart strategy for collaborating on standards, competing on implementation, improving software interchangeability, and benefiting both suppliers and consumers.

AUTOSAR uses a hierarchical design, which allows three abstraction layers between application software and hardware: Microprocessor Abstraction Layer (MCAL), ECU Abstraction Layer (ECAL), and Service Layer, which greatly increases the degree of software reuse, as shown in P2.

P2. software hierarchy diagram

Although AUTOSAR has good intentions, it still needs to be observed whether it can become the standard system for unified vehicle electronics in the future because of its complex structure, high dependence on tools during the development process, a large increase in development costs, a large number of participants, and a very complex standard. As the Active Assisted Security System (ADAS) which has emerged in recent years has not yet been included, it remains an important mainstream in the vehicle industry. It deserves our close attention.

At present, the Vehicle Center (ARTC) is actively developing the Advanced Assisted Safety System (ADAS) and Autonomous Driving System (ADS), noting the importance of an open architecture, and adopting the AUTOSAR approach to isolate hardware variability through standard interfaces in order to make our research and development more robust and standardized.

How to implement cross-Hardware platform applications?

In fact, the design of embedded software is nothing more than the combination of register setup and application logic, and the most closely integrated part with hardware platform is the register setup. In AUTOSAR, how registers should be set is saved in arxml files (some toolboxes define different file type names, but they are still used as arxml formats).

Readers should understand that AUTOSAR's tool software is basically two functions:

1. Generation and editing of arxml files;

2.  Generate source code.

Ideally, 1, if the performance of the two chips is similar, then the arxml file that I made to A chip should be small or even unmodified for B chip; 2. On the same chip, the arxml file I set with EB Tresos (EB's own file format is not arxml) should be able to import directly into DaVinci Configurator.

Neither of these can be done at this stage.

Tool software providers generally work closely with chip providers to ensure that reasonable code templates and user settings can be translated correctly into register settings.

The standardized design of the software mainly uses the function name and the port format as uniform as possible, and uses the same method. However, in the specific operation process, different users will make different internal process designs according to their own needs and resource configuration. AUTOSAR itself is not self-consistent, so the concept of CDD was creatively proposed, which can be used either as SWC or BSW, as a port, or as a direct call to underlying functions. This basically destroys AUTOSAR's original intent as soon as it comes out. You can imagine a scenario where all SWCs are defined as CDDs and AUTOSAR is not required.