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. Standardized by SAE International as AS6003, 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 operates over two independent channels at bit rates up to 25 Mbit/s per channel, with commercial controllers commonly deployed at 5 and 20 Mbit/s. Dual-channel operation with independent bus guardians allows the network to survive the loss of a channel or the failure of a single node.

The protocol has been certified to Design Assurance Level A and deployed in commercial aircraft systems, including power generation and environmental control on the Boeing 787, cabin pressure control on the Airbus A380, and distributed controls on the Bombardier CSeries and Embraer Legacy families.

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 access: In legacy half-duplex segments, CSMA/CD collision detection and binary exponential backoff create unbounded access delays
• Switch queuing: Variable queue depths in switches introduce unpredictable latency, and a single 1,522-byte frame already occupies a 100 Mbit/s port for roughly 123 microseconds
• Best-effort service: Priority tagging alone offers no bandwidth reservation and no bound on interference from same-priority traffic
• 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. Once several talkers converge on one egress port, buffering rather than media access becomes the dominant source of jitter. Real-time Ethernet solutions therefore add scheduling, synchronization, and traffic policing on top of the standard physical layer.

IEEE 802.1 Time-Sensitive Networking

Time-Sensitive Networking (TSN) is a family of IEEE 802.1 mechanisms that add real-time capabilities to bridged Ethernet. TSN provides a unified solution for converged networks carrying both time-critical and best-effort traffic. The individual amendments were developed separately and have since been rolled into the base bridging standard, so current implementations reference IEEE 802.1Q-2022 rather than the original amendment documents. Engineers still use the amendment letters as shorthand for the features.

Key TSN mechanisms include:

• IEEE 802.1AS (gPTP): Generalized Precision Time Protocol, a profile of IEEE 1588, distributes a common time base with sub-microsecond accuracy across the bridged network
• 802.1Qav (Credit-Based Shaper): Smooths reserved streams by metering each queue against an accumulating credit, bounding burst size
• 802.1Qbv (Time-Aware Shaper): Gate-controlled scheduling opens and closes egress queues according to a repeating, time-synchronized gate control list
• 802.1Qbu with IEEE 802.3br: Frame preemption lets an express frame interrupt a preemptable frame in mid-transmission, cutting worst-case blocking from a full maximum-size frame to a fragment
• 802.1Qcc: Stream reservation enhancements and the fully centralized, centralized-network, and distributed configuration models
• 802.1Qch (Cyclic Queuing and Forwarding): Cycle-based forwarding that bounds latency by hop count rather than by detailed per-stream analysis
• 802.1Qci (Per-Stream Filtering and Policing): Blocks babbling or misbehaving talkers before their traffic disturbs scheduled streams
• IEEE 802.1CB (Frame Replication and Elimination): Seamless redundancy by sending duplicate frames over disjoint paths and discarding the later copy

No system uses every mechanism. Industry profiles select the subset appropriate to a domain, such as the IEC/IEEE 60802 work for industrial automation and IEEE 802.1DG for automotive in-vehicle networks. Because TSN allows deterministic traffic to coexist with ordinary Ethernet on shared infrastructure, it is attractive wherever real-time controllers, engineering workstations, and cameras must share one cable plant.

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

Because each slave introduces well under one microsecond of forwarding delay, EtherCAT can update 1,000 distributed I/O points in roughly 30 microseconds and service 100 servo axes in about 100 microseconds, 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.

EtherNet/IP

EtherNet/IP, managed by ODVA, takes the opposite approach to EtherCAT: rather than modifying how frames traverse the network, it carries the Common Industrial Protocol over ordinary TCP/IP and UDP/IP on unmodified Ethernet hardware. Cyclic process data travels as UDP implicit messages, while configuration and diagnostics use TCP explicit messaging.

Real-time behavior comes from two extensions. CIP Sync distributes an IEEE 1588 time base so that distributed devices can act on a common clock, and CIP Motion builds on it to schedule drive updates against absolute timestamps rather than message arrival. ODVA has since aligned EtherNet/IP with TSN, which supplies the bounded latency the underlying network previously lacked.

The trade-off is clear: EtherNet/IP interoperates readily with plant information systems and standard switches, but it does not reach the cycle times of EtherCAT or PROFINET IRT without TSN-capable infrastructure.

AFDX (ARINC 664 Part 7)

Avionics Full-Duplex Switched Ethernet (AFDX) applies deterministic discipline to switched Ethernet through bandwidth policing rather than global scheduling. Developed by Airbus and standardized as ARINC 664 Part 7, it replaced the point-to-point ARINC 429 wiring of earlier aircraft with a switched network running at 100 Mbit/s per port.

Determinism in AFDX rests on the virtual link:

• Virtual links: Each virtual link is a unidirectional logical path from one transmitting end system to a fixed set of receivers, configured offline
• Bandwidth allocation gap: The minimum interval between consecutive frames on a virtual link, restricted to powers of two from 1 to 128 milliseconds
• Maximum frame size: A per-link frame ceiling that, together with the bandwidth allocation gap, caps the bandwidth any one link can consume
• Switch policing: Switches enforce the contract, so a faulty end system cannot starve other traffic
• Dual redundancy: Each end system transmits identical frames on two physically independent networks; receivers accept the first valid copy and discard the duplicate

Because bandwidth is reserved rather than scheduled to the microsecond, AFDX yields bounded latency without requiring network-wide clock synchronization. That relaxation simplifies certification and integration, at the cost of coarser timing resolution than a time-triggered network provides. AFDX carries the avionics backbone on the Airbus A380, A350, and A400M, and closely related switched Ethernet networks serve the same role on the Boeing 787.

