How to distinguish different identical sensors in a CAN bus network?

Question

Knowing about CAN bus protocol, there are parts I couldn't understand entirely. Consider a car, with lots of sensors, say throttle sensor, parking sensor, temperature sensors located at different parts of the car. I know how arbitration works between them but here is the thing: how does the relevant ecu that will process the temperature distinguish the two different sensors? Is it that the two sensors -though their job is the same, to measure the temperature- have different IDs compared to each other? (btw yes I know one node can send different messages with different IDs)

So, let's say there are two exact temperature sensors, one inside the car for the air conditioner(not so important) and one located near the engine(very important) and it is broken. Can't I replace the broken one with the other one?

Answer 1

The CAN protocol doesn't carry any information in a frame other than the address of the unit sending the message. However, it provides up to 8 bytes of user defined message area. So if you wish to unambiguously transmit a temperature reading you should do so in the data message area and append that reading with source information.

CAN is a peer-to-peer protocol and doesn't necessarily carry anything outside the message area that can be relied upon for recognition of any party on the bus.

Answer 2

No you can't run two sensors that share the same CAN identifier on the same bus. You need to have some way of allocating unique identifiers to each sensor. This is normally done by the manufacturer when the network is designed, but it can be done dynamically by designing a higher level protocol that includes a bus coordinator device to detect attached devices and allocate identifiers at startup.

If two sensors with the same identifier are used on the bus, then at some point each sensor will attempt to transmit a message at the same time. When the (different) payload data bits are reached, one of the sensors will detect a read back error on the CAN bus and issue an error frame which will terminate the message for both sensors. Once the error frame has finished, both sensors will again try to send their respective messages out. This process will repeat until the error counters in each node force the sensors into their bus-off state where they will no longer be able to operate.

Answer 3

Based on ID

The Identifier is the only way to recognize that the message is of from which CAN Node. Usually, these identifiers values were decided by the OEMs based on the priority of the message, bandwidth in the channel etc.

Say for example, the temperature sensor which senses the AC & Engine does pretty much the same. But it doesn't have the same level of priority assigned to it. Typically, Most of the nodes in the vehicle doesn't "need" the AC temperature for changing its behavior or being cautious about. But Engine temperature is important. More ECUs consume Engine temperature than the AC temperature. So, obviously it has to have higher precedence. This is achieved by assigning a high priority ID.

Lets take another example of Wheel Speed Sensors.

Unlike the temperature sensors you mentioned, All the wheel speed sensors are as important as the other. All the sensors were "identical" and does the same. However, the OEMs have to come up with ideas to "effectively" share the bus with the sensors. That is basically assigning IDs and designing the payload of the frame.

So, possible way to avoid clash in the sensor values in the bus is to have different IDs and framing the payload in the frame.

If the sensors were "identical", you can always replace the sensor from one node to the other. But, you cannot replace the complete Sensor CAN Nodes.

A Sensor CAN Node is not just a Sensor. It has more properties than acting simply as a sensor.

Edit

To clear how OEMs handle the "identical" sensors. Consider the Temperature Sensors as example.

We have one temperature sensor attached to the Engine ECU to monitor the Engine temperature. We have another temperature sensor attached to the Body ECU to monitor the vehicle AC temperature. Even if the sensors were same, but those were attached to different ECUs. This is because of the fact that the vehicle AC can be turned ON even without the Engine being ON. So, we effectively need to monitor the AC temperature whenever the AC is ON. This means, the "identical" sensors need not to be used together or controlled together.

So, consider now in the dashboard, we are seeing both AC and Engine temperature. Take, the AC temperature is 21.5 degC and Engine temperature is 78.255 degC.

We need higher precision for the Engine temperature to activate the Engine Overheat Alarm or activating a coolant on proper time and to learn the rate of change of temperature over the time.

However, the AC temperature is used to maintain the same climate in the vehicle for Automatic Climate Control functionality. This is not as high priority and +/- 0.5 degC is far more comfortable.

So, to clearing things for you, The sensors were same. But, the precision were different based on the functionality it is used. You know how to change the precision, reference voltage, ADC, etc. This also reflects in the payload of the CAN messages which carries the sensor information.

You know, we cannot send the floating point value in the CAN message. we need to convert into a whole number by multiplying with a factor and the receiving ECU has to retrieve temperature by dividing with the same factor.

So, to send the temperature without any losses, the AC Temperature will have a factor of 10. which makes the value range from 0 - 512 (0 to 51.2 degC) which only needs 9 bits to transmit. However, the Engine temperature will have a factor of 1000. which makes the value range from 0 - 131072 (0 to 131.072 degC) which needs 17 bits to transmit.

So, to answer your question, OEMs chooses ID to priorities the sensor information and frame the payload to make effectively use the sensor values. Beside these there were a lot of other concerns in designing the CAN network for a vehicle. I'm just trying to keep it in context and not to confuse you so much.

Answer 4

The Identifier in an CAN frame tells something about the contents of the message. It's not an address.

If you have a dozen of identical sensors on the system, they do not share the same identifier, because they do not have the same purpose.
All will have a different identifier to identify the content of the message.

Eg: 8 cylinder temperature sensors from the same type means they all need to be configured to send the identifier that specifies it's measuring cylinder X.

To help with this, there are higher layer protocols to use on top of ISO 11898, such as J1939 or CANOpen.

---

J1939 for example:
It solves this by reserving the least significant byte of the ID for a source address.

This allows the message contents (PGN) to still allow priority arbitration, regardless of the source address.

The PGN specifies it's a engine cylinder temperature message, and the source address specifies which sensor.

---

In general, it is avoided to have two nodes transmitting on with equal identifiers.
Since transmit will fail after arbitration if the message data is unequal. Both will retry and eventually succeed. But even then you're looking at data jumping around every frame. Unless some field in the message further describes the contents of the message.
Which is against fundamental the purpose of CAN. (see first line)

However, CAN is only layer 2 so you are free to do so. Although, it will make system integration a lot more difficult.