FlexRay is a fault-tolerant serial communication protocol developed for automotive applications, offering time-triggered and event-triggered messaging at up to 10 Mbps per channel. The time-triggered static segment provides deterministic, bounded-latency communication; the optional dynamic segment is event-driven and does not carry the same determinism guarantee. FlexRay was designed to meet the safety and reliability requirements of chassis and powertrain control systems where CAN's contention-based bus access introduces variable latency under load that cannot be bounded tightly enough.
In practice
FlexRay is found primarily in high-end automotive applications such as active suspension, steer-by-wire, brake-by-wire, and advanced chassis control systems. It is typically used where hard real-time guarantees are mandatory and where CAN's arbitration-based access scheme cannot provide the bounded latency required. Production deployments appeared in BMW, Audi, and other OEM platforms from the mid-2000s onward.
The protocol operates over one or two channels (A and B), each running at up to 10 Mbps. Using both channels simultaneously can increase aggregate bandwidth and add redundancy, though the actual usable throughput gain depends on how the network is configured; channels may be used for redundancy, for independent traffic, or for a combination of both. The communication cycle is divided into a static segment, where time slots are pre-assigned to specific nodes (TDMA), and an optional dynamic segment that provides event-driven access using a minislot mechanism, which is conceptually analogous to CAN's event-driven model but operates differently at the protocol level. A symbol window and network idle time round out the cycle. The static segment is what provides FlexRay's determinism guarantee.
FlexRay nodes require a dedicated controller peripheral plus a bus driver (transceiver). Several MCUs from NXP (MPC57xx, S32 series), Infineon (AURIX TC2xx, TC3xx), and STMicroelectronics (SPC56x) integrate FlexRay controllers on-chip. Standalone FlexRay controllers such as the NXP MFR4310 also exist for use with MCUs that lack an integrated peripheral. The physical layer uses a differential voltage scheme, typically implemented over twisted pair, and is not electrically compatible with CAN; different channel wiring topologies and cabling options are defined in the specification.
Configuration and scheduling are non-trivial. The static schedule must be defined at design time and is shared across all nodes; any change requires reconfiguring the entire network. Tools such as the AUTOSAR authoring environment or dedicated network design tools (e.g., Vector's CANdb++ with FlexRay extensions, or PREEvision) are used to manage cluster configuration. This rigidity, combined with higher cost and complexity compared to CAN FD, has led most new automotive designs to favor CAN FD or automotive Ethernet instead, and FlexRay is largely absent from new platform designs started after roughly 2015.
Frequently asked
What is the key difference between FlexRay's static and dynamic segments?
In the static segment, each time slot is pre-assigned to a specific node at design time using TDMA scheduling. A node always transmits in its designated slot regardless of whether it has new data, which guarantees bounded
latency. In the dynamic segment, nodes compete for mini-slots in a manner similar to
CAN's arbitration, making it event-driven but non-deterministic. Safety-critical signals are placed in the static segment; lower-priority data can use the dynamic segment.
How does FlexRay achieve fault tolerance?
FlexRay supports two independent physical channels (A and B). Safety-critical messages can be transmitted on both channels simultaneously. If one channel fails, the other continues operating. The protocol also includes a bus guardian function on each node to prevent babbling-idiot failures, where a faulty node monopolizes the bus by transmitting outside its assigned slot.
Why has FlexRay adoption declined in favor of CAN FD and automotive Ethernet?
FlexRay's static scheduling requires all nodes and their time slots to be defined at design time, making the network rigid and expensive to modify. The required controllers, transceivers, and tooling add cost and complexity.
CAN FD, standardized in ISO 11898-1:2015, raised CAN data-phase bit rates to up to 8 Mbps in typical implementations while retaining CAN's familiar development ecosystem and lower cost. For bandwidth-intensive applications such as cameras and sensor fusion, 100BASE-T1 or 1000BASE-T1 automotive
Ethernet provides far greater throughput. These alternatives cover most use cases at lower complexity, which has largely displaced FlexRay in new designs.
Which MCUs include an integrated FlexRay controller?
Several automotive-grade MCUs integrate FlexRay controllers on-chip. NXP's MPC5748G and S32R series, Infineon's AURIX TC27x and TC39x families, and STMicroelectronics' SPC56x (Chorus) parts are common examples. For MCUs without a built-in peripheral, external standalone controllers such as the NXP MFR4310 can be used over a parallel or
SPI interface.
Is FlexRay relevant outside the automotive industry?
Rarely. FlexRay was designed specifically for automotive environments and its ecosystem, tooling, and silicon support reflect that focus. Some industrial motion control or aerospace research projects have evaluated it for its determinism, but
CAN, EtherCAT, or other industrial protocols are far more common choices in those domains. For most non-automotive embedded designs, FlexRay is not a practical option.
Differentiators vs similar concepts
FlexRay is often compared to
CAN and CAN FD. The fundamental difference is that CAN and CAN FD use CSMA/CR arbitration, which introduces variable bus access
latency under load because multiple nodes contend for the bus, whereas FlexRay's static segment uses TDMA to provide hard real-time guarantees. CAN FD raises the data-phase bit rate to up to 8 Mbps in typical implementations and retains CAN's event-driven model, making it a simpler upgrade path for most applications. FlexRay's dual-channel redundancy and bus guardian are also absent in CAN and CAN FD. FlexRay should not be confused with automotive
Ethernet (100BASE-T1, 1000BASE-T1), which uses a different physical layer and protocol
stack entirely and targets much higher bandwidth applications such as video and sensor fusion.
