2
\$\begingroup\$

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?

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ In general (not really aware of car-specific stuff) each node on CAN network should have a unique address. Usually these are configured even for "identical" sensors. \$\endgroup\$ – Eugene Sh. Jul 25 '18 at 13:27
  • \$\begingroup\$ Okay then how is this configuration handled? Assuming a temperature sensor's job is to measuer the temperature and send the data via CAN bus, do manufacturers produce different-ID versions of sensors to locate to different parts of the car? Or is it that my assumption is wrong and a temperature sensor in a car just measure the temperature and "somehow" send it to its unique CAN controller, which transmits that data? This would makes sense. Is it the case? \$\endgroup\$ – Binary Yildirim Jul 25 '18 at 13:33
  • 1
    \$\begingroup\$ again, I don't know much about car electronics, but I would assume, that if it is just a sensor, it is not connected directly to the bus, but connected to some kind of controller sitting on the bus and having the address. We might say more if you tell us which part you are talking about exactly. \$\endgroup\$ – Eugene Sh. Jul 25 '18 at 13:35
2
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Ok, so I understand that ID section does not define any node address, but the data area does. But I still couldn't find the answer I am searching. Do manufacturers produce different ,say, temperature sensors that will send different node address in the data section; or do sensors send the data to their own CAN controllers each of which have different addresses to append to the data area? \$\endgroup\$ – Binary Yildirim Jul 25 '18 at 14:10
  • \$\begingroup\$ Sensors tend to be on a LIN bus teed off from a node that communicates on the main CAN bus like this: m.eet.com/media/1050657/C0267-Figure3.gif \$\endgroup\$ – Andy aka Jul 25 '18 at 14:40
  • \$\begingroup\$ @BinaryYildirim It depends on the high level communication protocol that's running on top of the CAN bus. As with lots of things under the sun, there are many protocols like that developed by different industries: automotive, military vehicles, motion control. CANopen may do it slightly differently than DeviceNet (I'm using these protocols as examples, because they are publicly available free of charge.) \$\endgroup\$ – Nick Alexeev Jul 25 '18 at 15:54
1
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ Incorrect. You can have N devices on the same bus transmitting the same message ID. You will just not be able to distinguish which one is which. Use case? Eg. emergency stop switch - you can have many of them in different places. If two nodes transmit at once, then the one sending more dominant states wins arbitration. The loosing node's CAN controller will just retransmit the frame later. Non-destructive arbitration on the CAN bus is a normal thing. An error frame has a different purpose. \$\endgroup\$ – filo Jul 29 '18 at 9:56
  • 2
    \$\begingroup\$ @filo No this is wrong. Section 6.1 of the CAN specification is unequivocal about this: "A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to be detected at that time, when the bit value that is monitored is different from the bit value that is sent. An exception is the sending of a 'recessive' bit during the stuffed bit stream of the ARBITRATION FIELD or during the ACK SLOT." Outside of the arbitration field (where the message ID is) attempts at arbitration will cause an error frame to occur, which will corrupt the message being sent. \$\endgroup\$ – Jon Jul 29 '18 at 10:34
1
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

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.j1939 pgn

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.

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.