Time-Triggered Buses, Global Time, and Bus Guardians

A controller area network resolves contention by priority: the node with the lowest identifier wins, and the losing node retries in the next arbitration window. That is efficient for event-driven traffic and poor for anything that needs a guarantee, because the waiting time of a low-priority frame depends on the arrival pattern of every higher-priority frame in the system. Time-triggered buses take the opposite approach. The schedule is computed offline, every node knows in advance when it may transmit, and the network carries no arbitration at all. What it carries instead is a shared notion of time, and the correctness of the whole arrangement rests on that notion.

The static schedule and what it removes

A time-triggered protocol divides time into rounds, and each round into slots. A slot is assigned to one node, and the assignment is fixed at design time. When a node’s slot begins, it transmits; when the slot ends, it stops, whether or not it has finished. Every other node listens. There is no backoff, no priority inversion, and no queueing delay, so the worst-case latency of a frame is a property of the schedule rather than of the traffic.

The FlexRay protocol makes the structure explicit. A communication cycle consists of a static segment, divided into slots of fixed duration, followed by a dynamic segment, divided into minislots that are consumed only by nodes with data to send, and then a symbol window and an idle time. The static segment carries the traffic that must be guaranteed; the dynamic segment carries the rest on a best-effort basis with a priority determined by minislot position. The cycle repeats with a period configured at design time, and the protocol allows the cycle length and the slot count to be set so that the schedule fits the application’s periods as integer multiples of a base cycle.

The static segment is where determinism lives. Because the slot boundaries are fixed and no node may transmit outside its slot, the time from the start of a cycle to the delivery of a given frame is bounded by arithmetic on the schedule, independent of every other node’s behaviour. That is the property that a CAN-based design cannot offer without priority analysis, and it is the reason time-triggered buses appear in systems where a missed deadline is a safety event rather than a performance problem.

The cost is paid in bandwidth. A node with nothing to send in its slot still owns the slot, and the slot is wasted. A schedule built for the worst case is idle most of the time, which is why the achievable utilisation of a static segment is far below the link rate. FlexRay’s nominal rates reach 10 megabits per second per channel, and a static schedule typically uses a modest fraction of that, with the remainder available to the dynamic segment. The trade is direct: determinism costs the ability to reclaim unused capacity.

Deriving global time from the schedule itself

A slot-based protocol works only if every node agrees on when slot boundaries occur. The agreement is not supplied by a central clock, because a central clock is a single point of failure. It is derived from the traffic: the start of each communication cycle is a synchronisation event, and each node measures the arrival times of frames relative to its own local clock, then adjusts.

The mechanism is a fault-tolerant average. Each node measures, for the frames it receives in a cycle, the deviation between the expected arrival time and the observed arrival time, using its local clock. It then computes a correction from those deviations, typically the arithmetic mean after discarding the extreme values, and applies it to its local schedule. The discarding is what makes the algorithm tolerant: a node whose clock has drifted, or whose transmissions are mistimed, contributes a deviation that the others see as an outlier and exclude.

The result is a set of clocks that track each other within a bounded precision, called the global time, and the bound is a design parameter. It depends on the oscillator tolerance, the number of synchronisation events per cycle, the rate at which the schedule runs, and the resolution of the local clock. A typical requirement is that the precision be small relative to the slot length, so that a node transmitting at the very edge of its slot does not collide with its neighbour. The ratio between the precision and the slot duration is the parameter that determines how much of the schedule can be used.

Two details keep the scheme from failing silently. The first is that a node which loses synchronisation must be excluded rather than allowed to transmit at the wrong time. Protocols implement this by requiring a node to be synchronised before it may transmit in the static segment, and by having the node’s peers stop accepting its frames when its deviations exceed the tolerance. The second is that the correction must be applied gradually, because a step change in a node’s schedule would move its transmissions into a neighbouring slot. Implementations rate-limit the adjustment, which means the clocks converge over several cycles rather than instantly.

Why a correct node can still transmit at the wrong time

Synchronisation keeps a healthy node’s slot boundaries aligned. It does not prevent a node with a hardware fault from transmitting outside its slot. A node whose clock circuit has failed, whose schedule table has been corrupted, or whose transmitter has latched on will produce a frame during another node’s slot, and in a time-triggered system that frame is indistinguishable from the legitimate one at the physical layer. It corrupts the other node’s transmission and can take down the channel.

