Unraveling Autosar's Diagnostic Stack: Bridging the Gap to Application Layer Efficiency

1. Diagnostics in AUTOSAR

1.1 Intro to Diagnostics in AUTOSAR

The diagnostic software in AUTOSAR consists of three modules: DCM, DEM, and FIM.

The DCM (Diagnostic Communication Manager) implements the diagnostic communication per ISO 14229-1 (UDS) and SAE J1979 (OBDII). All diagnostic requests are first preprocessed by the DCM. One of the tasks of the DCM is comprehensive handling of invalid diagnostic requests. The DCM can already fully process a majority of valid requests; it routes other requests to the functional software.

1.2 UDS Communication Protocol in AUTOSAR and Diagnostics

Unified Diagnostic Services (UDS) is a communication protocol used in the automotive industry for diagnostics and communication between vehicle components. It's specified in the ISO 14229 standard, also known as the Unified Diagnostic Services standard.

UDS allows for diagnostic communication over CAN, LIN, FlexRay, and other automotive communication protocols.

In AUTOSAR (Automotive Open System Architecture), UDS plays a crucial role in implementing diagnostic services. Within the AUTOSAR framework, UDS is implemented as part of the diagnostic stack.

UDS is a commonly defined protocol for both Off-board and Onboard diagnostics.

It finds existence on the Application layer of the OSI model, where:

• ISO 14229-1 specifies, Specifications and Requirements.
• ISO 14229-3 specifies, UDS on CAN.
• ISO 14229-4 specifies, UDS on FlexRay.
• ISO 14229-5 specifies, UDS on IP.
• ISO 14229-6 specifies, UDS on K-Line.
• ISO 14229-7 specifies, UDS on LIN.

2. Basic Concepts of Diagnostics

Diagnostics play a crucial role in ensuring the proper functioning of automotive systems.

Diagnostics protocols “ISO Standard” define a set of services used for diagnostics purposes throughout the whole automotive life cycle :

2.1 Development Phase:

• Requirements Analysis: Diagnostics requirements are identified during the early stages of system development. This includes defining diagnostic functions, communication protocols, fault detection mechanisms, and diagnostic trouble code (DTC) handling.
• Prototyping and Testing: Diagnostics software and hardware components are prototyped and tested extensively to ensure they meet performance, reliability, and regulatory requirements. This phase involves simulating fault conditions, validating diagnostic algorithms, and verifying communication interfaces.

2.2 Manufacturing Phase:

• Flash Programming: During manufacturing, ECUs are programmed with diagnostic software and configurations. This includes loading diagnostic routines, DTC tables, and calibration data onto the ECUs.
• End-of-Line Testing: Diagnostics are tested as part of end-of-line (EOL) testing procedures to ensure that ECUs are functioning correctly before they are installed in vehicles. This involves running diagnostic tests, checking communication interfaces, and verifying DTC storage and retrieval.

2.3 Vehicle Assembly and Integration:

• System Integration: Diagnostics are integrated into the overall vehicle system architecture, including communication networks and diagnostic interfaces. This involves configuring diagnostic services, setting up diagnostic communication channels, and ensuring interoperability between ECUs and diagnostic tools.
• Functional Testing: Once vehicles are assembled, diagnostic functions are tested to ensure they operate correctly in the vehicle environment. This includes testing sensor and actuator diagnostics, network communication, and overall system health monitoring.

2.4 Maintenance and Aftermarket:

• Onboard Diagnostics (OBD): Vehicles are equipped with onboard diagnostic systems that continuously monitor the vehicle's systems and components for faults. OBD systems alert drivers to potential issues via dashboard warning lights and provide diagnostic trouble codes (DTCs) for technicians to diagnose.
• Remote Diagnostics: Some vehicles are equipped with remote diagnostic capabilities that allow manufacturers and service providers to remotely access vehicle diagnostic data. This enables ?????????????????? ??????????????????????, ???????????? ??????????????????????????????, and ????????-??????-?????? software updates.

