Automotive Diagnostics

Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in Diagnostics

Introduction

• Present in Every ECU. (Gateway ECU, braking ECU and so on...)
• Monitors internal and External Faults, failures
Warning lamps etc.
• Provide Information on the environmental conditions in which the failure has occurred.
• Provide vital information like Operating Hours, VIN, and many users specific Requirements.
• With the help of diagnostics, we can download the software into the ECU without a debugger connection.
• Diagnostics will perform sensor calibrations.
• UDS (ISO-14229) is implemented on CAN, LIN, FLEX-RAY, and IP.

Fundamentals of Classic Platform

The AUTOSAR Architecture distinguishes on the highest.
abstraction level between three software layers:
• Software Component (SW-C)
• Virtual Function Bus (VFB)
• Basic SW
which runs on a Microcontroller?

Software Component (SW-C)

• SW-C: Components Designed to execute a specific set of tasks, as per the use case.
• Location: Application Layer.
• Functionality: They can Exchange information, and invoke functions from the Basic SW and other SW-C.
• Connection: SW-C’S provide/require ports and interfaces to connect to each other through the VFB to fulfill architectural responsibilities.

Virtual Function Bus (VFB)

• VFB: The Runtime environment is the virtual
function bus implemented for specific ECUs.
• Location: RTE Layer.
• VFB provides mechanisms for the following services
which are used by SWCs:

1. Communication with other SWCs in the system.
2. Communication with Sensors or actuators in the system.
3. Providing access to standard services such as reading/ writing to memory.
4. Responding to mode changes.
5. Communication with external calibration and measurement instruments.

Basic Software

• BSW: Can be defined as a standardized software module offering various services necessary to run the functional part of the upper software layer.
• Sub-Layers:
1. Services Layers
2. ECU Abstraction Layer
3. MCAL
4. CDD
Each of them can be further split into system, memory, and communication services.

Basic Software-Services

• *Services Offered *:
1. OS Functionality
2. Network Communication and Management Services
3. Memory services (NVRAM Management)
4. Diagnostics (including UDS communication, error
memory, and fault treatment)
5. ECU State Management
6. Watchdog Manager

Basic Software

• Location: Service layer interfaces between RTE
and Microcontroller.
• Application layer doesn’t know on which hardware the application is running.
• That way an ECU with identical functions, but different network connections (CAN, LIN, Flex- Ray, Ethernet) can use the same application SW with the communication services of BSW.

UDS Protocol

• UDS requirements of diagnostic services allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle electronic control unit (ECU, server).
• UDS will implement in the application layer and session layer based on the OSI Reference model.
• The application layer services are used in client- server-based systems to perform functions such as testing, inspection, monitoring, or diagnosis of on-board vehicle servers.

AUTOMOTIVE Diagnostics Diagnostic Communication Manager (DCM)

Introduction To DCM
• Provides Common API for Diagnostic Communication.
• Features Provided by DCM to External Diagnostic Tools.
• Development
• Verification and Validation
• Manufacturing
• Calibration
• Service
• Fault Logging
• Software or Hardware Related Data
• Software Updates

Diagnostic Communication Manager (DCM)

Introduction To DCM

• Location: Service Layer.
• Functionality: It handles the diagnostic communication between the tester tool and ECU over CAN via PDUR.
• It will validate the request from the tester tool, if the request is valid and processes correctly then DCM sends a positive response with the requested data.

• If the request detects as in-valid then DCM will send a negative response with NRC (Negative Response Code).
• DCM also communicates with DEM for Faults and sends the fault information to the tester via service 19.

AUTOSAR Diagnostic Modules: DCM

• The below figure will define DCM is
communication with tester

DSL (Diagnostic Session Layer)

• Functionality: Implements concurrent tester present logic.
• Reads current security level of ECU. Reads current diagnostic session state of ECU.
• Keeps track of current session, if the current session is not a defaulting session (i.e., it may be programming or default session) then checks for server timeout and when the server times out, the session is reset to the default session.Handling of different diagnostic protocol. i.e., DSL differentiates between OBD and UDS protocols, so you can configure OBD or UDS protocols or UDS protocols with different service sets. Protocol timings can be modified.

Conclusion

The AUTOSAR Diagnostic Communication Manager (DCM) plays a key role in enabling efficient diagnostics in the AUTOSAR architecture. The DCM provides a standard interface for diagnostic communication, managing diagnostic sessions, communicating with other AUTOSAR modules, supporting various diagnostic protocols, and facilitating troubleshooting and data access, which ensures seamless communication between the ECU and external diagnostic tools, enabling efficient troubleshooting and maintenance. vehicle systems. DCMand#039; the ability to manage software updates further increases its value by providing a mechanism to update ECU software without a debugger link, simplifying software maintenance procedures. Overall, DCM is an integral part of the AUTOSAR diagnostic ecosystem, contributing to the overall reliability and maintainability of vehicle electronic systems.

This will be continued in the next article, including examples.
Please let me know in the comments below if you have any questions.
Thanks for reading.