How standardized vehicle communication protocols impact diagnostics and vehicle operation
A commercial truck on the road today has more than 1 million lines of code, approximately 400 sensors, and numerous control units onboard that must communicate with one another in order for the vehicle to operate seamlessly. Gone are the days of fully mechanical vehicles. Today’s trucks are quite literally “computers on wheels.”
To make sense of these vehicle systems, it helps to have a basic understanding of how these systems communicate and the necessity of standardizing communication between systems. Additionally, challenges with how vehicle systems communicate can have a significant impact on the maintenance and service of a commercial vehicle.
Overview of standardized communication protocols
A vehicle bus is the term used for a communication network, or channel, which allows electronic control units (ECUs) on different systems of a vehicle to send and receive data and messages to and from one another. The transfer of data on a vehicle bus can be done without requiring a host computer, or excessive wiring, to connect to the different vehicle systems.
Bruno Gattamorta, vice president, diagnostic sales, for heavy duty scan tool manufacturer Cojali USA, provides an example of how data messages are transferred between the different ECUs, or what he refers to as “nodes,” on a vehicle bus.
“Messages are transmitted or broadcast through a node structure – a sort of highway – where any node can have access to any other node in the network,” he explains. “This makes communication much faster as it doesn’t require a sequential decoding as in the past, but all channel data at the same time.”
ECUs collect data readings through sensors and actuators and manage the operation of various systems on a vehicle. Two common ECUs are the powertrain control module (PCM), which manages communication for systems like the engine and aftertreatment systems, transmission, brakes, and ADAS; and the chassis control module (CCM) which includes systems such as body control units, instrument clusters, restraint systems, and TPMS. A commercial vehicle can have dozens of ECUs to manage different systems. Data transfer between these ECUs is made possible through standardized communication protocols.
“A standardized communication protocol creates a common language that allows for proper communication between various subsystems on a vehicle,” says Dave Covington, CTO, Noregon. “When using a standardized protocol, components are able to share data, and command and control each other’s actions.”
Noregon provides products that assist with the diagnosis and repair of vehicles and assist in total vehicle health and safety management.
Standards are released through the U.S.-based Society of Automotive Engineers (SAE), the International Organization for Standardization (ISO), and the American Truck Associations’ Technology & Maintenance Council.
Bosch introduced a standardized specification for a vehicle bus in the 1980s, referred to as the communication area network, or CAN bus.
The CAN bus was originally released as an SAE standard, with subsequent ISO standards announced a few years later. Several updates have been made to the original CAN bus specification, to remain flexible to the changes in vehicle communication.
Modern vehicles today have several vehicle bus communication networks to ensure the transfer of ever-increasing data between micro-control units.
“It is not uncommon to see a vehicle with two or three communication networks, and more than one communication protocol in use,” explains Brian Herron, President, Drew Technologies. “There is a significant amount of data being transmitted on the vehicle's network, including driving information, fault codes, and information collected from sensors for each system. This data can be used not only for maintenance, but also to capture analytics on the operation of the vehicle.”
A division of Opus IVS, Drew Technologies manufactures diagnostic and reprogramming products for the automotive and commercial vehicle industries.
Vehicles have a primary, or “gateway” ECU that receives information from all the different systems and makes them “talk the same language,” explains Fabio Mazzon, technical manager for TEXA USA. “If the ABS talks on a J1708 [communication standard] while the engine uses a J1939 standard, the gateway shares information between the two and makes them work together efficiently.”
TEXA provides products to assist with truck diagnostics, including the recent release of its aftermarket remote diagnostics device.
There are a variety of vehicle communication protocol types in-use on today’s vehicles, which communicate on a vehicle bus. A majority of on-road vehicles follow two main communication standards: OBD-II (defined by J1962 and J1979 SAE protocols), for light duty passenger vehicles; and J1939 for heavy duty commercial vehicles. Some heavy duty vehicles may also follow J1708 or Heavy Duty (HD) OBD communication standards. Medium duty vehicles are even more challenging to define and can follow any number of protocols listed above.
OBD-II started as a standardization to monitor vehicle emissions. It is required on all 1996 and newer model passenger vehicles. A 16-pin adapter is used to access an OBD-II diagnostic port on a vehicle. Heavy duty OBD, or HD OBD, is a standard for heavy duty vehicles that share similarities with OBD-II. It has been in development and implemented by a number of truck manufacturers that have passenger vehicle counterparts.
For example, Mack Trucks and Volvo recently switched to HD OBD. And, Hino Trucks uses HD OBD for their medium duty trucks. More widespread adoption of HD OBD will continue, says Covington.
“HD OBD is being adopted at a wide rate in [the U.S.] because of its success in European countries,” Covington explains. “Manufacturers who sell a high percentage of their components in Europe are looking to communize or synchronize their platform and release the same components in America without large-scale adjustments to the manufacturing process.”
Real-world application with vehicle diagnostics
Communication protocols not only allow for standardized communication between vehicle systems, they also provide standardized information about the vehicle’s performance and diagnostics. Technicians must have a point of access in order to obtain this vehicle information.
“Fleets will need to make sure they have the correct diagnostic software and vehicle communications hardware to support all of the vehicles in their fleet, as well as trained experienced technicians,” says Drew Technologies’ Herron. “Telematics systems can also help to streamline the service and maintenance process.”
Every vehicle – whether passenger vehicle or commercial vehicle – has a port, typically located on the driver’s side under the dash or door frame, to access a vehicle’s computer systems. Technicians connect a separate diagnostic tool to the vehicle’s port using a dongle or specially designed adapter.
From the mid-1990s through the mid-2000s, J1708 standard vehicles were outfitted with a 6-pin Deutsch connector to access the diagnostic port. With the advent of J1939 to account for the increase in data, a 9-pin Deutsch connector replaced the 6-pin design.
“The J1939 protocol, compared to the older J1708, has brought higher speed of communication and a huge increase in the amount of data available and transferable. This increase in the amount of information available through a standardized protocol has significantly improved the diagnostic operations and the amount of information that can be transferred to telematic devices,” says TEXA USA’s Mazzon.
In the last few years, the 9-pin adapter design has been updated into two separate versions: Type-I and Type-II. The Type-I 9-pin adapter is limited to a 250 kbps (kilobytes per second) data transfer rate and designed for vehicles manufactured before 2016. The Type-II 9-pin adapter provides up to a 500 kbps data transfer rate and works on 2016 and newer vehicles. Technicians may know these more familiarly as the black (Type-I) or green (Type-II) 9-pin adapters.
“Scan tools use these protocols to decipher the information that is being transmitted by the different ECMs,” says Cojali’s Gattamorta. “In this matter, each manufacturer will access the data transmitted by their system, decode it, and exhibit it on the computer in order to assist [the technician]. When you have multi-system scan tools, such as Jaltest Diagnostics, they are capable of reading all of the systems at the same time in order to identify what systems are present and what is the situation with each one of these systems.”
Standardized versus proprietary communication protocols
With a common language, it may seem fairly straightforward for maintenance shops to access and interpret a vehicle’s diagnostic information. This is not entirely the case.
Standardized protocols help to make communication among vehicle systems universal. But vehicle manufacturers have created, and will continue to maintain, their own proprietary communication unique to specific vehicle makes.
“Standardized fault codes only provide a single layer of information, lacking the proprietary diagnostic information that is incisive and helps the user determine the root cause of a problem,” says Noregon’s Covington. “To share an example, two engines could produce the same fault, but the associated diagnostic data, such as severity and fault tree information, can vary greatly between the two.”
This means fleets that service multiple vehicle makes must invest in multiple OE scan tools, or attempt to find an aftermarket scan tool with OE diagnostic information for multiple makes.
“If everyone used standardized faults, it would significantly reduce the cost of developing scan tools,” says Tom Kotenko, general manager, NEXIQ Technologies. “The challenge is that some OEs require proprietary faults and sensor information to troubleshoot faults using their specific diagnostic information.”
NEXIQ Technologies provides vehicle telematics and diagnostic products, software, and services for the trucking fleet vehicle industries.
“There is a subset of data that is standard, but in order to do anything close to a decent job of [diagnosing vehicle issues], you have to have the proprietary OEM information in your tool,” adds Robert Vogt, CEO of telematics solutions provider IoSiX.
The unavailability of this information has caused some fleets to request access, says Martin Falch, co-owner of CSS Electronics.
Denmark-based CSS Electronics is a developer of CAN bus data logging devices used to record raw CAN, J1939 and OBD-II data from vehicles.
“We increasingly see a shift towards end-users demanding transparency and open source solutions,” he says. “As such, we expect open access to the full protocol data may become a key negotiation factor in e.g. fleet procurement settings.”
The first challenge is to decipher the information from the vehicle. Then, once that information is obtained, fleets must also verify they have a full, holistic view of all the vehicle systems working together.
“With proprietary information from component manufacturers in the mix, telematics providers and aftermarket tool manufacturers must either purchase the data or reverse engineer it,” Covington explains. “With both approaches often being expensive, the lack of a true standardized protocol for diagnostics drives up the cost of these tools and services, making it difficult to pass along savings to the end user.”
Covington says the best plan of action is to have a standardized approach to diagnosing vehicle issues and ensure the tools and adapters used by technicians in the shop cover all these common protocols. This can help fleets in finding the root cause of the problem in order to ensure maximized vehicle uptime.
“You must be able to understand what is wrong with the entire vehicle before estimating downtime, parts and labor requirements, technician needs, and more,” Covington adds. “Use a diagnostic and repair tool that can read all protocols to ensure you understand the needs of the entire vehicle, rather than one or two major components.”
Addressing potential security risks
Aside from providing an accurate and thorough picture of the vehicle’s performance, there are additional issues fleets may face.
The main challenge with standardized communication protocol? Security.
Hacking of vehicle systems is a viable threat and should be considered.
“With the rise of IoT [the Internet of Things] and connected vehicles, an increasing share of vehicles are online,” says CSS Electronics’ Falch. “This exposes them to hackers, as recently shown across various simulations.” Falch sites two examples in particular: when hackers Charlie Miller and Chris Valasek conducted a hack of a Jeep Cherokee, documented by Wired magazine in 2015; and a University of Michigan study conducted by Yelizaveta Burakova, Bill Hass, Leif Millar, and André Weimerskirch, titled “Truck hacking: An experimental analysis of the SAE J1939 standard,” documenting the hacking of a 2006 Class 8 tractor and 2001 school bus.
Falch explains that three items are required to complete a vehicle hack remotely:
- A means of accessing the vehicle online, typically through a low-security dongle connected to the vehicle.
- A means to transmit CAN data to the vehicle network.
- An understanding of what messages to send to control various vehicle functions. In particular, Falch says, the standardized J1939 protocol aids in learning those messages.
Some may argue against standardization or having closed access to the CAN bus. Falch disagrees. “Rather, end users need to seriously scrutinize the security specs of what they connect to their vehicles.”
To address these security issues, along with other foreseeable system needs, updated communication protocols are on the horizon.
As vehicle systems become more complex, they will need to have the ability to transfer this data and information to other areas of the vehicle quickly. Many in the industry believe ethernet may phase out some of the current vehicle protocols. Before ethernet, updates to CAN bus protocols such as CAN FD (flexible data-rate) and CAN XL may occur first.
“Big changes are coming as ADAS systems require more bandwidth,” says Drew Technologies’ Herron. “The CAN protocol in use today is being revised to a new CAN FD standard that supports higher throughput. In addition, many manufacturers are developing systems that use Diagnostics over IP (DOIP) which is basically automotive ethernet.”
CAN FD will be helpful in transmitting data requiring more bandwidth, but that may be less time-sensitive or used less frequently, such as cameras.
But the current CAN network used in today’s vehicles isn’t going away, at least not anytime soon. Ethernet would be used to transmit much larger amounts of data, but the timing of transmission is less predictable. CAN-based protocols will still be necessary for highly-reactive, time-sensitive events such as usage and monitoring of braking systems, says IoSiX’s Vogt.
“It takes years to develop standards, and they are often revised several times to accommodate new technology or improve connectivity,” adds Herron. “It's a long, difficult process to develop standards, but there's no way we would have so many features and suppliers without standards.”
Future of vehicle communication systems
It is hard to predict the future of vehicle communication systems, with regards to how they will impact vehicle service and diagnostics.
Some say the vehicle manufacturer, and subsequently the dealership, will have more control over the information available through vehicle communication protocols. Cojali’s Gattamorta suggests the vehicle manufacturers will continue to utilize and expand proprietary communication protocols for security purposes.
“We see more functions being managed through specific downloads, central services, and factory passwords that channel all through dealer-specific networks,” says Gattamorta. “This will take control over the industry where central services will be the ones running the diagnostics and changing the repair industries mainframe as we know it today.”
But ultimately the vehicle owner owns that vehicle’s data – whether they can actually access and decipher the information or not. Others say, vehicle owners – be it an owner-operator or a fleet – will need to be proactive in gaining clarity and transparency from vehicle manufacturers on the information transmitted from the truck.
“Companies increasingly want to internalize the ownership, control, and know-how around their [vehicles’] data,” says CSS Electronics’ Falch.
“This is driven by security concerns, as well as a drive towards 'digital transformation.’ As [fleets] grow more digitally savvy, they realize the importance of fully owning their data - and they build capabilities to support this.”
Those capabilities may also include in-house, custom-built telematics, instead of relying on third-party telematics service providers, adds Falch. If anything, it will continue to drive a desire to have access to this information.
“A standardized J1939 protocol will be a key prerequisite for this, and we expect to see these companies increasingly flex their procurement muscles to force OEMs to either adhere to standards or provide insight into proprietary decoding rules,” Falch adds.
The evolution will continue with diagnostic systems as telematics allow for the automatic access and transmission of vehicle data and fault codes, without the need to physically connect a scan tool.
“Scan tools, telematics systems, electronic logging devices (ELDs), etc., all basically do the same thing; they monitor and provide viewing of the vehicle data bus for needed information such as faults detected, speed, engine rpm, temperatures, etc.,” says NEXIQ Technologies’ Kotenko. “Scan tool products may have the ability to take this further with added information to assist the technician.”
IoSiX’s Vogt provides additional examples of where standardized data can help with the vehicle’s operation and analysis of vehicle systems, especially as it relates to telematics and vehicle operation analysis.
“We extract information like seatbelts, and wipers, and doors, and transmissions, and infotainment, climate control, and headlights – things that the driver can interact with,” explains Vogt. In addition, he says data on a vehicle’s operation, with information such as fuel consumption and system temperatures, are also easy to accessAs the commercial vehicle industry moves forward with more computerized vehicle systems, it will create additional challenges for these systems to transfer data and maintain security.
“Protocol improvements and vehicle network improvements will continue to address information needs and create added challenges,” says NEXIQ Technologies’ Kotenko. “Automotive vehicles will also drive the need for change as data will be even more plentiful and required for decision-making purposes.”