• Service and Repair: When vehicles require maintenance or repair, diagnostic tools are used to identify and diagnose faults. Technicians use diagnostic testers to retrieve DTCs, perform diagnostic routines, and troubleshoot issues to ensure proper vehicle operation.

Throughout the lifecycle, effective diagnostics are essential for ensuring vehicle reliability, safety, and compliance with regulatory standards. By integrating diagnostics into the development, manufacturing, and maintenance processes, automotive manufacturers can improve product quality, reduce downtime, and enhance customer satisfaction.

3. Unwrapping diagnostics modulus in AUTOSAR

The Diagnostics stack contains DEM (Diagnostic Event Manager), DCM (Diagnostics Communication Manager), FIM (Function Inhibition Manager), and DET (Development Error Tracer).

Click here for more information.

NvM is part of the memory stack. Here NvM is required to store event-related data when an event fails. i.e. to store freeze frame data and extended data. Blocks are created in NvM to store diagnostic event-related data.

3.1 Diagnostic Event Manager (DEM)

DEM handles and stores the diagnostic events detected by diagnostic monitors in both Software Components (SW-Cs) and Basic Software Modules (BSWM). In simple terms DEM stores the fault that is detected by the BSW or ASW component, each fault will have a unique ID that could be used to identify the fault. The stored fault could be used by other modules to take corrective action or suppress some features.

Click here for more information.

3.2 Diagnostic Communication Manager (DCM)

The DCM handles communication with external diagnosis tools. It checks if the requested diagnostic service from the tester device is supported and in this case, it checks if the service can be executed in the current session (diagnostics have different sessions which have restrictions on what data can be accessed, this is done to restrict access to different users. For eg. OEM-controlled devices will have more access to vehicles than service station devices).

Click here for more information.

3.3 Development Error Tracer (DET)

DET is a module used at the time of development. While the Development DET module is enabled and for final release, DET should be disabled. DET module provides APIs to report an error. When the DET module is enabled, different checks are added to functions of different BSW modules to capture an error. Error is API function is called with the wrong argument, API function is called with NULL Pointer, etc. Each error has an error number and each module has a module number. This is a highly useful module to debug SW errors in the development phase for the Developers and Testers.

3.4 Function Inhibition Monitor (FIM)

The FiM stands for the evaluation and assignment of events to the required actions for Software Components (e.g. inhibition of specific “Monitors”). The Function Inhibition Manager is responsible for providing a control mechanism for software components and the functionality therein.

4. Diagnostics and Communication Management and UDS Services

4.1 Diagnostics and Communication Management

This Diagnostics and Communication Management Functional unit is to control the diagnostic and communication-related operations in the ECU.

The diagnostic system model consists of:

• ???????????????????? ????????
• ??????(??) ???? ???? ??????????????????
• ?????? ?????????????????????????? ?????????????? ?????????????? ?????? ?????????????????????? ???????? ?????? ?????????????????? ??????(??) ??.??. ??????, ??????.

4.1.1 UDS Working topology:        

UDS functions in an elementary Client-Server topology. Where a ‘Tester’ requests for service, hence termed as a ‘client’, and the ECU responds or serves to the request made by the’ Tester’, hence known or termed as a server. The diagnostic tool requests a service and the ECU responds with results. And The response can be positive or negative.

Click here for more information.

• Tester/Client:

The Tester/Client uses the diagnostic functions and other functions such as database management, specific interpretations, and human-machine interface. A system that controls functions such as inspection, monitoring, testing, or diagnostics on and on-vehicle ECU, and it may be dedicated to a specific type of operator:

1. An off-board scan tool dedicated to garage mechanics.
2. An onboard tester tool dedicated to assembly plants, etc.

• Server:

The Server functions as a part of an ECU and provides diagnostics services. ECU contains at least one server. UDS differentiates between the server and ECU so that the standard remains independent from the implementation. Includes ABS (Anti-Lock Braking System) and engine management systems. Every server or ECU in the vehicle must be able to communicate with the tester tool as per the UDS protocol. The tester can trigger various actions in the ECU in the form of service requests. Such as,

