What problem FlexRay solves

CAN's arbitration (see CAN Bus Fundamentals) guarantees that the highest-priority message wins the bus, but it doesn't guarantee when a lower-priority message will get through - under heavy bus load, a low-priority frame can be delayed. For most body and infotainment signals that's fine. For steer-by-wire, brake-by-wire, or active suspension control, it isn't - a control loop that occasionally arrives late is a safety problem, not just an inconvenience. FlexRay was designed by a consortium of OEMs and suppliers specifically to guarantee message timing, at the cost of being considerably more complex to configure than CAN.

Time-triggered, not priority-triggered

FlexRay's core idea is a shared, precisely synchronised sense of time across every node on the network, divided into a repeating communication cycle. That cycle is split into segments, and within the most important one, every message has a pre-assigned time slot it - and only it - is allowed to transmit in:

  • Static segment - fixed time slots, one per message, assigned at design time. If a message is due in slot 12, it transmits in slot 12, every cycle, on schedule - no arbitration, no contention, no possibility of being delayed by other traffic.
  • Dynamic segment - a CAN-like priority-arbitrated segment for less time-critical messages, giving back some of CAN's flexibility for signals that don't need hard real-time guarantees.
  • Symbol window & network idle time - reserved for network management and clock synchronisation itself.

Because every node agrees on exactly when the cycle starts and how long each slot is, a receiving node knows precisely when to expect a given message - and if it doesn't arrive in its slot, that's immediately and unambiguously a fault, not just a busy bus.

Dual-channel for redundancy

FlexRay is commonly wired as two independent channels (A and B) rather than one bus. A safety-critical message can be sent on both simultaneously, so a single wiring fault on one channel doesn't lose the message - the receiving node still gets it on the other. This is a deliberate redundancy feature, not a bandwidth-doubling trick, though a system can also use the second channel for extra throughput where redundancy isn't required.

CANFlexRay
ArbitrationPriority-based (see CAN Bus Fundamentals)Time-triggered (static segment) + priority (dynamic segment)
Speedup to 1 Mbit/sup to 10 Mbit/s per channel
ChannelsSingle pairTypically dual (A + B) for redundancy
Timing guaranteePriority-dependent, not fixedDeterministic - a static-segment message's exact arrival time is known in advance
Why this makes capture harder: reading FlexRay traffic means understanding the cluster's cycle configuration (slot assignments, cycle length, both channels) up front - unlike CAN, where you can start listening and start decoding immediately with just a DBC file. A FlexRay logger has to join the network's time base correctly before any of the traffic it captures makes sense.

Where this fits into the ONAC platform

FlexRay capture and cluster configuration work is part of ONAC's vehicle network systems consultancy service, alongside CAN, CAN FD, and the other protocols in this section - particularly relevant for chassis and safety-system work where FlexRay is still in active use.