One question that appears regularly in SAE J1939 discussions is whether multiple Electronic Control Units (ECUs) can transmit the same Parameter Group Number (PGN).
At first glance, the answer seems straightforward: if the J1939 standard defines a message, why shouldn’t multiple devices be allowed to transmit it?
In reality, the situation is more nuanced. While SAE J1939 does not universally prohibit multiple nodes from transmitting the same PGN, doing so can range from perfectly reasonable to highly problematic, depending on the application and the specific PGN involved.
Let’s take a closer look.
Understanding What a PGN Represents
A PGN defines the structure and meaning of a message. It does not necessarily define who must transmit it.
For example, PGN 61444 (Electronic Engine Controller 1, EEC1) contains engine-related information such as engine speed and engine torque. The PGN definition itself merely describes the data format.
The question becomes:
Can more than one node transmit that same PGN?
The answer is both yes and no. The CAN protocol itself does not permit multiple nodes to transmit messages using the same CAN identifier (11-bit or 29-bit). If two nodes attempt to send frames with the same identifier, the result can be transmission conflicts and error frames.
SAE J1939, however, adds another dimension to the message identifier: the Source Address. Consequently, multiple nodes can transmit messages containing the same PGN, provided each node uses a unique source address. In that case, the resulting CAN identifiers remain unique and no conflict occurs at the network level.
The real question, therefore, is not whether multiple nodes can transmit the same PGN, but whether receiving applications can correctly interpret multiple sources of the same information.
The challenge lies at the application level.
The Single-Source Assumption
The CAN protocol is based on the principle of message-oriented communication. A transmitting node does not care which nodes receive the data, and a receiving node generally does not care which node transmitted it. Instead, the receiving application uses the message identifier to determine whether the data is relevant and should be processed.
Many SAE J1939 applications operate under a similar assumption: a particular type of information originates from a single source. For example, engine speed is expected to come from the engine controller, while transmission data is expected to come from the transmission controller. As long as there is only one source for a given type of information, the receiving application can process the data without ambiguity.
Consider engine speed.
In a typical vehicle, there is only one engine controller. Therefore, receiving devices assume that all EEC1 messages originate from that controller.
If two different ECUs begin transmitting EEC1 messages with different engine speed values, the receiving device may not know which value to trust.
Possible outcomes include:
- The receiver uses the first message received.
- The receiver uses the most recent message.
- The receiver alternates between values.
- The receiver rejects both values.
- The receiver behaves unpredictably.
The J1939 standard does not necessarily define how every receiving application should handle such situations.
As a result, interoperability may suffer.
Cases Where Multiple Sources Make Sense
There are situations where transmitting the same PGN from multiple nodes is entirely reasonable.
Redundant Systems
High-reliability systems sometimes employ redundant controllers.
For example:
- Primary engine controller
- Backup engine controller
Under normal conditions, only one controller actively transmits data. The backup remains silent until a failure occurs.
In this scenario, both controllers are capable of transmitting the same PGNs, but they do not do so simultaneously.
Simulators and Test Equipment
Laboratory environments often use multiple devices capable of generating the same PGN.
Examples include:
- ECU simulators
- Test benches
- HIL (Hardware-in-the-Loop) systems
- Diagnostic tools
During testing, engineers may intentionally replace the original message source with a simulator.
This can be extremely useful when validating dashboards, telematics systems, or control software.
Data Fusion Applications
Some custom systems generate virtual PGNs based on data collected from multiple sources.
For example, a gateway may receive information from several sensors and then transmit a consolidated PGN.
In these cases, multiple devices may be capable of generating the same PGN, although typically only one device is active at any given time.
Cases Where Problems Are Likely
Engine Data
Suppose two controllers transmit EEC1 messages.
One reports:
- Engine Speed = 1,500 RPM
The other reports:
- Engine Speed = 1,550 RPM
A dashboard receiving both messages now faces a conflict.
Since both messages appear legitimate, the dashboard has no obvious method of determining which one represents reality.
Vehicle Speed
The same issue can occur with vehicle speed messages.
If multiple speed sources provide slightly different values, receiving applications may display unstable or inconsistent readings.
Diagnostic Messages
Diagnostic messages present additional challenges.
Messages such as:
- DM1
- DM2
- DM3
- DM4
are often expected to represent the diagnostic state of a specific ECU.
While multiple ECUs can legitimately transmit DM1 messages, each message must originate from a unique source address and describe faults associated with that ECU.
A diagnostic application typically distinguishes the messages based on the source address.
Problems arise when multiple devices attempt to impersonate the same ECU.
The Role of Source Addresses
An important detail often overlooked is that a J1939 message consists of more than just its PGN.
The message also includes:
- Source Address
- Priority
- Data
Therefore, two EEC1 messages from different source addresses are not identical messages.
A sophisticated receiver may distinguish them and process them separately.
However, many applications are not designed to handle multiple sources for data that is normally expected to come from only one device.
Consequently, the mere existence of different source addresses does not guarantee correct operation.
What About Address Claiming?
Address claiming introduces another layer of protection.
Under normal circumstances, only one ECU may own a given source address.
If two devices attempt to claim the same address, the Address Claim procedure determines which device wins.
This mechanism prevents one class of conflicts but does not prevent multiple ECUs from transmitting the same PGN using different source addresses.
Therefore, address claiming does not solve the duplicate-PGN question.
Real-World Industry Practice
In production vehicles, the vast majority of important operational PGNs originate from a single ECU.
Examples include:
- Engine speed
- Fuel rate
- Engine temperatures
- Transmission data
- Brake data
This approach simplifies integration and avoids ambiguity.
When redundancy is required, manufacturers typically implement carefully controlled failover mechanisms rather than allowing multiple controllers to transmit the same operational data simultaneously.
The result is a clear ownership model:
One parameter, one authoritative source.
So, Is It Allowed?
The technically correct answer is:
Yes, multiple J1939 nodes can transmit the same PGN.
The more important question is:
Should they?
The answer depends entirely on the application.
In testing, simulation, redundancy, and specialized architectures, transmitting the same PGN from multiple nodes can be perfectly valid.
In production systems, however, transmitting the same operational information from multiple active sources often creates ambiguity and may lead to unpredictable receiver behavior.
For that reason, most vehicle manufacturers and system integrators prefer a single authoritative source for any given parameter.
Conclusion
The CAN bus itself has no objection to multiple nodes transmitting the same PGN. SAE J1939 also does not universally prohibit the practice.
The real challenge lies in how receiving applications interpret the data.
If multiple sources provide the same information and all receiving devices understand how to handle it, the approach can work well.
If receivers assume a single source—as many do—the result may range from harmless confusion to serious operational issues.
Ultimately, the question is not whether multiple nodes can transmit the same PGN, but whether the overall system architecture has been designed to accommodate it.
SAE J1939 to USB Gateway
The SAE J1939-to-USB Gateway provides a simple and effective way to connect a PC or laptop to an SAE J1939 network for real-time data monitoring and analysis. Designed for engineers, technicians, and fleet maintenance personnel, the interface captures J1939 traffic directly from the CAN bus and transfers it to a computer via USB, enabling users to observe network activity, monitor engine and vehicle parameters, and diagnose communication issues with ease.
Whether you are troubleshooting electronic control units (ECUs), validating network performance, or studying J1939 communications in heavy-duty vehicles and industrial equipment, the gateway offers a reliable connection between the vehicle network and your software tools. Combined with compatible monitoring applications, it provides detailed access to Parameter Group Numbers (PGNs), diagnostic messages, and protocol traffic, making it an essential tool for J1939 network analysis, diagnostics, maintenance, and training. More information…
Comments are closed.