Time-Triggered Message Scheduling over Classic CAN (TTCAN-style)

The problem

Event-triggered CAN gives low average latency but latency varies with load, which complicates timing guarantees for safety and control. Time-triggered schedules give predictable timing at the cost of flexibility. TTCAN (ISO 11898-4) standardises this, but few low-cost controllers support it fully; this project implements the main ideas in software on classic CAN and measures the benefit.

Objectives

• Design a basic cycle with reference, exclusive and arbitrating windows.
• Implement a time master that sends reference messages and slaves that synchronise to them.
• Align FreeRTOS tasks to the schedule so messages are sent in their windows.
• Measure synchronisation error, jitter and latency.
• Compare with the same message set sent event-triggered.

What you need

Key concepts

Basic cycle

A repeating period that starts with a reference message from the time master, followed by a fixed sequence of time windows.

Exclusive and arbitrating windows

In an exclusive window only one scheduled message may be sent, so it never competes. In an arbitrating window normal CAN arbitration applies for event messages.

Local time and synchronisation

Each node measures time from the reference message's start of frame. bxCAN's time-triggered mode captures a timestamp at start of frame, giving a precise common reference.

Disabled automatic retransmission

In a time-triggered schedule, a frame that fails should not be retried outside its window, so automatic retransmission is turned off for scheduled messages.

Step-by-step guide

1. 1

   Design the schedule

   Take a message set of about ten periodic messages (BMS status, motor command, dashboard data) and a few event messages. Choose a 10 ms basic cycle: reference message, then exclusive windows for the periodic messages, each long enough for a worst-case stuffed frame plus a guard margin, and one or two arbitrating windows for events. Draw the cycle as a timeline with window start and end times.

   Checkpoint: A schedule table and timeline showing every window with its start offset, length and owner.

2. 2

   Build the bench

   Connect both kits and the USB-CAN adapter on a terminated twisted-pair bus. Enable CAN, UART and LED DIP switches. Configure bxCAN at 500 kbit/s with time-triggered communication mode enabled, so start-of-frame timestamps are captured, and automatic retransmission disabled. Bring up FreeRTOS on both kits with a 1 kHz tick. Use a shared configuration header for the schedule so both kits use identical window definitions. Check each node in loopback mode before connecting it to the bus.

   Checkpoint: Each node sends and receives test frames and reports start-of-frame timestamps.

3. 3

   Implement the time master

   On kit 1, a hardware timer generates the cycle start; at each start the master sends the reference message with a cycle counter. Record its transmit timestamp with HAL_CAN_GetTxTimestamp. Optionally include the previous cycle's precise transmit time in the next reference for finer correction. Show the cycle count on the LCD. Light an LED on each cycle start at a slow divided rate so the cycle is visible, and log the measured reference period over UART for one minute.

   Checkpoint: Reference messages appear on the bus every 10 ms with low jitter on the PC log.

4. 4

   Implement slave synchronisation

   On kit 2, capture the reference message's receive timestamp and compute the offset between local time and master time. Adjust a local hardware timer so window events fire at the right offsets, correcting drift each cycle with a small proportional gain. Toggle a GPIO at each window start on both kits for measurement. Log the offset correction each cycle and plot it to see the clock drift between the two boards and how well the correction removes it.

   Checkpoint: Window-start markers on both kits stay aligned within a stated bound, for example 20 µs.

5. 5

   Align tasks to windows

   Use the window timer interrupt to notify the FreeRTOS task that owns the next window, with a direct-to-task notification, so it prepares and queues its frame at the window start. Give scheduled tasks higher priority than background tasks. Event messages are queued into the arbitrating window by a separate task. Measure the time from window start to the frame being queued and make sure it is well inside the guard margin. Keep scheduled tasks short and free of blocking calls.

   Checkpoint: Each scheduled message's start-of-frame time falls inside its window in every cycle of a ten-minute log.

6. 6

   Handle missed windows and faults

   If a frame cannot be sent in its window, abort it with HAL_CAN_AbortTxRequest at window end and count a miss. If the reference message is not received for several cycles, the slave stops scheduled transmission and signals a sync-lost state on the RGB LED; it resumes after valid references return. Design what happens if the time master fails. Count misses per message and report them over UART.

   Checkpoint: Disconnecting the master makes the slave stop scheduled sends and show sync lost; reconnection restores the schedule.

7. 7

   Build the event-triggered baseline

   Run the same message set as normal event-triggered CAN on the same bench, sending each periodic message from its own FreeRTOS task with automatic retransmission enabled. Use the same background event traffic from the adapter. Keep the same message IDs, lengths and periods, and the same FreeRTOS configuration, so the only difference between the two designs is how transmission times are chosen. Log start-of-frame timestamps in exactly the same way so the results can be compared directly.

   Checkpoint: The baseline runs with the same message rates and background traffic.

8. 8

   Measure and compare

   For both designs, log start-of-frame times for all messages at several background loads. Compute period jitter, latency from intended to actual transmission, and the worst case. Measure synchronisation error with GPIO markers and the optional logic analyser. Note the bandwidth lost to window guard margins. Run each configuration for at least ten minutes and twice on different days. Present the results as distributions, not only averages, because the main benefit of time-triggering shows up in the tails.

   Checkpoint: Plots and tables comparing jitter and worst-case latency for both designs across loads.

9. 9

   Analyse the trade-offs

   Discuss where time-triggering helps (bounded jitter for control messages) and what it costs (reserved bandwidth, more complex configuration, dependence on the time master). Relate the results to ISO 11898-4 concepts and note which parts of the standard you did not implement. Estimate how the reserved bandwidth would change for a larger vehicle message set, and discuss what kind of EV messages, such as motor commands in a distributed control loop, would most benefit from exclusive windows.

   Checkpoint: A written trade-off analysis based on measured numbers.

10. 10

    Document

    Document the schedule, synchronisation method, task design, fault handling, measurements and comparison. Include firmware for both nodes, the schedule configuration and analysis scripts. Add a timeline figure of one measured basic cycle showing every window and the actual frame positions on the bus, a table of synchronisation and jitter results, and a section on how to change the schedule safely. Record the guard margins you used and how you chose them.

    Checkpoint: A repository that reproduces the schedule and measurements on two kits.

Testing & validation

• Synchronisation error between nodes measured with GPIO markers.
• All scheduled frames inside their windows over long runs.
• Jitter and worst-case latency against the event-triggered baseline.
• Behaviour on loss and return of the time master.

Expected results

A software TTCAN-style schedule on classic CAN with measured synchronisation accuracy, bounded jitter for scheduled messages and a quantified comparison with event-triggered operation.

Take it further

• Add a backup time master with takeover on master loss.
• Use a system matrix with several basic cycles for messages of different periods.
• Run a closed control loop over the schedule and compare control quality.
• Compare with a FlexRay-style static and dynamic segment model in simulation.

Viva and review questions