Time-Triggered Architecture (TTA)
What is it?
TTA is a design approach for distributed embedded systems in which all computation and communication are initiated at predefined times derived from a common global clock. Instead of reacting to unpredictable events, each node follows a static, precomputed schedule that allocates fixed time slots on the network (time-division multiple access, TDMA). This yields deterministic message delivery with bounded latency and minimal jitter, simplifying timing analysis and certification. Protocol realizations 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 synchronization and membership services make node failures explicit and contained, so 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/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.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 destabilizing unrelated parts of the system.
Inputs & Outputs
Inputs
- Globally synchronized time base and synchronization parameters.
- Static TDMA schedule (slots, cycle length, message mapping) and node timing budgets.
Outputs
- Deterministic message transport with known latency/jitter bounds.
- Membership/fault-isolation information and diagnostics tied to the global time.
Procedure
- Derive timing requirements: periods, deadlines, end-to-end latencies, and jitter limits for each control loop/message.
- Construct the static schedule: allocate TDMA slots and cycle structure; include slack for growth and recovery.
- Configure synchronization & services: clock sync parameters, membership thresholds, and error-containment (temporal firewalls).
- Verify & validate: perform worst-case timing analysis, fault-injection (missed slot, late/omitted frame), and demonstrate the safe reaction.
Worked Example
High-level
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
// 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/modifying applications does not force unrelated schedule or interface changes.
Common pitfalls
- Over-rigid schedules make upgrades painful — Mitigation: reserve slack slots and follow change-control with re-analysis criteria.
- Poor handling of sporadic events (alarms) — Mitigation: add a small event-triggered channel or mixed ET/TT design with bounded impact.
References
FAQ
Is TTA only for aerospace?
No. The concepts are widely applied in automotive (e.g., FlexRay static segment), rail, and industrial control where 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—then specify and test the safe reaction if the event channel is delayed or unavailable.