Automotive Diagnostic Standards

Table of Contents

Introduction to Vehicle Diagnostics

As global emissions continue to rise, many countries have implemented strict regulations to reduce vehicle emissions, driving the adoption of advanced technologies in modern automobiles.

Automotive diagnostics play a key role in identifying, verifying, and classifying symptoms to determine the root cause of issues in a vehicle. The detection, mitigation, and communication of abnormal system operations are monitored by electrical and electronic systems. The primary goal of diagnostics is to identify the underlying cause of a malfunction, enabling effective repairs, in order to restore the function of the vehicle systems which impact emissions.

Exhaust pipes

Image: Exhaust pipes

Diagnostics are applied in several key areas of vehicle development and operation:

  • Development: During development, diagnostics validate the correct functionality of vehicle components. The diagnostic subsystem is used to access an ECU’s internal data, including sensor readings and actuator values.
  • Production: In the manufacturing process, diagnostics are used to transfer calibration data and software updates to an ECU’s non-volatile memory. This includes End-of-Line (EOL) programming and system testing.
  • Aftersales: Diagnostics are critical for error detection in operational vehicles. Detected errors are stored in a persistent fault memory, and trouble codes are retrieved during service visits to facilitate troubleshooting and repairs.

Throughout the automotive system’s lifecycle—development, production, and service—diagnostics serve essential functions. To support these functions, diagnostic systems must utilize common databases, such as the ODX (Open Diagnostic Data Exchange) standard, which defines tools for data management, change tracking, and diagnostic development. These systems require computer tools to interface with communication protocols and diagnostic connectors, enabling comprehensive and efficient diagnostics.

Go back

Early OBD Systems

The introduction of on-board diagnostic (OBD) systems marked a turning point in the automotive industry, paving the way for significant advancements in vehicle maintenance and emissions control. Early OBD systems provided manufacturers and technicians with valuable tools to diagnose and troubleshoot faults in vehicle systems. However, during their initial development, these systems lacked standardization across the industry. Fault codes, diagnostic procedures, and testing methodologies varied significantly not only between manufacturers but also across different vehicle models within the same manufacturer.

The California Air Resources Board (CARB) played a pivotal role in the evolution of OBD systems. By the early 1980s, CARB recognized the potential of the emerging diagnostic capabilities in electronic control units (ECUs) for emissions monitoring. CARB saw an opportunity to leverage OBD systems to identify vehicles with emission-related malfunctions and assist technicians in repairing these faults. Their foresight laid the foundation for the regulatory framework that would shape modern OBD systems.

In April 1985, CARB formally proposed and adopted the first OBD requirements under Title 13 of the California Code of Regulations (1968). These regulations mandated that vehicles equipped with OBD systems should be capable of monitoring key emission-control components and alerting drivers to malfunctions that could lead to increased emissions. This early legislative action marked the beginning of a standardized approach to on-board diagnostics.

Vehicle OBD Timeline

Image: Vehicle OBD Timeline
Credit: CSS Electronics

During the early 1980s, automotive manufacturers increasingly incorporated electronic control units (ECUs) into their vehicles. These computers were tasked with managing various functions, including engine operation, fuel delivery, and emission control. The integration of ECUs allowed for more precise control over engine parameters, enabling improvements in fuel efficiency, performance, and emissions reduction.

As vehicle systems grew in complexity, manufacturers recognized the need for built-in diagnostic capabilities to aid in maintenance and repair. These early diagnostic tools were embedded in ECU software and could perform basic tests to identify faults in sensors, actuators, and circuits. Diagnostics often focused on emission-related systems, reflecting the growing regulatory and environmental emphasis on reducing vehicle emissions.

The diagnostic methods used in these early systems were rudimentary by modern standards. Typically, technicians initiated diagnostic tests by grounding a specific pin on the ECU’s connector. Once activated, the ECU would output fault information using a simple signaling method: a series of voltage “blips” or pulses. Each pattern of blips corresponded to a numerical fault code that technicians could interpret using service manuals.

Electronic Control Unit (ECU)

Image: Electronic Control Unit (ECU)
Credit: Delphi

Fault codes in these early systems were often tied to specific circuits, sensors, or components. For example, a fault code might indicate an open or short circuit in a sensor, a failure in an actuator, or an out-of-range signal. Service manuals provided detailed troubleshooting procedures to guide technicians in identifying and resolving the underlying issues.

Despite their limitations, these early OBD systems were invaluable. They allowed technicians to diagnose faults without disassembling components unnecessarily, saving time and reducing maintenance costs. However, the lack of standardization presented challenges. Technicians needed manufacturer-specific tools and knowledge, which increased the complexity and cost of vehicle repair.

The diversity of early OBD implementations highlighted the need for a unified approach. Without standardization, interpreting fault codes and performing diagnostics was cumbersome, particularly for independent repair shops servicing multiple vehicle brands. This fragmentation underscored the importance of developing industry-wide standards to ensure consistency and interoperability.

CARB’s initial OBD requirements were a step toward addressing these challenges. By mandating that OBD systems monitor emissions-related components and provide standardized alerts, CARB set the stage for further advancements in OBD technology. Over the coming decades, these early efforts would evolve into the comprehensive OBD-II standards that are now universally adopted.

In summary, early OBD systems laid the groundwork for the sophisticated diagnostics we rely on today. While they faced challenges related to fragmentation and limited functionality, their development marked a significant leap forward in automotive technology, enabling more efficient vehicle maintenance and advancing environmental protection efforts.

Go back

OBD-I

The first generation of On-Board Diagnostics, known as OBD-I, marked the initial effort to integrate diagnostic capabilities into vehicles to monitor emission control systems and improve maintenance efficiency. These systems were introduced as a regulatory requirement to reduce vehicle emissions and ensure compliance with environmental standards. While primitive compared to modern OBD systems, OBD-I played a significant role in shaping the future of automotive diagnostics.

Introduced with the 1988 model year, OBD-I regulations were applied to new light-duty vehicles to enhance emissions monitoring and repair accuracy. These requirements remained in effect until the advent of OBD-II standards, continuing to apply to some vehicles through the 1996 model year.

OBD-I systems were designed with a few essential capabilities:

  • Malfunction Indicator Light (MIL): vehicles were required to have a dashboard warning light, typically labeled as “Check Engine” or “Service Engine Soon.” The MIL served as a visual alert to notify drivers of emission-related malfunctions.
  • On-Board Testing: OBD-I systems included basic diagnostic tests within the electronic control unit (ECU) software to detect malfunctions in various emission-related components and systems.
  • Fault Code Storage: when a fault was detected, the ECU stored a diagnostic trouble code (DTC) corresponding to the malfunction. These codes indicated the likely area of the fault and remained in the ECU’s memory for a specified period, such as 50 engine start/run cycles, even if the issue was intermittent or self-corrected.