1. ???????????????? ?????????????????????? ??????????????.
2. ???????? ???? ?????????? ?????? ?????????????????????? ?????????????? ????????.
3. ?????????????????????????????? ?????????????? ????????????.
4. ???????????????????? ?????????????????? ???????? ????????????.
5. ???????? ????????????-???????????????? ????????????.
6. ???????????????????? ?????? ????????.
7. ?????????????? ???????? ????????.
8. ?????????????? ?????????? ???? ???????????????????? ?????? ?????????????? ???????? ?????? ??????????????.
9. ???????????????? ?? ??????????????.
10. ???????????????? ????????????.
11. ?????????????? ?? ????????????????, ??????.

4.2 UDS Services

UDS defines many diagnostic services that can be requested by a tester as a client and performed by an ECU as a server:

• ???????????? ?????????????? ??????????????.
• ???????????? ???????????????? ????????????????.
• ?????????????? ????????????
• ?????????????????? ????????????????.

4.2.1 Request Messages VS Responce Messages        

Request Frame

• SID (Service Identifier): In a request frame, the SID specifies the type of diagnostic service being requested by the diagnostic tool. It indicates the action that the diagnostic tool wants the ECU to perform, such as reading data, clearing faults, or performing tests.
• subSID (Sub-Service Identifier): If a diagnostic service has multiple variants or sub-functions, the subSID may be included in the request frame to specify the particular variant or sub-function to be executed by the ECU.
• DID (Data Identifier): When requesting data parameters from the ECU, the diagnostic tool includes one or more DIDs in the request frame to specify the data parameters it wants to read or modify.

Responce Frame

• SID (Service Identifier): In a response frame, the SID corresponds to the service identifier of the diagnostic service that was requested by the diagnostic tool. It indicates the type of service performed by the ECU and the nature of the response.
• subSID (Sub-Service Identifier): If applicable, the subSID in the response frame provides additional information about the variant or sub-function of the diagnostic service that was executed by the ECU.
• DID (Data Identifier): In the response frame, DIDs are used to identify the data parameters included in the response. Each DID corresponds to a specific data parameter or data item returned by the ECU.
• Data Record: The Data Record contains the actual diagnostic data or results transmitted by the ECU in response to the diagnostic service request. It typically consists of multiple data parameters grouped together to provide comprehensive diagnostic information.

There are two types of response frames. That is a Positive response and a Negative response.

• Positive Response:

A positive response indicates that the requested diagnostic operation was successfully performed by the ECU.

It confirms that the diagnostic service request was understood and executed without any errors.

Positive responses often include relevant data or information requested by the diagnostic tool, such as sensor readings, diagnostic trouble codes (DTCs), or confirmation messages.

• Negative Response:

A negative response indicates that the requested diagnostic operation could not be completed or encountered an error.

It signifies that the ECU was unable to fulfill the diagnostic service request for various reasons, such as invalid parameters, unsupported functionality, or communication errors.

Negative responses may include error codes or status bytes to indicate the reason for the failure and provide diagnostic information to the diagnostic tool.

4.2.2 Message Timing        

For the session layer of UDS, there is no special operation besides the timing of handling requests/responses during communication. In general, we have to configure the following timers:

Tester

P2Client: Timeout value for the client to wait after the successful transmission of a request message till the start of the incoming response message.

• P2Client_max: is the initial/default value of P2Client
• P2*Client_max: enhanced timeout for the client to wait after the reception of a negative response message, with negative response code 0x78(requestCorrectlyReceived-ResponsePending) for the start of the next incoming response messages.

S3 client time: Time the diagnostic client (=tester) should wait before sending a tester present request.

ECU

P2Server: performance timer of ECU, and is either loaded with P2Server_max or P2*Server_max value.

