Real-Time Networking: CAN, Time-Sensitive Networking (TSN) and Wireless with Guarantees

A real-time system is only as predictable as its slowest link. A brake-by-wire controller can meet every CPU deadline and still fail if the message carrying the pedal position arrives late. Distributed control loops in cars, aircraft, factories and robots depend on networks that offer timing guarantees, not just high average throughput. This article looks at three generations of technology for providing them: the Controller Area Network (CAN) and its successors, Time-Sensitive Networking (TSN) over Ethernet, and wireless protocols that try to bring determinism to an inherently unreliable medium.

What a network timing guarantee means

For a periodic or sporadic message stream, the key quantity is the worst-case response time: the longest time from when a message is queued for transmission until it has been completely received. Related metrics are jitter (latency variation) and, for wireless, the delivery ratio within a deadline.

End-to-end latency in a distributed system adds up stages: the sending task’s response time, queuing and transmission on one or more network segments, and the receiving task’s response time. Each stage can be analyzed with techniques similar to those for CPUs, as in our response-time analysis worked example. The stages interact through release jitter: variability in one stage becomes jitter for the next.

CAN: priority arbitration on a shared bus

CAN, developed by Bosch in the 1980s and standardized as ISO 11898, remains the backbone of automotive and industrial control networks. Every frame begins with an identifier. During arbitration, nodes transmit identifier bits simultaneously, and a dominant bit (0) overwrites a recessive bit (1) on the wired-AND bus. A node that sends recessive but reads dominant has lost and stops transmitting, so the lowest identifier wins without corrupting the frame. The bus therefore acts as a global, non-preemptive, fixed-priority scheduler, where the identifier is the priority.

Frame times

To guarantee a message, you need its worst-case transmission time. Bit stuffing (a complementary bit inserted after five identical bits) lengthens frames depending on content. For classic CAN with 11-bit identifiers and s data bytes, the worst-case frame length used in the revised analysis is:

C = (g + 8s + 13 + ⌊(g + 8s − 1) / 4⌋) · τ_bit      g = 34 (11-bit ID), 54 (29-bit ID)

8 data bytes, 11-bit ID:  34 + 64 + 13 + 24 = 135 bits
at 500 kbit/s (τ_bit = 2 µs):  C = 270 µs

Response-time analysis, refuted and revised

Tindell and Burns published the first CAN schedulability analysis in 1994. It was widely used in industry tools for over a decade. In 2007, Davis, Burns, Bril and Lukkien showed that the original analysis could be optimistic. Because transmission is non-preemptive, a message’s busy period can extend beyond its period, and a later instance of the same message can then have a longer response time than the first. The corrected analysis checks every instance within the busy period. It also gives a simple sufficient variant that takes blocking as the longest frame among messages of lower or equal priority:

from math import ceil
BIT = 2.0                                   # µs per bit at 500 kbit/s

