SAE TECHNICAL
`PAPER SERIES
`
`2001-01-0676
`
`FlexRay – The Communication System for
`Advanced Automotive Control Systems
`
`Josef Berwanger, Christian Ebner and Anton Schedl
`BMW AG
`
`Ralf Belschner, Sven Fluhrer and Peter Lohrmann
`DaimlerChrysler AG
`
`Emmerich Fuchs, Dietmar Millinger and Michael Sprachmann
`Dependable Computer Systems KEG
`
`Florian Bogenberger, Gary Hay, Andreas Krüger and Mathias Rausch
`Motorola GmbH
`
`Wolfgang O. Budde, Peter Fuhrmann and Robert Mores
`Philips GmbH
`
`400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A.
`
`Tel: (724) 776-4841 Fax: (724) 776-5760
`
`SAE 2001 World Congress
`Detroit, Michigan
`March 5-8, 2001
`
`Page 1 of 14
`
`Mercedes Exhibit 1017
`
`

`
`The appearance of this ISSN code at the bottom of this page indicates SAE’s consent that copies of the
`paper may be made for personal or internal use of specific clients. This consent is given on the condition,
`however, that the copier pay a $7.00 per article copy fee through the Copyright Clearance Center, Inc.
`Operations Center, 222 Rosewood Drive, Danvers, MA 01923 for copying beyond that permitted by Sec-
`tions 107 or 108 of the U.S. Copyright Law. This consent does not extend to other kinds of copying such as
`copying for general distribution, for advertising or promotional purposes, for creating new collective works,
`or for resale.
`
`SAE routinely stocks printed papers for a period of three years following date of publication. Direct your
`orders to SAE Customer Sales and Satisfaction Department.
`
`Quantity reprint rates can be obtained from the Customer Sales and Satisfaction Department.
`
`To request permission to reprint a technical paper or permission to use copyrighted SAE publications in
`other works, contact the SAE Publications Group.
`
`All SAE papers, standards, and selected
`books are abstracted and indexed in the
`Global Mobility Database
`
`No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written
`permission of the publisher.
`
`ISSN 0148-7191
`Copyright 2001 Society of Automotive Engineers, Inc.
`
`Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE. The author is solely
`responsible for the content of the paper. A process is available by which discussions will be printed with the paper if it is published in
`SAE Transactions. For permission to publish this paper in full or in part, contact the SAE Publications Group.
`
`Persons wishing to submit papers to be considered for presentation or publication through SAE should send the manuscript or a 300
`word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE.
`
`Printed in USA
`
`Page 2 of 14
`
`