• P2Server_max: The server either processes the request and sends back a response in time or the request processing is still going and the timeout(P2Server_max value) occurs then the server sends back a negative with NRC=0x78 for “requestCorrectlyReceived-ResponsePending” to notify about the pending final response.
• P2*Server_max: performance requirement for the server to start after the transmission of a negative response message with negative response code 0x78. In case the server can still not provide the requested information within the enhanced P2*Server_max, then a further(number of times depending on configuration) negative response message with negative response code 0x78 shall be sent again.

S3 server time: Timeout in the diagnostic server for leaving a non-default session.

P4Server: The performance requirement time is the period between receiving a request and beginning the transmission of the final response, which may be a positive or a negative response with a non-0x78 NRC. For requests to schedule periodic responses, the initial Unacknowledged Segmented Data Transfer (USDT) response, whether positive or negative, indicating acceptance or rejection of the scheduling request, is considered the final response. If P4Server_max equals P2Server_max, this prohibits a negative response with negative response code 0x78 for that service or data.

• P4Server_max: is the maximum value of P4Server

Click here for more information.

4.2.3 Diagnostic Session Control        

The diagnostic session’s service ID is 0x10 and the Response SID is 0x50.

???????????????????? ?????????????? ?????????????? is one of the most important services used by UDS. Diagnostic Session control is used for controlling the diagnostic session of the ECU. This service is used to change the current diagnostic session to a different session.

These sessions are used to enable or disable a particular set of diagnostic functions and features in an ECU.

Default Session(0x01)

• This session is in an idle state. Whenever the ECU is powered ON, it will be in this default session only. ECU remains in default session until another diagnostic session is requested from the client.
• Services like Write data byte identifier (0x2E), Read data byte identifier (0x22), ECU Reset (0x11), Tester Present (0x3E), and Reading DTC (0x19) are available in this session.
• Security access (0x27) is not available. This service has low security compared to all other diagnostics session control sub-functions.

Example: In a garage, a person is trying to read the Diagnostic Trouble Code(DTC).

Programming Session(0x02)

• This Session is used to program the ECU or transfer data from client to server.
• All the services that are allowed in the Default session are allowed in this session.
• ECUs are entered into default session if this session is ended or expired.

Example: Programming session is End line engineer flashing calibration software.

Extended Session(0x03)

• All services allowed in the Default session are allowed in this session
• This session is used to unlock the additional diagnostic functions also
• Security access(0x27) is allowed in this session, meaning security levels are unlocked in this session
• ECUs entered into default session if this session is ended or expired

Example: This session is End of line engineers doing a dynamic vehicle test to check the security level

4.2.4 ECU Reset        

The ECU reset’s service ID is 0x11 and the Response SID is 0x51.

ECU Reset service is used to restart the particular ECU or all the ECUs in the Vehicle. The motive of this service is to recover the ECU from malfunction or hanged state or non-working condition. During the reset of the ECU, it will not accept any request from the client and will not send any responses to the client. This service is supported in an Extended session. After a successful reset, the ECU shall return to the default session.

Hard Reset (0x01)

• Hard reset means removing the battery (power supply) from the ECU and connecting the ECU again with the battery.
• In this type of reset, ECU re-initializes the core hardware components of the system and also It will re-initializes the Non-volatile and volatile memory.
• This reset may lose some data because the battery is removed suddenly during the running time of the ECU.

Key off On Reset (0x02))

• The Key Off-On Reset is simply the ignition Off-On process of a vehicle. It is the normal sleep-wake-up mode of a Microcontroller.
• When we are doing Key Off On reset ECUs will not get the power down immediately. It will go to the boot mode then it will store all the data in Non-Volatile memory and de-initialize the hardware variables without losing any data.
• In this method of resetting, there is no chance of losing data. This is the proper way to reset, and most of the OEMs are using this type of ECU Reset.

Soft Reset (0x03)

• A soft reset is nothing but restarting the application’s main software. When we do this type of reset, the stack pointer of the microcontroller points to the main() function’s address. Then it will start to execute from first.