Engine MIL

Image: Engine MIL

OBD-I requirements mandated the monitoring of specific emission-related components and systems, including:

  • Electronic Control Unit (ECU): The central processing unit responsible for managing engine and emission control systems. The ECU itself was monitored for electrical issues like open or short circuits.
  • Fuel Metering System: Sensors and actuators related to fuel injection or carburetion were monitored to ensure proper fuel-air mixture for combustion.
  • Ignition System: Components such as spark plugs, ignition coils, and timing mechanisms were checked for faults that could impact combustion efficiency.
  • Exhaust Gas Recirculation (EGR) System: If equipped, the EGR system was monitored for proper operation to ensure recirculation of exhaust gases to reduce nitrogen oxide (NOx) emissions.

OBD-I systems focused primarily on electrical issues, such as open or short circuits, in critical emission-related components. These faults were detected using basic diagnostic logic within the ECU. For example, if a sensor output was outside its expected voltage range, the ECU flagged it as a fault.

When a malfunction was detected, a diagnostic trouble code (DTC) was generated. Early fault codes were numerical and specific to the manufacturer, often requiring proprietary diagnostic tools or manuals for interpretation. This lack of standardization created challenges for independent repair shops and technicians.

Exhaust Gas Recirculation (EGR)

Image: Exhaust Gas Recirculation (EGR)
Credit: Bosch

Despite its groundbreaking role in automotive diagnostics, OBD-I had several limitations that highlighted the need for more advanced and standardized systems:

  • Limited Component Coverage: OBD-I did not monitor all emission control system components. Key systems, such as catalytic converters and evaporative emission control (EVAP) systems, were not included in the monitoring scope. This meant that many potential sources of increased emissions could go undetected.
  • Non-Standardized Implementation: OBD-I regulations did not require manufacturers to standardize diagnostic codes, connector types, or testing procedures. Each manufacturer developed its own proprietary system, making it difficult for technicians to work on multiple brands and increasing the cost of diagnostic tools.
  • Basic Diagnostic Capabilities: The diagnostic tests in OBD-I systems were relatively simple, primarily focusing on electrical faults like opens and shorts. Performance-related issues, such as sensor degradation or component efficiency loss, were often undetectable.
  • Driver Information: While the MIL provided a useful alert for drivers, it offered no information on the nature of the fault. This often left vehicle owners dependent on technicians to diagnose even minor issues.

The OBD-I regulations represented a substantial step forward in integrating diagnostic capabilities into vehicles. By mandating on-board monitoring of critical emission control components, these regulations helped technicians identify malfunctions more efficiently and repair vehicles equipped with ECUs. However, the limitations of OBD-I underscored the need for a more comprehensive and standardized diagnostic system.

The lessons learned from OBD-I informed the development of OBD-II, which introduced standardized codes, connectors, and protocols, as well as broader monitoring capabilities. While OBD-I systems are now obsolete, their legacy lives on in the sophisticated diagnostic technologies that have become a cornerstone of modern automotive engineering.

Go back

OBD-II

The journey toward OBD-II began in November 1988 when CARB proposed revisions to the OBD-I system. These revisions aimed to expand the scope of on-board diagnostic systems, ensuring the continuous monitoring of all emission-related components for proper performance under real-world conditions. Following extensive collaboration with automobile manufacturers, the U.S. Environmental Protection Agency (EPA), and the Society of Automotive Engineers (SAE), CARB officially adopted the OBD-II regulations on September 12, 1992. These were codified under Section 1968.1, Title 13, California Code of Regulations.

OBD-II regulations initially applied to all gasoline, diesel, and alternative-fuel passenger cars and trucks starting with the 1994 model year. This mandate covered vehicles with a gross vehicle weight rating (GVWR) of up to 14,000 pounds.

OBD-II introduced stringent requirements for monitoring emission control systems and components. The key systems monitored under OBD-II include:

  • Catalyst System: Ensures the catalytic converter operates efficiently in reducing hydrocarbons (HC), carbon monoxide (CO), and nitrogen oxides (NOx).
  • Engine Misfire: Detects combustion irregularities that could increase emissions or damage the catalytic converter.
  • Evaporative Emission Control System: Monitors for fuel vapor leaks and ensures the system effectively captures and stores fuel vapors.
  • Secondary Air Injection System: Verifies proper airflow during cold starts to help oxidize emissions.
  • Fuel System: Tracks fuel delivery and injector performance.
  • Oxygen Sensors: Monitors the air-fuel mixture by measuring oxygen levels in the exhaust.
  • Exhaust Gas Recirculation (EGR) System: Ensures proper recirculation of exhaust gases to reduce NOx formation.
  • Positive Crankcase Ventilation (PCV) System: Confirms proper ventilation of engine blow-by gases.
  • Engine Cooling System: Tracks cooling efficiency and thermostat performance.
  • Cold Start Emission Reduction Strategy: Monitors systems that reduce emissions during engine warm-up.
  • Air Conditioning System: Ensures compliance with emissions standards for refrigerant use.
  • Variable Valve Timing (VVT) System: Validates the proper operation of timing adjustments for efficiency and emissions reduction.
  • Direct Ozone Reduction System: Monitors systems designed to reduce ozone formation.
  • Diesel Particulate Trap: Ensures proper function in trapping particulate matter from diesel engines.

OBD-II regulations include a provision for monitoring any electronic powertrain component or system that:

  • Contributes to vehicle emissions under typical driving conditions.
  • Plays a role in the diagnostic strategy of other monitored systems.

This requirement extends to sensors, actuators, and control modules that interface with the vehicle’s on-board computer. Malfunctions affecting these systems are to be promptly identified and reported, ensuring emissions compliance and facilitating timely repairs.

Diesel Particulate Filter (DPF)

Image: Diesel Particulate Filter (DPF)
Credit: Audi

The OBD-II standards underwent significant revisions on April 25, 2002, resulting in the creation of two new sections in the California Code of Regulations:

  • Section 1968.2: Addressed enhanced requirements for 2004 and subsequent model-year vehicles, focusing on malfunction detection and diagnostic systems.
  • Section 1968.5: Introduced enforcement provisions for malfunction and diagnostic system requirements.

The revised regulations incorporated advanced diagnostic features, including:

  • Enhanced Catalyst Monitoring: Expanded requirements to include monitoring of NOx conversion efficiency, alongside the existing HC efficiency checks.
  • Improved Monitoring Frequency: Increased checks for intermittent faults in critical components.
  • Diesel Vehicle Requirements: Mandated monitoring of catalyst systems and particulate matter traps to address emissions from diesel engines.
  • Variable Valve Timing and Cold Start Strategies: Included these systems in the monitoring framework due to their impact on emissions.

