Why External Steering Request (XSR) J1939 message has checksum message within the 8-byte Data Field?

[jani12]

Camera ECU sends External Steering Request (XSR) J1939 message to the steering ECU. The PGN of this message is 0xF341. There is 4-bit checksum within the 8 byte data field. The SPN of this checksum is 21095.

This 4-bit checksum is used to verify the signal path from the demanding device to the active steering system. It is calculated using the first 7 data bytes, the 4 bit message counter and the bytes of the message identifier.

Since there is 16 Bit CRC Field in the J1939 frame (please see attached), why does J1939 specification include 4-bit checksum within the Data Field?

 

[Diver300]

The additional checksum will allow verification of the data by the application software.

The transport layer, in this case the CANbus, will apply the checksum in hardware, so there is no check that the software that sent the signal has done any verification unless the additional checksum is added within the 8 bytes.

Also the 8 bytes, or some of the 8 bytes, could end up being translated into another CAN frame, or even some other transport mechanism, such as Flexray. In that case the CANbus checksum would only protect one transmission and not a second one. However, the 4 bit checksum within the 8 bytes would give end-to-end verification and detect glitches in the translation software, as well as in the transmission hardware.