OBD-II Port Elimination in Germany: Understanding the Future of Vehicle Diagnostics

The On-Board Diagnostic system, or OBD-II, has become a cornerstone of modern vehicle maintenance and data access. For years, the standardized OBD-II port has provided mechanics, enthusiasts, and third-party services with crucial insights into vehicle health and performance. But what if this ubiquitous port were to disappear, particularly in a major automotive hub like Germany?

This article delves into the world of OBD-II, exploring its functions, history, and the potential shift towards Obdii Port Elimination Germany. We’ll examine the concerns driving this potential change and what it could mean for vehicle diagnostics and data accessibility in the future.

What is OBD-II? A Diagnostic Gateway

OBD-II is essentially your car’s internal health monitor. It’s a standardized system integrated into vehicles, designed to self-diagnose and report issues. This protocol allows access to diagnostic trouble codes (DTCs) and real-time data through a standardized OBD-II connector, typically a 16-pin port.

You’ve likely encountered OBD-II in action if you’ve ever seen the check engine light illuminate on your dashboard.

This light, also known as the malfunction indicator light (MIL), signals a problem detected by the car’s onboard diagnostics. Mechanics use OBD-II scanners to communicate with the vehicle’s computer, retrieving DTCs and live data to pinpoint the issue.

Connecting an OBD-II scanner to the OBD-II 16 pin connector, usually located near the steering wheel, allows technicians to send ‘OBD-II requests’ and receive ‘OBD-II responses’. These responses can include vital information such as speed, fuel level, and those all-important Diagnostic Trouble Codes (DTCs), streamlining the troubleshooting process.

OBD-II Compatibility: Is Your Car Equipped?

The answer is most likely yes, especially if you own a newer, non-electric vehicle. OBD-II has become a near-universal standard for gasoline and diesel cars. While most modern cars utilize the CAN bus protocol for OBD-II communication, it’s worth noting that older vehicles with a 16-pin connector might not actually support the OBD-II protocol fully. To confirm OBD-II compliance, consider the vehicle’s origin and purchase date:

Does My Car Have OBD2?

A Brief History of OBD-II: From California to Global Standard

OBD-II’s story begins in California. The California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards, primarily for emission control.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD-II, defining DTCs and the universal OBD connector (SAE J1962). This standardization was key to its widespread adoption.

The OBD-II standard rollout progressed globally over time:

1996: OBD-II became mandatory in the USA for cars and light trucks.
2001: The European Union (EU) required OBD-II for gasoline cars.
2003: The EU extended the mandate to diesel cars (EOBD – European On-Board Diagnostics).
2005: OBD-II was required in the US for medium-duty vehicles.
2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD-II communication.
2010: OBD-II became mandatory for heavy-duty vehicles in the US.

The Future of OBD-II: Challenges and Changes on the Horizon

While OBD-II remains relevant, its future is being shaped by new automotive technologies and evolving industry perspectives.

One key factor is the rise of electric vehicles (EVs). Interestingly, legislated OBD-II, originally designed for emissions monitoring, isn’t strictly required for EVs. Consequently, most modern EVs don’t support standard OBD-II requests. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift makes accessing data from EVs considerably more challenging, often requiring reverse engineering to decode proprietary data formats. However, some progress has been made in reverse engineering data access for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

Furthermore, limitations in OBD-II’s data richness and underlying communication protocols have spurred the development of advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These protocols aim to enhance OBD communication by building upon the more versatile UDS protocol. For a deeper dive into these protocols, our introduction to UDS provides valuable insights.

In an era of connected cars, traditional OBD-II emission checks are becoming less efficient. The concept of OBD3 emerges as a potential solution, envisioning the integration of telematics into all vehicles.

OBD3 proposes adding a small radio transponder to cars, enabling wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated monitoring. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already demonstrate the feasibility of transferring CAN or OBD-II data wirelessly.

While OBD3 offers convenience and cost savings, it raises privacy concerns due to potential surveillance implications.

This brings us to the core of the obdii port elimination germany concept. While OBD-II was initially intended for emission controls, its use has expanded significantly to encompass real-time data access for third-party services via OBD-II dongles, CAN loggers, and more. However, the German automotive industry is considering a significant shift that could impact this ecosystem.

As Christoph Grote, SVP Electronics at BMW, stated in 2017:

“OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface“

The proposal from German automakers involves potentially disabling OBD-II functionality during normal driving. Vehicle data would instead be collected and centralized on manufacturer servers. This would effectively place automakers in control of the burgeoning ‘automotive big data’.

