Time-Triggered Architecture (TTA) in Functional Safety

Time-Triggered Architecture (TTA) is a distributed real-time design approach where all computation and communication are initiated at predefined times derived from a common global clock. It delivers deterministic, bounded-latency message transport — making it a powerful technique for controlling systematic failures in safety-related systems under IEC 61508.

What is Time-Triggered Architecture?

In TTA, each node follows a static, precomputed schedule that allocates fixed time slots on the network using time-division multiple access (TDMA). Instead of reacting to unpredictable events, the system executes by schedule.

This yields deterministic message delivery with bounded latency and minimal jitter, simplifying timing analysis and certification. Protocol realisations include historic TTP/C, the static segment of FlexRay, and Time-Triggered Ethernet (SAE AS6802).

How it supports functional safety

TTA tackles systematic failures by enforcing temporal determinism and well-defined interfaces ("temporal firewalls"), which prevent hidden couplings and uncontrolled interactions between software components.

Fault-tolerant clock synchronisation and membership services make node failures explicit and contained — a faulty node cannot disturb the rest of the cluster beyond its own outputs.

While aimed at systematic control, the architecture also exposes manifestations of random or common-cause hardware faults (e.g. clock drift, corrupt frames) through time checks and consistency monitoring, so the safety function does not silently act on bad data.

The key question is: can you prove that every safety-critical message arrives within its deadline — and that a faulty node cannot disturb the rest of the system?

When to use

• You need deterministic, bounded-latency communication for closed-loop control with tight jitter budgets
• You require transparent, certifiable fault tolerance and strong fault isolation between nodes
• You want composability — adding or modifying applications without destabilising unrelated parts of the system

Inputs and outputs

Inputs

• Globally synchronised time base and synchronisation parameters
• Static TDMA schedule (slots, cycle length, message mapping) and node timing budgets

Outputs

• Deterministic message transport with known latency and jitter bounds
• Membership and fault-isolation information and diagnostics tied to the global time

Procedure

1. Derive timing requirements. Define periods, deadlines, end-to-end latencies, and jitter limits for each control loop and message.
2. Construct the static schedule. Allocate TDMA slots and cycle structure. Include slack for growth and recovery.
3. Configure synchronisation and services. Set clock sync parameters, membership thresholds, and error-containment rules (temporal firewalls).
4. Verify and validate. Perform worst-case timing analysis, fault-injection (missed slot, late or omitted frame), and demonstrate the safe reaction.

Worked example — steer-by-wire system

An automotive steer-by-wire system runs on a TTA network. The primary ECU publishes steering angle every 5 ms in its reserved slot; the backup ECU publishes health state in its own slot.

If the primary misses its slot or its frame fails checks, membership removes it from the trusted set and the backup takes control — preventing uncontrolled steering commands.

Code-level example

// Pseudo-C for time-triggered message handling (FlexRay/TTEthernet style)

#define SLOT_STEER_TX  3
#define CYCLE_MS       5

void app_cycle(uint64_t global_time_ticks) {
    if (is_my_slot(global_time_ticks, SLOT_STEER_TX)) {
        msg_t m = make_msg(STEER_ID, read_angle_sensor(), local_health());
        send_in_slot(SLOT_STEER_TX, m);
        // SAFE REACTION (sender): if can't meet window, skip transmit to preserve bus silence
    }

    msg_t rx = receive(STEER_ID);
    if (rx.valid && rx.fresh && in_time_window(rx.timestamp, CYCLE_MS)) {
        steering_angle = rx.value;
        last_good_time = now();
    } else {
        // SAFE REACTION (receiver): hold last known safe value
        // If stale >= 20 ms, request takeover
        if (now() - last_good_time >= 20_ms) {
            request_backup_takeover();   // enter safe state for primary path
        }
    }

    if (!membership_is_trusted(PRIMARY_ECU)) {
        engage_backup_controller();      // SAFE REACTION: controlled switchover
    }
}

Result: Steering commands are deterministic and bounded in latency. Faulty or late frames are contained and trigger defined safe reactions, preserving controllability.

Quality criteria

• Proven determinism: All end-to-end deadlines and jitter limits verified under worst-case load and fault conditions.
• Error containment: A faulty node cannot affect timing or correctness of others beyond its outputs.
• Composability: Adding or modifying applications does not force unrelated schedule or interface changes.

Common pitfalls

Over-rigid schedules

Static schedules that leave no room for future changes make upgrades painful and risky.

Poor handling of sporadic events

Pure time-triggered designs struggle with asynchronous alarms that need fast response.

Frequently asked questions

Is TTA only for aerospace?

No. The concepts are widely applied in automotive (e.g. FlexRay static segment), rail, and industrial control — wherever deterministic timing and fault isolation are essential.

How do I handle urgent sporadic events?

Use a mixed architecture: keep safety-critical control loops on the time-triggered schedule and add a bounded, event-triggered channel (with admission control) for alarms. Specify and test the safe reaction if the event channel is delayed or unavailable.

Related techniques

• Cyclic Redundancy Check (CRC) — protects frame data integrity within time-triggered messages
• Redundancy and diversity — complements TTA with independent lanes and fail-operational behaviour

References

• Kopetz, H.; Bauer, G. — "The Time-Triggered Architecture," Proceedings of the IEEE, 2002
• Rushby, J. — "An Overview of Formal Verification for the Time-Triggered Architecture," LNCS 2469, 2002
• SAE AS6802 — Time-Triggered Ethernet

---