Using Autosar's hierarchical software architecture to diagnose CAN apps

Table 2: Here are the OBD services supported by Autosar.

It can be concluded from Table 2 above and Table 3, below, that Autosar doesn't support the 0x05 service (Request the monitoring result of oxygen sensor), because the CAN-line based 0x05 service can be realized in 0x06.

Table 3: The UDS services supported by Autosar.

It does not support 0x28 (communication control), 0x34 (remote download), 0x35 (program upload), 0x36 (data transport) and 0x37 (request to exit the transport) services in UDS; and the 0x10 service doesn't support the two sub-functions of programming session and extension session. All these services are mainly used in the reprogramming of ECU, and thus Autosar doesn't support Bootloader.

Although Autosar doesn't support these services at present, it has not restricted the developers' extensions to them. Diagnoses-related modules in the Autosar architecture are shown in Figure 2 below.

Figure 2: Autosar CAN diagnoses-related modules.

FIM module's function is to enable or to disable the function entity inside the software component according to the event status reported by Diagnostic Event Manager (DEM).

PDU router module is just responsible to forward the I_PDU (Interaction Layer Protocol Data Unit) between DCM (Diagnostic Communication Manager) and CAN TP (CAN Transport Layer), and shall not make any modification to the data.

CAN Interface module, CAN Driver module and CAN Transceiver module are responsible for the transport of L_PDU (Data Link Layer Protocol Data Unit). DEM, DCM and CAN TP are the diagnoses-related core modules in the Autosar architecture.

DCM module conforms to the standards of ISO 14229-1, ISO 15031-5, ISO 15765-4 & SAE J1979 and could directly process the 0x10, 0x27 & 0x3E services. Upon receipt of Autosar supported OBD service or other UDS services, it shall respond by loading the interfaces provided by DEM, software component or other BSW modules.

Autosar recommends building DCM with three function blocks, i.e. Diagnostic Session Layer (DSL), Diagnostic Service Dispatcher (DSD) and Diagnostic Service Processing (DSP).

Among them, DSL is responsible to process the diagnoses requests transferred by PDU Router, manage the timing parameter of ses sion layer and application layer, and handle the switching of session statuses etc.

DSD is responsible to forward the diagnoses requests transferred by DSL to DSP, and meanwhile transfer the diagnoses responding message from DSP to DSL. DSP is responsible to analyze the received diagnoses request message, and check the message's format and its requested sub-functions.

It is not until the service identifier, sub-function, format etc. of the diagnoses request message have all satisfied the conditions, should DSP process the received request message and tidy up the processing result as diagnoses responding message responding message to send to PDU Router.

Conforming to the same standards with those of DCM, DEM is responsible to directly process the DTC-related services, e.g. the 0x19 service in UDS (responding message to be sent by DCM).

When trouble has been detected by software component's Monitor Function or the BSW module, DEM module shall be informed to process and store "Diagnoses Event" (identified by Event ID).

If the trouble has been confirmed by diagnoses, the interface provided by NVRAM Manager shall be loaded to save it in the NVRAM and inform the application layer to initiate trouble notification. The statuses of DEM are shown in Figure 3 below.

Figure 3: The statuses of DEM.

Conclusion
As a result of strict hierarchy, almost all the Autosar's diagnoses-related modules (except the CAN driver and CAN transceiver modules that rely on hardware) are completely independent from the hardware. Diagnostic codes developed along with this architecture could cast off the bondage of hardware, and are provided with maximum reusability.

Autosar currently does not support SAE J1939. It is temporarily not possible to apply Autosar software architecture in the development of Bootloader programs.

Liu Xiaoyan is a developer in the Auto Electronics Department at Beijing HiRain Technologies Co. Ltd.