The rationale behind this move is often framed around security concerns, such as mitigating the risk of car hacking. However, critics argue that it’s primarily a commercial strategy to control valuable vehicle data and limit aftermarket access, as suggested by Navixy. The long-term impact of this potential trend remains uncertain, but it could significantly reshape the market for third-party OBD-II-based services.

Enhance Your CAN Bus Expertise

Eager to become a CAN bus expert?

Access our comprehensive collection of 12 ‘simple intros’ in a single 160+ page PDF:

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBD-II Standards: Defining the Protocol

On-board diagnostics, specifically OBD-II, operates as a higher-layer protocol, similar to a language, while CAN functions as the communication method, akin to a phone line. This positions OBD-II alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBD-II standards meticulously define aspects such as the OBD-II connector, lower-layer protocols, OBD-II parameter IDs (PIDs), and more.

These standards can be visualized within a 7-layer OSI model. Notably, both SAE (Society of Automotive Engineers) and ISO (International Organization for Standardization) standards contribute to various layers. This reflects the development of OBD standards in both the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

The OBD-II Connector: SAE J1962 Standard

The 16-pin OBD-II connector provides straightforward access to vehicle data and is standardized under SAE J1962 / ISO 15031-3.

The illustration above shows a Type A OBD-II pin connector, also known as a Data Link Connector (DLC).

Key features of the OBD-II connector include:

Location near the steering wheel, although it may be hidden from plain sight.
Pin 16 provides battery power, often active even when the ignition is off.
The OBD-II pinout configuration varies based on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L).

OBD-II Connector Types: A vs. B

In practical applications, you might encounter both Type A and Type B OBD-II connectors. Type A is commonly found in cars, while Type B is more prevalent in medium and heavy-duty vehicles.

While both types share similar OBD-II pinouts, they differ in power supply output (12V for Type A and 24V for Type B) and often baud rates. Cars typically use 500K baud rate, while heavy-duty vehicles often use 250K (with increasing support for 500K).

A distinguishing feature is the interrupted groove in the middle of the Type B OBD-II connector. Consequently, a Type B OBD-II adapter cable is compatible with both Type A and B sockets, whereas a Type A connector will not fit into a Type B socket.

OBD-II and CAN Bus: ISO 15765-4 Standards

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD-II in all vehicles sold in the US, as defined by ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) outlines specific constraints applied to the CAN standard (ISO 11898).

Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD-II adapter cable must have a maximum length of 5 meters.

OBD-II CAN Identifiers: 11-bit and 29-bit

OBD-II communication always involves request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD-II. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD-II compatible ECUs (Electronic Control Units) for data related to the requested parameter (as per ISO 15765-4). Conversely, CAN IDs in the range 0x7E0-0x7E7 can be employed for ‘Physical Addressing’ requests directed to specific ECUs, although this is less common.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM – Engine Control Module), followed by 0x7E9 (TCM – Transmission Control Module).

Some vehicles, particularly vans and light/medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD-II communication instead of 11-bit IDs.

In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses will be observed with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ within the J1939-71 standard.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBD-II vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s ECUs operate using proprietary CAN protocols defined by the Original Equipment Manufacturer (OEM), independent of OBD-II. These proprietary protocols are specific to the vehicle brand, model, and year. Unless you are the OEM, interpreting this raw CAN data is generally not possible without reverse engineering.

Connecting a CAN bus data logger to your OBD-II connector might capture OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, many modern vehicles employ a ‘gateway’ that restricts access to this OEM CAN data via the OBD-II port, allowing only OBD-II communication.

In essence, OBD-II functions as an ‘additional’ higher-layer protocol running alongside the OEM’s proprietary protocol.

Bit-rate and ID Validation

OBD-II can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles commonly use 500K with 11-bit IDs, but external tools should systematically verify this.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method leverages the requirement that OBD-II compliant vehicles must respond to a specific mandatory OBD-II request (detailed in the OBD-II PID section) and the fact that incorrect bit-rate transmission will trigger CAN error frames.

Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) instead of the more traditional OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD-II/OBDonEDS (as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS, testing tools can send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID.

Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is primarily used in EU trucks and buses.

Five Lower-Layer OBD-II Protocols

While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD-II, particularly in vehicles manufactured after 2008, older cars may utilize other protocols. Understanding these legacy protocols and their corresponding OBD-II connector pinouts can be helpful for diagnosing older vehicles:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars in the 2000-2004 timeframe.
SAE J1850 (VPW): Predominantly used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD-II Messages (ISO 15765-2)

OBD-II data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. ISO-TP enables the transmission of data payloads exceeding the 8-byte CAN frame limit. This is crucial for OBD-II functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. Refer to our UDS introduction for more information on ISO-TP.

However, much OBD-II data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD-II communication.

Decoding the OBD-II Diagnostic Message: SAE J1979, ISO 15031-5

To effectively work with OBD-II over CAN, understanding the structure of a raw ‘Single Frame’ OBD-II CAN message is essential. In simplified terms, an OBD-II message consists of an identifier, a data length indicator (PCI field), and the actual data. The data portion is further broken down into Mode, parameter ID (PID), and data bytes.

OBD-II Request/Response Example: Vehicle Speed

Let’s examine a practical request/response example for obtaining the ‘Vehicle Speed’ parameter.

An external tool sends a request message to the vehicle with CAN ID 0x7DF, containing two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with three payload bytes. The vehicle speed value is encoded in the 4th byte of the CAN data frame, which is 0x32 (decimal 50).

By consulting the OBD-II PID specifications for PID 0x0D, we can determine that the physical value represents 50 km/h.

The following sections will detail OBD-II modes and PIDs.

The 10 OBD-II Services (Modes)

OBD-II defines 10 diagnostic services, often referred to as modes. Mode 0x01 provides access to real-time data, while other modes are used to retrieve and clear diagnostic trouble codes (DTCs), or access freeze frame data.

Not all vehicles are required to support all 10 OBD-II modes. Furthermore, manufacturers may implement OEM-specific OBD-II modes beyond the standardized set.

In OBD-II messages, the mode is indicated in the second byte. In a request message, the mode is directly included (e.g., 0x01). In a response message, 0x40 is added to the requested mode value (e.g., a response to mode 0x01 will start with 0x41).

OBD-II Parameter IDs (PIDs)

Within each OBD-II mode, Parameter IDs (PIDs) are used to specify the data being requested.

For example, mode 0x01 encompasses approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.

One PID holds a special significance: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD-II services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU indicates its support for PIDs in the range 0x01-0x20. This makes PID 0x00 a fundamental test for OBD-II compatibility. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for subsequent PID ranges within mode 0x01.

OBD2 PID overview tool

OBD-II PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD-II PIDs. This information is crucial for converting raw OBD-II data into meaningful physical values, as detailed in our CAN bus introduction.

For quick lookups of mode 0x01 PIDs, our OBD-II PID overview tool is a valuable resource. It assists in constructing OBD-II request frames and dynamically decoding OBD-II responses.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD-II Data

This section provides a hands-on example of logging OBD-II data using the CANedge CAN bus data logger.

The CANedge’s configurable CAN transmit functionality makes it ideal for OBD-II logging.

Connecting the CANedge to your vehicle via our OBD2-DB9 adapter cable enables straightforward data acquisition.

OBD2 Supported PIDs Test Review responses to ‘Supported PIDs’ requests using asammdf.

Review supported PIDs via OBD2 lookup tool

Step 1: Bit-rate, ID, and Supported PID Validation

As discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
Use the identified bit-rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine 11-bit or 29-bit ID usage based on response IDs.
Identify supported PIDs based on response data.

We provide plug-and-play configuration files to streamline these tests.

Most non-EV vehicles manufactured after 2008 typically support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD-II/OBDonEDS protocol.

As illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This is because the 0x7DF request ID polls all ECUs for responses. Since all OBD-II/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are frequently observed. For subsequent ‘Supported PIDs’ requests, fewer ECUs tend to respond. Note that the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step 2: Configuring OBD-II PID Requests

Once you’ve identified the supported OBD-II PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your transmit list with the PIDs you want to log.

Consider these factors when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request.
Request Spacing: Introduce a delay of 300-500 ms between each OBD-II request to prevent overwhelming ECUs and ensure reliable responses.
Battery Drain Management: Implement triggers to halt transmissions when the vehicle is inactive to avoid unnecessary ECU wake-ups and battery drain.
Data Filtering: Apply filters to record only OBD-II responses, especially if your vehicle also transmits OEM-specific CAN data.

With these configurations in place, your CANedge is ready to log raw OBD-II data!

obd2-transmit-list-example-canedge Example CANedge OBD-II PID request configuration.

OBD2 data decoded visual plot asammdf CAN bus DBC file Visualize DBC-decoded OBD-II data in asammdf.

Step 3: DBC Decoding of Raw OBD-II Data

To analyze and visualize your logged data, you need to decode the raw OBD-II data into physical values (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we offer a free OBD-II DBC file to facilitate DBC decoding of raw OBD-II data in most CAN bus software tools.

Decoding OBD-II data is more intricate than standard CAN signal decoding. This is because different OBD-II PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to identify the signals within the payload.

To address this, you must consider the CAN ID, OBD-II mode, and OBD-II PID to uniquely identify each signal. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented using DBC files.

CANedge: Your OBD-II Data Logging Solution

The CANedge simplifies OBD-II data recording to an 8-32 GB SD card. Connect it to your car or truck to begin logging and utilize free software/APIs and our OBD-II DBC for data decoding.

OBD2 logger intro CANedge

OBD-II Multi-Frame Examples: ISO-TP in Action

All OBD-II data communication leverages the ISO-TP transport protocol (ISO 15765-2). While many examples involve single-frame communication, multi-frame communication is necessary for larger data sets.

Multi-frame OBD-II communication requires flow control frames (see our UDS intro). In practice, this can be achieved by transmitting a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Furthermore, processing multi-frame OBD-II responses requires CAN software/API tools with ISO-TP support, such as the CANedge MF4 decoders.

OBD2-multi-frame-request-message-vehicle-identification-number

Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD-II

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various other applications (refer to our UDS introduction for details). To retrieve the VIN using OBD-II requests, you use mode 0x09 and PID 0x02:

VIN Vehicle Identification Number OBD2 Example multi-frame

The tester tool initiates a Single Frame request containing the PCI field (0x02), request service identifier (0x09), and PID (0x02).

The vehicle responds with a First Frame that includes the PCI, total length (0x014 = 20 bytes), mode (0x49, derived from 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

Example 2: OBD-II Multi-PID Request (6x)

External tools can request up to 6 mode 0x01 OBD-II PIDs within a single request frame. The ECU will respond with data for the supported PIDs (omitting data for unsupported PIDs), potentially across multiple frames as per ISO-TP.

This efficient method enables higher-frequency data collection. However, the signal encoding becomes specific to the request method, making generic OBD-II DBC files less suitable for this use case. We generally advise against this approach in practice. Below is an example trace:

Requesting multiple PIDs in one request

The multi-frame response structure is similar to the VIN example. The payload includes the requested PIDs and their corresponding data. Note that the PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by the ISO 15031-5 standard.

Decoding such responses using generic DBC files is challenging. We recommend against this approach for practical data logging unless you are using tools with specific built-in support. This approach introduces complex extended multiplexing scenarios, where DBC files need to account for the specific payload position of each PID, making generalization across vehicles with varying PID support difficult. Furthermore, managing multiple such multi-PID requests via pure DBC manipulation becomes impractical, as uniquely identifying messages becomes problematic.

Workarounds could involve custom scripts that interpret responses based on the corresponding request messages. However, such approaches are generally difficult to scale.

Example 3: OBD-II Diagnostic Trouble Codes (DTCs)

OBD-II mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows you to request emissions-related DTCs. The request does not include a PID. The target ECU(s) will respond with the number of stored DTCs (potentially 0 if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits represent a 4-digit code (hexadecimal). Decoded DTC values can be looked up using OBD-II DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

Real-World Applications of OBD-II Data Logging

OBD-II data from cars and light trucks has diverse applications:

Vehicle Data Logging

OBD-II data logging in cars can be used for purposes like reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.

obd2 logger

Real-time Vehicle Diagnostics

OBD-II interfaces enable real-time streaming of human-readable vehicle data, facilitating efficient diagnostics of vehicle issues.

obd2 streaming

Predictive Maintenance

Cloud-connected IoT OBD-II loggers can monitor cars and light trucks for predictive maintenance, anticipating and preventing potential breakdowns.

predictive maintenance

Vehicle Black Box Functionality

An OBD-II logger can act as a ‘black box’ for vehicles or equipment, providing valuable data for dispute resolution or in-depth diagnostics.

can bus blackbox

Do you have an OBD-II data logging application in mind? Contact us for expert consultation!

Explore our guides section for more introductory resources, or download our comprehensive ‘Ultimate Guide’ PDF.

Need to log or stream OBD-II data?

Acquire your OBD-II data logger today!

Buy now Contact us