In practical terms, a message from the crank sensor sends "engine speed" to the ECM. That message will be sent by the ECM along the CAN-Bus so "engine speed" can be accepted by the automatic transmission, instrument cluster, brake and traction system and other control units that have a need to process the message (see Diagram 3).
"The same message would just pass through a control unit that could not use the data and continue to pass along through the network unit it reached the endpoint terminating control unit."
CAN messages are a piece of data that contains seven parts, says Ord, and the CAN protocol allows up to 2,048 different message types. Each message is 8 bytes of data. This 8-byte message is also called the CAN Data Telegram. Each part of the message is important and provides the necessary information so that the content of the message can be received and used by the applicable control unit.
Within the message contents, the CAN Data Telegram shows which sensor sent it, the priority, the intended recipient (single ECU address or multiple ECU addresses), the subject (status of component X), the content of the message (actual data bytes), acknowledgment of receipt and end comment. As these messages can relate to status or operation, the contents can vary within the standards.
CAN-Bus software and hardware create an efficient network post office for messages. "To avoid confusion and a loss of data, each message can only be sent when the CAN Data Bus is free," Ord explains. "If several control units simultaneously start to send a message, a procedure called arbitration initiates. With arbitration, the network determines which message has the highest priority. Priorities are set due to the specific function initiated by the message."
By way of example, a message that contains "driver airbags deployed" has higher priority than "blower fan level." If a control unit's message is halted during arbitration, the sender will automatically repeat the message transmission as soon as the CAN network is free again.
"CAN messages are not just to broadcast status automatically," says Ord. "Some messages are requests for data from one control unit to another. The air conditioner/heater control unit may send a request message to the engine control unit for 'coolant temperature' to avoid overheating and the appropriate control unit then reacts to the request. Since 'coolant temperature' is used by several control units that continuously monitor this CAN message in real time, if the engine control unit is busy, another could send the coolant temperature status to the air conditioner/heater."
If there are any network problems or missing data, both the sending control unit and any receiving control units on the CAN-Bus will log either fault codes or CAN event codes.
When control units and components are networked, a different approach is necessary to diagnose problems. Common faults can include drivability issues (low power, transmission in limp-home mode, etc.), convenience issues (no a/c, poor heat output, etc.) or operational issues (power windows not functioning, doors will not lock, etc.). When a drivability or operational problem is being addressed on a vehicle with CAN-Bus, limited knowledge of how CAN works can lead to a long and difficult process that may or may not yield any results.
Because the Sprinter is a fairly complex vehicle that has a lot of electronic control units, Mercedes engineers built in a very comprehensive fault logging capability in each control unit, Ord says. For many control units, there are hundreds of possible fault codes that provide a solid roadmap to pinpoint the cause of many types of vehicle problems. "Most CAN-Bus network problems are identified by the control units through fault codes; this is the first place to start the diagnostic process."
Understanding fault codes, also known as diagnostic trouble codes (DTC), "is the most important first step in identifying where a CAN-Bus network problem has occurred," Ord emphasizes. "It is critical that suitable scan tools be used for testing - ones that will actually recognize all of the control units, not just engine and transmission.
Onboard vehicle data used to be the domain of the system from where it originated. It didn’t take long, though, before engineers figured out that sharing data from one system could be useful in...