To assist repair technicians and Inspection and Maintenance (I/M) programs, the new OBD-II requirements also mandated the provision of extensive diagnostic data, including:

  • Parameter IDs (PIDs): Real-time data from sensors and systems.
  • Freeze Frame Data: Captures system status at the moment of a detected fault.
  • Mode $06 Data: Provides detailed diagnostic test results for technicians.
  • Pending Codes: Early warning of potential faults before they trigger the malfunction indicator lamp (MIL).
  • Monitor Readiness Status: Indicates whether specific diagnostics have been completed since the last system reset.
  • Vehicle Identification Information: Includes VIN, Calibration Identification (CALID), and Calibration Verification Number (CVN).

To streamline access, the regulations standardized the placement of the Diagnostic Link Connector (DLC).

OBD-II connector

Image: OBD-II connector

From the 2008 model year onwards, vehicles were required to implement J2284/ISO 15765-4 (Controller Area Network, or CAN) protocols for data communication. This standard ensures compatibility and reliability across all OBD-II-compliant vehicles, simplifying diagnostic processes for technicians and inspectors.

OBD-II represents a transformative leap in automotive diagnostics and emissions control. By enabling real-time monitoring of critical systems, OBD-II helps reduce vehicle emissions, enhance repair efficiency, and ensure compliance with regulatory standards. Its evolution demonstrates the continuous effort to improve diagnostic precision and environmental stewardship in the automotive industry.

Go back

EOBD

EOBD (European On-Board Diagnostics) is the European equivalent of OBD-II, designed to monitor the emission control systems of vehicles in compliance with European Union (EU) regulations. Introduced in 2001 for petrol vehicles and in 2004 for diesel vehicles, EOBD was implemented as part of the EU’s strategy to reduce air pollution and enforce stricter emission limits.

EOBD systems share many similarities with OBD-II, but they are tailored to European regulatory requirements. Key features include:

  • Emission System Monitoring: EOBD monitors critical emission control components, such as the catalytic converter, oxygen sensors, particulate filters (in diesel engines), and the fuel injection system. The system detects malfunctions that may cause emissions to exceed the permissible limits set by EU standards.
  • Diagnostic Trouble Codes (DTCs): Like OBD-II, EOBD uses standardized diagnostic trouble codes (DTCs) to identify faults. These codes help technicians diagnose and repair malfunctions in the vehicle’s emission system.
  • Standardized Diagnostic Connector: EOBD mandates the use of a standard 16-pin diagnostic connector, similar to OBD-II, allowing universal diagnostic tools to be used across different vehicle brands.
  • Malfunction Indicator Light (MIL): Vehicles equipped with EOBD feature a MIL on the dashboard to alert drivers when an emission-related fault is detected.
  • Fuel Type Adaptation: EOBD systems are designed to accommodate a variety of fuels, including petrol, diesel, and alternative fuels like liquefied petroleum gas (LPG) and compressed natural gas (CNG).
Diesel engine

Image: Diesel engine
Credit: VW

While EOBD is largely modeled on OBD-II, there are some key differences and region-specific adaptations:

Feature OBD-II EOBD
Region of application United States of America European Union
Introduction year 1996 2001 (petrol/gasoline) / 2004 (diesel)
Focus Comprehensive emissions and performance monitoring Primarily focused on emissions monitoring
Monitored standards Complies with EPA and CARB regulations Complies with EU emission standards (Euro 3, Euro 4, etc.)
Vehicle types Gasoline, diesel, hybrid, and alternative fuel vehicles Gasoline, diesel, LPG, and CNG vehicles
Diesel emission monitoring Comprehensive but introduced later Integral from the start due to stricter EU diesel emissions standards
Connector and codes Standardized 16-pin connector and universal DTCs Same as OBD-II, ensuring compatibility with diagnostic tools

Unique Aspects of EOBD

  • Focus on Diesel Engines: Due to the popularity of diesel vehicles in Europe, EOBD systems were designed with stricter diesel emission monitoring from the outset. Features like particulate filter monitoring and NOx emissions detection were emphasized.
  • Alignment with Euro Standards: EOBD directly correlates with the European “Euro” emission standards (e.g., Euro 3, Euro 4, etc.), ensuring vehicles meet specific limits for CO2, NOx, and particulate emissions.
  • Implementation Timeline: Unlike OBD-II, which was implemented across all vehicle types in 1996, EOBD was introduced in phases, beginning with petrol vehicles in 2001 and later extending to diesel vehicles in 2004.

Both OBD-II and EOBD represent milestones in automotive diagnostics and emissions control. By providing real-time monitoring and diagnostic capabilities, these systems have enabled significant reductions in vehicle emissions while improving maintenance efficiency. The collaborative effort between the U.S. and European regulatory frameworks has also led to global standardization, making modern vehicles more environmentally friendly and easier to service worldwide.

Go back

Vehicle Diagnostic System

The modern automobile consists of a structured set of subsystems, including the powertrain, chassis, body, and other functional domains driven by customer needs and regulatory requirements.

These subsystems are increasingly managed by electrical and electronic components using sophisticated control algorithms and software strategies. These systems must align with strict automotive standards to ensure reliability, safety, and performance under diverse operating conditions.

In automotive electronics, an Electronic Control Unit (ECU) refers to a dedicated electronic device designed to monitor, control, and manage specific vehicle subsystems. ECUs are integral to embedded control systems, which require well-defined methodologies, processes, and tools for their development.

A generic ECU comprises of:

  • input/output interfaces: Facilitate the handling of digital and analog signals from various sensors and actuators.
  • communication controllers: Enable data exchange between the ECU and other modules within the vehicle, often via protocols like CAN, LIN, or Ethernet.

This architecture allows ECUs to interconnect as part of a larger ECU network cluster, ensuring seamless communication and coordination across multiple subsystems. The image below illustrates the block diagram of a generic ECU, showcasing these core components and their functional layout.

Block Diagram and Architecture of generic ECU

Image: Block Diagram and Architecture of generic ECU
Credit: [1]

Automotive ECUs are categorized based on the specific subsystems they control. Common examples include:

  • Engine Control Module (ECM): Manages engine performance, including fuel injection, ignition timing, and emission controls.
  • Powertrain Control Module (PCM): Oversees both engine and transmission systems, integrating their operations for optimal efficiency.
  • Transmission Control Module (TCM): Handles automatic transmission functions, including gear shifts and torque converter operation.
  • Electronic Brake Control Module (EBCM): Monitors and controls braking systems such as ABS and traction control.
  • Suspension Control Module: Adjusts suspension settings for ride comfort and stability based on road conditions.

Other specialized modules are defined and named by the Original Equipment Manufacturer (OEM), depending on vehicle requirements and design specifications.

Example of automotive EE architecture

Image: Example of automotive EE architecture
Credit: [2]

In many cases, modern vehicle architectures consolidate the functions of multiple ECUs into a single assembly. For example, the PCM often integrates the functionalities of the ECM and TCM, streamlining the management of engine and transmission systems. This modular approach reduces hardware complexity, optimizes system communication, and enhances overall vehicle performance.

This evolution toward integrated systems exemplifies the growing sophistication of automotive electronics, where advanced ECUs serve as the backbone of modern vehicle technology, meeting both consumer expectations and stringent regulatory demands.

OBD-II requires continuous monitoring of a vehicle’s emission-related components, such as the catalytic converter, oxygen sensors, and fuel system. These tasks are performed by the Engine Control Module (ECM) or Powertrain Control Module (PCM), which monitors and adjusts engine and transmission parameters to ensure compliance with emissions standards.

Go back

OSI Model

The OSI (Open Systems Interconnection) model is a conceptual framework that standardizes network communication into seven hierarchical layers. Each layer performs specific functions, enabling interoperability between different systems and technologies.

OSI Model

Figure x. OSI Model.

  1. Physical Layer (Layer 1): Handles the physical connection between devices, including cables, connectors, and signaling.
  2. Data Link Layer (Layer 2): Manages data frames and error detection/correction during transmission.
  3. Network Layer (Layer 3): Handles data routing, addressing, and packet forwarding between devices on different networks.
  4. Transport Layer (Layer 4): Ensures reliable data transfer with error recovery and flow control.
  5. Session Layer (Layer 5): Manages sessions or connections between applications.
  6. Presentation Layer (Layer 6): Translates data formats and handles encryption/decryption for application-layer compatibility.
  7. Application Layer (Layer 7): Interfaces directly with end-user applications, enabling high-level communication services.

This layered model allows different communication systems to interact easily by adhering to standardized protocols and interfaces.

OBD-II diagnostic systems leverage communication protocols to facilitate data exchange between vehicle Electronic Control Units (ECUs) and external diagnostic tools. While OBD-II itself does not explicitly follow the OSI model, its communication protocols align with OSI principles.

Here is a table that maps each OSI model layer to its implementation in the OBD-II standards, including references to relevant ISO and SAE standards. An explanation for each layer follows the table.

OSI Layer Implementation in OBD-II Diagnostic Standards
Physical (Layer 1) Defines the physical connection via the Diagnostic Link Connector (DLC). Includes pinouts, voltage levels, and signal characteristics. SAE J1962
ISO 15765-4
ISO 9141-2
SAE J1850
Data Link (Layer 2) Handles message framing, error detection (e.g., CRC), and arbitration on the bus (e.g., CAN arbitration). ISO 15765-4 (CAN)
SAE J1850
ISO 9141-2
Network (Layer 3) Routes diagnostic messages to the correct ECU using addressing schemes. ISO 15765-4 (CAN)
SAE J1979
Transport (Layer 4) Manages message segmentation and reassembly, flow control, and error recovery. ISO 15765-2 (CAN transport layer)
SAE J1979
Session (Layer 5) Establishes and maintains diagnostic communication sessions. ISO 14229 (UDS)
ISO 15765-4
Presentation (Layer 6) Converts raw binary or hexadecimal data into human-readable or interpretable formats (e.g., PIDs, freeze frame data). SAE J1979 (OBD-II PID decoding)
Application (Layer 7) Defines the diagnostic services and data exchange (e.g., retrieving DTCs, emission readiness). SAE J1979
SAE J2012 (DTCs)
ISO 14229 (UDS)

Go back

OBD-II mapped to OSI

Physical Layer (Layer 1)

Implementation: The DLC (Diagnostic Link Connector) provides the physical interface for diagnostic tools to connect to the vehicle. Standards like SAE J1962 specify the pin configuration and physical attributes of the connector. The communication medium includes twisted-pair wires for CAN or single wires for older protocols (J1850, ISO 9141).

OBD-II DLC Pinout

Image: OBD-II DLC Pinout
Credit: CSS Electronics

Standards:

  • SAE J1962: DLC pinout and physical interface.
  • ISO 15765-4: Physical layer specifications for CAN.
  • ISO 9141-2 and SAE J1850: Older physical layer standards.

Data Link Layer (Layer 2)

Implementation: Responsible for creating and interpreting message frames, performing error detection (e.g., CRC), and managing access to the bus using arbitration (in CAN). This ensures reliable communication between the diagnostic tool and the ECU.

Standards:

  • ISO 15765-4: Defines CAN data framing and error control.
  • SAE J1850: Describes older data link layer protocols (VPW and PWM).
  • ISO 9141-2: For older, slow-speed communication.

Network Layer (Layer 3)

Implementation: OBD-II systems use addressing to direct messages to specific ECUs. For instance, the CAN protocol defines identifiers for different ECUs.

Standards:

  • ISO 15765-4: Includes addressing schemes for message routing in CAN networks.
  • SAE J1979: Specifies network-level behavior for OBD-II systems.

Transport Layer (Layer 4)

Implementation: Segmentation and reassembly of larger messages are handled here, especially in CAN-based protocols. This layer also implements flow control and error recovery to ensure reliable data transfer.

Standards:

  • ISO 15765-2: Defines transport layer mechanisms for CAN.
  • SAE J1979: Specifies error-handling and data transfer methods.

Session Layer (Layer 5)

Implementation: OBD-II requires the establishment of diagnostic sessions for data retrieval or fault diagnostics. The session ensures that the diagnostic tool and ECU remain synchronized during communication.

Standards:

  • ISO 14229: Unified Diagnostic Services (UDS) protocol for session control.
  • ISO 15765-4: Supports session-related operations in OBD-II.

Presentation Layer (Layer 6)

Implementation: Converts raw data (e.g., hexadecimal fault codes or sensor readings) into standardized formats like PIDs (Parameter IDs) or freeze frame data, making it understandable for technicians or diagnostic applications.

Standards:

  • SAE J1979: Specifies PID formats and freeze frame data encoding.

Application Layer (Layer 7)

Implementation: Defines diagnostic services such as reading DTCs, retrieving live sensor data, and checking emission readiness. This layer includes the diagnostic protocols that the OBD-II system uses to interact with the technician’s tools.

