CAN Networks in the Field

Every control action in a CAN system exists in three versions at once. There is the state the controller commanded, the state the device reports back, and the state you would see if you stood next to the device and looked. During a normal transition the three are allowed to disagree for a moment. The question this project asks is when that disagreement outlasts the allowed response time.

The moment is longer and less predictable than it looks, and the reasons are built into the protocol. CAN arbitrates by priority: when two nodes start transmitting together, the frame with the lower identifier wins and the other waits for the bus to go idle and tries again. A low-priority command can therefore sit in a transmit buffer behind a run of higher-priority traffic, and how long it sits depends on how busy the bus happens to be at that instant. Frame length varies too, because CAN inserts a stuff bit after every five identical bits, so the same message can take a slightly different number of bit times depending on its contents. Inside a node, a transmit queue that releases frames in the order they were queued rather than by priority can hold an urgent frame behind a routine one. At the far end, the device that receives the command takes its own time to act and then reports its new state on whatever schedule its firmware uses, often a periodic broadcast, so the reported state can lag the real one by up to a full broadcast period even when everything is working. Add all of that up and the response time of one control action is a distribution, not a number, and the tail of the distribution is where state mismatches live.

I’m designing experiments to study exactly that: timing and device-state mismatches in real CAN control systems. The project is in its research-design phase, which means I am reviewing prior work, including the response-time analysis for CAN that Tindell and Burns developed in the 1990s and the corrections it has collected since, narrowing the questions, and defining the experiments, firmware, software, and measurements it will take to study these systems repeatably rather than anecdotally. There are no experimental findings to report yet, and I would rather say so plainly than imply otherwise.

The first milestone is a dedicated test platform. On it I need to control bus utilization and message timing, so that the load on the bus is a variable I set rather than whatever the installed devices happen to produce; measure arbitration delay by identifier priority, so that I can see how much of a frame’s latency is waiting and how much is transmission; and record endpoint response latency, from the moment a command frame leaves the bus to the moment the device’s reported state changes. Once timing and load are under control, the platform becomes the instrument for the measurement I actually care about: when commanded, reported, and observed state diverge, how long that divergence persists, and whether it exceeds the expected response window. The observed state is the hard one to instrument, because it means measuring the physical output independently of anything the device says about itself. That is also what makes it the only one of the three that can’t lie.