FlexRay was born out of necessity. As automobile manufacturers began investigating new power train, chassis, and by-wire control systems, two companies in particular, BMW and DaimlerChrysler, realized that the current in-vehicle networking solutions did not meet their needs. They required a very fast, deterministic, and fault-tolerant protocol that could satisfy the speed, reliability, and safety requirements of such applications as brake-by-wire and steer-by-wire.
Other available protocols, such as controller area networks (CANs) and media oriented systems transport (MOST) networks, either don't have the data rate or the functionality suitable for advanced power train, chassis, and by-wire applications. FlexRay has been under development since 2000, when BMW, DaimlerChrysler, Philips, and Motorola (and later its spinoff Freescale Semiconductor, in 2004) founded the FlexRay Consortium with the expressed goal of developing "an advanced communications technology for high-speed control applications in vehicles to increase safety, reliability, and comfort." Since then, most of the automotive industry's major players have joined the consortium.
After five years of development, the second version of the FlexRay protocol specification (Version 2.1) was released in spring of 2005. This upgrade offers a number of features which do not exist in traditional in-car communication protocols, and which may open up great opportunities for a new class of applications. The basic features are:
2 x 10 Mbit/sec data rate. FlexRay supports two communication channels, each of them operating at a 10 Mbit/sec data rate. Depending on the configuration and comparison model, this constitutes a ten- to forty-fold increase of available bandwidth when compared with the CAN protocol.
Synchronized time base. FlexRay relies on an access method based on a synchronized time base, which is autonomously established and synchronized by the protocol, and then made available to the application. The accuracy of the time base ranges from 0.5 to 10 μs (usually 1 to 2 μs).
Known message latency with guaranteed variance. The communication is organized in periodically recurring cycles. A specific message has a fixed position in a communication cycle such that a receiver already knows in advance when each message will arrive. The arrival time's narrow temporal variance margin is guaranteed.
Redundant and non-redundant communication. FlexRay can redundantly transmit individual messages to provide an additional layer of network reliability. Programmable transmission redundancy allows the developer to pick and choose redundant messages to make the most efficient use of network bandwidth.
Flexibility. During FlexRay's development, a primary focus has been on flexibility. In addition to the free choice of which messages will be transmitted redundantly or non-redundantly, the system can be optimized for availability (static bandwidth allocation) or for throughput (dynamic bandwidth allocation), thus making it possible to extend a system without adjusting the software in the existing nodes. FlexRay supports bus topologies as well as star topologies, and a variety of configuration parameters, such as the duration of the communication cycle or the message length, enable adjusting the communication system to specific application requirements.
FlexRay is designed to service new technologies and emerging uses, but its high speed and network flexibility also allow it to fulfill the needs for a number of current in-vehicle applications:
CAN-Substitute. In applications which require data rates beyond CAN, two or more CAN buses are sometimes used in parallel. FlexRay is ideally suited to replace such multi-bus solutions.
Backbone. Due to its high data rate, FlexRay is suitable for automotive backbones to provide connectivity between several independent networks.
Real-time applications and distributed control systems. The known and guaranteed message cycle time at narrow variance margins makes FlexRay a technology of choice for distributed control systems driven by strict real-time requirements.
Safety-oriented systems. FlexRay on its own does not make a system safe, but a variety of functions in FlexRay support the design of safety-oriented systems, such as by-wire systems.
Migrating from event-driven CAN to time-driven FlexRay communication is a paradigm shift for in-vehicle communication. This affects the introduction of a new technology and requires all involved parties to be re-trained. This will take some time, but once this first step is taken, many new application areas will be discovered.
A variety of protocols have been specifically designed for automotive applications (see below), of which CAN is the oldest and best known. High-speed CAN (CAN-C) is primarily deployed in power train applications while low-speed CAN (CAN-B) is used in body applications. CAN's maximum achievable data rate is 1 Mbit/sec, but networks are often operated at less than 500 kbit/sec.
Developed only a few years ago, the local interconnect network (LIN) protocol is already widespread. It has been developed for cost-effective modules with low-speed transmission requirements, most often deployed in body applications, such as seat and mirror adjustments and power windows. The 20 kbit/sec data rate is sufficient for this class of applications.
The D2B protocol and its successor MOST protocol were specifically developed for multimedia applications and are exclusively used in this area, and are not suitable for deployment in other areas. With respect to speed, FlexRay falls between the CAN protocol and the MOST protocol, but due to its fault-tolerance features, FlexRay is somewhat more complex.
Communication using FlexRay is organized into periodically recurring communication cycles. Each cycle always consists of a static segment and the Network Idle Time (NIT). The NIT is required for protocol internal processes, and during this time no communication takes place between the nodes of a cluster.
The static segment of the communication cycle is based on TDMA (Time Division Multiple Access) technology, which allocates fixed time slots the individual nodes use for message transmission. All slots are the same size and are numbered sequentially. One or more of these slots are permanently allocated to each cluster node, and this allocation must not be changed during operation.
In addition to the static segment, a communication cycle can include a dynamic part. A so-called mini-slot method is used to access the communication medium within this dynamic segment. Outgoing messages are assigned to a dynamic slot, but transmission takes place only if required, with the available bandwidth dynamically allocated. A node with a pending outgoing message transmits if the frame number (ID) corresponds to the slot number. If no node is transmitting, all nodes wait for exactly one mini-slot before they increase their slot counters. After increasing the slot counter, all nodes check whether the new slot number corresponds to the ID of one of their outgoing messages. If there is a match, the node sends its message, and each receiving node waits until the complete message has been delivered before it increases its slot counter.
This process continues until the end of the dynamic segment. If, during a cycle, none or only a few nodes transmit messages, the dynamic segment ends with a higher slot number. The higher the number the lower the slot priority. If many nodes transmit during the cycle, the segment ends with a lower number, meaning a higher priority slot. Therefore, it's possible that a node that has an outgoing message with a high slot number can transmit in one cycle but not in another, depending on how many nodes transmitted messages prior to it in that dynamic segment. To make certain that a message is transmitted, the user must send it within the static portion of the communication cycle or must allocate it to a lower slot number within the dynamic segment.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.