Standards:

  • SAE J1979: Core OBD-II application protocol for emission-related diagnostics.
  • SAE J2012: Defines Diagnostic Trouble Codes (DTCs).
  • ISO 14229: UDS for extended diagnostic functions in newer systems.

The OBD-II system aligns well with the OSI model, with each layer corresponding to specific aspects of diagnostic communication. By adhering to ISO and SAE standards, OBD-II ensures a standardized, interoperable framework for fault detection and diagnostics across all compliant vehicles. This integration enables efficient and reliable vehicle maintenance.

Go back

ISO 9141

This standard was used by many Japanese manufacturers. ISO 9141 is not a Network protocol, it can only be used for diagnostics. The first variant of the standard did not have bus arbitration therefore it could only be used to connect only one ECU to the diagnostic control module.

ISO 9141 is relatively slow, the data transmission speed is 10.4 Kbps.

There are 3 variants of the standard:

  • ISO 9141:1989
  • ISO 9141-2:1994
  • ISO 9141-3:1998

ISO 9141:1989

Overview: The original ISO 9141 standard defines a single-wire serial communication interface for automotive diagnostic systems. It focuses on the electrical characteristics and signaling of the communication bus, laying the groundwork for subsequent OBD communication standards.

Mapping to OSI Model:

  • Physical layer (Layer 1): Specifies the single-wire communication bus, voltage levels, and timing requirements for signal transmission.
  • Data Link layer (Layer 2): Introduces basic framing for messages and error detection mechanisms.

Applications: Used in pre-OBD-II vehicles for simple diagnostic communication. This standard lacks robust multi-device communication capabilities.

ISO 9141-2:1994

Overview: ISO 9141-2 enhances the original standard with additional specifications for fault-tolerant communication. It is explicitly designed for OBD-II compliance, providing a standardized protocol for vehicles that require diagnostics of emission-related systems.

Mapping to OSI model:

  • Physical layer (Layer 1):
    • Specifies two key lines:
      • K-Line: Used for data transmission and reception.
      • L-Line: Optional, used for wake-up signaling in some systems.
    • Defines voltage thresholds and timing characteristics for bus signals.
  • Data Link layer (Layer 2):
    • Includes message framing, addressing, and error detection via checksum mechanisms.
    • Supports half-duplex communication (data is sent and received alternately).
  • Session layer (Layer 5) (Basic):
    • Introduces diagnostic session initiation through a specific handshake sequence using the K-Line.

Applications: Widely adopted in European and Japanese vehicles for OBD-II diagnostics, ensuring interoperability between diagnostic tools and vehicles.

ISO 9141-3:1998

Overview: ISO 9141-3 builds upon ISO 9141-2 by introducing multiplexed communication capabilities, allowing more than one diagnostic device or ECU to share the same communication line.

Mapping to OSI Model:

  • Physical layer (Layer 1): Maintains the single-wire bus but improves signal handling to support multiple nodes.
  • Data Link layer (Layer 2):
    • Introduces arbitration and bus access control mechanisms to allow multiple devices to communicate without collisions.
    • Enhances framing and error detection for more reliable diagnostics in complex systems.
  • Network layer (Layer 3):
    • Adds basic addressing to distinguish between multiple devices on the bus.

Applications: Used in vehicles with more advanced diagnostic requirements, especially where multiple ECUs or diagnostic tools interact.

Summary of ISO 9141 mapped to OSI Model

OSI Layer ISO 9141:1989 ISO 9141-2:1994 ISO 9141-3:1998
Physical (Layer 1) Single-wire communication, voltage levels, and timing. Adds K-Line and optional L-Line for wake-up signals. Refines physical signaling for multiplexed communication.
Data Link (Layer 2) Basic message framing and error detection. Frames messages, handles checksums, and supports half-duplex. Adds arbitration and collision avoidance for multiple devices.
Network (Layer 3) Not applicable. Not applicable. Introduces basic addressing for multiple nodes.
Transport (Layer 4) Not applicable. Not applicable. Not applicable.
Session (Layer 5) Basic session handling. Adds handshake protocols for session initiation. Similar to ISO 9141-2.
Presentation (Layer 6) Not applicable. Not applicable. Not applicable.
Application (Layer 7) Not covered (defined by other standards). Not covered (defined by SAE J1979 or similar). Not covered (defined by SAE J1979 or similar).

ISO 9141 Summary

  • ISO 9141:1989: Introduced foundational single-wire communication for automotive diagnostics.
  • ISO 9141-2:1994: Adapted for OBD-II compliance, adding K-Line and diagnostics-specific enhancements.
  • ISO 9141-3:1998: Enabled multiplexed communication for more advanced diagnostic environments.

These standards fit within the lower layers of the OSI model, focusing on physical and data link functionalities, with limited extensions into session management. Higher layers (e.g., application) rely on standards like SAE J1979 to define OBD-II diagnostic commands and data formats.

Go back

SAE J1850 PWM (Pulse Width Modulation)

SAE J1850 is also one of the communication protocols used in OBD-II systems for vehicle diagnostics. It comes in two variants: PWM (Pulse Width Modulation) and VPW (Variable Pulse Width). The PWM variant is predominantly used in Ford and some other North American vehicles.

The protocol operates on a two-wire bus with differential signaling, ensuring robust communication in electrically noisy automotive environments. It supports message broadcasting and arbitration, enabling multiple ECUs to communicate efficiently.

J1850 PWM was used in Ford vehicles. which was called internally as Standard Corporate Protocol (SCP). J1850 PWM is a true Network protocol that in corporates bus arbitration and it’s used for both vehicle network communication and diagnostic communication.

Technical specification

  • Bit rate:
    • Operates at 41.6 kbps.
  • Signal lines:
    • Bus+ and Bus- lines are used for differential signaling, which provides improved noise immunity.
  • Voltage levels:
    • High voltage = 5 V (dominant state).
    • Low voltage = 0 V (recessive state).
  • Message framing:
    • Message frames are broadcasted in a Pulse Width Modulated (PWM) signal, with timing defining data bits (0s and 1s).
  • Arbitration:
    • A contention-based arbitration mechanism ensures that higher-priority messages are transmitted first.

Mapping to OSI Model

OSI Layer SAE J1859 PWM implementation
Physical (Layer 1) Defines the electrical characteristics of the two-wire bus, including differential signaling, voltage levels, and timing.
Data Link (Layer 2) Manages message framing, bus arbitration, error detection (CRC), and acknowledgment.
Network (Layer 3) Not explicitly defined. J1850 uses broadcast messaging, and addressing is implicit in message IDs.
Transport (Layer 4) Not explicitly defined. Messages are short enough (<12 bytes) to avoid segmentation.
Session (Layer 5) Basic session initiation is handled implicitly via broadcasting and tool-initiated diagnostics.
Presentation (Layer 6) Not applicable. The interpretation of raw data is handled by higher-level standards like SAE J1979.
Application (Layer 7) Diagnostic requests and responses, such as retrieving DTCs or PIDs, are defined by higher-level protocols (e.g., SAE J1979).

