Electronics Guide

Timing Requirements

Real-time systems are characterized by their temporal constraints:

• Hard real-time: Missing a deadline constitutes system failure. Examples include airbag deployment signals and anti-lock braking commands where late delivery is as bad as no delivery.
• Firm real-time: Late data has no value but does not cause system failure. Sensor readings that arrive after a control loop iteration completes are discarded.
• Soft real-time: Late data has diminished value but remains useful. Audio and video streaming tolerate occasional delays with graceful degradation.

Key timing metrics for real-time communication include:

• Latency: Time from message transmission to reception, including queuing, transmission, propagation, and processing delays
• Jitter: Variation in latency between successive messages, critical for periodic data streams
• Deadline: Maximum acceptable latency for message delivery
• Period: Interval between successive transmissions of periodic messages

Determinism and Predictability

Deterministic communication guarantees bounded worst-case latency, enabling system designers to verify that all timing requirements will be met under all operating conditions. Achieving determinism requires controlling or eliminating sources of timing variability.

Sources of non-determinism in communication systems include:

• Contention: Multiple nodes competing for shared media creates variable queuing delays
• Arbitration: Priority-based arbitration can delay low-priority messages indefinitely
• Error recovery: Retransmission after errors introduces variable delays
• Protocol overhead: Variable-length headers and acknowledgments affect timing
• Clock drift: Unsynchronized clocks cause scheduling variations across nodes

Real-time protocols address these issues through various mechanisms including time-triggered scheduling, traffic shaping, and global time synchronization.

Event-Triggered vs. Time-Triggered Communication

Two fundamental paradigms govern real-time communication architectures:

Event-triggered systems transmit messages in response to events such as sensor threshold crossings or state changes. This approach efficiently utilizes bandwidth by transmitting only when necessary but can lead to unpredictable bus load and potential message collisions during simultaneous events.

Time-triggered systems transmit messages according to predetermined schedules synchronized across all network nodes. While potentially less bandwidth-efficient, time-triggered communication provides inherent determinism since the timing of every message is known at design time.

Many modern real-time networks combine both approaches, using time-triggered slots for critical periodic data while allowing event-triggered communication during designated windows for asynchronous messages.

Time-Triggered Architecture

The Time-Triggered Architecture (TTA) developed by Hermann Kopetz provides a comprehensive framework for building fault-tolerant real-time systems. Central to TTA is the concept of a global time base that synchronizes all system components.

Key principles of time-triggered design include:

• Temporal firewalls: Strict timing boundaries prevent faults in one component from propagating timing disturbances to others
• Composability: System components can be integrated and verified independently, with predictable combined behavior
• Deterministic message schedules: Every message has a predetermined transmission time known at design time
• Sparse time base: Discrete time representation simplifies reasoning about temporal properties

TTA systems typically organize communication into recurring cycles where each node has assigned slots for transmission. The schedule repeats predictably, enabling straightforward worst-case timing analysis.

Time-Triggered Protocol (TTP)

The Time-Triggered Protocol implements TTA principles for safety-critical distributed systems. TTP provides deterministic communication with integrated fault tolerance for applications requiring the highest reliability levels.

TTP characteristics include:

• TDMA-based access: Time Division Multiple Access ensures collision-free communication
• Synchronized global time: Fault-tolerant clock synchronization maintains tight time alignment across nodes
• Bus guardian: Independent hardware prevents nodes from transmitting outside their assigned slots
• Membership service: Consistent agreement on which nodes are operational
• Implicit acknowledgment: Subsequent transmissions confirm successful reception without explicit ACK frames

TTP supports dual-channel configurations for fault tolerance, with independent buses and guardians ensuring continued operation despite single points of failure. The protocol has been certified for safety-critical applications including aerospace fly-by-wire systems.

Time-Triggered CAN

