J1939-22 (-22) is a new recommended best practice from the SAE. Below is my proposal for the bare minimum needed to get a -22 implementation off the ground. Each sub section focuses on a particular feature that will need to be added. Stated goals of -22 - Take better advantage of the increased bandwidth capabilities of CANFD - Ensure as much backwards compatibility with J1939-21 (-21) so that rewrites to existing applications are kept to a minimum. Major changes from -21 - Except in certain cases, you are not allowed to send classic can frames on a -22 network - Parameter groups that total less than 60 bytes will be packed together in a new CAN FD frame called a multipg. Multiple parameter groups are to be sent in one multipg - The transport protocol allows for up to 4 simultaneous BAM sessions per network to be active at once, as well as 8 simultaneous RTS/CTS sessions per application. - Large emphasis on assurance data for functional safety and cyber security 1) Kernel implementation of multipg service: The method I propose for implementing the multipg service is as follows. A cyclic task within the kernel runs every 10ms. When the task is running it checks a send queue for each source address registered within the kernel. For each parameter group within the send queue a multipg is constructed from the contents of the queue and transmitted. 2) Sending assurance data -22 provides a very clear format for where assurance data should go within a message. As a result, I believe it is the responsibility of the kernel to handle the packaging of assurance data on behalf of the application. When sending a message, applications have the option to include either 32bits or 64bits of assurance data for each parameter group. BAM and RTS/CTS messages can include assurance data as well, but the length in that case can be up to 52 bytes. I am open to ideas for how to pass this assurance data to the kernel, but I believe it needs to be separate from the data bytes that are written to the socket. One idea I have considered is expanding the sockaddr_can.can_addr.j1939 struct to include a pointer to the assurance data bytes as well as a length for the assurance data bytes. 3) BAM Handling BAM messages is straightforward. The kernel will need to keep track of which source addresses are currently executing a BAM transfer. There is a maximum of 4 simultaneous BAM transfers allowed on a network. The kernel will need to issue an error to applications that attempt to start a BAM while there are 4 active transfers going on. 4) RTS/CTS These become a little trickier with -22 mostly since assurance data can be bundled with and RTS/CTS message. The kernel needs to be able to pass the data bytes to the receiving application. The application will then need to process the received payload and ensure that the received payload matches the supplied assurance data. At which point the application should give the OK to the sender and the session can be closed. It would be nice if the receiving application could supply a callback function to the kernel so that once the message was received the kernel could execute the callback function, verify the data bytes, and then acknowledge or abort the connection. 5) Simultaneous BAM and RTS/CTS handling Under the new scheme it is possible that a particular application on the network can be transmitting a BAM request as well as an RTS/CTS message at the same time. To avoid mixing up messages from the two transfer sessions the kernel will need to keep track of the: source address, destination address, and session number for each established transport protocol sessions.
