CAN Protocol: MSXII

We defined our own transport-layer protocol for MSXII by dividing the standard identifier into message ID, type, and source device. The general idea behind our protocol is to take advantage of CAN's broadcast-based system and have nodes perform actions based on the messages that they receive, regardless of the source device. By defining the message ID in the most significant bits and the source device in the least significant bits, the source device has almost no effect on the frame priority. Since that information is transmitted mostly for telemetry, our chunking accurately reflects the effect each field should have on a frame's priority.

Although most CAN messages will be broadcast openly, there are some messages that must be processed by all appropriate systems, such as a BPS fault. Critical messages are defined as events that will result in an unrecoverable failure condition if not processed. To ensure that these messages are processed, we define acknowledgements (ACKs) as a response to critical messages. When a critical message is received, an ACK must be sent as a reply with the same message ID and the type field set to ACK. Currently, an ACK's data field is unused.

One option we're currently exploring is using the remote transmission request (RTR) bit to represent ACKs. Unfortunately, the CAN standard defines frames with the RTR bit set as remote frames. These frames are used to request data to be sent to a destination device and do not contain data fields. Instead, the data length code (DLC) represents the data length of the expected response. Using the RTR bit to represent ACKs would be misusing the protocol.