Time-Triggered CAN (TTCAN) extends the Controller Area Network protocol with time-triggered capability while maintaining backward compatibility with standard CAN. Defined in ISO 11898-4, TTCAN adds a time reference mechanism and scheduled transmission windows to CAN's event-triggered foundation.

TTCAN operation is based on:

• Reference messages: A time master periodically broadcasts reference messages that synchronize all nodes and mark the start of communication cycles
• Basic cycle: Fixed-duration interval divided into exclusive, arbitrating, and free windows
• Exclusive windows: Time slots assigned to specific messages, guaranteeing collision-free transmission
• Arbitrating windows: Standard CAN arbitration for event-triggered messages
• System matrix: Complete schedule of exclusive windows repeating over multiple basic cycles

TTCAN achieves determinism for critical messages in exclusive windows while preserving CAN's flexibility for non-critical communication. This hybrid approach enables gradual migration from event-triggered to time-triggered operation.

Challenges with Standard Ethernet

Traditional Ethernet presents several challenges for real-time communication:

• Non-deterministic latency: CSMA/CD collision detection and binary exponential backoff create unbounded delays
• Switch queuing: Variable queue depths in switches introduce unpredictable latency
• Best-effort service: No mechanisms for traffic prioritization or bandwidth reservation
• Lack of synchronization: No built-in time synchronization between network nodes

Full-duplex switched Ethernet eliminates collisions but does not address queuing delays or provide timing guarantees. Real-time Ethernet solutions add scheduling, synchronization, and traffic management mechanisms to achieve determinism.

IEEE 802.1 Time-Sensitive Networking

Time-Sensitive Networking (TSN) is a set of IEEE 802.1 standards that add real-time capabilities to Ethernet. TSN provides a unified solution for converged networks carrying both time-critical and best-effort traffic.

Key TSN standards include:

• IEEE 802.1AS (gPTP): Generalized Precision Time Protocol provides sub-microsecond time synchronization across the network
• IEEE 802.1Qbv (Time-Aware Shaper): Gate-controlled scheduling opens and closes queues according to predetermined schedules
• IEEE 802.1Qbu/802.3br (Frame Preemption): Allows high-priority frames to interrupt lower-priority transmissions
• IEEE 802.1Qcc (Stream Reservation Protocol): Centralized or distributed configuration of reserved streams
• IEEE 802.1Qch (Cyclic Queuing and Forwarding): Cycle-based forwarding for bounded latency
• IEEE 802.1CB (Frame Replication and Elimination): Seamless redundancy through duplicate frame transmission

TSN enables coexistence of deterministic traffic with standard Ethernet communication, making it attractive for industrial automation, automotive, and professional audio/video applications where real-time and non-real-time devices share network infrastructure.

EtherCAT

EtherCAT (Ethernet for Control Automation Technology) achieves exceptional real-time performance through a unique processing-on-the-fly architecture. Developed by Beckhoff Automation, EtherCAT is widely used in industrial automation and motion control applications.

EtherCAT's distinctive features include:

• Processing on the fly: Slave devices read and insert data as frames pass through, minimizing latency
• Single frame efficiency: One Ethernet frame can address hundreds of devices, reducing protocol overhead
• Distributed clocks: Sub-microsecond synchronization enables precise coordinated motion
• Flexible topology: Supports line, tree, and star configurations
• Standard Ethernet frames: Uses standard Ethernet frame format, enabling integration with conventional networks

EtherCAT achieves cycle times under 100 microseconds with thousands of I/O points, meeting the most demanding industrial control requirements. The protocol handles both cyclic process data and acyclic mailbox communication for configuration and diagnostics.

PROFINET IRT

PROFINET Isochronous Real-Time (IRT) extends the PROFINET industrial Ethernet standard with deterministic communication capability. IRT provides guaranteed cycle times for motion control and other applications requiring precise synchronization.

PROFINET IRT features:

