По каким признакам определить, что произошла именно коллизия?

Вот комбинации флагов состояния в зависимости о количества ошибок(контроллер mc9s08dz32):

Bits 6:4 LEC[2:0]: Last error code
This field is set by hardware and holds a code which indicates the error condition of the last
error detected on the CAN bus. If a message has been transferred (reception or
transmission) without error, this field will be cleared to ‘0’.
The LEC[2:0] bits can be set to value 0b111 by software. They are updated by hardware to
indicate the current communication status.
000: No Error
001: Stuff Error
010: Form Error
011: Acknowledgment Error
100: Bit recessive Error
101: Bit dominant Error
110: CRC Error
111: Set by software

2:0 LEC Last error code
Type of the last error to occur on the CAN bus.The LEC field holds a
code which indicates the type of the last error to occur on the CAN bus.
This field will be cleared to ‘0’ when a message has been transferred
(reception or transmission) without error. The unused code ‘111’ may be
written by the CPU to check for updates.
000 R/W
0x0 No error.
0x1 Stuff error. More than 5 equal bits in a sequence have occurred in a
part of a received message where this is not allowed.
0x2 Form error. A fixed format part of a received frame has the wrong
format.
0x3 AckError. The message this CAN core transmitted was not
acknowledged.
0x4 Bit1Error. During the transmission of a message (with the exception of
the arbitration field), the device wanted to send a HIGH/recessive level
(bit of logical value ‘1’), but the monitored bus value was
LOW/dominant.
0x5 Bit0Error. During the transmission of a message (or acknowledge bit,
or active error flag, or overload flag), the device wanted to send a
LOW/dominant level (data or identifier bit logical value ‘0’), but the
monitored Bus value was HIGH/recessive. During busoff recovery this
status is set each time a sequence of 11 HIGH/recessive bits has been
monitored. This enables the CPU to monitor the proceeding of the
busoff recovery sequence (indicating the bus is not stuck at
LOW/dominant or continuously disturbed).
0x6 CRCError. The CRC checksum was incorrect in the message received.
0x7 Unused. No CAN bus event was detected (written by the CPU).

Интересно, даже не знал. Жаль, подобной детализации нет во фрискейлах.

20:16 ERRBIT
4:0[3]
Error Code Capture: when the CAN controller detects
a bus error, the location of the error within the frame is
captured in this field. The value reflects an internal
state variable, and as a result is not very linear:
0 X
00011 Start of Frame
00010 ID28 ... ID21
00110 ID20 ... ID18
00100 SRTR Bit
00101 IDE bit
00111 ID17 ... 13
01111 ID12 ... ID5
01110 ID4 ... ID0
01100 RTR Bit
01101 Reserved Bit 1
01001 Reserved Bit 0
01011 Data Length Code
01010 Data Field
01000 CRC Sequence
11000 CRC Delimiter
11001 Acknowledge Slot
11011 Acknowledge Delimiter
11010 End of Frame
10010 Intermission
10001 Active Error Flag
10110 Passive Error Flag
10011 Tolerate Dominant Bits
10111 Error Delimiter
11100 Overload flag
21 ERRDIR When the CAN controller detects a bus error, the
direction of the current bit is captured in this bit.
0 X
0 Error occurred during transmitting.
1 Error occurred during receiving.
23:22 ERRC1:0 When the CAN controller detects a bus error, the type
of error is captured in this field:
0 X
00 Bit error
01 Form error
10 Stuff error
11 Other error

Вообще в CAN коллизия ошибкой не является и не ведет к порче данных.

Вы не путаете коллизию с потерей арбитража?

А чем проигрыш арбитража отличается от коллизии в CAN?

Хоть это и не относится к вопросу ТС... давайте разберемся)

Если адреса узлов разные и передача стартует одновременно, то узел с меньшим адресом выигрывает арбитраж и продолжает передавать.
Проигравший не просто отвалится, он еще и корректно примет эту посылку.

Но это только в поле адреса узла. Если при передаче данных и служебных полей будет обнаружен доминант при передаче рецессива, то
узел не перейдет в режим слушателя, а начнет активно действовать:
1) увеличит счетчик ошибок передачи (+8?);
2) если счетчик меньше определенного значения (<127?), то выставит несколько доминантов (6?) на шине - мол, ошибка (активная). Все кто принимал увидят эту ошибку и увеличат свои счетчики ошибок приема;
3) если счетчик больше определенного числа, то выставит несколько рецессивов (6?) - тоже ошибка, только пассивная;
4) если счетчик переполнился (255), то наступает bus-off на сколько-то idle-циклов шины (13?).
5) если счетчик не переполнился, то будет повторная передача (если она включена, зависит от протокола, настроек контроллера и т.п.). При этом bus-off гарантируется.

Итого: два одинаковых id узла на шине страшное зло! а не просто потеря арбитража.

PS. В деталях могу напутать, но общий смысл такой.

Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета.