12
\$\begingroup\$

CAN arbitration is done with IDs, and any node on the bus can transmit with any ID (ideally it should not, but a nasty node can).

What if two different nodes connected on the same CAN bus transmit messages with the same IDs but different data bytes?

My thinking: It will generate garbage on the bus. Whoever has the dominant bits those only will get transmitted.

\$\endgroup\$
  • 1
    \$\begingroup\$ I'm not sure why they did it this way. I would have thought it would make more sense for arbitration to apply to the whole message. \$\endgroup\$ – Rocketmagnet Oct 9 '12 at 9:35
11
\$\begingroup\$

Section 6.1 of the CAN spec:

BIT ERROR: A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to be detected at that bit 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.

So, the node which first transmits a '1' when the other is transmitting a '0' will note a Bit Error and then signal an error as normal - by transmitting an error-flag (see Section 3.1.3) , as described formally in Section 6.2.

Informally, if that node is error-active (which should be the usual case) it will transmit an error flag of 6 dominant bits, which all other nodes will also detect (as a stuff error). This has the effect of destroying that message completely:

  • no-one will receive it
  • none of the transmitters will think they have successfully transmitted anything.

Each transmitter will then attempt to retransmit - depending on the precise timing of the retransmissions, one may start sufficiently before the other the gain control of the bus. Otherwise, the same sequence may happen again. (Or another higher-priority message may put them both off for a while!)


Extended answer inspired by @clabbacchio's answer below.

You mention "nasty nodes", and clabbacchio makes the valid point that if two nodes transmit at different times, each receiver needs to decide what to do with its multiple receptions.

This was demonstrated by a hack last year. The paper discusses, in the section "PSCM specifics", how an attacker can synchronise to the regular messages on the bus and play their evil message just before the one that the "good" ECU is about to send. The receiving ECU accepts the earlier message, updates its message counter and then discards the "good" messages as erroneous, because its message counter has not incremented.

\$\endgroup\$
1
\$\begingroup\$

If the messages data field is different, you'll (hopefully!) get an error frame on the bus due to wrong CRC.

\$\endgroup\$
1
\$\begingroup\$

In your question, you make this hypothesis:

Whoever has the dominant bits those only will get transmitted.

Which assumes that the two messages are transmitted at exactly the same time, which is a specific case of a more general issue. Martin's valid answer covers this specific issue, but ignores the (more general) case in which the two nodes transmit at different times.

In that case, there will be two messages with the same ID but different payload circulating on the bus, and it is up to the logic of the receivers to discriminate between the two messages and decide whether it is the content they need to receive. If they fail to distinguish the two messages, they may misinterpret the data and cause more serious issues than just error frames.

E.g. say that one message contains the reading of a temperature sensor, the other contains the target position of an actuator on the same byte (SHOULD NEVER HAPPEN IN REAL LIFE), you may have the actuator get that as its target without even knowing.

\$\endgroup\$
  • \$\begingroup\$ Yes, a logic should be implemented to distinguish between two messages. But my question was if arbitration is done on the basis of ID, then what will happen if message ID is same and data is different. \$\endgroup\$ – Swanand Nov 8 '17 at 15:36
  • \$\begingroup\$ @Swanand only on the hypothesis of simultaneous transmission then? Just notice that it's a corner case, the opposite is more likely \$\endgroup\$ – clabacchio Nov 8 '17 at 15:38

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.