• Reserved bandwidth: Dedicated time slots for IRT communication guarantee deterministic delivery
• Isochronous operation: Synchronized execution of control tasks across distributed devices
• Dynamic frame packing: Efficient bandwidth utilization through optimized frame structures
• Coexistence: IRT, real-time, and standard Ethernet traffic share the same network

IRT achieves cycle times down to 31.25 microseconds with jitter below 1 microsecond, supporting demanding applications such as high-speed packaging machines and synchronized multi-axis drives.

TTEthernet

TTEthernet (Time-Triggered Ethernet) combines time-triggered determinism with Ethernet's flexibility, developed for aerospace and safety-critical applications. TTEthernet supports three traffic classes with different timing characteristics.

Traffic classes in TTEthernet:

• Time-triggered (TT): Scheduled transmission at precise times with minimal jitter, suitable for control loops
• Rate-constrained (RC): Guaranteed bandwidth with bounded latency for periodic data
• Best-effort (BE): Standard Ethernet traffic using remaining bandwidth

TTEthernet has been adopted for aerospace applications including the NASA Orion spacecraft and Boeing 787 flight control systems, demonstrating its suitability for the most demanding safety-critical environments.

Enhanced Capabilities

CAN FD provides significant improvements over classical CAN:

• Increased payload: Maximum data field expanded from 8 bytes to 64 bytes, reducing the number of messages needed for large data transfers
• Higher data rate: Data phase bit rate can exceed arbitration phase rate, up to 8 Mbps in typical implementations
• Improved efficiency: Larger payloads reduce protocol overhead percentage for data transmission
• Stronger error detection: 17-bit or 21-bit CRC provides better coverage than classical CAN's 15-bit CRC

The flexible data rate concept allows CAN FD to use different bit rates for different frame portions. Arbitration occurs at classical CAN speeds for compatibility, while the data phase can operate much faster when the bus is controlled by a single transmitter.

Frame Structure

CAN FD frames include new fields and modified formats compared to classical CAN:

• FDF bit: Distinguishes CAN FD frames from classical CAN frames
• BRS bit: Bit Rate Switch indicates whether to use higher data phase bit rate
• ESI bit: Error State Indicator shows transmitter error state
• Extended DLC: Data length codes above 8 encode specific larger payload sizes (12, 16, 20, 24, 32, 48, 64 bytes)

The transition between arbitration and data phase bit rates is carefully managed through bit timing parameters to ensure reliable communication across varying cable lengths and node counts.

Real-Time Performance

CAN FD improves real-time performance through reduced transmission times and better bandwidth utilization:

• Lower latency: Higher bit rates during data phase reduce message transmission time
• Reduced bus load: Fewer messages needed for equivalent data throughput
• Better determinism: Faster transmission times improve worst-case latency analysis
• Priority preservation: Classical CAN arbitration mechanism maintained for consistent priority handling

For hard real-time applications, CAN FD's improved throughput enables more frequent sensor updates or transmission of larger control data sets within timing constraints.

Implementation Considerations

Deploying CAN FD requires attention to hardware and network design:

• Transceiver selection: CAN FD transceivers must support fast edge rates for high-speed data phase operation
• Network topology: Higher bit rates are more sensitive to reflections, requiring careful attention to stub lengths and termination
• Clock tolerance: Tighter oscillator requirements for reliable high-speed operation
• Mixed networks: Classical CAN nodes can coexist but cannot receive CAN FD frames

Migration strategies typically involve upgrading critical nodes to CAN FD while maintaining classical CAN compatibility for non-critical devices during transition periods.

Protocol Architecture

FlexRay operates at 10 Mbps per channel with support for dual redundant channels. The communication cycle structure provides both deterministic and flexible communication:

• Static segment: Time-triggered slots assigned to specific messages, providing guaranteed transmission times
• Dynamic segment: Event-triggered mini-slots for flexible, priority-based communication
• Symbol window: Special symbols for network management functions
• Network idle time: Period for clock synchronization and error handling

