Worst-Case Response-Time Analysis vs Measured Latency on Classic CAN

The problem

EV networks carry safety-relevant messages from the BMS, motor controller and VCU, and engineers rely on response-time analysis to prove deadlines are met. The analysis makes assumptions about transmit buffers, queueing and bit stuffing that real controllers and drivers can break, so measured behaviour can differ from the proof.

Objectives

• Implement the revised classic CAN response-time analysis for a message set, including bit-stuffing worst case and queuing jitter
• Build a hardware testbed that generates the message set and timestamps each frame
• Quantify the gap between analytical bounds and measured worst-case and percentile latencies
• Show how driver choices such as transmit-mailbox priority mode cause priority inversion

What you need

Key concepts

Response-time analysis

For each message, the worst-case response time is its queuing jitter plus blocking by one lower-priority frame plus interference from higher-priority frames plus its own transmission time, solved by fixed-point iteration.

Worst-case bit stuffing

A standard-ID frame with 8 data bytes can grow to 135 bits after stuffing, which is 270 microseconds at 500 kbit/s; the analysis must use this, not the nominal length.

Transmit mailbox priority

bxCAN has three transmit mailboxes; the TXFP bit chooses whether they go out by identifier priority or by request order, and request order can cause priority inversion.

Hardware timestamps

With time-triggered communication mode enabled, bxCAN records a 16-bit timer value at start of frame for received and transmitted messages, giving timestamps without interrupt latency.

Step-by-step guide

1. 1

   Define the message set and hypotheses

   Choose a realistic EV message set of 15–30 messages with identifiers, periods, deadlines, payload lengths and sender nodes, for example adapted from the classic SAE benchmark used in the CAN scheduling literature. Write down hypotheses, such as 'measured worst case stays below the bound' and 'FIFO mailbox mode causes inversion'. Fix the bit rate (500 kbit/s) and target bus loads.

   Checkpoint: A message-set table and a list of testable hypotheses reviewed with your supervisor.

2. 2

   Implement the analysis tool

   Write a Python tool that takes the message table and computes, for each message, the worst-case transmission time including bit stuffing, the blocking from the longest lower-priority frame, and interference from higher-priority frames, using the revised analysis with fixed-point iteration over the level-i busy period. Validate the tool on a published worked example before trusting it on your own set. Output per-message bounds, total bus utilisation and a flag for any deadline miss, and keep the code under version control with unit tests.

   Checkpoint: The tool reproduces the bounds of a published example within one bit time.

3. 3

   Configure the nodes

   Set every kit to a 72 MHz system clock with APB1 at 36 MHz, and configure bxCAN at 500 kbit/s with the same bit timing on all nodes. Enable time-triggered communication mode so that receive and transmit mailboxes carry start-of-frame timestamps from the CAN internal timer. Set the DIP switches to connect each CAN transceiver, and fit 120 ohm termination only at the two physical ends of the bus. Run a soak test before any measurement so you know the wiring is clean.

   Checkpoint: Every node exchanges frames at 500 kbit/s with zero error-counter growth over one hour.

4. 4

   Generate periodic traffic

   On each sender node, use a hardware timer to release each message at its period, with release jitter you control and record. Queue the frame with HAL_CAN_AddTxMessage and store the release time from a free-running 1 MHz timer together with the identifier and a sequence number in the payload. Keep the queueing logic simple and documented, because every software decision here becomes part of the system you are analysing. Check that no message is released while its previous instance is still pending unless that is intended.

   Checkpoint: Measured release periods on the console match the configured periods within a few microseconds.

5. 5

   Timestamp transmissions and receptions

   On a monitor node, read the Timestamp field of every received header, and on senders read the transmit timestamp in HAL_CAN_TxMailbox0CompleteCallback and the matching callbacks for mailboxes 1 and 2. Convert counts to microseconds, unwrap the 16-bit counter using the known message periods, and send compact binary records over UART to the PC at a baud rate high enough not to back up. Compute response time as completion time minus release time, and log any record you had to drop.

   Checkpoint: For an isolated single message, measured response time equals the computed frame time plus a small, constant software offset.

6. 6

   Calibrate offsets and clocks

   Each node has its own crystal, so timestamps from different nodes drift apart. Pick one node's periodic message as a reference, observe it on every other node, and fit a linear offset-and-drift model per node over a long window. Separately measure the fixed software delay from the release interrupt to the mailbox request with the DWT cycle counter. Subtract both consistently in the analysis scripts and state the residual timing uncertainty, because it sets the smallest difference between analysis and measurement you can claim.

   Checkpoint: Cross-node timestamps agree within a documented error bound, for example under 5 microseconds after correction.

7. 7

   Run the load sweep

   Run the message set at several bus loads, for example 30%, 50% and 70%, by scaling periods while keeping priorities fixed. Each run must be long enough to catch rare worst-case phasings, so plan hours rather than minutes. Repeat the sweep with identifier-priority and request-order mailbox modes (the TXFP setting) and with deliberately increased release jitter. Save raw logs with a run description file recording firmware version, configuration and date, so every figure in the thesis can be traced back to its data.

   Checkpoint: A dataset per configuration with at least several hundred thousand instances of each message.

8. 8

   Compare analysis with measurement

   For each message, plot the analytical bound against the measured maximum, 99.9th percentile and the full latency distribution, at each load and configuration. Compute pessimism as bound divided by measured worst case. Identify every message that exceeded its bound and trace the cause, such as request-order mailboxes, driver queuing or interrupt latency that the jitter term did not include. Use the calibration uncertainty from earlier to decide whether a small exceedance is real or within measurement error.

   Checkpoint: A per-message comparison table and plots, with every bound violation explained.

9. 9

   Extend the analysis

   Add the effects you found to the model, for example extra blocking from non-abortable transmit mailboxes, the software queue in your driver, or interrupt latency as an additional jitter term. Recompute bounds for every configuration and show whether the extended model now encloses all measurements while staying tighter than a naive safe bound such as assuming the worst for everything. Discuss which extension matters most in practice and whether it would apply to other CAN controllers.

   Checkpoint: The extended model encloses every measured response time in all configurations.

10. 10

    Write up for review

    Document the testbed, calibration method, uncertainty budget, results and the model extension in a paper-style chapter. Include a threats-to-validity section covering the small number of nodes, a single bit rate and the specific controller. Release the analysis tool, firmware and anonymised logs alongside the thesis so others can reproduce each figure, and ask a colleague to rerun one figure from the released material before submission.

    Checkpoint: A draft paper-style chapter with method, results, threats to validity and reproducibility notes.

Testing & validation

• Analysis tool reproduces a published worked example
• Single-message response time equals computed frame time plus constant offset
• Cross-node timestamp error bound measured and documented
• Measured versus bound comparison for every message at every load and mailbox mode

Expected results

A reproducible CAN timing testbed, an analysis tool, and a quantified comparison of predicted and measured response times, showing where classic analysis is pessimistic and which implementation choices break its assumptions.

Take it further

• Add error frames at a controlled rate and extend the analysis with an error model
• Compare with a second CAN controller or a USB-CAN adapter as one node
• Study the effect of FreeRTOS task scheduling on release jitter

Viva and review questions