TTEthernet

TTEthernet (Time-Triggered Ethernet), standardized by SAE International as AS6802, combines time-triggered determinism with Ethernet's flexibility for aerospace and safety-critical applications. It supports three traffic classes with different timing characteristics that share the same physical network.

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 demanding aerospace applications, most notably as the onboard data network of the NASA Orion spacecraft, demonstrating its suitability for the most safety-critical environments. The ability to carry scheduled control traffic and best-effort data on a single converged network reduces wiring mass and integration cost relative to maintaining separate buses.

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: The data phase bit rate can exceed the arbitration phase rate. Conventional transceivers and bus-line topologies support roughly 2 to 5 Mbit/s; signal improvement capability transceivers specified in CiA 601-4 suppress topology-induced ringing and extend practical operation to 5 or 8 Mbit/s
• 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: A classical CAN controller cannot decode a CAN FD frame and will signal an error, disturbing the bus. Only CAN FD-tolerant controllers, which ignore such frames instead of flagging them, coexist safely on a mixed segment

Migration strategies typically involve upgrading critical nodes to CAN FD while maintaining classical CAN compatibility for non-critical devices during transition periods. Because a CAN FD frame carrying 64 bytes occupies the bus far longer than an 8-byte classical frame, the worst-case blocking time seen by a high-priority message grows, and response time analysis must be rerun rather than assumed to improve.

CAN XL

CAN XL is the third generation of the protocol, specified by CAN in Automation in the CiA 610 series and incorporated into ISO 11898-1:2024. It targets the gap between CAN FD and 10BASE-T1S automotive Ethernet, where designers previously had to choose between insufficient bandwidth and a full Ethernet stack.

• Payload: Data fields from 1 to 2,048 bytes, large enough to carry an Ethernet frame as a tunneled payload
• Bit rate: Pulse-width modulated coding in the data phase supports 20 Mbit/s and above, depending on physical network design
• Arbitration compatibility: The arbitration phase retains classical CAN behavior, preserving priority-based, non-destructive bus access
• Service data unit type: A header field identifies the payload format, allowing CAN XL to transport higher-layer protocols directly

For real-time design, CAN XL preserves the familiar priority model and its associated response time analysis while shortening transmission times, which relieves bus load without forcing a change of scheduling paradigm.

Protocol Architecture

FlexRay operates at 10 Mbit/s per channel with support for two channels that can be wired for redundancy or aggregated for higher throughput. Communication proceeds in a repeating cycle, typically a few milliseconds long, divided into four parts:

• 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

FlexRay achieved meaningful adoption in premium platforms, notably at BMW and Audi, but its cost and configuration complexity limited broader uptake. New vehicle architectures now more often pair CAN FD for cost-sensitive control traffic with automotive Ethernet for high-bandwidth and backbone roles, leaving FlexRay largely confined to existing platforms rather than new designs.

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; the schedule itself is the proof, and verification reduces to checking that every slot is long enough and that the hyperperiod closes. For event-triggered systems, analysis must account for worst-case message arrival patterns. On a priority-arbitrated bus such as CAN, the worst-case response time of a message combines three terms: the blocking time imposed by one lower-priority frame that has already started transmitting, the interference from every higher-priority message that can be queued during the busy period, and the frame's own transmission time. Because the blocking term depends on the longest frame on the bus, adding a single long low-priority message can push an unrelated high-priority message past its deadline.

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.

Bandwidth Margin and Guard Times

Real-time networks are not run at full capacity. Two forms of headroom are budgeted deliberately:

• Bus load margin: Event-triggered buses are commonly designed to a nominal load well below saturation so that error retransmissions and burst arrivals do not cascade into missed deadlines. Automotive CAN networks are frequently specified to stay under roughly half of theoretical capacity in normal operation
• Guard times: Time-triggered schedules insert idle intervals between slots to absorb the residual clock offset between nodes. The guard time must exceed the worst-case synchronization error, so tighter synchronization directly buys usable bandwidth
• Growth allowance: Vehicle and machine programs add signals throughout their life, so schedules and identifier ranges are laid out with room for later additions

Margin is also a diagnostic asset. A network engineered with headroom degrades gracefully and gives measurable warning as load climbs, whereas a fully loaded network fails abruptly and intermittently.

Selecting a Protocol

No single protocol suits every real-time problem. The practical trade-offs run as follows:

• Required cycle time: Millisecond-class control tolerates CAN FD or rate-constrained Ethernet; coordinated motion in the tens of microseconds points to EtherCAT, PROFINET IRT, or a scheduled TSN network
• Fault tolerance and certification: Applications requiring redundancy, membership agreement, and a certification argument favor TTP, TTEthernet, AFDX, or FlexRay, all of which build fault containment into the protocol rather than the application
• Traffic mix: A network that must carry control loops alongside camera streams and diagnostics argues for TSN or TTEthernet, which isolate traffic classes on shared infrastructure
• Cost and ecosystem: CAN FD transceivers, connectors, and tooling remain far cheaper than Ethernet equivalents, which keeps CAN dominant for low-bandwidth distributed sensing and actuation
• Change tolerance: Static schedules must be regenerated and revalidated whenever the message set changes; priority-based buses accommodate late additions more easily, at the cost of weaker timing guarantees

Most substantial systems use several protocols in a hierarchy, with a deterministic backbone connecting subnetworks chosen for the requirements of each domain, and gateways translating between them.