Can CAN 2.0B and J1939 coexist in the same CAN Network?

Please consider CAN communication network in a heavy vehicle:

• Steering Electronic Control Unit (ECU) has CAN 2.0B. It doesn't have J1939 stack.
• All other ECUs in this network are implemented with J1939 stack.

Can CAN 2.0B coexist with J1939?

What code changes are needed in steering ECU and other ECUs in order to communicate successfully on the same CAN bus?

How will the ECUs claim static source address since steering ECU doesn't have J1939 stack?

See the Definition section here:

According to that, J1939 data can be transported via CAN, so no conflicts.

For the different higher level protocols, presumably you need some sort of gateway device to translate?
Vehicles often have a gateway / router unit to manage cross-communications between the various high & low speed busses, so I'd guess that would use the same approach/

It's certainly possible to have ECUs on the same network that don't communicate with each other. As long as each ECU can receive all the data that it needs, it will ignore other messages.

As a result of this, and modules being designed at different times, most networks on most cars have redundant messages or signals that nothing is listening to.

Most modern vehicles have many CANbuses.

I don't think that J1939 and CAN 2.0B systems are capable of talking to each other, but that doesn't prevent some modules being capable of working with both types of message.

Please allow me try and clarify my question. What software changes are needed in order for steering ECU (it's CAN 2.0B, no J1939 stack) and other ECU's (they have full J1939 stack) to exchange messages on the same bus?
What software changes are required in the steering ECU and other ECU's in order for them to talk to each other?

For example, steering ECU will need to implement the capability to packetize messages with PGN and SPN and send on the bus. Steering ECU will also need to parse PGN and SPN's from incoming messages.

How will address claim work? Steering ECU doesn't have Network Management (NM) layer (J1939-81). Therefore, it cannot automatically claim static source address? Can all the other ECUs claim source address in the absence of NM layer in steering ECU? Or in order for all this to work, steering ECU and all other ECUs will need to hard code source addresses?

If you can change the software on the steering ECU, then you can change it to include a J1939 stack and exchange information with the rest of the vehicle.

However, getting access to the software is likely to be difficult. You would need to rewrite quite a lot of the software, and without the source code that would be very difficult.

It would probably be far easier to have some separate gateway that communicates with the steering ECU using CAN 2.0B and with the rest of the vehicle with J1939, and passes back and forth the messages that are needed. It is possible that the gateway could run with a single CAN connection for both types of message, but it might be easier to have them physically separate.

I don't know how J1939 devices claim their source address. The only network management that I have come across is in CAN 2.0B where it is used to decide when the module go to sleep mode and the current consumption drops right down.

Diver300 said:

It would probably be far easier to have some separate gateway that communicates with the steering ECU using CAN 2.0B and with the rest of the vehicle with J1939, and passes back and forth the messages that are needed.

Click to expand...

For reference, attached is mapping of a J1939 message into the extended CAN 29-Bit message. Instead of gateway ECU constructing J1939 frame from CAN 2.0B frame, why not steering ECU do the message construction and send it directly on bus for ECUs that need the message.

This is prototype software. All J1939 stack features aren't needed. Steering ECU just needs to transmit and receive parameters over CAN bus from other ECUs in order to provide steering assist functionality.

If you can change the software in the steering ECU, and you can make it send and receive the J1939 messages, that would be the best thing to do.