The static segment uses Time Division Multiple Access (TDMA) where each node has exclusive access during assigned slots. The dynamic segment uses Flexible TDMA (FTDMA), allocating bandwidth dynamically based on demand while maintaining bounded latency.

Clock Synchronization

FlexRay achieves tight synchronization across all network nodes through a distributed clock synchronization algorithm:

• Sync frames: Designated nodes transmit synchronization frames in static slots
• Measurement: All nodes measure arrival times of sync frames relative to their local clocks
• Correction: Rate and offset corrections maintain global time alignment
• Fault tolerance: Algorithm tolerates faulty sync frames through median filtering

Typical synchronization precision is within 1 microsecond across the network, enabling coordinated actuator control for applications such as active suspension systems.

Fault Tolerance

FlexRay incorporates multiple fault tolerance mechanisms essential for safety-critical applications:

• Dual channel: Two independent communication channels provide redundancy
• Bus guardians: Independent hardware ensures nodes transmit only in assigned slots
• Frame and bit CRC: Error detection at both frame and header levels
• Startup and wakeup: Defined procedures for network initialization and recovery

Channel redundancy can be configured for fault tolerance (both channels carry identical data) or bandwidth optimization (different data on each channel). Applications can switch configurations dynamically based on detected faults.

Automotive Applications

FlexRay found primary application in premium vehicle platforms for systems requiring high bandwidth and deterministic timing:

• Active suspension: Coordinated control of multiple dampers requires synchronized, low-latency communication
• Steer-by-wire: Safety-critical steering systems demand guaranteed message delivery
• Brake-by-wire: Electronic braking requires fault-tolerant, deterministic communication
• Adaptive chassis: Integration of multiple chassis systems benefits from FlexRay's bandwidth

While FlexRay achieved significant adoption in luxury vehicles, CAN FD and emerging automotive Ethernet solutions have influenced the direction of new vehicle network architectures.

Timing Analysis

Worst-case timing analysis verifies that all messages meet their deadlines:

• Response time analysis: Calculate maximum latency for each message considering interference from higher-priority traffic
• Schedulability analysis: Verify that the message set is schedulable given bandwidth constraints
• Network calculus: Mathematical framework for analyzing queuing and delay bounds
• Simulation: Validate analysis through simulation of worst-case scenarios

For time-triggered systems, timing analysis confirms that the static schedule meets all constraints. For event-triggered systems, analysis must account for worst-case message arrival patterns.

Priority Assignment

In priority-based systems, correct priority assignment is critical for meeting timing requirements:

• Rate monotonic: Assign higher priority to messages with shorter periods
• Deadline monotonic: Assign higher priority to messages with shorter deadlines
• Application requirements: Safety-critical messages may require elevated priority regardless of timing characteristics

Priority inversion, where low-priority messages block high-priority ones, must be avoided through careful design of communication patterns and protocol selection.

Redundancy and Fault Tolerance

Safety-critical applications require communication systems that continue operating despite component failures:

• Channel redundancy: Dual or triple redundant buses ensure continued communication if one channel fails
• Node redundancy: Critical functions replicated across multiple nodes
• Message redundancy: Duplicate transmissions or error correction codes protect against message loss
• Guardian mechanisms: Independent watchdogs prevent faulty nodes from disrupting communication

Redundancy design must consider common-mode failures that could affect multiple redundant elements simultaneously.

Clock Synchronization

Synchronized clocks across network nodes enable coordinated actions and simplify timing analysis:

• Synchronization protocols: IEEE 1588 PTP, IEEE 802.1AS, or protocol-specific mechanisms
• Precision requirements: Tighter synchronization enables shorter guard times between slots
• Fault tolerance: Synchronization must be maintained despite faulty or malicious time sources
• Initialization: Procedures for establishing synchronization during network startup

Time-triggered protocols inherently require clock synchronization, while event-triggered protocols may use synchronization for timestamping and diagnostic purposes.