Comprehensive Guide to Diagnostic
Introduction
Diagnostic related history and concept, from OBD, UDS to DoCAN, DoIP etc.
OBD
OBD stands for On-Board Diagnostics and is a computer system inside of a vehicle that tracks and regulates a car’s performance. This on-board computer system collects information from the network of sensors inside the vehicle, which the system can then use to regulate car systems or alert the user to problems. A technician can then simply plug into the OBD system to collect vehicle data and diagnose the problem. OBD systems have been a great help in helping users better understand vehicle diagnostics.
Based on ISO15765-1:2011(DoCAN) and ISO 13400-1:2011(DoIP), enhanced and legislated WWH-OBD diagnostic specifications applicable to the OSI layers are divided into:
| ISO 7498-1/ISO 10731 OSI 7 layers |
Vehicle manufacturer enhanced diagnostics |
Legislated OBD | Legislated WWH-OBD |
|---|---|---|---|
| Application Layer | ISO 14229-1, ISO 14229-3 |
ISO 15031-5 | ISO 27145-3, ISO 14229-1 |
| Presentation (layer 6) | Vehicle manufacturer specific | ISO 15031-2, ISO 15031-5, ISO 15031-6, SAE J1930-DA, SAE J1979-DA, SAE J2012-DA |
ISO 27145-2, SAE 1930-DA, SAE J1979-DA, SAE J2012-DA, SAE J1939:2011, Appendix C (SPN), SAE J1939-73:2010, Appendix A (FMI) |
| Session (layer 5) | ISO 14229-2 | ISO 14229-2 | ISO 14229-2 |
| Transport protocol (layer 4) | ISO 15765-2, ISO 13400-2 |
ISO 15765-2, ISO 15765-4 |
ISO 15765-4, ISO 15765-2, ISO 27145-4, ISO 13400-2 |
| Network (layer 3) | ISO 15765-2, ISO 13400-2 |
ISO 15765-2, ISO 15765-4 |
ISO 15765-4, ISO 15765-2, ISO 27145-4, ISO 13400-2 |
| Data link (layer 2) Physical (layer 1) |
ISO 11898-1, ISO 11898-2, ISO 11898-3, ISO 11898-5, ISO 13400-3, or user defined |
ISO 11898-1, ISO 11898-2, ISO 15765-4 |
ISO 15765-4, ISO 11898-1, ISO 11898-2, ISO 27145-4, ISO 13400-3 |
Components
A basic OBD system consists of a central system, a network of sensors, a connection point and indicators, creating a complete monitoring system with standardized access and readability. The OBD system consists of the following components:
- ECU: The central part of the OBD system is the Electronic Control Unit, or ECU. The ECU collects input from various sensors throughout the vehicle. The ECU then uses this data to either control parts of the vehicle, like fuel injectors, or monitor for issues.
- Sensors: There are sensors throughout vehicles covering every area from the engine and chassis to the electronic system itself. Each one of these systems sends codes to the ECU, specifying the source and the parameters of the signal. The ECU then “reads” and interprets this signal.
- DTC: If a sensor sends information to the ECU that falls outside of the normal range, the ECU saves the information as a code called a Diagnostic Trouble Code, or DTC. The DTC code essentially is a list of letters and numbers, which indicate the source and nature of the problem. DTC codes are usually standardized but may be manufacturer-specific. When a DTC is saved, the ECU sends a signal to your indicator light to state that a problem has been found. The DTC can also be pulled by linking a sensor to the connector for the OBD system.
- MIL: When the ECU collects a DTC code, it sends a signal to the vehicle dashboard to turn on the appropriate indicator lights. These lights, known formally as Malfunction Indicator Lights or MILs, provide an early warning system for vehicle malfunctions. Generally speaking, if the light turns on and stays on, the problem is minor. If the light flashes, the problem is urgent.
- DLC: All of the data and DTC codes collected by the ECU can be accessed via the Diagnostic Link Connector or DLC. The DLC port is the point of access for vehicles with OBD systems and is often found beneath the dashboard on the driver’s side of the vehicle, though it may be located elsewhere in commercial vehicles. Current vehicles are made with a standard OBDII system so that any scan tool with a type 2 cable can connect to the type 2 connector.
History
The history of on-board diagnostics goes back to the 1960s. Several organizations set the groundwork for the standard, including the California Air Resources Board (CARB), the Society of Automotive Engineers (SAE), the International Organization for Standardization (ISO) and the Environmental Protection Agency (EPA).
It’s important to note that before standardization, manufacturers were creating their own systems. The tools from each manufacturer (and sometimes models from the same manufacturer) had their own connector type, electronic interface requirements. They also used their own custom codes for reporting problems.
1968 — The first OBD computer system with scanning capability was introduced by Volkswagen.
1975 — Datsun introduced a simple OBD system with limited non-standardized capabilities.
1979 — The Society of Automotive Engineers (SAE) recommends a standardized diagnostic connector and set of diagnostic test signals.
1980 — GM introduced a proprietary interface and protocol capable of providing engine diagnostics through an RS-232 interface or more simply, by flashing the Check Engine Light.
1988 — Standardization of on-board diagnostics came in the late 1980s after the 1988 SAE recommendation that called for a standard connector and set of diagnostics.
1991 — The state of California required all vehicles to have some form of basic on-board diagnostics. This is referred to as OBD I.
1994 — The state of California mandated that all vehicles sold in the state starting in 1996 must have OBD as recommended by SAE — now referred to as OBDII. This stems from the desire to perform across the board emissions testing. OBDII included a series of standardized diagnostic trouble codes (DTCs).
1996 — OBD-II becomes mandatory for all cars manufactured in the United States.
2001 — EOBD (European version of OBD) becomes mandatory for all gasoline vehicles in the European Union (EU).
2003 — EOBD becomes mandatory for all diesel vehicles in the EU.
2006 — All vehicles manufactured in Australia and New Zealand were required to be OBD2 compatible.
2008 — Starting in 2008, all vehicles in the US are required to implement OBDII through a Controller Area Network as specified by ISO 15765-4.
2012 — ISO 27145 consists of the following parts, under the general title Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements
2013 — The ISO 13400 series has been established in order to define common requirements for vehicle diagnostic systems implemented on an IP communication link
2021 — SAE J1979-2 (“OBDonUDS”) , describes the communication between the vehicle’s OBD systems and test equipment required by OBD regulations. The new standard will be introduced in the USA from 2023 and will be mandatory from 2027
UDS (ISO 14229)
The Automotive UDS Protocol, also known as Unified Diagnostic Services, is a communication protocol used in the automotive industry for diagnostics, debugging, and vehicle communication. It provides a standardized way for electronic control units (ECUs) in vehicles to communicate with diagnostic tools and software applications. The protocol is based on the ISO 14229 standard and is widely used by automotive manufacturers and service technicians.
ISO 14229 has been established in order to define common requirements for diagnostic systems, whatever the serial data link is.
To achieve this, ISO 14229 is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU, server) are broken into the following layers in accordance with below table:
- — Application layer (layer 7), unified diagnostic services specified in this document, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, ISO 14229-8 UDSonCXPI, further standards and ISO 27145-3 VOBD.
- — Presentation layer (layer 6), vehicle manufacturer specific, ISO 27145-2 VOBD.
- — Session layer services (layer 5) specified in ISO 14229-2.
- — Transport layer services (layer 4), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 20794-3 CXPI, ISO 27145-4 VOBD.
- — Network layer services (layer 3), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 20794-3 CXPI, ISO 27145-4 VOBD.
- — Data link layer (layer 2), specified in ISO 11898-1, ISO 11898-2, ISO 17458-2, ISO 13400-3, IEEE 802.3, ISO 14230-2, ISO 17987-3 LIN, ISO 20794-4 CXPI, and further standards, ISO 27145-4 VOBD.
- — Physical layer (layer 1), specified in ISO 11898-1, ISO 11898-2, ISO 17458-4, ISO 13400-3, IEEE 802.3, ISO 14230-1, ISO 17987-4 LIN, ISO 20794-4 CXPI, and further standards, ISO 27145-4 VOBD.
| ISO 7498-1/ISO 10731 OSI 7 layers |
Vehicle manufacturer enhanced diagnostics |
VOBD |
|---|---|---|
| Application Layer | ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, ISO 14229-8 UDSonCXPI, further standards |
ISO 27145-3 |
| Presentation (layer 6) | Vehicle manufacturer specific | ISO 27145-2 |
| Session (layer 5) | ISO 14229-2 | ISO 14229-2 |
| Transport protocol (layer 4) | ISO 15765-2, ISO 13400-2 |
ISO 27145-4 |
| Network (layer 3) | ISO 15765-2, ISO 13400-2 |
ISO 27145-4 |
| Data link (layer 2) Physical (layer 1) |
ISO 11898-1, ISO 11898-2, ISO 11898-3, ISO 11898-5, ISO 13400-3, or user defined |
ISO 27145-4 |
UDS Protocol
The UDS protocol is a diagnostic protocol used in Automotive Vehicles to find the cause of a problem for the health check. Basically, it is used in the automotive field for vehicle diagnostic, ECU new software flashing, etc. Nowadays the use of the protocol is increasing due to its flexibility. This protocol is defined in ISO-14229-1 standard and it is derived from the ISO 14230-3 (KWP-2000) and ISO 15765-3 (Diagnostic Communication over the CAN (DoCAN).
The UDS (Unified Diagnostic Services) protocol operates at the 5th (Session layer) and 7th (Application layer) of the OSI model.
UDS Protocol Architecture
Those services allow a tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (server) applied for example on the electronic fuel injection, automatic gearbox, anti-lock braking system, etc., connected on a serial data link embedded in a road vehicle.
The server, usually a function that is part of the ECU, uses the application layer services to send response data, provided by the requested diagnostic service back to the client. The client is usually referred to as an External Test Equipment when it is off-board but can in some systems, also be an on-board tester. The usage of the application layer services is independent of the client being an off-board or on-board tester. It is a possibility to have more than one client on the same vehicle system.
The most typical network configuration of the client-server communication for the vehicle diagnostics: the client as an Off-board tester. Communication is based on a request-response model. In the context of diagnostics, the following concepts are useful for a better understanding of the semantics handled on the UDS standard environment:
- Diagnostic Trouble Codes (DTC ): The numerical common identifier fault condition identified by the on-board diagnostic system.
- Diagnostic Data: Data that is located in the memory of an electronic control unit that may be inspected and/or possibly modified by the tester (diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate values and various status information). EXAMPLES: vehicle speed, throttle angle, mirror position, system status, etc.
- Diagnostic Session: The current model of the server, which affects the level of diagnostic functionality.
- Diagnostic Routine: The routine that is embedded in an electronic control unit and that may be started by a server upon a request from the client. NOTE: It could either run instead of the normal operating program or run concurrently to the normal operating program. In the first case, the normal operation of the ECU is not possible. In the second case, multiple diagnostic routines may be enabled that run while all other parts of the electronic control unit are functioning normally.
- Tester: The system that controls functions such as test, inspection, monitoring or diagnosis of an in-vehicle electronic control unit and which may be dedicated to a specific type of operator (e.g. a scan tool dedicated to garage mechanics or a test tool dedicated to the assembly plant agents).
UDS Protocol Frame Format
UDS is a Request and Response-based protocol based on client-server architecture, and it has having unique service ID(SID). SID is the size of one byte, and it ranges from 0x00 to 0x3E .
Basically, there are 4 types of frame formats:
- Request frame with sub-function ID
- Request frame without sub-function ID
- Positive Response Frame
- Negative Response Frame
Use 0x11(ECU Reset) service as an example:
| SID | Sub-function ID | Description |
|---|---|---|
| 0x11 | 0x01 | Hard Reset |
| 0x11 | 0x02 | Key-Off On Reset |
| 0x11 | 0x03 | Soft Reset |
Request Frame Format
| Service ID (SID) | Sub-Function ID (optional) | Data Parameters |
|---|
Response Frame Format
Positive Response
In UDS diagnostics, the tester acts as a client, and ECUs act as a server. When the server (ECU)receives the service request from the tester, the server checks the message. If everything is fine, then it executes the requested service and responds to the client with a positive response. If the response is positive, then the 6th bit of the SID should be 1 .
For example,
Service ID – 0x31 => 0 0 1 1 0 0 0 1
For a positive response, 0 1 1 1 0 0 0 1 is equal to 0x71 (0x31 + 0x40).
In another way, we can say the positive response means SID+ 0x40 , There is no logical reason for this. Simply, it is defined in International standard IS0-14229-1:
| Service ID (SID) + 0x40 | Sub-Function ID (optional) | Data Response Code |
|---|
Negative Response
In UDS diagnostics, the tester acts as a client, and ECUs act as a server. When the server (ECU) receives the service request from the tester, ECU checks the message. If the server finds something wrong, then it executes the negative response and sends the Negative response code(NRC). There are some Negative Response Codes given below.
- General Rejection –
0x10 - Sub-Function Not Supported –
0x12 - Incorrect Message Length(IML) –
0x13 - Busy Repeat Request –
0x21 - Condition not correct –
0x22 - Request sequence Error –
0x24 - Request Out Of Range(ROOR) –
0x31 - Security Access Denied –
0x33 - Invalid Key –
0x35
| 0x7F | Service ID | Negative Response Code |
|---|
Functions of Diagnostic Services In UDS Protocol
Besides specifying services’ primitives and protocols that describe the client-server interaction, UDS also defines within its framework several functional units that comprise several services each, identified with a hexadecimal code. These units are intended for the different individual purposes that support the overall diagnostic function/task. The UDS protocol having different services for the different types of work tasks to do on the server. These are having 6- types as:
- Diagnostic and communication management.
- Data Transmission.
- Stored Data Transmission.
- Input/Output Control.
- Remote activation of routine.
- Upload/Download.
Each functional group has more than one service ID for different-2 tasks so to get the detail of the above functional group and related services.
Diagnostic Session Control
The diagnostic session’s service ID is **0x10 **and the Response SID is 0x50 . 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.
The main purpose of this diagnostic session is to give security to the ECU. It will prevent the ECU from unwanted access. And only an authorized person can access it. If every diagnostics service can access the ECU, it may get damaged by the wrong flashing of software.
So before making any diagnostic request, the Client must make sure that this service is accessible or not in the ECU current session. if not, then first send a request for session change after that desirable request shall be performed.
If the Server(ECU) is in a non-default session or if there is diagnostic inactivity for 5 seconds, the ECU goes back to the default session.
| Sub-function | Description |
|---|---|
| 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 |
| Safety system Diagnostic system(0x04) | * Used to test all safety-critical diagnostic functions. * This diagnostics session control sub-function has a high level of security. Example : This session is checking the safety of Airbags, and tire pressure monitors. |
| 0x05 to 0x3F | Reserved |
| Vehicle Manufacture Specific (0x40 to 0x5F) | This session depends on Each OEM, If they want to implement any session based on their requirement they can use it. |
| System supplier Specific (0x60 to 0X7E) | This session is also like Vehicle Manufacture Specific only but instead of the vehicle manufacturer, if the system suppliers want to implement any session based on their specific requirement they can use it. |
| 0x7F | Reserved |
ECU Reset
The ECU reset’s service ID is 0x11 and the Response SID is 0x51 .
| Sub-function | Description |
|---|---|
| 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. |
| Enable Rapid Power shutdown (0x04) | * In this type of reset, ignition off will not occur. ECU will go to sleep mode and ECU is ready to wake up at any time. |
| Disable Rapid Power shutdown (0x05) | * This service is used to disable the previously enabled rapid power shutdown. |
Security Access
The Security Access’s service ID is **0x27 **and the Response SID is 0x67. This service will grant Read, and Write access to the particular service. Before processing any of the Service IDs(SID) operation, it’s mandatory to check the security access, to know whether, for this SID, the client has access to read or write.
Security access is granted based on these two:
- Seed (0x01)
- Key (0x02)
- The tester sends the request to unlock the ECU using SID 0x27 and sub-function ID 0x01 . 0x01 means requesting for seed.
- The UDS server receives the request assumes conditions are correct and generates the random seed and key based on a cryptographic algorithm and the Server sends the Seed to the client with a positive response.
- With the received seed, the tester tool generates the key and sends this key to the server to unlock the ECU using SID 0x27 and sub-function ID 0x02 . 0x02 means key.
- If the unlock key sent by the tester tool(client) matches with the server expecting key it will send the positive response and Unlock the ECU otherwise it will send a negative response with the specific negative response code.
Authentication Service
This Authentication service was added after the year 2020, and this is used to provide a standardized approach to more modern methods of authentication than are permitted by the Security Access ( 0x27 ) service, including bidirectional authentication with PKI-based Certificate Exchange.
The Authentication’s service ID is 0x29 and the Response SID is 0x69 .
ReadMemoryByAddress (0x23): UDS Protocol
The ReadMemoryByAddress service enables the client to request memory data from the server. It involves specifying a starting address and the size of memory to be read.
The ReadMemoryByAddress request message is used to request memory data from the server based on the specified memory address and size. The byte count for the memory address and size is determined by the addressAndLengthFormatIdentifier (low and high nibble). Using a fixed addressAndLengthFormatIdentifier is also an option. Any unused bytes in the memory address or size parameter are padded with the value 00 hex in the higher range address locations.
WriteMemoryByAddress (0x3D): UDS Protocol
This service allows the client/Tester to write information into the server/ECU at one or more contiguous memory locations. The tester sends a memory address, and the number of bytes, and a data string (according to the number of bytes ). The ECU writes the data string into its memory. The addressAndLengthFormatIdentifier parameter in the request specifies The number of bytes used for the memory address and memory size parameter.
Routine Control (31 hex): UDS Protocol
The Vehicle Diagnostics may require testing the faulty component in a given range of parameters. During vehicle testing, certain system tests may need an extended runtime. To initiate a test, the client triggers a routine in the server’s memory. Two methods exist in this UDS Protocol remote request service: one where the client interrupts the routine to halt it, and the other where the server/ECU completes the routine after a specified time frame. This service allows the client to initiate, interrupt, and check the result of a routine after successful execution.
Requests: RoutineControlType:
- startRoutine (01 hex).
- stopRoutine (02 hex).
- reqestRoutineControl (03 hex).
Other OBD and UDS Ddiagnostic Services
One of the most important concepts in UDS is the diagnostic service identifier (SID), which is a one-byte code that specifies what kind of service the tester is requesting from the ECU.
| SID | Description |
|---|---|
| 01-0Ahex | OBD services |
| 10hex | DiagnosticSessionControl |
| 11hex | ECUReset |
| 14hex | ClearDiagnosticInformation |
| 19hex | ReadDTCInformation |
| 22hex | ReadDataByIdentifier |
| 23hex | ReadMemoryByAddress |
| 27hex | SecurtityAccess |
| 29hex | Secure Diagnostics |
| 2Ehex | WriteDataByIdentifier |
| 2Fhex | InputOutputControlByIdentifier |
| 31hex | RoutineControl |
| 34hex | RequestDownload |
| 35hex | RequestUpload |
| 36hex | TransferData |
| 37hex | RequestTransferExit |
| 38hex | RequestFileTransfer |
| 3Dhex | WriteMemoryByAddress |
| 3Ehex | TesterPresent |
| 85hex | ControlDTCSetting |
| 86hex | ResponseOnEvent |
| 87hex | LinkControl |
ODX (Open Diagnostic data eXchange)
The standard ODX ISO 22901-1 (O pen D iagnostic data e X change) describes an XML format for exchanging diagnostic data. It contains both diagnostic specifics and flash data for individual ECUs, as well as Information on accessing the entire vehicle network. The data is usually processed on a D-Server in accordance with ISO 22900-3.
PDX （Packaged ODX）, a collection of CDX
Timing Performance
Timing parameters play a crucial role in Unified Diagnostic Services (UDS) for managing the timing aspects of diagnostic communication between electronic control units (ECUs) in vehicles and diagnostic tools. These parameters help regulate the timing of various diagnostic services and functions within the UDS protocol to ensure efficient and reliable communication. Some common timing parameters in UDS include:
- P2 Timeout : This parameter defines the time interval between consecutive diagnostic requests from the diagnostic tool to the ECU. It ensures that the diagnostic tool does not overwhelm the ECU with requests.
- P2 Timeout *: This parameter is similar to P2 Timeout but is used for specific services that require a different timing interval.
- P3 Timeout : This parameter specifies the maximum time allowed for an ECU to respond to a diagnostic request. If the response is not received within this timeout period, the diagnostic tool may consider the request as failed.
- S3 Timeout : This parameter specifies the time interval for which an ECU should stay in the “response pending” state after receiving a request. If the ECU does not provide a response within this timeout, the diagnostic tool may consider the request as failed.
- Communication Timeout : This parameter sets the maximum time allowed for the completion of a diagnostic communication session between the diagnostic tool and the ECU.
Proper configuration and management of timing parameters in UDS are essential for ensuring efficient and reliable diagnostic communication, minimizing delays, and preventing communication errors. Timing parameters help in optimizing the timing aspects of diagnostic services and ensuring timely exchange of diagnostic information between ECUs and diagnostic tools.
Abbreviation
| Abbreviation | Description |
|---|---|
| BRS | bit rate switch |
| BS | BlockSize |
| CAN | controller area network |
| CAN FD | controller area network with flexible data rate and larger payload as defined in ISO 11898-1 |
| CLASSICAL CAN | controller area network with static data rate and up to 8 data bytes as defined in ISO 11898-1 |
| CF | ConsecutiveFrame |
| CTS | continue to send |
| DA | destination address |
| DLC | CAN frame data link layer data length code |
| DoCAN | diagnostic communication over controller area network |
| ECM | Engine Control Module |
| ECU | Electronic Control Unit |
| FC | FlowControl |
| FF | FirstFrame |
| FF_DL | FirstFrame data length in bytes |
| FMI | failure mode indicator |
| FS | FlowStatus |
| ID | identifier |
| Mtype | message type |
| N/A | not applicable |
| NA | network address |
| N_AE | network address extension |
| N_AI | network address information |
| N_Ar | network layer timing parameter Ar |
| N_As | network layer timing parameter As |
| N_Br | network layer timing parameter Br |
| N_Bs | network layer timing parameter Bs |
| N_ChangeParameter | network layer service name |
| N_Cr | network layer timing parameter Cr |
| N_Cs | network layer timing parameter Cs |
| N_Data | network data |
| N_PCI | network protocol control information |
| N_PCItype | network protocol control information type |
| N_PDU | network protocol data unit |
| N_SA | network source address |
| N_SDU | network service data unit |
| N_TA | network target address |
| SOM | start of message |
| SP | nominal sample point |
| SPN | suspect parameter number |
| STmin | Separation Time minimum |
| STRT | serviceToRespondTo |
| TA | target address |
| TCM | transmission control module |
| UDS | unified diagnostic services |
| USDT | unacknowledged segmented data transfer |
| UUDT | unacknowledged unsegmented data transfer |
| WWH-OBD | world-wide harmonized on-board diagnostics |
| ISO 15031 | OBD |
| ISO 15765 | DoCAN |
| ISO 13400 | DoIP |
| ISO 14229 | UDS |
| ISO 27145 | WWH-OBD |