For Example, will take a watchdog reset. Whenever hanging or any malfunctions are happening, this watchdog timer will reset the microcontroller and it will start from the main() function.

4.2.5 Security Access        

The Security Access’s service ID is 0x27 and the Response SID is 0x67.

In the context of Unified Diagnostic Services (UDS), security access refers to the mechanisms by which access to certain diagnostic functions and operations within an Electronic Control Unit (ECU) is controlled and secured. Security access is crucial for preventing unauthorized access to sensitive vehicle systems and functions, such as engine control, emissions systems, and other critical components.

Click here for more information.

Security Access Levels

No Security Access

• At this level, no security mechanism is implemented.
• Access to diagnostic services is granted without any authentication or authorization.
• This level is typically used for testing or debugging purposes and may not be suitable for production environments due to security concerns.

Seed/Key Access

• This access level implements the Seed and Key mechanism for security.
• When a diagnostic session is initiated, the ECU responds with a seed value.
• The diagnostic tool then calculates a key using the seed and sends it back to the ECU.
• If the key is valid, access is granted to the requested diagnostic services.
• Level 1 provides basic security by requiring authentication for access to diagnostic functions.

Example

4.2.6 Read/Write Data By Identifier        

In the context of automotive diagnostics, particularly within the Unified Diagnostic Services (UDS) protocol, "Read/Write Data By Identifier" refers to a diagnostic service used to retrieve or modify specific data parameters stored within an Electronic Control Unit (ECU) of a vehicle.

Here's an overview of how this service typically works:

Read Data By Identifier

• This diagnostic service allows a diagnostic tool to request specific data values from the ECU by providing the corresponding data identifier (DID).
• The data identifier is a numeric value that uniquely identifies the parameter or data item being requested.
• The ECU responds with the current value of the requested parameter, allowing the diagnostic tool to retrieve information such as sensor readings, system status, or configuration settings.

Examples of RDBI service:

• Read the vehicle identification number
• Read the current software version

Write Data By Identifier

• This diagnostic service enables a diagnostic tool to modify specific data values within the ECU by providing the data identifier (DID) along with the new value.
• The diagnostic tool sends a request to the ECU specifying the DID and the desired new value for the parameter.
• If the ECU supports writable parameters with the specified identifier, it updates the parameter value accordingly and acknowledges the successful write operation.

Examples of WDBI service

• Write calibration data into ECU
• Clearing non volatile memory block

5. Unveiling the Core Functions of Automotive Diagnostic Event Manager (DEM)

The Diagnostic Event Manager (DEM) is a crucial component in automotive diagnostics, especially in modern vehicles with sophisticated electronic control systems. Its primary role is to manage diagnostic events, which are essentially notifications or alerts triggered by various conditions within the vehicle's systems.

Here are some key aspects and features typically associated with a DEM:

5.1 Operation Cycle

In automotive diagnostics, the operation cycle of a DEM (Diagnostic Event Manager) typically encompasses several phases or stages that occur during the vehicle's operation. These cycles are initiated by specific events or triggers and involve various tasks related to fault detection, error code generation, communication, and data logging.

The three primary operation cycles commonly associated with DEM are:

5.1.1 Power On/Off Cycle        

This cycle occurs when the vehicle's power is turned on (ignition switch turned to the "ON" position) or off (ignition switch turned to the "OFF" position). During the power-on cycle, the DEM initializes and performs diagnostic checks on various systems and components to ensure they are functioning properly. It may also retrieve diagnostic trouble codes (DTCs) stored in memory from previous driving cycles. The power-off cycle involves shutting down non-essential systems and preparing for vehicle shutdown.

5.1.2 Ignition On/Off Cycle        

Similar to the power on/off cycle, the ignition on/off cycle focuses specifically on the ignition switch state. When the ignition is turned on, the DEM begins monitoring sensors, performing system checks, and detecting any faults or abnormalities. It may also communicate with other ECUs (Electronic Control Units) and diagnostic tools. The ignition off cycle involves tasks such as clearing temporary diagnostic data, storing relevant information, and preparing for the next ignition cycle.

