Design Article

IMG1

FlexRay: The New Communication Paradigm for Automotive Electronics

Arnold Zimmermann and Roman Nossal

10/19/2004 12:00 AM EDT

Electronics is the key enabler for progress in the automotive sector. Some experts estimate that electronics account for up to 90% of all the innovations that make driving safer, more comfortable, and more fun. This development and concepts such as X-By-Wire—where mechanical systems such as steering will be replaced by electronic systems (Steer-By-Wire)—have been the major drivers and motivation for the design of an advanced and future-proof communication system—FlexRay.

The Roots of the Future
Driving a present-day car, there is a high chance that braking and safety systems such as ABS skid control or ESP are assisting you. These applications work in the background, combining multiple sensors, actuators, and electronic control units. The prerequisite for this highly sophisticated interaction is a communication system that connects the different parts. Communication systems that have been used nowadays show certain technical limitations and, furthermore, do not meet the stringent requirements for future applications—in other words, fault-tolerance, deterministic behavior, or higher data rates, to name but a few. BMW, DaimlerChrysler, Freescale Semiconductor (formerly Motorola SPS), Philips, GM, and Bosch have therefore teamed up in the FlexRay Consortium with the objective to develop a communication system that is able to meet all the requirements. The result: FlexRay is an open and scalable, deterministic and high performance communication technology for automotive applications.

Fast, Faster, FlexRay
One of the constraints of current automotive electronic communications systems is the limited bandwidth. For a start, the FlexRay Consortium selected a data transfer rate of 10 MBit/s on each of the two communication channels as a viable trade-off between the need for high performance and the economic constraints. As the current FlexRay specification is open for higher bit rates, faster physical layers are possible in the future.

…and Fault-Tolerant
Scalable system fault-tolerance via the support of either single or dual channels—that was one of the important sub-goals in developing FlexRay. Since the needs of automotive applications differ quite substantially in terms of fault-tolerance, the new communication system sets out to do the splits between distributed fault-tolerant and non fault-tolerant systems. Therefore, the two channels can be used as:

  • Single-channel system (doubling the data throughput)
  • Dual-channel system (controllers that are connected to two channels can be configured to transmit data redundantly on two channels at the same time)
  • Dual-channel system with mixed connectivity (here some nodes connect to both channels, some connect only to one).

New Dimension: Safety-Critical
The need for speed was, however, not the only trigger for developing a new communication system. Some of the new electronic functions in cars will exhibit a characteristic that is not present up to now—they are safety-critical. In safety-critical systems, communication reliability cannot be based on probabilistic measures. In a CAN system, for example it is not possible to calculate the communication delay except for some high priority messages. If a message is safety-critical, its transport must be guaranteed; what is more, the latency it will experience must also be known.

Deterministic System Design
In contrast to current event-triggered communication protocols such as CAN, FlexRay combines a time-triggered along with an event-triggered system. Based on an extended TDMA (time-division multiple access) media access strategy, a so-called communication cycle is set up, consisting of a mandatory static segment, an optional dynamic segment and two protocol segments called symbol window (optional) and network idle time (mandatory). Application cycles can be formed by one or more communication cycles, which are executed from start-up of the network until its shutdown.

Static Segments
In the static segment, requirements such as latency and jitter are taken care of by means of deterministic communication timing. Since communication access follows a TDMA (time division multiple access) scheme with equally sized slots, the point of time when a frame is transmitted on the channel is exactly known. ECUs own slots exclusively in order to guarantee the transmission of their respective data. The duration and the number of slots are determined by configuration parameters of the FlexRay controllers. In order to rule out any on-line competition for the communication medium, slot assignment is done off-line during system planning. Furthermore, all the scheduling has to be done during this planning process.

