Cloud Login
OBD2 is the standard diagnostics interface used in most modern passenger cars and light commercial vehicles. If you work with vehicle data, service, telematics, fleet management, or development, OBD2 is usually the first interface you connect to before going deeper into CAN, UDS, or OEM-specific data.
This article explains what OBD2 is, how it works, which vehicles are normally compatible, and how OBD2 data can be read with scanners, data loggers, and AutoPi devices.
What is OBD2?
OBD2, also written OBD-II, stands for On-Board Diagnostics version 2. It is a standardized diagnostic system used by vehicles to monitor emissions-related systems and report faults.
When the vehicle detects a problem, it stores a diagnostic trouble code, also called a DTC. If the issue affects emissions or an important operating condition, the vehicle may also turn on the malfunction indicator lamp, often called the check engine light.
OBD2 does not give access to every signal inside a vehicle. It gives access to a defined set of diagnostic services, fault codes, and live parameters. For many use cases, that is enough. For deeper vehicle data, it may be necessary to work directly with CAN bus data, UDS diagnostics, or manufacturer-specific signal definitions.
The OBD2 system collects information from sensors and control units in the vehicle. The engine control unit (ECU) monitors values such as fuel trim, oxygen sensor readings, coolant temperature, misfires, and emission-related behavior. If a value moves outside the allowed range, the ECU can store a fault code.
A common example is a faulty oxygen sensor. The vehicle may still drive, but fuel consumption can increase and emissions can be affected. OBD2 gives a scanner or data logger a way to read the stored code and identify where the problem starts.
How does OBD2 work?
OBD2 works through a diagnostic connector, a set of diagnostic services, and one of several supported communication protocols. A scanner or data logger connects to the OBD2 port and sends diagnostic requests. The vehicle responds with supported data, fault codes, or status information.
The OBD2 port is usually located under the dashboard on the driver side, but the exact location depends on the vehicle. Some ports are behind a small cover or placed near the center console.
See where the OBD2 port is located.
When a fault is detected, the vehicle stores a diagnostic trouble code (DTC). A simple OBD2 scanner can read and clear many of these codes. A more advanced automotive data logger can also record live data over time.
In newer vehicles, OBD2 communication is normally carried over CAN bus. Older vehicles can use other protocols such as ISO 9141-2, KWP2000, or SAE J1850. The connector is standardized, but the underlying protocol depends on vehicle year, region, and manufacturer.
Is my car OBD2 compatible?
OBD2 compatibility depends mainly on where the vehicle was sold new, the model year, the fuel type, and the local regulation at the time. It is not enough to look only at the brand or where the vehicle was built.
If your car is newer than 1996 in the US, or 2001 in the EU for petrol vehicles, it is most likely OBD2 compatible.
This is a simplified rule. Diesel vehicles, imports, early transition models, and manufacturer-specific implementations can differ. Always check the vehicle manual, connector, or manufacturer documentation when exact compatibility matters.
| Country or region of sale | Typical OBD2 requirement | Note |
|---|---|---|
| USA | 1996 and newer | OBD2 became mandatory for light-duty vehicles from 1996. Diesel requirements followed later. |
| European Union | 2001 petrol / 2004 diesel | Often referred to as EOBD in Europe. |
| Japan | Around 2002 and newer | Imported and domestic market vehicles may differ. |
| Australia | Around 2006 and newer | Requirements depend on vehicle category and ADR implementation. |
| Canada | Late 1990s and newer | Generally aligned closely with US standards. |
OBD2 scanner
An OBD2 scanner is a diagnostic tool that connects to the OBD2 port. A basic scanner can read and clear fault codes. More advanced tools can show live data such as engine RPM, coolant temperature, vehicle speed, fuel trims, oxygen sensor data, and readiness monitor status.
A scanner is normally used during service or troubleshooting. A data logger or telematics device is used when the data must be recorded over time, sent to a backend, or used in a fleet management workflow.
Go beyond fault codes with AutoPi
A normal OBD2 scanner is useful for reading fault codes in the workshop. AutoPi devices are used when the same type of data must be collected continuously from a vehicle or fleet.
The AutoPi CAN FD Pro can be used for projects that need vehicle data logging, CAN bus access, OBD2 data, and remote upload. Instead of only reading a fault code once, the device can log selected values over time and forward them to AutoPi Cloud or an external system.
This is useful for testing, fleet monitoring, development, and cases where an intermittent fault only occurs while the vehicle is in operation.
The useful difference is persistence. A scanner shows what the vehicle reports now. A logger can show what happened before, during, and after the fault appeared.
How does OBD2 log data?
OBD2 itself does not work like a full-time black box recorder. The vehicle continuously monitors its own systems and stores diagnostic information when a fault condition is detected. A scanner or data logger can then request data from the ECU through the OBD2 port.
If a measured value is outside the expected range, the ECU can store a DTC in the on-board computer. Some faults also store freeze frame data, which is a snapshot of selected vehicle conditions at the time the fault was detected.
A guide to reading fault codes is available here: how to read OBD2 codes.
OBD2 and CAN bus connection
OBD2 defines the diagnostic interface and services. CAN bus is one of the physical/data-link communication methods that OBD2 can use. On modern vehicles, OBD2 over CAN is the normal implementation.
This distinction matters. OBD2 is not the same as CAN bus. OBD2 is a diagnostic standard. CAN is the network used to move the messages. A vehicle can have many CAN messages that are not available through standard OBD2 requests.
For many projects, OBD2 is the correct starting point because it is standardized and easy to access. If the required data is not available through OBD2, the next step is often direct CAN logging or manufacturer-specific diagnostics.
The five OBD2 signal protocols
The OBD2 connector is standardized, but older vehicles did not all use the same communication protocol. Depending on region, manufacturer, and model year, the vehicle may use one of several protocols behind the same 16-pin connector.
The five common OBD2 protocols are summarized below. In newer vehicles, ISO 15765 CAN is the most relevant one. Older vehicles may use J1850, ISO 9141-2, or KWP2000.
SAE J1850 PWM
SAE J1850 PWM was mainly used by Ford. It communicates at 41.6 kbit/s and uses pins 2 and 10 for the bus lines.
| Protocol | Main details |
|---|---|
| SAE J1850 PWM | Typical use: Ford. Bus +: Pin 2. Bus -: Pin 10. Power: Pin 16. Ground: Pins 4 and 5. Speed: 41.6 kbit/s. |
SAE J1850 VPW
SAE J1850 VPW was mainly used by General Motors. It uses a single bus line on pin 2 and operates at lower speed than J1850 PWM.
| Protocol | Main details |
|---|---|
| SAE J1850 VPW | Typical use: General Motors. Bus +: Pin 2. Power: Pin 16. Ground: Pins 4 and 5. Speed: 10.4 kbit/s. |
ISO 9141-2
ISO 9141-2 was common on older Chrysler, European, and Asian vehicles. It uses K-line communication on pin 7 and, in some cases, an optional L-line on pin 15.
| Protocol | Main details |
|---|---|
| ISO 9141-2 | Typical use: Older Chrysler, European, and Asian vehicles. K-line: Pin 7. L-line: Pin 15 where used. Power: Pin 16. Ground: Pins 4 and 5. Speed: 10.4 kbit/s. |
ISO 14230 KWP2000
ISO 14230, also called Keyword Protocol 2000 or KWP2000, is another K-line based diagnostic protocol. It was used on many European and Asian vehicles before CAN-based OBD2 became dominant.
| Protocol | Main details |
|---|---|
| ISO 14230 KWP2000 | Typical use: Older European and Asian vehicles. K-line: Pin 7. L-line: Pin 15 where used. Power: Pin 16. Ground: Pins 4 and 5. Speed: 10.4 kbit/s. |
ISO 15765 CAN
ISO 15765 is OBD2 over CAN. It is the most relevant protocol for modern vehicles and uses CAN high on pin 6 and CAN low on pin 14.
| Protocol | Main details |
|---|---|
| ISO 15765 CAN | Typical use: Modern OBD2 vehicles. CAN high: Pin 6. CAN low: Pin 14. Power: Pin 16. Ground: Pins 4 and 5. Speed: commonly 250 kbit/s or 500 kbit/s. |
OBD2 timeline
OBD1 vs OBD2
OBD1 refers to the earlier generation of on-board diagnostics. It was mostly manufacturer-specific. Connector types, fault codes, communication methods, and available data varied a lot between brands and models.
OBD2 introduced a standardized connector, standardized diagnostic services, and a common way to report emissions related faults. This made diagnostics easier across manufacturers and allowed generic scanners to work on many vehicles.
The practical difference is simple: OBD1 usually requires brand-specific tools and knowledge. OBD2 provides a common baseline that generic tools, scanners, data loggers, and telematics devices can use.
What OBD2 is useful for
OBD2 is useful for reading fault codes, checking readiness monitors, viewing live engine data, and logging basic vehicle parameters. It is a good interface for service, emissions checks, simple fleet monitoring, and early-stage vehicle data projects.
It also has limits. OBD2 does not expose every internal signal in the vehicle. Some data is manufacturer-specific, hidden behind UDS diagnostics, or only available by logging raw CAN traffic. For technical projects, it is important to check whether the required data is available through standard OBD2 before designing the full solution around it.
Working with OBD2 data in practice
A practical OBD2 project should start with a clear signal list. Decide what data is needed, how often it should be sampled, whether it must be logged locally, and where it should be sent.
Common OBD2 values include RPM, vehicle speed, coolant temperature, intake air temperature, fuel trims, engine load, battery voltage, fuel level where supported, and diagnostic trouble codes. Availability and update rate vary between vehicles.
For fleet or development work, the important question is not only whether a value can be read. The important question is whether it is stable, updated often enough, and useful for the problem you are trying to solve.
Take the next step
AutoPi devices can be used to collect OBD2, CAN, CAN FD, LIN, and J1939 data depending on the hardware and vehicle. They are suited for projects where vehicle data must be logged, sent to a cloud platform, or integrated with an existing backend.
Learn more about AutoPi devices, watch the 4-minute OBD2 tutorial, or get in touch if you need to clarify which data can be collected from a specific vehicle.
