Solution
In automotive based CAN, it is not uncommon to have a rolling counter on some signals in a CAN Frame. The purpose is to ensure the integrity of data being sent, by incrementing a value with every transmission of the frame. Then any device on the bus can read all frames being transmitted, and can determine if the device is still talking, and still performing the task of incrementing the counter, which may give some insight into the status of the device. If a listener on the CAN bus still sees frames coming in, but they are not incrementing, then it knows that the device is still functioning and I might be able to better understand the devices status. Also, CAN frames have a very basic CRC built in which ensures that the message is received properly. In some automotive applications an additional CRC can be added to ensure the data being received is correct and from a device that is still communicating. In most instances, this is implemented within the last byte of the payload. Currently, the NI-XNET driver does not allow user level CRC modifications, therefore a software solution is chosen.
A very good approach for solving this problem is described in the blog post of one of our community users. The full article can be found here. It is based on Queued mode sessions and called by the author the "Bucket Filling Techinque" 