datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Using Autosar's hierarchical software architecture to diagnose CAN apps

Liu Xiaoyan

5/1/2010 8:39 PM EDT

The Automotive Open Systems Architecture (Autosar) as an embedded hierarchical software architecture for vehicle electronics was initiated together by global vehicle OEMs and suppliers.

This hierarchical architecture consists of microcontroller abstraction layer, electronic control unit (ECU) abstraction layer, service layer, RTE (runtime environment) and application layer. The former three layers are jointly called as Basic Software (BSW).

Interactions between software in various Autosar layers are realized via three types of interfaces, i.e. standard interface, Autosar interface and Standard Autosar interface (Figure 1, below).

Figure 1: The hierarchical architecture of Autosar.

Among them, the standard interface is used for the interaction between various modules of BSW and has been realized by C language, for example void Adc_Init (const Adc_ ConfigType* ConfigPtr).

Autosar interface is used for the interaction between SW-Cs (Software Component) or the interaction between software components and ECU firmware (abstract of IO hardware, drivers of complex facilities) and has been named in "Rte_" prefixes. Standard Autosar interface is used for the software component's visiting of Autosar services.

Owing to the hierarchical architectures and interface definitions as these, Autosar has evidently enhanced the reusability of auto electronics' embedded software - the higher the layer is, the greater the reusability shall be. It is remarkable that:

Microcontroller abstraction layer is the lowest layer and shall be changed along with the changes of microcontroller.

Although RTE is of lower layer than the application layer, it is not reusable since it runs as the bridge between application layer and BSW and is of the highest coupling degree with hardware.

The application layer (excluding the software components concerning sensors and actuator), being completely independent with the hardware, is of absolute reusability.

Auto diagnoses profile
Currently, OEM and auto suppliers are adopting the method combining online and offline diagnoses. Among them, online self diagnoses are realized by internal software and hardware of ECU.

During the running process of automobile, self-diagnoses system shall apply real-time monitoring on the working status of various components of electrical control system, and shall thus detect the troubles in the electrical control system.

The self-diagnoses system shall on one hand warn the driver with the detected trouble via certain methods (the warning lights for instance), and on the other hand save the trouble codes and the concerned data into ECU memorizer.

Offline diagnoses realize the diagnostic operations by reading concerned diagnosing information via external diagnosing facilities. Offline diagnoses' realization lies mainly on how to realize the communication mechanism and diagnoses services between diagnosing facilities and ECU, i.e. diagnosing protocol.

Standards of diagnoses protocol can be currently divided into two systems: ISO and Society of Automotive Engineers (SAE). SAE standard system is applied in the United States, while ISO standard system is applied in most other countries (including China).

In the field of passenger vehicles, OEM is gradually turning from self-diagnoses protocol to ISO standard. While in the field of commercial vehicles, OEM is inheriting SAE diagnoses, and the European OEM has added ISO diagnoses as a plus. refer to the comparison of some ISO & SAE standards in Table 1 below.

Table 1: Shown is the comparison of ISO & SAE Standards (SAE J1939 excluded).


Next:




Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)