Advantages of SAE J1850 PWM

  • Differential signaling: Enhances robustness against noise, making it suitable for automotive environments.
  • Bus arbitration: Ensures efficient communication without collisions, prioritizing critical messages.
  • Backward compatibility: Widely used in OBD-II compliant vehicles before transitioning to CAN.

Limitations of SAE J1850 PWM

  • Low data rate: The 41.6 kbps bit rate is slow compared to newer protocols like CAN.
  • Limited scalability: The 12-byte frame size restricts data transmission for advanced diagnostics.
  • Obsolescence: Gradually replaced by ISO 15765-4 (CAN) due to its higher speed and broader feature set.

SAE J1850 Summary

SAE J1850 PWM fits the lower layers of the OSI model, focusing on physical and data link functionalities, with basic support for session management. Higher-level OBD-II standards like SAE J1979 handle application-layer communication, making SAE J1850 PWM an integral but now largely outdated part of the OBD-II ecosystem.

Go back

SAE J1850 VPW (Variable Pulse Width)

SAE J1850 VPW (Variable Pulse Width) is a communication protocol used in OBD-II systems for vehicle diagnostics. It is predominantly found in General Motors (GM) vehicles and differs from SAE J1850 PWM (Pulse Width Modulation) in its single-wire signaling and specific timing for bit representation.

VPW facilitates communication between the vehicle’s diagnostic tools and its electronic control units (ECUs). It adheres to the SAE J1850 specification but implements a distinct signaling mechanism, making it compatible only with systems designed for VPW.

It is classified by General Motors as a Class 2 protocol, which is a true network protocol that incorporates bus arbitration. As a class 2 protocol, it is used for both vehicle network communication and diagnostic communication.

Technical specification

  • Bit rate:
    • Operates at 10.4 kbps.
  • Signal lines:
    • Uses a single-wire bus for communication, simplifying vehicle wiring.
  • Voltage levels:
    • High (dominant): +7 V.
    • Low (recessive): 0 V.
  • Message framing:
    • Frames include a start-of-frame (SOF), data bytes, cyclic redundancy check (CRC), and an end-of-frame (EOF).
  • Arbitration
    • Arbitration is achieved by timing priority: lower IDs (higher priority) win the bus in contention scenarios.
  • Broadcast Communication:
    • Diagnostic requests and responses are broadcasted, and only relevant ECUs respond.

Mapping to OSI Model

OSI Layer SAE J1859 VPW implementation
Physical (Layer 1) Defines single-wire bus, voltage levels (+7V/0V), and bit timing for variable pulse width signaling.
Data Link (Layer 2) Manages message framing, bus arbitration, error detection (CRC), and acknowledgment.
Network (Layer 3) Not explicitly defined. VPW uses broadcast messaging with implicit addressing via message IDs.
Transport (Layer 4) Not explicitly defined. Messages are small (<12 bytes), eliminating the need for segmentation.
Session (Layer 5) Basic session handling occurs during diagnostic tool interactions with ECUs.
Presentation (Layer 6) Not applicable. Higher-level standards handle data interpretation and formatting.
Application (Layer 7) Supports OBD-II diagnostics, including retrieving diagnostic trouble codes (DTCs) and parameter IDs (PIDs), defined by SAE J1979.

Comparison of SAE J1850 VPW and PWM

Feature SAE J1850 VPW SAE J1850 PWM
Bit rate 10.4 kbps 41.6 kbps
Signal type Single-wire Two-wire differential
Voltage levels +7V (high), 0V (low) +5V (high), 0V (low)
Primary use General Motors vehicles Ford and some other manufacturers
Arbitration Timing-based priority Timing-based priority
Noise immunity Moderate High (due to differential signaling)

Applications and Limitations

  • Applications:
    • Predominantly used in GM vehicles for OBD-II diagnostics.
    • Enables basic fault detection and emission monitoring.
  • Limitations:
    • Lower speed compared to PWM and modern protocols like CAN.
    • Limited scalability due to the single-wire architecture.
    • Being replaced by more robust and faster standards like ISO 15765-4 (CAN).

SAE J1850 VPW Summary

SAE J1850 VPW maps primarily to the lower layers of the OSI model, with functionality focusing on physical signaling, message framing, and basic arbitration. Higher-level diagnostic operations depend on complementary standards like SAE J1979. Though effective for its time, VPW has largely been phased out in favor of faster and more versatile communication protocols.

Go back

ISO 14230 (Keyword Protocol 2000)

The ISO 14230 standard, commonly known as Keyword Protocol 2000 (KWP2000), defines a set of specifications for diagnostic communication in road vehicles over a K-Line. K-Line was widely used in OBD-II systems before being replaced by faster protocols like CAN. This standard provides a robust framework for emission diagnostics and control, enabling communication between a vehicle’s electronic control units (ECUs) and diagnostic tools.

ISO 14230 consists of four parts, each addressing a specific layer or requirement of the communication protocol. Below is a technical breakdown of these parts, their functionality, and their implementation.

ISO 14230 has been established in order to define common requirements for vehicle diagnostic systems implemented on K-Line (UART based) communication link, as specified in this part of ISO 14230.

ISO 14230 consists of the following parts, under the general title Road vehicles — Diagnostic communication over K-Line (DoK-Line):

  • Part 1: Physical layer (ISO 14230-1)
  • Part 2: Data link layer (ISO 14230-2)
  • Part 3: Application layer (ISO 14230-3)
  • Part 4: Requirements for emission-related systems (ISO 14230-4)

ISO 14230-1 Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 1: Physical layer

The physical layer defines the electrical and physical connection characteristics of the K-Line. This layer ensures the proper transmission of diagnostic signals between the diagnostic tool and the vehicle’s ECUs over a single-wire bus.