Dynamic Segment
The dynamic segment consists of one slot of fixed duration, which addresses the need for event-driven communication, for example, diagnosis data. A prioritization scheme enables variable bandwidth distribution during runtime (Figure 1). The fixed duration of the dynamic segment is subdivided into minislots that define potential start times of transmission within the given interval. Throughout the course of the dynamic segment, all controllers in the network maintain a consistent view about the active minislot. Each sending controller has a minislot assigned to a transmit-frame. If the active minislot matches to a configured transmit-frame, the controller accesses the medium and transmits the frame. Due to this demand driven access pattern the reserved bandwidth for dynamic communication is perfectly used. Both parameters—dynamic segment as well as minislots—are globally configured.

Symbol Windows and Network Idle Time
In addition to static and dynamic segments, each communication cycle can contain a symbol window and the network idle time. The symbol window is also a time slot of fixed duration for the transmission of special symbols, for example, the media access test symbol. Due to a special quality of the symbols, the transceiver components of the physical layer can understand and act on the symbols transmitted by the communication controllers.

The Network Idle Time (NIT) is a configurable, communication-free period at the end of each communication cycle. Two major tasks are performed in the NIT:

  • The communication controller performs several computations (for example, calculation of clock correction values, error handling, update of error indicators and counters and so on).
  • The offset correction. At the end of each odd cycle the NIT is enlarged or reduced according to the offset correction value.

The configuration has to guarantee that the remaining length of the NIT is sufficient for the execution of above-mentioned computations.

The Combination of These Segments
Each communication cycle has to have a static segment and a network idle time whereas dynamic segments and symbol window are optional. This prerequisite allows three configurations:

  • A pure static configuration, which contains only static slots for transmission (Figure 2)
  • A mixed configuration consisting of a static and a dynamic segment, where the ratio between static bandwidth and dynamic bandwidth can vary in a broad range.
  • A pure dynamic configuration with all bandwidth assigned to dynamic communication.

Considering the most likely application domains, mixed configurations will be dominant.

Important: The Right Time
A time-triggered communication system depends upon a common time base, the so-called global time. This time base has to be shared by all communication controllers in the network. In order to synchronize the clock, certain messages are marked as synchronization messages in the static segment. By means of a special algorithm, the local clock-time of a component, for example, a communication controller, is corrected in such a way that all local clocks run synchronously to a global clock.

A Guard for the Bus
Access to the communication bus has to be carefully managed, especially with regard to safety relevant applications. An independent component that protects a channel from interference is needed. It must limit the times that any communication controller can transmit to those pre-assigned intervals, in which it is allowed to do so. This component is the Bus Guardian. Basically, FlexRay systems allow to use bus guardians with independent clocks and are configured in a way that an error in the controller cannot influence the guardian and vice versa.

Composability
As mentioned above, currently used systems are event-triggered, which means that whenever a station has data to send it tries to access the bus. Adding a new message is convenient to realize by assigning an identifier to it. The pitfall comes with the testing of such a system since any new message or change of the application modifies the behavior of the communication system. From the very onset of the FlexRay Consortium, a high demand was put on composability of the new communication system.

As described above in the section about the deterministic system, both the static and dynamic segments strictly adhere to the exclusive ownership of slots, a key foundation for the composability. As each ECU owns slots exclusively, it is possible to develop ECUs autonomously and to later integrate them without side effects (Figure 3).

Conclusion
With FlexRay, a new communication system has been developed that will help to shape the future of automotive electronics. Due to its deterministic, fault-tolerant, and high performance characteristics, new—safety-critical—applications are going to be realized in the coming decade making driving again safer and less stressful.


About the Authors
Dr. Arnold Zimmermann is Marcom Manager for Decomsys Dependable Computer Systems. The Austrian high-tech Company is a development member of the FlexRay Consortium and provides a comprehensive portfolio of software, prototyping hardware, chip design, test cases, consulting, trainings, engineering, and support. His email address is zimmermann@decomsys.com.

Dr. Roman Nossal received the M.Sc. and Ph.D. degrees in Computer Science from the Vienna University of Technology. After joining Decomsys in July 2001, he headed the System Development team, which focuses on the process and tools for the development of distributed systems in general and for FlexRay in particular. Since August 2003 Roman Nossal is Decomsys product manager.


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm