OBD-II versus CAN: Many FAQs answered!

A lot of people are confused about OBD2 versus CAN. This article attempts to answer the following questions:

- What exactly is OBD2?
- What is OBD2 spec versus OBD2 protocol?
- What exactly is CAN?
- What is the CAN application layer protocol of a four-wheel sedan?
- How is OBD2 related to CAN?
- Can OBD2 and CAN coexist in the same vehicle?
- Is all CAN traffic available via the OBD connector?

Q: What exactly is OBD2?

A: OBD-II is used to request data from a vehicle, mostly used as a diagnostic tool. It can also be used to tell you about the health of the car. For example, you can use an OBD2 scanner to ask an OBD2 compliant vehicle what components in the car are broken. The OBD2 spec contains the parameters that an OBD2 compliant vehicle must support. Here is a list of PIDs: https://en.wikipedia.org/wiki/OBD-II_PIDs

For example, PID 0A means fuel pressure, PID 0D means vehicle speed. Mode is the type of operation you want the vehicle to do. Mode 01 means “show current date”. So if you use mode 01 and PID 0A, the vehicle will return 1 byte of data indicating the current fuel pressure, with the minimum value of 0 and the maximum value of 765, and the unit is kPa. If you use mode 01 and PID 0D, the vehicle will return 1 byte of data indicating the vehicle speed in km/h, from 0 to 255.

The OBDII function can be accessed via the Data Link Connector, which is a physical 16 pin connector usually located under the dashboard near the driver’s seat. The OBD2 spec can be implemented by five different underlying communication protocols. Here are some of them per https://learn.sparkfun.com/tutorials/getting-started-with-obd-ii:

1. SAE J1850 PWM
2. SAE J1850 VPW
3. ISO 9141-2
4. ISO 14230 KWP2000: https://en.wikipedia.org/wiki/Keyword_Protocol_2000 says it covers layer 1, 2, 7. Here, in this context, OBD2 uses layer one and layer two, which correspond to ISO 14230-1 and ISO 14230-2.
5. ISO 15765 CAN

The term “communication protocol” here refers to the physical layer and data link layer of the OSI model. For example, for SAE J1850 PWM, pin 2 is BUS +, but for ISO 15765 CAN, pin 2 is not used. For SAE J1850 VPW, the Maximum Signal Voltage is +7V, and for ISO 9141-2, the Maximum Signal Voltage is +12V.

So the OBD2 scanner connected to your vehicle’s Data Link Connector needs to speak many different OBD2 communication protocols in order to talk to many different cars. When the car’s OBD2 connector uses SAE J1850 PWM, the OBD2 scanner can detect that this is the case and automatically use SAE J1850 PWM to communicate with the vehicle. When the car’s OBD2 connector uses ISO 15765 CAN, the OBD2 scanner can detect that this is the case and automatically use ISO 15765 CAN to communicate with the vehicle. Or the mechanic can manually do the setting. If the OBD2 scanner doesn’t support the communication protocol, which shouldn’t be the case, then it won’t be able to talk to and diagnose the car.

Luckily, ISO 15765 CAN has been mandated in all vehicles sold in the U.S. from 2008 and later. So if your car falls in that range, your OBD2 scanner will only need to support ISO 15765 CAN.

Q: What is OBD2 spec versus OBD2 protocol?

A: The OBD2 spec doesn’t care how the car’s OBD2’s communication protocol works or what it is, it only cares that the OBD2 scanner can successfully get the diagnostic data from a vehicle, and that data format complies with OBD2 spec. For example, when the OBD2 scanner sends PID 0A to the car via the OBD2 connector, the car must know it means OBD2 scanner wants to know about the fuel pressure and must return one byte of data. When the OBD2 scanner sends PID 0D, it must mean vehicle speed and the car must return one byte of data. Same thing applies to mode. That’s what OBD2 spec is all about.

For example, you can even implement your own OBD2 communication protocol in addition to the five protocols that’s already mentioned above. But if the OBD2 scanner used doesn’t speak your protocol, it’s no use.

Many people use OBD2 spec and OBD2 protocol interchangeably, but it’ll create confusion.

Q: What exactly is CAN?

A: CAN is short for controller area network, and you can find its details at https://en.wikipedia.org/wiki/CAN_bus. In a nutshell, when people say CAN, they may refer to ISO11898-1 (data link layer of the OSI model), ISO11898-2 (physical layer of the OSI model), and/or ISO 11898-3 (physical layer for low-speed, fault-tolerant CAN). In the future more ISO 11898 specs may come out, but the term “CAN” will almost always refer to the physical layer and/or data link layer of the OSI model.