Technical characteristics of ISO 14230 Physical Layer:

  • Based on ISO 9141-2:The physical layer of ISO 14230 is derived from ISO 9141-2, which was an earlier standard for vehicle diagnostics. It retains many of the foundational elements of this protocol.
  • Voltage supply: It supports vehicles with either 12 V d.c. or 24 V d.c. voltage supplies, making it versatile for different vehicle types.
  • Communication protocol: The protocol allows for both single-wire and dual-wire communication methods, enhancing flexibility in how diagnostic tools connect to vehicle systems.
  • Baud rate: The standard specifies a baud rate of 10.4 kbps, which is the speed at which data is transmitted over the communication line. This rate is suitable for the diagnostic messages exchanged between the vehicle and the diagnostic tool.
  • Signal levels: The physical layer defines specific signal levels for logical high and low states, ensuring reliable communication. Typically, a logical high is represented by a voltage close to the supply voltage (12 V), while a logical low is near ground (0 V).
  • Connector specifications: ISO 14230 outlines the connector types and pin assignments used for interfacing diagnostic tools with the vehicle’s onboard diagnostic (OBD) system, ensuring standardization across different manufacturers.
  • Message framing: The standard includes specifications for message framing, which defines how messages are structured and transmitted, including start and stop bits, data bits, and parity bits.
ISO 14230 Standard Mapping to OSI Model

Image: ISO 14230 Standard Mapping to OSI Model
Credit: iso.org

In summary, the ISO 14230 physical layer is a crucial component of vehicle diagnostic communication, providing a standardized method for connecting diagnostic tools to vehicle systems. Its compatibility with different voltage supplies, communication methods, and defined signal levels ensures effective and reliable diagnostics across various vehicle models. Understanding these characteristics is essential for professionals in the automotive industry to facilitate accurate vehicle diagnostics and maintenance.

ISO 14230-2 Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer

The data link layer handles message framing, error detection, and control mechanisms for communication over the K-Line. It ensures reliable data exchange between ECUs and the diagnostic tool.

The data link layer is designed for UART-based communication over the K-Line, which is a single-wire communication method commonly used in vehicle diagnostics.

Technical characteristics of ISO 14230 Data Link layer:

  • Message framing:
    • Each message consists of a header, payload, and checksum.
    • Headers can be 1-byte (default) or 3-byte (enhanced) for extended functionality.
  • Error detection:
    • A checksum byte is used to detect transmission errors.
  • Flow control:
    • Defines mechanisms for handling message acknowledgments and retransmissions.
  • Session management:
    • Supports diagnostic sessions to manage ongoing communication.

This layer ensures the structured exchange of data, allowing ECUs to interpret and respond to diagnostic requests reliably. It also provides mechanisms for retrying failed messages and controlling the flow of data.

ISO 14230-3 Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 3: Application layer

The application layer defines the diagnostic commands and responses exchanged between the diagnostic tool and the vehicle. It specifies how the data is structured and interpreted for diagnostic purposes.

Technical characteristics of ISO 14230 Application layer:

  • Diagnostic services: Supports UDS-like services (Unified Diagnostic Services), such as:
    • Read Data by Identifier (0x22): Retrieve real-time data or ECU parameters.
    • Request Diagnostic Trouble Codes (0x13): Retrieve emission-related trouble codes.
    • Clear Diagnostic Trouble Codes (0x14): Reset fault codes in the ECU.
  • Data formats:
    • Defines how data fields are encoded, including numerical and string values.
  • Session control:
    • Allows transitioning between different diagnostic modes (e.g., normal, extended).

ISO 14230-4 Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4: Requirements for emission-related systems

While this part specifies requirements unique to emissions systems, it operates in conjunction with ISO 14230-1 (physical layer), ISO 14230-2 (data link layer), and ISO 14230-3 (application layer). Together, these standards form a complete diagnostic communication system.

Go back

ISO 15031

The ISO 15031 Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics series is a set of standards defining the communication between On-Board Diagnostic (OBD) systems in vehicles and external diagnostic tools. It ensures the seamless exchange of data for emissions-related diagnostics, supporting regulatory compliance and facilitating vehicle maintenance. Developed in collaboration with the Society of Automotive Engineers (SAE) and other international bodies, ISO 15031 is closely aligned with OBD-II standards and incorporates various diagnostic protocols, including SAE J1979.

The standard covers critical aspects of diagnostic communication, such as parameter data identification (PIDs), diagnostic trouble codes (DTCs), and test mode definitions. It enables standardized access to information on emission control systems, ensuring interoperability across vehicles and diagnostic equipment. By fostering global harmonization, ISO 15031 plays a vital role in reducing environmental impact and enhancing automotive repair efficiency.

The table below provides a description of the different parts of the ISO 15031 standard and their equivalent SAE standard.

ISO Standard Title Description Equivalent SAE Standard
ISO 15031-1 General information and use case definition Provides general information, an overview of the document set, use case definitions, and common resources such as definitions and references for other parts. N/A
ISO 15031-2 Guidance on terms, definitions, abbreviations and acronyms Defines standard terminology, abbreviations, and acronyms used throughout the ISO 15031 series to ensure clarity and uniformity. SAE J1930
ISO 15031-3 Diagnostic connector and related electrical circuits, specification and use Specifies the diagnostic connector (DLC) and its electrical requirements, ensuring compatibility across vehicles and diagnostic tools. SAE J1962
ISO 15031-4 External test equipment Defines requirements for external test equipment used for accessing OBD functions, including power, communication interfaces, and signal protocols. SAE J1978
ISO 15031-5 Emissions-related diagnostic services Describes diagnostic services (e.g., retrieving diagnostic trouble codes, freeze frame data) that external equipment can use to interact with emission-related ECUs. SAE J1979
ISO 15031-6 Diagnostic trouble code definitions Specifies a standardized format for diagnostic trouble codes (DTCs), ensuring uniformity in fault identification across vehicles. SAE J2012
ISO 15031-7 Data link security Addresses the security mechanisms needed to protect OBD communication from unauthorized access and tampering. SAE J2186

The ISO 15031 standard series provides a structured framework for emissions-related On-Board Diagnostic (OBD) communication requirements, effectively mapping to various layers of the OSI model as shown in the table. It integrates seamlessly with related standards, such as ISO 14230 (Keyword Protocol 2000) and ISO 9141, to address the diverse physical, data link, and application-layer requirements of OBD communication.

ISO 15031 Standard Mapping to OSI Model

Image: ISO 15031 Standard Mapping to OSI Model
Credit: iso.org

Go back

ISO 27145

The ISO 27145 standard, named Road Vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) Communication Requirements, is a globally standardized framework for diagnostic communication in vehicles. It is designed to support the regulatory requirements of the Worldwide Harmonized Light Vehicle Test Procedure (WLTP) and extend the principles of On-Board Diagnostics (OBD) to a global context. ISO 27145 is essential for ensuring interoperability between vehicle manufacturers and diagnostic equipment providers, facilitating consistent emission control monitoring and fault detection across diverse vehicle types and regions.

