Anyone who has worked on heavy-duty vehicle electronics has come across SAE J1939 protocol. It is the common communication language that allows different ECUs inside trucks, buses and off-highway vehicles to enable inter-ECU communication.
Plug a diagnostic tool into a heavy vehicle and you will see it in action immediately. Engine speed, fuel rate, coolant temperature, torque demand, brake signals – everything flows across the CAN bus as J1939 messages.
Over the years, J1939 has become the protocol of choice for ECU communication in heavy vehicles. Tier-1 suppliers, transmission manufacturers, brake system vendors, telematics providers, diagnostic tools etc. rely on this protocol to exchange information inside the vehicle.
However, J1939 was designed primarily for reliable communication and interoperability between ECUs. Like many CAN-based vehicle protocols developed during that time, it assumes that devices connected to the network are trusted.
Messages are broadcast on the network using standardized identifiers, and ECUs typically process the signals they expect without verifying the identity of the sender.
What Happens When Trust in J1939 Messages Is Not Enough?
In a typical J1939 network, multiple electronic control units exchange operational data continuously. The engine controller broadcasts parameters such as engine speed and torque. The transmission controller listens to these signals and adjusts its shift strategy. Diagnostic tools and telematics units also access the same network to read operational data.
This broadcast-based communication model has worked extremely well for decades. J1939 defines standardized Parameter Group Numbers (PGNs) that allow controllers from different suppliers to exchange information in a consistent and predictable manner.
In such networks, ECUs generally listen for the parameters they require and react accordingly.
This approach works reliably if the devices connected to the network behave as expected.
However, it is useful to understand how messages are interpreted in such systems.
ECUs typically process J1939 messages based on their identifier and parameter structure. If a message appears on the bus with the expected format, the receiving controller can interpret it as a valid signal.
For example:
- An ECU may broadcast engine torque information
- Another controller may transmit vehicle speed data
- Diagnostic tools may request operational parameters
As long as the message structure and identifier match the expected format, the receiving ECU can process the information.
In most vehicle architectures, this communication model is supported by several system-level protection mechanisms.
These typically include:
- Physical isolation of the internal CAN network
- Gateway ECUs separating different vehicle networks
- Diagnostic access control for service tools
- OEM-specific message filtering mechanisms
These architectural controls help ensure that only trusted systems interact with the vehicle network.
However, vehicle architectures are gradually evolving.
Modern commercial vehicles increasingly include systems such as telematics gateways, remote diagnostics platforms and connected fleet management solutions. These systems interact with internal vehicle networks and enable new services for monitoring, maintenance and fleet operations.
As connectivity increases, the industry has started paying closer attention to how messages themselves are validated once they appear on the network.
In other words, an important question arises.
How can an ECU confirm that a J1939 message originates from an authorized controller and has not been altered during transmission?
This is where newer approaches to securing in-vehicle communication begin to emerge.
Enter J1939-91C: Securing J1939 Communication
To address this challenge, SAE introduced J1939-91C, a standard focused on securing communication within J1939 networks.
Rather than replacing the traditional J1939 protocol, J1939-91C extends it by introducing mechanisms that allow ECUs to verify the authenticity and integrity of messages exchanged on the network.
The idea is simple.
When a message appears on the network, the receiving ECU should be able to determine whether it was sent by a trusted ECU and whether the message content has remained unchanged during transmission.
J1939-91C introduces several mechanisms to support this.
Key Capabilities that will be Introduced by J1939-91C
- ECU Authentication
- Message Authentication
- Replay Protection
Before participating in secure communication, ECUs authenticate themselves using digital certificates managed through a public key infrastructure (PKI).
This helps ensure that only authorized ECUs are allowed to exchange protected messages on the network.
Certain messages can include cryptographic authentication data. This allows the receiving ECU to verify that the message originated from a trusted ECU and has not been modified during transmission.
Previously captured messages could potentially be replayed on the network. J1939-91C introduces freshness mechanisms that allow ECUs to detect and reject such replayed messages.
These capabilities add an additional layer of verification to the communication process.
Instead of relying solely on architectural protection around the network, ECUs can now verify the authenticity of the messages themselves.
It is important to note that J1939-91C does not change the fundamental communication structure of J1939. PGNs, message formats and CAN-based communication remain the same.
What changes is the security layer that accompanies certain messages, allowing ECUs to perform additional checks before acting on them.
In the next section, we will look at how J1939-91C changes the traditional communication architecture and what additional components are introduced into the network.
J1939 vs J1939-91C: Understanding the Architectural Difference
At this point, it is useful to understand how J1939-91C differs from the traditional J1939 communication model.
As discussed earlier, J1939 was designed to enable reliable communication between ECUs in heavy-duty vehicles. The protocol defines how messages are structured using Parameter Group Numbers (PGNs), how they are transmitted over the CAN bus, and how receiving ECUs interpret those parameters.
This basic communication framework remains the same even when J1939-91C is introduced.
J1939-91C does not replace the protocol. Instead, it introduces additional mechanisms that allow ECUs to verify the authenticity and integrity of certain messages exchanged on the network.
In simple terms, the communication model stays the same, but a security layer is added around selected messages.
The following comparison helps illustrate the difference.
| Feature | Traditional J1939 | J1939-91C |
| Communication method | Broadcast messaging using PGNs | Same broadcast communication model |
| ECU identity verification | Not defined in protocol | ECUs authenticate using digital certificates |
| Message validation | Messages interpreted based on PGN and format | Cryptographic authentication allows verification |
| Replay protection | Not defined | Freshness mechanisms detect replayed messages |
| Encryption | Not supported | Optional encryption for protected messages |
As seen above, the core communication structure of J1939 remains unchanged. ECUs continue to exchange operational data using familiar PGNs and CAN-based messaging.
What changes is the ability to verify certain messages before acting on them. This helps ensure that ECUs can confirm whether a message originates from an authorized controller and whether it has remained unchanged during transmission.
This approach allows the industry to retain the interoperability and simplicity of J1939 while introducing additional safeguards for modern vehicle architectures.
Where J1939-91C Becomes Important in Real Vehicles
The need for secure communication in J1939 networks becomes more relevant as commercial vehicles add connectivity, remote services, and more complex electronic architectures.
We discuss here some practical scenarios where secure J1939 communication becomes relevant. These are also the ideal use-cases for the upcoming J1939-91C.
- Connected Fleet Vehicles
- engine performance parameters
- fuel consumption data
- diagnostic information
- vehicle utilization statistics
- Remote Diagnostics and Service Tools
- Electrified Commercial Vehicles
- battery management systems (BMS)
- power electronics controllers
- charging interface controllers
- energy management systems
- Safety-Critical Vehicle Functions
- engine torque management
- braking system signals
- vehicle speed information
- powertrain coordination
Many trucks and buses today are connected to fleet management platforms through telematics gateways.
These systems collect operational data such as:
The telematics gateway often acts as a bridge between external communication networks and the internal vehicle CAN network. If access to the internal network is not properly controlled, it can introduce potential security risks.
Mechanisms such as ECU authentication and message verification help ensure that only trusted nodes can participate in critical vehicle communication.
J1939 is widely used for vehicle diagnostics and service operations.
Technicians connect diagnostic tools to retrieve fault codes, monitor live data, or perform calibration procedures. Increasingly, some of these diagnostic operations can also be performed remotely.
In such environments, verifying that commands and messages originate from authorized systems becomes important to prevent unintended interactions with vehicle ECUs.
Electrification is introducing new subsystems into heavy-duty vehicle architectures.
These may include:
Many of these components rely on network communication to coordinate system behaviour. Ensuring that messages exchanged between these ECUs are authentic and unaltered becomes an important consideration for overall system reliability.
J1939 communication can influence parameters related to vehicle operation such as:
In systems where ECUs depend on messages from other controllers to make operational decisions, mechanisms that allow verification of message authenticity can add an additional layer of confidence in system behaviour.
Conclusion
As commercial vehicles continue to evolve toward connected, electrified and software defined architectures, the role of secure communication mechanisms is expected to grow.
J1939-91C represents one such step towards strengthening communication trust within J1939-based systems.