The mechanism that addresses this is the bus guardian: a small, independent device between the node’s communication controller and the physical bus, which enables the transmitter only during the slots the node is permitted to use. The guardian has its own schedule, its own clock, and its own power, so a failure in the node cannot widen the guardian’s window. When the node transmits outside its slot, the guardian has already disabled the driver and the frame never reaches the wire.

The guardian’s independence is the whole point, and it is the same argument as for a watchdog: a guardian implemented in the node’s own controller, clocked from the node’s own oscillator, shares the failure modes it is supposed to contain. FlexRay’s specification describes the bus guardian as an optional component, and the decision to include it is a function of the integrity target rather than of the protocol. A system claiming high availability on a single channel generally needs it, because a babbling node is otherwise a channel-wide failure.

The guardian’s own schedule is a copy of the node’s transmit windows, which means the two must agree. A guardian whose schedule is misconfigured, or whose clock has drifted relative to the node’s, will either cut off legitimate frames or admit illegitimate ones. Both are failures that a periodic test must detect, and the test has to exercise the guardian’s enforcement rather than merely confirm that it is present, in the manner described in Runtime Self-Tests and Diagnostic Coverage Measurement.

Channels, replication, and the cost of a second wire

Time-triggered buses are usually deployed as two channels carrying the same schedule. The replication is not redundancy in the voting sense; it is spatial separation of the transmission medium, so that a cut wire, a shorted connector, or a failed transceiver on one channel does not remove the frame. A receiver that has both channels available can take the first valid copy of each frame, and the arrival times of the two copies differ by the propagation skew between the channels, which is small compared with a slot.

The replication has a subtlety that is easy to get wrong. If both channels are driven by the same communication controller, then a fault in the controller produces the same frame on both channels, and the receiver’s choice between them is meaningless. The channels must therefore be driven by separate controllers, or by a controller with a documented internal separation, and the bus guardians for the two channels must be independent as well. FlexRay allows a node to be connected to one or both channels, and a node connected to both with a single controller is claiming redundancy at the medium level only.

The second subtlety is the schedule. Both channels normally carry the same static schedule, so a frame lost on one channel is present on the other. Some designs use the channels for different traffic instead, which doubles the usable bandwidth and removes the redundancy. The choice is a design decision recorded in the communication matrix, and it cannot be changed at run time without invalidating the schedule analysis.

Where the schedule analysis actually bites

The offline schedule is computed against a set of assumptions, and the assumptions are where time-triggered designs fail. Three of them recur.

The first is that the slot is long enough for the frame plus the protocol overhead plus the propagation delay plus the precision of the global time. A slot sized for the payload alone will produce collisions at the boundary once the clocks are at opposite ends of their tolerance. The correct sizing adds all four terms and then some margin for the oscillator’s temperature drift over the life of the equipment.

The second is that the application’s periods divide the cycle length. A task that needs to run every 7 milliseconds in a 5-millisecond cycle cannot be scheduled without either changing the cycle or accepting jitter, and the acceptance is a decision that must be made explicitly rather than absorbed by the scheduler. FlexRay’s cycle length is configurable but not arbitrary; it is expressed as a multiple of the protocol’s macroticks, and the granularity of the resulting periods is set by the clock configuration.

The third is that the receivers are ready. A frame that arrives in its slot is only useful if the receiving node’s software has armed the buffer for it, and a node that is late in its own processing can miss a frame that the bus delivered correctly. The protocol’s answer is the same as the transmitter’s: the receive buffers are part of the schedule, and the software must be structured so that the buffer for a slot is available before the slot begins. That constraint propagates into the task design, and it is why time-triggered systems tend to have a static task schedule as well as a static communication schedule. The software side of that schedule is then argued through the objectives and evidence that DO-178C Objectives and Structural Coverage describes for the airborne case, where the schedule itself becomes a requirement rather than an implementation detail.

The bus does not make the system safe; it makes the communication analysable. A time-triggered schedule gives a bound on latency and a bound on jitter, and those bounds feed the end-to-end timing analysis that the safety case needs. Everything else, including the sensor’s sampling, the actuator’s response, and the software’s own execution time, has to be bounded separately. The bus is one link in a chain whose total is the subject of Worst-Case Execution Time Analysis and Its Uses, and a chain is only as strong as its least analysed link.