This standard is applicable to modern communication protocols such as Unified Diagnostic Services (UDS) over Controller Area Network (CAN) and Ethernet, addressing the growing complexity of vehicle systems. By harmonizing diagnostic protocols worldwide, ISO 27145 promotes environmental compliance, enhances repair efficiency, and simplifies the diagnostic processes in a rapidly evolving automotive industry. It serves as the successor to region-specific OBD standards, such as ISO 15031 (OBD-II), and aligns with global emissions regulations.

The table below provides a description of the different parts of the ISO 27145 standard.

ISO Standard Title Description
ISO 27145-1 General information and use case definition Defines the overall framework of WWH-OBD, including the general structure, use case definitions, and resource organization.
ISO 27145-2 Common data dictionary Provides a harmonized data dictionary for emission-related diagnostics, ensuring consistent interpretation of parameters globally.
ISO 27145-3 Common message dictionary Specifies diagnostic services and communication protocols for WWH-OBD systems, supporting diagnostic access across global markets.
ISO 27145-4 Connection between vehicle and test equipment Defines transport protocols, ensuring reliable data transfer between diagnostic tools and vehicles over CAN or Ethernet.
ISO 27145-6 External test equipment (under preparation)

ISO 27145 accommodates various transport mechanisms (e.g., CAN, DoIP) and harmonized parameter definitions, making it scalable and suitable for diverse vehicle platforms globally. The standard ensures vehicles meet global emissions regulations through unified diagnostic communication.

ISO 27145 Standard Mapping to OSI Model

Image: ISO 27145 Standard Mapping to OSI Model
Credit: iso.org

Go back

ISO 15765

The ISO 15765 Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) standard, defines common requirements for vehicle diagnostic systems using the Controller Area Network (CAN), as specified in the ISO 11898 series. The ISO 15765 series presumes the use of external test equipment for inspection, diagnostics, repair and other possible use cases connected to the vehicle.

ISO Standard Title Description
ISO 15765-2 Transport protocol and network layer services Defines transport and network layer protocols for efficient communication over CAN, including segmentation and reassembly of diagnostic messages.
ISO 15765-4 Requirements for emissions-related systems Specifies requirements for emissions-related diagnostics (OBD-II and WWH-OBD), ensuring compliance with regulatory standards.
ISO 15765-5 Specification for an in-vehicle network connected to the diagnostic link connector Specifies the OSI layers 4 to 1 (transport layer, network layer, data link layer and physical layer) requirements related to the connection between the external test equipment externally connected to the diagnostic link connector

ISO 15765 is divided into several parts, each addressing specific aspects of communication, including the physical layer, transport protocols, and network layer implementation. By utilizing the CAN protocol, ISO 15765 ensures robust and high-speed communication across vehicle systems while supporting the growing complexity of automotive electronics. Its modular design also allows compatibility with higher-layer standards like ISO 14229 (UDS) and ISO 27145 (WWH-OBD), making it a well established standard for automotive diagnostics.

ISO 15765 Standard Mapping to OSI Model

Image: ISO 15765 Standard Mapping to OSI Model
Credit: iso.org

Go back

ISO 14229

The ISO 14229 series, titled Road Vehicles — Unified Diagnostic Services (UDS), defines a comprehensive framework for diagnostic communication within modern vehicles. It provides a standardized set of services for managing and monitoring vehicle electronics, covering a wide range of tasks, including fault detection, ECU programming, and system diagnostics. Designed to address the increasing complexity of automotive systems, ISO 14229 enables seamless interaction between diagnostic tools and various electronic control units (ECUs) across different vehicle manufacturers.

ISO Standard Title Description
ISO 14229-1 Application layer This document specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle.
ISO 14229-2 Session layer services This document specifies common session layer services and requirements to provide independence between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay, ISO 14230-2 DoK-Line, and ISO 20794-3 CXPI).
ISO 14229-3 Unified diagnostic services on CAN implementation (UDSonCAN) This document specifies an application profile for the implementation of unified diagnostic services (UDS) on controller area network (CAN) in road vehicles.
ISO 14229-4 Unified diagnostic services on FlexRay implementation (UDSonFR) This part of ISO 14229 specifies the implementation of a common set of unified diagnostic services (UDS) on FlexRay networks (FR) in road vehicles (UDSonFR).
ISO 14229-5 Unified diagnostic services on Internet Protocol implementation (UDSonIP) This document specifies an application profile for the implementation of unified diagnostic services (UDS) Internet Protocol (IP) in road vehicles (UDSonIP).
ISO 14229-6 Unified diagnostic services on K-Line implementation (UDSonK-Line) This part of ISO 14229 specifies the implementation of a common set of unified diagnostic services (UDS) on K-Line (UART based) in road vehicles (UDSonK-Line).
ISO 14229-7 UDS on local interconnect network (UDSonLIN) This document specifies an application profile for the implementation of unified diagnostic services (UDS) local interconnect network (LIN) in road vehicles (UDSonLIN).
ISO 14229-8 UDS on Clock eXtension Peripheral Interface (UDSonCXPI) This document specifies the implementation of a common set of unified diagnostic services (UDS) on clock extension peripheral interface networks in road vehicles. The UDSonCXPI diagnostics defines methods to implement diagnostic data transfer between a client and the CXPI slave nodes via the CXPI master node.

This standard is widely used in combination with transport protocols like ISO 15765-2 (CAN) and ISO 13400-2 (DoIP) to ensure robust and efficient communication. ISO 14229 is integral to on-board diagnostics (OBD) and supports compliance with global regulatory requirements. By unifying diagnostic services, it promotes interoperability, improves repair efficiency, and simplifies the development of diagnostic tools and systems.

OSI layer Enhanced diagnostic services
Application (layer 7) 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
Presentation (layer 6) vehicle manufacturer specific
Session (layer 5) ISO 14229-2
Transport (layer 4)
Network (layer 3)
ISO 15765-2 ISO 10684-2 ISO 13400-2 Not applicable ISO 17987-2 ISO 20794-2
Data link (layer 2)
Physical (layer 1)
ISO 11898-1,
ISO 11898-2
ISO 17458-2
ISO 17458-4
ISO 13400-3,
IEEE 802.3
ISO 14230-2
ISO 14230-1
ISO 17987-3
ISO 17987-4
ISO 20794-4

Go back

References

[1] Helio Rocha Pegorer et al, Communication Protocols Analysis for Automotive Diagnostic: KWP2000, J1939 and UDS, SAE Technical Paper, 2013-36-0248.
[2] Shreejith Shanker, Enhancing Automotive Embedded Systems with FPGAs, Thesis, April 2016.
[3] https://www.iso.org

Leave a Reply

Ad Blocker Detected

Dear user, Our website provides free and high quality content by displaying ads to our visitors. Please support us by disabling your Ad blocker for our site. Thank you!

Refresh