`
`FlexRay – The Communication System for Advanced
`Automotive Control Systems
`
`2001-01-0676
`
`Josef Berwanger, Christian Ebner and Anton Schedl
`BMW AG
`
`Ralf Belschner, Sven Fluhrer and Peter Lohrmann
`DaimlerChrysler AG
`
`Emmerich Fuchs, Dietmar Millinger and Michael Sprachmann
`Dependable Computer Systems KEG
`
`Florian Bogenberger, Gary Hay, Andreas Krüger and Mathias Rausch
`Motorola GmbH
`
`Wolfgang O. Budde, Peter Fuhrmann and Robert Mores
`Philips GmbH
`
`Copyright © 2001 Society of Automotive Engineers, Inc.
`
`ABSTRACT
`
`BMW, DaimlerChrysler, Motorola and Philips present
`their joint development activity related to the FlexRay
`communication system that is intended for distributed
`applications in vehicles. The designated applications for
`powertrain and chassis control place requirements in
`terms of availability, reliability and data bandwidth that
`cannot be met by any product currently available on the
`market under the testing conditions encountered in an
`automobile.
`
`A short look back on events so far is followed by a
`description of the protocol and its first implementation as
`an integrated circuit, as well as its incorporation into a
`complete tool environment.
`
`INTRODUCTION
`
`The CAN bus system has been used by several
`automotive manufacturers since the start of the 1990’s.
`These firms can now look back at over a decade of field
`experience
`in
`event-triggered
`communications
`networking. The complexity of the networking as well as
`the physical transmission technology (physical layer)
`posed particular challenges.
`
`Over the past few years, the research departments at
`DaimlerChrysler have intensified their work on time-
`triggered architectures, with a part of that work being
`carried out for two EU projects which they cooperated on
`
`with other partners (X-By-Wire: Safety Related Fault
`Tolerant Systems in Vehicles, TTA: Time Triggered
`Architecture). In the course of this work, different bus
`systems (including TTP/C /1/, TCN: Train Communication
`Network, TTCAN) were researched and
`tested
`for
`suitability for future applications in automobiles.
`
`In the period from 1996 to 1999, BMW together with
`Motorola, Infineon and ELMOS developed the optical
`data bus system byteflight /4/ /5/ for networking passive
`safety functions. byteflight is a data protocol with high
`data integrity, reliability and malfunction resistance in
`addition to flexible use of bandwidth to allow effective
`diagnosis of the complete system. BMW will start with the
`first series production application in the automotive sector
`within the next year, when it will cover passive safety and
`body functions.
`
`investigations carried out by and experience
`The
`accumulated by DaimlerChrysler and BMW revealed that
`none of the current established or prototype data bus
`systems is able to meet all the requirements for use in
`automotive series production with regards to future
`automobile
`systems.
`In mid-1999, BMW
`and
`DaimlerChrysler decided to work together to speed up
`the specification and development of a future data bus
`system /7/. This joint project resulted in the requirement
`specification for the future FlexRay data bus system. The
`FlexRay requirement documents were handed over to
`major
`semiconductor manufacturers
`for
`further
`implementation.
`
`Page 3 of 14
`
`

`
`the
`to
`regards
`the state variables with
`updates
`synchronized system time. Consequently, sensors can
`be read out and actuators triggered synchronously.
`
`in vehicles -
`Standardization of
`
`the bus systems
`
`Automobile manufacturers tend to use a small number of
`data bus systems that are best suited for the category of
`application at hand. Figure 1 illustrates the orientation
`strategy at DaimlerChrysler and BMW for the field of
`powertrain and chassis bus systems. As before, CAN is
`still the principal basis for event-triggered systems.
`FlexRay will be used as a high-end data bus system for
`applications that place high requirements in terms of
`performance, determinism, fault tolerance and flexibility.
`
`)OH[5D\
`
`&$1
`
`/,1
`
`0267
`
`&RQWURO(cid:3)DQG
`JRYHUQLQJ(cid:3)V\VWHPV
`
`7HOHPDWLFV
`DSSOLFDWLRQV(cid:3)
`
`5HTXLUHPHQWV
`
`Figure 1. Strategy for standardization of bus systems at DC and BMW
`
`is
`OBJECTIVES - The FlexRay data bus system
`currently being developed by Philips (physical layer) and
`Motorola (data link layer) according to the requirements
`established by BMW and DaimlerChrysler. There is no
`interest at any of the involved parties in developing a
`proprietary data bus system. Rather, the goal is for the
`system to be used as widely as possible. The objectives
`are:
`
`•
`
`•
`
`•
`
`FlexRay is a cross-manufacturer bus system for
`high-speed applications.
`Broad use of the data bus system should be
`achieved.
`A declared target is the standardization of the
`protocol.
`
`FlexRay communication technology is available for all
`interested parties.
`
`REQUIREMENTS IN THE VEHICLE
`
`asynchronous
`Configurable
`
`and
`synchronous
`
`
`transmission - In motor vehicles, different systems with
`
`varying requirements are networked with one another.
`Distributed control systems mostly require synchronous
`transmission, while all data which are not needed
`
`MOTIVATION AND OBJECTIVES
`
`MOTIVATION - The in-vehicle data bus systems used
`today
`in automobiles
`for control applications have
`reached
`their performance
`limit. Future automotive
`systems will further increase the requirements placed on
`a communications system. In order to implement these
`future systems, a new data bus system that takes these
`requirements into account must be established.
`
`
`Requirements with regards to higher data transmission
`
`
`
`rates - CAN data bus systems rated for data transmission
`at up to 1 Mbit/sec are already in use today for the
`powertrain and chassis. Due to vehicle-related peripheral
`conditions however, the data transmission rate in series
`production is limited to 500 Kbit/sec. The evolution of
`automotive networking is therefore already reaching its
`performance limit today.
`
`
`Determinism
`today
`- Virtually all systems used
`
`communicate asynchronously, cyclically and/or event
`triggered. Although these systems continue to behave
`deterministically with an increasing bus load, the resulting
`worst-case scenario deteriorates dramatically. This is
`particularly true in the case of faults or malfunctions,
`where messages are re-transmitted.
`In
`the event-
`triggered systems, the activities are triggered by events,
`which are unforeseeable in terms of time. In time-
`triggered systems on the other hand, the activities are
`started at pre-defined points in time. Usually, in a time-
`triggered system new messages overwrite any old
`messages which are still present, so that the system can
`never be overloaded by a rapid succession of events.
`The timing of the message transmission is defined
`statically, so that the communications system has a
`predefined load. Message bursts and the resulting load
`peaks do not occur.
`
`
`Fault tolerance - Future systems face the challenge of
`
`performing complex vehicle functions using fault-tolerant
`electronics. This is particularly true when systems are
`designed without a mechanical
`fail-safe
`level, and
`hydraulics or mechanics are replaced by fault-tolerant
`electronics. The data bus must support the redundancy
`in such as way that data transmission can be sustained
`in the event of a fault. At the bus level, redundancy takes
`the form of increased availability. This makes it possible
`to supply all necessary data to the function without any
`omissions in the event of a fault.
`
`
`Support for distributed controls - Future chassis control
`
`systems will take the form of typical distributed control
`systems. Characteristic problems
`include, amongst
`others, maintenance of the sampling intervals, application
`synchronization as well as the chronological functional
`chain of the distributed closed control circuit. Time-
`triggered types of system architecture are best suited for
`the implementation of distributed controls. They possess
`a globally synchronized time basis. At set times, the
`system makes a snapshot of its environment and
`
`Page 4 of 14
`
`

`
`vehicle and equipment variants place high demands in
`terms of flexible system expandability. Specifically, this
`affects the addition and deletion of control units and
`functions) without being forced to reconfigure unaffected
`bus users. A good system programming interface and
`diagnosis compatibility are essential for effective service
`and early fault detection, and require flexible bandwidth
`usage for the communications system.
`
`FLEXRAY
`
`COMMUNICATION PROCESS - Communication takes
`place in a communication cycle that consists of a static
`and a dynamic part. The border between the static and
`dynamic part can be freely defined before the run- time of
`the system, whereby either part may also be empty. The
`communication cycle begins with a SYNC symbol. The
`time slots are identified by ID numbers that are used for
`both the static and for the dynamic part. Network nodes
`that are connected to both channels send their messages
`in the static part simultaneously on both channels. In the
`dynamic part, there may be differences in the time slots
`on the two channels. In order to guarantee clock
`synchronization, only messages from network nodes
`connected to both channels are used. All network nodes
`perform clock synchronization. However, only selected
`messages from the static part are used for clock
`synchronization.
`
`6* $
`
`6* %
`
`6* &
`
`6* '
`
`6* (
`
`6* )
`
`6* *
`
`channel 1
`
`6<1& V\PERO
`
`channel 2
`
`VORW
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 
`
`Ed
`
`q
`
`Fd
`
`o
`
`
`
`Ad
`
`m
`
`
`
`AG
`
`O
`
`
`
`N
`
`PHVVDJHV
`FKDQQHO 
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`D
`
`E
`
`F
`
`G
`
`H
`
`I
`
`J
`
`constantly, such as diagnosis and service data, can be
`transmitted more efficiently asynchronously.
`
`
`High transmission bandwidth - The current requirement
`
`for powertrain and chassis applications is approx. 2 Mbit/
`sec, meaning a
`target bandwidth
`for
`the protocol
`definition of 10 Mbit/sec.
`
`
`Deterministic transmission, guaranteed message latency
`
`
`and jitter - To achieve high control quality, distributed
`
`controls in particular require deterministic transmission.
`Deterministic transmission is also beneficial for creating
`redundancies. Any jitter that occurs, i.e. variation in the
`transmission operating time, should be as minimal as
`possible and should not be influenced by the operating
`status (e.g. the bus load).
`
`(scalable)
`Support
`The
`-
`
`redundancies
`of
`
`communications system must be able to be configured
`for simple and for fault-tolerant applications (scalable to
`the greatest possible extent).
`
`
`Fast fault detection and signaling - In fault-tolerant real-
`
`time systems, every fault affecting the function must be
`recognized and processed in the shortest possible time.
`So-called "dormant faults" in fault-tolerant applications
`must be prevented by a suitable means of fault signaling.
`
`
`Global time - In order that synchronous functions can in
`
`the future be implemented in the distributed systems,
`common interpretation of time is necessary. The data
`bus system derives this global time based on the data
`transfer and makes this time available to the individual
`systems. This permits
`the
`local
`times within
`the
`distributed system to be synchronized.
`
`CG
`
`FG
`
`EG
`
`DG
`
`BG
`
`CG
`
`BG
`
`AG
`
`VORW
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Gd
`
`p
`
`
`
`Ad
`
`n
`
`
`O
`
`AG
`
`
`N
`
`CG
`
`
`
`Gd
`
`j
`
`
`
`DG
`
`H
`
`
`G
`
`BG
`
`
`
`CG
`
`L
`
`
`
`BG
`
`K
`
`
`D
`
`AG
`
`PHVVDJHV
`FKDQQHO 
`
`VWDWLF SDUW
`
`G\QDPLF SDUW
`
`FRPPXQLFDWLRQ F\FOH
`
`IUDPH VWDWLF SDUW

`
`,'
`datatype
`sending
`node
`
`,'
`datatype
`sending
`node
`
`IUDPH G\QDPLF SDUW

`
`Figure 2. Bus access according to the priority defined by the identifier
`(ID)
`
`
`Static part - The static part of the transmission cycle is
`
`made up of a freely configurable number of transmitting
`slots of identical length. Bus access takes place using the
`TDMA (Time Division Multiple Access) procedure. Each
`connected node can transmit one or several messages
`synchronously on both channels in slots reserved for it.
`Any data content is permissible. The message identifier
`corresponds to the respective time slot in which the
`
`
`Fault containment on the network via the physical layer -
`
`In the case of fault-tolerant systems, it must be ensured
`that it is not possible for one user to block the
`communications system by monopolizing the network
`(“babbling idiot”). An independent entity ("bus guardian")
`can be used to contain the fault in the time domain if
`necessary.
`
`transmission
`Arbitration-free
`- The stipulation of
`
`
`arbitration-free transmission stems from the requirement
`for higher transmission bandwidth and independence of
`the deterministic characteristics from the network load,
`random events or the topology of dependent influencing
`variables (line lengths).
`
`
`Support of optical and electrical physical layer - The
`
`communications system should support both electrical
`and optical physical layers, in order to meet all current
`and future requirements in the motor vehicle.
`
`in
`Flexibility, expandability and user-configurability
`
`
`
`automotive applications - Ever shortening development
`
`times, quick reaction times to market requirements as
`well as the task of taking into account many different
`
`Page 5 of 14
`
`

`
`message will be transmitted. If a message is not
`transmitted (for instance if a node fails or if an item of
`optional equipment has not been
`fitted),
`then
`the
`corresponding time elapses without being used.
`
`
`Dynamic part - In the dynamic part, transmission takes
`
`place in accordance with the byteflight specification /5/.
`The slot counters
`in all nodes count upwards
`synchronously and bus access follows the mini-slotting
`bus access method. Whereas in the static part, the slot
`counters continue to count until the pre-configured slot
`time has elapsed, the slot counters in the dynamic part
`carry on counting after just a short delay if there is no
`transmission request for the ID concerned. When the slot
`counters reach an identifier value for which there is a
`transmission request, the message is transmitted over
`the bus with this identifier. Both the transmitters and the
`receivers (all bus controllers in the network) stop the slot
`counters at the present value for the duration of the
`transmission. Once transmission is complete, the slot
`counters carry on counting upwards.
`
`
`Message format - The message format is identical for all
`
`messages, in both the static and the dynamic part. When
`a SYNC bit is set, the cycle counter in the first data byte
`is coded. The cycle counter is an 8 bit counter which
`counts
`the communication cycles. This counter
`is
`identical in all nodes throughout the system.
`
`,'
`
`08;
`
`6<1&
`
`/(1 &<&/(
`
`'$7$
`
`&5&
`
`
`
`10 bit
`
`1 bit
`
`1 bit
`
`4 bit
`
`8 bit
`
`0...11 byte
`
`15 bit
`
`1 bit
`
`Figure 3. Frame format with cycle counter (SYNC = "1")
`
`,'
`
`08;
`
`6<1&
`
`/(1
`
`'$7$
`
`&5&
`
`
`
`10 bit
`
`1 bit
`
`1 bit
`
`4 bit
`
`0...12 byte
`
`15 bit
`
`1 bit
`
`Figure 4. Frame format without cycle counter (SYNC = "0")
`
`ID - Identifier, 10 bit, value range: (110 ... 102310), defines
`the slot position in the static part and the priority in the
`dynamic part. The smaller the identifier, the greater the
`priority. ID = 0 is reserved for the SYNC symbol. An
`identifier may only be used once in a network. Each node
`may use one or several identifiers, in the static as well as
`in the dynamic part.
`
`MUX - Multiplex field, 1 bit. This bit allows different data
`to be transmitted with the same identifier.
`
`SYNC - SYNC field, 1 bit. This bit indicates whether the
`message is being used for clock synchronization and
`whether the first data byte contains the cycle counter
`
`(SYNC = “1”: message with frame counter and clock
`synchronization, SYNC = “0”: message without frame
`counter)
`
`LEN - Length field, 4 bit, number of data bytes (010 ...
`1210). A value greater than 12 is interpreted as LEN=12. If
`the cycle counter is used (SYNC=1), LEN=11 is set for
`values greater than 11.
`
`CYCLE - The CYCLE field can be used as a cycle
`counter or as the first data byte. The cycle counter is
`increased in all communication controllers simultaneously
`at the start of every communication cycle.
`
`D0 … D11 - Data bytes, 0 – 12 bytes
`
`CRC - 15 bit cyclic redundancy check.
`
`Startup - The communication system is started up when
`
`
`at least two nodes take part in communication. In a two-
`channel system, only nodes connected to both channels
`may participate in the start-up. Before a node can
`transmit its first message (from the static part) in bus idle
`mode (after power-on or wake-up) it has to wait until the
`startup time-out has elapsed. The startup time-out is
`mainly determined by the cycle length.
`
`If the node receives at least one message (from a node
`that has synchronized itself to the first message), the
`system is enabled for communication. If the node does
`not receive a message from another node within a
`certain period of time (listen time-out), the node will
`retransmit the first message. This procedure ensures
`startup can take place without time-consuming collision
`resolution. A special control makes sure that one
`controller with defective reception (an incoming link
`failure of both channels) cannot disrupt the startup of a
`cluster.
`
`In a purely dynamic system, startup and synchronization
`take place by the predefined bus master transmitting the
`SYNC symbol in accordance with byteflight specification
`/5/. The SYNC symbol corresponds to the time slot and
`ID = 0. Troubleshooting strategies to deal with the failure
`of a bus master must be implemented on the application
`level in a purely dynamic system.
`
`
`Clock synchronization - Clock synchronization in FlexRay
`
`ensures that all communicating nodes in the system have
`a consistent, standardized view of the global time to a
`defined degree of precision. Clock synchronization is
`active as soon as (or as long as) at least two nodes are
`active (i.e. are ready to communicate). The degree of
`fault tolerance in a system with a static portion depends
`on the number of active nodes.
`
`With a system configuration which includes a static part,
`a distributed,
`fault-tolerant
`clock
`synchronization
`algorithm is used following startup. A system with a
`purely dynamic configuration starts off with a master
`
`Page 6 of 14
`
`

`
`synchronization. The synchronization procedure takes
`place in three phases, which are described below.
`
`Measurement of clock deviation - In a system with a
`static portion, the difference between the expected and
`the actual time of reception of selected messages in the
`static part is measured.
`
`Selection of the messages to be measured is carried out
`when designing the system and ensures that for every
`node that transmits in the static part there is exactly one
`measured value. Furthermore, only messages that are
`received correctly within the defined value and time
`range are used for clock synchronization. The result of
`this phase is a sorted list of deviations between the local
`clock time and the clocks of the other active nodes in the
`system.
`
`Calculation of the correction term for the local clock - All
`nodes calculate the correction term for adjusting the local
`clock to the global time based on the list of measured
`values produced at the end of the last static slot. A fault-
`tolerant average algorithm (FTM: Fault Tolerant Midpoint
`/6/) is used for this.
`
`In order to calculate the local correction term, the
`measured deviations are sorted and the k largest and
`smallest values are discarded (Figure 5). The value k
`represents
`the number of
`faulty measured values
`(clocks) which are to be tolerated. The value of k is
`predefined statically. In cases where the number of high
`and low values which can be discarded is less than k, the
`algorithm is executed to a lower level of quality. This
`reduced quality is signaled to the host.
`0HDVXUHG(cid:3)9DOXHV
`(cid:17)(cid:17)(cid:17)
`(cid:20)(cid:24)
`(cid:20)(cid:22)
`(cid:20)(cid:20)
`(cid:17)(cid:17)(cid:17)
`(cid:25)
`(cid:16)(cid:22)
`(cid:16)(cid:24)
`(cid:17)(cid:17)(cid:17)
`
`N(cid:3)VPDOOHVW
`YDOXHV
`
`Figure 5. Clock synchronization algorithm
`
`N(cid:3)ODUJHVW
`YDOXHV
`
`&ORFN
`&RUUHFWLRQ
`7HUP
`
`+
`
`(cid:20)(cid:26)
`(cid:21)
`
` (cid:3)(cid:27)(cid:15)(cid:24)
`
`Of the remaining values, the midpoint of the largest and
`smallest values is derived. The result of this operation
`represents the deviation of the local clock from the global
`time and serves as the basis for correcting the local
`clock.
`
`Correction of the local clock - The correction terms
`calculated by each node for its local clock at the end of
`the communication cycle is then applied in the next
`communication cycle. The correction is distributed evenly
`over the complete communication cycle, eliminating
`instability in the time basis. A correction phase of the
`communication cycle n coincides with the measuring
`phase of the communication cycle n+1, so that the
`stability of the time base continues to be maintained over
`several communication cycles.
`
`External clock synchronization - In addition to internal
`clock synchronization, which synchronizes the nodes of a
`communication network, FlexRay offers the option of
`feeding in an external time base via the local clock of one
`of several nodes. A field to be written by the host is
`provided for this purpose, in which an external correction
`term can be entered from an application. This term
`replaces the calculated local correction term and thereby
`influences the global time basis. Using this mechanism, it
`is possible
`to synchronize
`the global
`time of a
`communication network with an external time base (e.g.,
`with the time base of another communication network or
`with a reference time received via GPS).
`
`SYSTEM CONFIGURATION - The protocol must be
`parameterized before startup. Once in operation, these
`parameters are protected against changes. By adjusting
`the baud rate and cycle time, it is possible to adapt the
`protocol to different applications with different control
`cycles and sample rates. The “slot length” and “number
`of slots” parameters for the static part define the duration
`of the static part in the communication cycle. In the other
`part of the cycle, bus access takes place using the
`dynamic access procedure familiar from byteflight. This
`necessitates the configuration of
`timing parameters
`which determine the length of pauses between frames in
`the dynamic part /4/.
`
`FLEXRAY COMMUNICATION CONTROLLER
`
`is currently preparing a detailed protocol
`Motorola
`specification and is working on a first implementation of a
`FlexRay communication controller, which will be
`evaluated in an FPGA prototyping environment. During
`the last couple of years, Motorola has built a significant
`level of experience and expertise in the field of time-
`triggered and mini-slotting based communication
`architectures.
`Distributed,
`fault-tolerant
`clock
`synchronization and the implementation of the byteflight
`protocol are two examples that will directly flow into the
`development of a FlexRay communication controller.
`
`Page 7 of 14
`
`

`
`This section gives an overview on the Motorola FlexRay
`plans and activities.
`
`PROTOCOL MODELING – FlexRay is a new protocol
`that has been designed based on the knowledge of
`existing solutions (byteflight, TTP). Nevertheless, every
`innovation has a certain potential
`for unexpected
`behaviour. Therefore Motorola decided
`to study
`implementations of the new protocol as early as possible.
`Already during the protocol definition phase Motorola
`started to build a Virtual Prototype, a simulation model of
`a FlexRay controller.
`
`
`Multiple Benefits - A first full-featured protocol model was
`
`ready shortly after the protocol definition was frozen,
`much earlier than an FPGA could have been built. A
`close feedback loop between the modeling team and the
`protocol definition
`team helped
`to discover open
`questions very early in the process.
`
`In parallel to the controller modeling the team started to
`define and develop all kinds of tests: protocol robustness
`tests, scenarios
`to study
`fault
`tolerance, startup
`scenarios, boundary tests going to and beyond the limits
`of different parameters, tests to study different algorithms
`for startup, clock synchronisation, etc. This allowed to
`
`•
`•
`
`•
`
`analyze the characteristics of the FlexRay protocol
`check the controller model’s compliance to the
`protocol specification
`prepare tests for design verification (FPGA and
`silicon)
`
`The model will also serve as an executable specification
`for the FlexRay protocol, which may be distributed as a
`reference model.
`
`
`Modeling Level and Accuracy - The different application
`
`areas of the model have different requirements: Some
`demand high simulation performance while others need
`high accuracy. Motorola tried to fulfill both with an
`enhanced token based approach that allows to model
`effects down to the bit level of the protocol. It runs on a
`high performance event based simulator.
`
`Every frame is represented by a token, so only one event
`is generated to model a complete frame transmission.
`Delays and reaction times are calculated rather than
`simulated. The reduced number of events results in a
`very high simulation performance so that a complete
`FlexRay network with multiple nodes can be simulated.
`Nevertheless, effects on the bit level like bits toggling due
`to transmission errors or noise can be modeled and
`cause the model to behave according to the protocol
`specification. This allows to study a FlexRay based
`system under error conditions, which
`is extremely
`important
`for a protocol
`for dependable control
`applications.
`
`The timing of the model is absolutely accurate with
`regard to the FlexRay protocol. The complete register
`map of the controller is reflected with support of all
`features, so it is possible to use this model for software
`development. Reactions of the model match the timing of
`the protocol spec, so it is possible to track starting times
`of static and dynamic slots as well as the speed and
`correction of each controller’s local synchronised clock.
`
`Major characteristics of the model are
`
`•
`•
`
`•
`•
`•
`
`100% support of protocol functionality
`full
`timing accuracy according
`to
`protocol including clock synchronisation
`support of all controller registers
`high simulation performance
`capability to model various types of faults in the
`system
`
`the FlexRay
`
`The model is used as reference for the controller design
`and therefore is an accurate and verified model of the
`real controller.
`
`BLOCK DIAGRAM - Figure 6 shows a basic block
`diagram of the FlexRay module. The module consists of
`the following high level units: A register block and a
`message buffer interface, together forming the interface
`to the host CPU, a message state machine, a timing unit,
`a CRC unit, and two receive and transmit units, one each
`per channel.
`
`5HJLVWHU %ORFN
`
`0HVVDJH %XIIHU ,QWHUIDFH
`
`3URWRFRO 6WDWH
`0DFKLQH
`
`&5& 8QLW
`
`7LPLQJ 8QLW
`
`5HFHLYH 8QLW
`5HFHLYH 8QLW
`[

`
`7UDQVPLW 8QLW
`7UDQVPLW 8QLW
`[

`
`Figure 6. Communication controller block diagram
`
`
`Register Block - The register block contains control
`
`registers for configuring the FlexRay device and status
`registers for reading back current status information of
`the protocol.
`
`
`Message Buffer Interface - The message buffer interface
`
`is used by the CPU to receive and transmit data. It
`contains a number of buffers with an associated control
`register that allows to configure each buffer individually
`
`Page 8 of 14
`
`

`
`as receive or transmit buffer. Currently, 32 16-byte
`message buffers are planned, although this number is
`subject to change as application requirements become
`clearer. The following section gives more details on the
`message
`buffer
`interface
`and
`the
`associated
`mechanisms.
`
`Protocol State Machine - The protocol state machine is
`
`
`the core of the communication controller. It implements
`the complete protocol
`logic, such as handling of
`messages, establishing
`the communication cycle,
`startup, and error handling.
`
`
`Timing Unit - This unit is responsible for the timing
`
`control of the protocol, including support of the distributed
`clock synchronization.
`
`
`CRC Unit - The CRC unit is used during message
`
`transmission and reception to generate and check the
`CRC checksum of each data frame.
`
`
`Transmit Units - The two transmit units transform the
`
`data contained in a transmit message buffer into a serial
`output stream. The units also encode the data, either in a
`standard serial NRZ 8N1 (8 data bits, no parity, 1 stop
`bit) code, or into a Miller/MFM-based code called Xerxes.
`It shares the distinction of clock points (between bit cells)
`and data points (at the center of bit cells). Xerxes groups
`the bit stream into distinct sequences with different
`coding rules for each:
`
`(a) any number of 1s without 0s (111..11)
`(b) any even number of 1s with a leading 0 and a closing
`0 (011..110)
`(c) any odd number of 1s with a leading 0 and a closing
`0 (011..10)
`(d) a pair of 0s (00)
`
`Subsequences of type (a) are encoded by a transition at
`the data point of each bit cell (standard Miller/MFM
`coding). Type (b) sequences are encoded by transitions
`at the clock points at the beginning of each pair of 1s and
`by a transition at the clock point at the end of the last pair
`of 1s. Subsequences of type (c) are encoded by
`transitions at the clock points at the beginning of each
`pair of 1s and by an additional transition at the data point
`of the last (odd) 1. Finally, subsequences of type (d) are
`encoded by a transition at the clock point at the end of
`each bit cell (standard Miller/MFM coding).
`
`
`Receive Units - The receive units decode the encoded bit
`
`stream and fill the corresponding message buffer with the
`received data.
`
`CPU INTERFACE AND DEVICE CONFIGURATION -
`This section gives an overview of the currently planned
`message buffer interface. Since the message buffers are
`also used to configure the communication cycle, this
`topic is also covered in this section.
`
`
`Interface Structure - At the core of the FlexRay host CPU
`
`interface are a number of message buffers. Each of
`these buffers can be configured as a transmit or as a
`receive buffer through an associated buffer control
`register. As a conventio