5.1.3 Drive Operation Cycle        

This cycle occurs during vehicle operation, encompassing the period between ignition on and off. Throughout the drive operation cycle, the DEM continuously monitors vehicle systems, sensors, and parameters for any deviations from normal operating conditions. It detects faults, generates diagnostic trouble codes (DTCs), logs relevant data, and may initiate appropriate actions to address identified issues. The drive operation cycle is critical for real-time diagnostics and maintaining vehicle performance and safety.

5.2 DTC (Diagnostic Trouble Code)

A DTC is a code generated by the DEM to indicate a specific problem or fault detected within the vehicle's systems. Each DTC corresponds to a particular issue, such as a malfunctioning sensor, a communication error between ECUs, or a system failure. DTCs provide valuable diagnostic information to technicians and service personnel, helping them identify and resolve problems efficiently.

A DTC defines unique identifier mapped to diagnostic event(of DEM) and can be interrogated later by Tester(through DCM).

• The first byte shall address the location of fault, basically the location of ECU in vehicle(e.g. Powertrain, Body,..) and whether this DTC is defined by ISO spec or manufacturer.
• The second byte show the failed component/system.
• The last byte show the failure category and subtype, detailed what kind of fault had occurred.

5.2.1 Freeze Frame        

In simple terms, a freeze frame is a snapshot of data. It’s a snapshot of sensor or component readings (parameter values) captured at the moment when the electronic control unit detected a malfunction. In addition, the freeze frame contains the Diagnostic Trouble Code (DTC) that the computer system identified as the reason for the malfunction.

If a monitor reports “Failed”, the relevant DIDs are temporarily stored with their measured values.

5.3 Priority

Event priority is defined as a ranking of events based upon level of importance. It is used to determine which fault entries may be removed from the event memory in case the number of stored events exceeds the maximum number of memory entries(event memory is full).

5.4 Aging

Aging is a process within the DEM where older diagnostic trouble codes (DTCs) or events may be cleared or archived after a certain period of time or number of ignition cycles. This helps prevent diagnostic clutter and ensures that the DEM focuses on current or recurring issues. Aging mechanisms vary depending on the vehicle's design and manufacturer specifications.

5.4.1 threshold        

In the context of aging within a Diagnostic Event Manager (DEM), the "threshold" refers to the predefined criteria used to determine when diagnostic trouble codes (DTCs) or events are cleared or archived due to aging. The aging process involves managing the lifespan of diagnostic information stored by the DEM. As time passes or a certain number of drive cycles occur, older DTCs and events may be considered less relevant or indicative of current issues. Therefore, the DEM implements threshold criteria to decide when to remove or archive these older entries.

Thresholds can be defined based on various factors, including:

1. Time: A threshold based on time specifies how long a diagnostic event or DTC will remain active before it is aged out. For example, the DEM may be configured to clear DTCs that have been active for a certain number of days or weeks.
2. Ignition Cycles: Another threshold parameter is based on the number of ignition cycles the vehicle has undergone since the diagnostic event occurred. This approach considers the vehicle's usage patterns, as some issues may only manifest intermittently.
3. Drive Cycles: Similar to ignition cycles, drive cycles refer to the number of times the vehicle has been driven since the event occurred. This threshold accounts for the vehicle's operational history and helps ensure that aged-out events are reflective of current conditions.
4. Severity of the Event: The severity of the event or DTC may also influence the aging threshold. Critical or high-priority faults may have longer lifespans before they are cleared compared to minor issues.

5.5 Enable Condition

An enable condition is a set of criteria or prerequisites that must be met for a specific diagnostic function or event to be activated or triggered. These conditions often involve specific sensor readings, system states, or environmental factors. For example, certain diagnostic tests or monitoring functions may only be enabled when the vehicle is operating within certain temperature ranges, speed limits, or driving conditions.

5.6 debouncing

In the context of a Diagnostic Event Manager (DEM), "debouncing" refers to a technique used to filter out and prevent the generation of multiple diagnostic events or trouble codes (DTCs) for a single underlying issue or fault. Debouncing in a Diagnostic Event Manager (DEM) involves various methods and techniques to filter out transient or spurious events and ensure the generation of accurate diagnostic trouble codes (DTCs).

Here are some common methods used for debouncing within a DEM:

5.6.1 Time-Based Debouncing:        

When enabled, the Dem provides an internal debounce timer for each individual event to qualify the reported event. The way it works is the same as the counter based debounce algorithm.

It’s also possible for the monitor to implement a debounce algorithm, instead of on the Dem side.

In that case, monitors which implement the debounce algorithm are not allowed to report the event status DEM_EVENT_STATUS_PREFAILED and DEM_EVENT_STATUS_PREPASSED.

5.6.2 Count-Based Debouncing:        

The Dem module increments its internal debounce counter until reaching the configured DemDebounceCounterFailedThreshold to mark an event as Failure. Conversely, it decrements the counter until reaching the DemDebounceCounterPassedThreshold to mark it as Passed. When the status argument is PASSED or FAILED, the counter immediately adjusts to respective threshold values. Additionally, if the monitor reports DEM_EVENT_STATUS_PREPASSED during counter incrementing, it jumps down to DemDebounceCounterJumpDownValue and begins decrementing.

6. Automotive Diagnostics Over CAN: Autosar's Approach

Automotive diagnostics play a crucial role in modern vehicles, enabling the monitoring and troubleshooting of various systems for optimal performance and safety. Within the Autosar framework, diagnostics over Controller Area Network (CAN) is a fundamental aspect, allowing for efficient communication between Electronic Control Units (ECUs) and diagnostic tools.

6.1 Software Modules for Segmentation

In Autosar, the handling of diagnostic messages over CAN involves specialized software modules responsible for segmenting diagnostic data into manageable units for transmission. These modules ensure that large diagnostic payloads are efficiently transmitted over CAN networks, optimizing bandwidth utilization and ensuring timely delivery of diagnostic information to external diagnostic tools.

6.2 Transport Protocol CANtp

The Transport Protocol (CANtp) serves as the foundation for diagnostics communication over CAN within the Autosar ecosystem. CANtp facilitates the reliable transmission of diagnostic messages by providing mechanisms for segmentation, reassembly, and error detection. It ensures that diagnostic data is transmitted in a structured and standardized manner, promoting interoperability among different ECUs and diagnostic tools across the automotive industry.

6.3 Frame Types

6.3.1 Single Frame        

Single frame messages are used for transmitting diagnostic data that can fit within a single CAN frame. These messages are ideal for conveying small to medium-sized diagnostic payloads with minimal latency. Single frame messages are efficient for transmitting critical diagnostic information such as sensor readings or fault codes in real-time.

6.3.2 First Frame        

First frame messages are employed when the size of the diagnostic payload exceeds the maximum payload limit of a single CAN frame. The first frame contains information about the total size of the diagnostic message and initiates the segmentation process. It serves as an indicator to the receiving ECU or diagnostic tool that the diagnostic data will be transmitted in multiple segments.

6.3.3 Consecutive Frame        

Consecutive frames carry the segmented portions of the diagnostic payload beyond the first frame. Each consecutive frame contains a segment of the diagnostic data along with sequence information to facilitate proper reassembly at the receiving end. These frames enable the transmission of large diagnostic payloads across the CAN network in a structured and organized manner.

6.3.4 Flow Control Frame        

Flow control frames are utilized in conjunction with segmented diagnostic messages to manage the flow of data between the transmitting and receiving entities. These frames convey information such as the buffer availability and the maximum number of segments that can be transmitted at a given time. Flow control frames help prevent data overflow and ensure reliable transmission of segmented diagnostic payloads.