Design Article
FlexRay speeds automotive safety applications
Mathias Rausch, Freescale Semiconductor
1/29/2006 10:24 PM EST
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.
FlexRay overview
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:
Application areas
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:
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.
Protocol classification
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.
Access methods
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.
Next: Clock synchronization