So you just have to remember, when people say two systems are using CAN, it means that the two systems use CAN data frames to talk to each other, but this fact does not say anything about the application layer protocol the two systems are using. Therefore if you use a CAN sniffer, you will be able to get CAN frames and you’ll see the CAN ID and the payload, but you won’t be able to know what they mean (e.g. speed, torque, air bag) unless you know the application layer protocol used.

In terms of the physical architecture, there can be high speed CAN and low speed CAN, which refer to the physical and data link layer. The data format of the CAN data frame transmitted on a high speed CAN network is the same as that transmitted on a low speed CAN network. There are two CAN frame formats, CAN 2.0 A and CAN 2.0 B. Both high speed CAN network and low speed CAN network can be configured to work with both or one of these CAN frame formats.

Long story short, inside a vehicle, you could have one group of CAN nodes on the high speed CAN architecture, and another group of CAN nodes on the low speed CAN architecture. They can coexist in the same vehicle, but they may need to be connected to a mutual gateway in order to talk to each other because their architectures are different. Suppose node A in one group wants to talk to node B in the other group, they may need a gateway in between to reconcile the architectural differences and the transmission speed differences.

The CAN frame carries an ID and payload, but what do they mean? Suppose ID in decimal is 4256 and payload in decimal is 778919, what do they mean? That’s where CAN-based higher level protocol comes in. In this context, “higher level protocol” refers to the application layer protocol, which is layer 7 of the OSI model. For example, the SAE J1939, mostly used by buses and trucks, might say that ID of 4256 means vehicle speed. The ARINC 812, used for the aviation industry, might say that ID of 4256 means the torque of the left aircraft engine. Another thing is a CAN frame may only be a part of the data. For example, in SAE J1939 (which also covers the application layer), a node can send data bigger than 8 bytes to another node by using multiple frames. Another CAN application layer protocol may not have this feature.

Q: What is the CAN application layer protocol of a four-wheel sedan like Toyoto, Volvo, Benz, Ford?

A: Despite that they use CAN in the physical and data link layer (ISO 11898), most vehicle manufacturers use their own developed application layer protocol on the CAN network. For example, one model of Mercedes-Benz uses IES CAN as the CAN application layer protocol, and its documents may not even be available online. Luckily, if the car supports OBD2, you can use OBD2 scanner to get data from the car without knowing anything about the car’s CAN’s application layer protocol.

Q: How is OBD2 related to CAN?

A: OBD2 is a spec implemented by a compliant OBD2 protocol (e.g. physical layer and data link layer = ISO 15765-4. application layer = ISO 15031-5), and that OBD2 protocol is totally independent of the high-level CAN protocol of the vehicle.
Suppose the car’s OBD2 protocol is ISO 15765-4 for physical layer and data link layer and ISO 15031-5 for application layer, and the car’s CAN application protocol is SAE J1939. A gateway understanding both protocols needs to exist between OBD2 and CAN to resolve their differences. Here’s the flow of how OBD2 scanner gets the vehicle speed from the car:

1. You have OBD2 scanner use mode 01 and PID 0D to find out the vehicle speed.
2. The OBD2 scanner uses the car’s OBD2 protocol to send this request per OBD2 spec.
3. The gateway gets this request and converts it to the equivalent SAE J1939 data frame and sends it on the CAN bus.
4. The vehicle’s speed CAN node returns the speed data per SAE J1939.
5. The gateway gets this data and converts it to the equivalent OBD2 protocol data to send it to the OBD2 scanner.
6. The OBD2 scanner gets the data and interprets it according to the OBD2 spec. Then it displays the vehicle speed.

Q: Can OBD2 and CAN coexist in the same vehicle?

A: The answer is yes. OBD2 is used for reporting the vehicle’s information and states, and CAN is used for various nodes (sensors, actuators, control devices, etc.) within the vehicle to communicate with each other. The two protocols are totally independent of each other, and they communicate with each other via a gateway.

You can imagine a car without OBD2. It’ll run fine, but you won’t be able to get diagnostic information from it via an OBD2 scanner. You can also imagine that if the OBD2 scanner doesn’t speak the OBD2 protocol the car uses, then you won’t be able to get any diagnostic information from the car either.

Q: Is all CAN traffic available via the OBD connector?

A: No. OBD2 scanner can only get information specified by the OBD2 spec. For example, you can get fuel pressure and vehicle speed via OBD2. Here is a list of data you can get via OBD2: https://en.wikipedia.org/wiki/OBD-II_PIDs

For more information on OBD2, please visit https://www.csselectronics.com/screen/page/simple-intro-obd2-explained and https://www.youtube.com/watch?v=OhShoU_E-0g!

If you have any questions let me know and I will do my best to help you!