def frame_time(n, g=34):                    # worst-case classic CAN frame
    return (g + 8*n + 13 + (g + 8*n - 1) // 4) * BIT

# (name, ID, data bytes, period = deadline [µs], queuing jitter [µs])
msgs = sorted([("brake", 0x100, 8,  5000, 0), ("steer", 0x200, 8, 10000, 0),
               ("status", 0x300, 4, 10000, 0), ("diag", 0x400, 8, 20000, 0)],
              key=lambda m: m[1])           # lower ID = higher priority

for i, (name, _, n, T, J) in enumerate(msgs):
    C = frame_time(n)
    B = max(frame_time(m[2]) for m in msgs[i:])     # lower-or-equal priority
    w = B
    while True:
        w_next = B + sum(ceil((w + m[4] + BIT) / m[3]) * frame_time(m[2])
                         for m in msgs[:i])
        if w_next == w or w_next > T:
            break
        w = w_next
    print(name, "R =", J + w_next + C, "µs")   # 540, 810, 1000, 1270

Queuing jitter often dominates in practice. It is caused by the sending task’s response-time variation and by gateway software, and it enters the formula directly. So does the transmit-buffer design: a controller that can’t abort a lower-priority frame waiting in its hardware buffer introduces priority inversion that the textbook model doesn’t capture.

CAN FD and CAN XL

CAN FD keeps the arbitration phase at classic bit rates but switches to a faster data phase (commonly 2–5 Mbit/s) and allows up to 64 data bytes. CAN XL, specified by CAN in Automation and incorporated into the latest revision of ISO 11898-1, raises the data phase further and allows payloads of up to 2048 bytes. Both keep identifier-based arbitration, so the same analysis framework applies with adjusted frame-time formulas. On Linux, SocketCAN configures all of them:

# Classic CAN at 500 kbit/s
ip link set can0 type can bitrate 500000
ip link set can0 up

# CAN FD: 500 kbit/s arbitration, 2 Mbit/s data phase
ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on

# Observe traffic (can-utils)
candump -td can0

Time-Sensitive Networking: deterministic Ethernet

Ethernet offers bandwidth that CAN cannot, but standard switched Ethernet gives no latency bound: a long best-effort frame or a queue build-up can delay a critical frame unpredictably. TSN, developed by the IEEE 802.1 TSN Task Group (successor of the Audio Video Bridging group), adds the missing mechanisms as amendments, most now consolidated into IEEE 802.1Q.

Scheduled traffic in practice

With 802.1Qbv, each egress port cycles through a gate control list. Within each cycle, a window is reserved exclusively for time-critical traffic. Shared 802.1AS time lets these windows be aligned along a path, so latency is set by the schedule, not by contention. A guard band before each protected window prevents a best-effort frame from overrunning it, and frame preemption shrinks that guard band. Linux implements the time-aware shaper in the taprio queuing discipline, with hardware offload on supporting NICs:

# Sync the NIC's hardware clock with gPTP (linuxptp)
ptp4l -i eth0 -f gPTP.cfg -m &
phc2sys -s eth0 -c CLOCK_REALTIME -w -m &

# 1 ms cycle: 300 µs for TC0, 300 µs for TC1, 400 µs for TC2 (intervals in ns)
tc qdisc replace dev eth0 parent root handle 100 taprio 
    num_tc 3 
    map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 
    queues 1@0 1@1 2@2 
    base-time 1000000000 
    sched-entry S 01 300000 
    sched-entry S 02 300000 
    sched-entry S 04 400000 
    clockid CLOCK_TAI

Computing gate schedules for a whole network is a constrained scheduling problem, often solved with SMT or ILP solvers. Shaper-based TSN configurations (credit-based or asynchronous traffic shaping) are usually analyzed with network calculus. Industry profiles narrow the options for specific domains, notably IEC/IEEE 60802 for industrial automation and IEEE 802.1DG for automotive in-vehicle networks.

Wireless with guarantees

Wireless links suffer from interference, multipath fading and external traffic that no protocol controls. A wireless network therefore cannot offer the hard bound a wired CAN bus can. Instead, it provides probabilistic guarantees, such as “99.99% of packets delivered within 100 ms”, by combining scheduling with diversity in time, frequency and space.

WirelessHART and ISA100.11a

WirelessHART (standardized as IEC 62591) was introduced with HART 7 for process automation. It runs on the IEEE 802.15.4 2.4 GHz radio and uses TDMA with 10 ms slots, channel hopping across the band, and a mesh topology with redundant routes. A central network manager computes the communication schedule and routes. Because transmissions are collision-free and scheduled, worst-case latency per hop follows from the schedule. Reliability comes from retries on different channels and paths. ISA100.11a (IEC 62734) follows similar principles.

TSCH and 6TiSCH

The Time-Slotted Channel Hopping mode, introduced by the IEEE 802.15.4e amendment in 2012 and now part of the base IEEE 802.15.4 standard, generalizes these ideas. Time is divided into slotframes of repeating timeslots. Each link is assigned a (timeslot, channel offset) cell, and the physical channel changes every slot according to channel = hoppingSequence[(ASN + channelOffset) mod N], where ASN is the absolute slot number. The IETF 6TiSCH working group runs IPv6 over TSCH, with a minimal configuration defined in RFC 8180 and dynamic scheduling functions built on top.

Wi-Fi and 5G URLLC

Recent Wi-Fi generations add scheduled access (OFDMA in 802.11ax, restricted target wake time in 802.11be), and IEEE 802.11bn targets ultra-high reliability. These improve statistical behavior; they are not hard bounds.

5G introduced Ultra-Reliable Low-Latency Communication (URLLC) in 3GPP Release 15, with flexible numerologies, short “mini-slot” transmissions and configured-grant uplink that avoids request–grant delays. The ITU-R IMT-2020 requirements for URLLC include a user-plane latency of 1 ms and a reliability of 99.999% (success probability 1 − 10^−5) for delivering a 32-byte packet within 1 ms. Release 16 added industrial IoT features, including integration of the 5G system as a logical TSN bridge and distribution of time synchronization. These are design targets under specific conditions. Achieved performance depends on deployment, radio conditions and load, and stringent industrial use cases are generally addressed with dedicated private networks.

Choosing a technology

In practice, hierarchical designs are common: CAN or CAN FD for local sensor/actuator loops, TSN for the backbone, and wireless for mobile or retrofit nodes where losing a sample occasionally is tolerable. Safety-critical closed loops over wireless typically need application-level measures: state estimation across lost samples, fail-safe behavior on timeout, and control designs that tolerate bounded packet loss.

Contracts for networks: a historical note

Treating network bandwidth as a reservable, contract-managed resource, just like CPU time, was one of the objectives of the FRESCOR project. Its scope explicitly included real-time networks, including wireless ones. The idea that an application negotiates a guaranteed share of the medium, and that the platform enforces it, is the network counterpart of the contract-based scheduling model. The same isolation principle matters for mixed-criticality systems that share a network between safety-critical and best-effort traffic, and for applications like real-time embedded vision, where video streams compete with control messages. If you need help analyzing a distributed timing chain, our Real-Time Schedulability Audit can include network response-time analysis, and our glossary defines the terms used here.

References and further reading

1. R. I. Davis, A. Burns, R. J. Bril and J. J. Lukkien, “Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised,” Real-Time Systems, 35(3), 2007.
2. K. Tindell and A. Burns, “Guaranteeing Message Latencies on Controller Area Network (CAN),” Proc. 1st International CAN Conference, 1994.
3. Time-Sensitive Networking (TSN) Task Group — IEEE 802.1
4. tc-taprio(8): Time Aware Priority Shaper — Linux man-pages
5. SocketCAN — Controller Area Network — Linux kernel documentation
6. RFC 8180: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration — IETF
7. WirelessHART — Wikipedia
8. FRESCOR project record — CORDIS, European Commission