Since I work in the automotive industry I realize I need to know how CAN bus works, how OBD-II works, how CAN bus and OBD-II work together, how CAN bus and OBD-II are related to each other. Surprisingly, such information accessible on the Internet is not easily understandable. For example, who gets to decide how to represent 50-degree-Celsius in binary bits? When the engine coolant temperature sensor wants to send a CAN message that says, "I am 50 degrees Celsius now." Which protocol defines how to encode such information in the message at the bit level?
If you'd like to know how the heck CAN bus and OBD II work, how OBD-II and CAN bus are different from each other, or CAN bus versus OBD2 you have come to the right place. I've read several authoritative articles on these topics and will be summarizing my findings below in simple, easy-to-follow terms.
What is CAN bus?
You can read all about CAN bus at http://en.wikipedia.org/wiki/CAN_bus. I will use layman's terms to describe what CAN bus is so anybody can understand. CAN stands for controller area network, and is a vehicle bus standard designed to allow electronic control units, or ECUs (e.g. brake, engine, electronic fuel injection, automatic gear box, anti-lock braking system) to communicate with each other within a vehicle without central computer.
Here are some important points to note:
1. CAN is a multi-master broadcast serial bus standard for connecting ECUs, meaning there is no central computer.
2. When an ECU sends a message, every other ECU on the bus receives it and can choose to respond to it or ignore it.
3. Every message has a unique priority. The higher the priority the more likely it will be sent first. For example if two messages are being sent at the same time, the message with the higher priority will get sent first and the other message will back off and wait. For example, brake may have the highest priority. When you apply brake you definitely want the car to slow down as soon as it can.
4. CAN defines the structure and the way data are transferred between one ECU and the other ECUs.
ISO 15765 CAN protocol defines the data frame format, in which the data field can be as long as 64 bits, but not how to encode data in the data field. Here is a question. When an ECU sends a message with data field set to 01001101, how do the other ECUs know what it means?
The answer is ISO 15765 CAN needs to work with a higher layer protocol, or the application data protocol, which defines the meaning of the bits in the data field of a CAN message. You can find a list at http://en.wikipedia.org/wiki/CAN_bus under 'Higher layer implementations' section. An example is GMLAN, which stands for General Motor Local Area Network and is used by General Motors. This protocol will define, for example, that 01001101 in the data field of the CAN data frame means that the engine coolant temperature is 100 degrees Celsius. Another example is CANaerospace, which adds node addressing function to support peer-to-peer communication.
However this list of implementations contains no reference to the common family sedan cars such as Toyota Camry or Mercedes Benz. What application data protocol are they using? According to ISO 15765, ISO 14229 is the application layer protocol used by ISO 15765. So I assume many sedan models use ISO 14229 as the higher layer implementation.
It is worth noting that ISO 15765 CAN protocol is not the only protocol to allow ECUs to communicate with each other within a vehicle. Below is a list of such signaling protocols according to Wikipedia:
SAE J1850 PWM: used by Ford
SAE J1850 VPW: used by General Motors
ISO 9141-2
ISO 14230 KWP2000
Almost every vehicle implements only one of these signaling protocols. After year 2008, only ISO 15765 CAN is used.
Does that mean, for example, SAE J1850 VPW is not based on CAN infrastructure? The SAE J1850 VPW specification says, "The most predominant in-vehicle networking standard for Class C is CAN, (Controller Area Network)." So the answer is these signaling protocols may or may not be based on the CAN infrastructure, but they all provide a means for ECUs to talk to each other.
An example of CAN bus in action
When you turn on your car, the CAN bus is very busy with status messages. For example, the engine control device continuously sends a CAN message with the engine speed (in RPM). The ECUs on the bus listen for this message. The tachometer arm updates itself when it receives a new value.
So what are the differences between OBD-II and CAN bus? We'll get there soon. Next let's look at what OBD 2 is and how OBD 2 is related to CAN bus.
What is OBD II?
On-board diagnostics (OBD) refers to a vehicle's self-diagnostic and reporting capability. If your car supports OBD, it means your car gives access to the status of the various vehicle sub-systems such as engine temperature and engine speed. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signalling protocols available, and the messaging format.
The OBD-II standard has been mandatory for all cars and light trucks sold in the United States since 1996. If your car supports OBD-II you'll find the connector within 2 feet (0.61 m) of the steering wheel. Here's a photo of it:
Below we'll look at an example of how OBD-II and CAN bus work with each other to provide self-diagnostic function. You'll see how CAN bus differs from OBD-II.
How are CAN bus and OBD II related to each other?
There are five signaling protocols that are permitted with the OBD-II interface. They use the identical J1962 connector. Most vehicles implement only one of the protocols. It is often possible to deduce the protocol used based on which pins are present on the J1962 connector.
SAE J1850 PWM
SAE J1850 VPW
ISO 9141-2
ISO 14230 KWP2000
ISO 15765 CAN
After year 2008, only ISO 15765 CAN is used.
If you recall, OBD-II has been mandatory for all cars and light trucks sold in the United States since 1996, but ISO 15765 CAN has been mandatory since 2008. This means prior to 2008, some cars may have been using protocols other than ISO 15765 CAN to work with OBD-II interface.
An example of CAN bus working with OBD II
When you attach an OBD-II scan tool, it sends specially formatted diagnostic command messages over the CAN bus. Nodes on the network that can output diagnostic information are listening for these messages, and send out the requested status information over CAN when asked. For example the technician enters Mode 1 (query the real time state of the car, meaning your car needs to be started) PID 0D (query for vehicle speed) into the scan tool, and the scan tool sends the corresponding message over the CAN bus, and the engine control unit that knows the vehicle speed returns the vehicle speed (the response format is defined by OBD-II PIDs at http://en.wikipedia.org/wiki/OBD-II_PIDs), and the scan tool displays the vehicle speed on the tool's screen.
Usually you would use an OBD II scan tool to diagnose the car because the car's check engine light is on. In this case you would use Mode 2, which provides a snapshot of the same data taken at the point when the last diagnostic trouble code was set. For example the technician enters Mode 2 PID 0D into the scan tool, and will get the vehicle speed when the last diagnostic trouble code was set. He would also enters Mode 2 PID 02 to get the diagnostic trouble code that caused freeze frame to be stored.
The diagnostic request protocol is relatively standard across vehicle manufacturers, but beyond the standardized and mandated OBD-II parameters, the diagnostic message identifiers and formats are also largely proprietary.
This means if your car supports OBD-II it means the following things:
1. Your car has an internal OBD-II system that lets you know the state of your car. For example if the OBD-II system detects that there is something wrong with your engine, OBD-II system would turn on your malfunction indicator lamp (MIL), or commonly known as the check engine light.
2. Your car must have a J1962 connector within 2 feet (0.61 m) of the steering wheel.
3. An OBD-II scan tool can be plugged into the connector and send and receive messages on the CAN bus.
4. OBD-II defines a set of information your car must be able to supply. Your car's ECUs responsible for these pieces of information must return the status result to the scan tool in the format dictated by OBD-II standard.
http://en.wikipedia.org/wiki/OBD-II_PIDs shows you a list of parameter IDs that any OBD-II compatible car must support. Beyond these parameters every car manufacturer can have their own proprietary parameters.
Here is a rough flow of how OBD II works with MIL:
1. When OBD II detects a possible fault and keeps track of it in its storage.
2. OBD II waits until the next trip to see if the same fault occurs again. MIL will blink if problem is misfire.
3. In the next trip if the same fault occurs again, OBD II sets diagnostic trouble code (DTC) indicating the fault and turns on MIL.
4. MIL remains on as long as the fault is present. MIL goes out after three trips if the fault goes away. DTC is cleared after forty trips if the fault goes away.
Is OBD II necessary for a car to function?
In theory your car only needs CAN to function. Every ECU in the car knows about the status of any other ECUs. When you apply the brake the car slows down and eventually stops. When you switch to reverse gear, your rear view camera's feed is displayed in the head unit monitor. Nothing is wrong.. until your car has malfunctions and needs to be taken to a repair shop. If your car does not support OBD II, then there is no way for the technician to use the OBD-II scan tool to diagnose the car.
In fact if your car does not have an internal OBD II system, your car would need some other way to turn on the MIL when a fault is found.
Hopefully now you've understood how CAN bus and OBD II are different from each other. We've looked at an example of how CAN bus works, and an example of how OBD-II works. If you have any questions let me know and I will do my best to help you!