Table of Contents

Title Page


Why this book now?

Today, protocols for multiplexed industrial networks such as CAN, LIN and others are relatively mature, and only a few aspects such as ‘Time-Triggered Protocol’ and ‘X-by-Wire’ systems continue to evolve.

On the two latter subjects, little information or technical training is available to engineers, technicians or students. We hope that this book will at least partly fill this gap.

I waited for a long time before again dipping my pen into the inkwell of my PC(!). I preferred to wait until there were no announcements of the ‘free shave tomorrow …’ type in sight. Which, of course, as usual, took a long time … Version 2.1, revision A of FlexRay was delivered officially to the public in March 2005, then some minor modifications and additions (conformity tests) called rev. 2.1 A and B were added in November 2006, and finally, at the end of 2010, there was 3.0, which clarified some points of detail.

Above all, this book is not intended to give a literal translation of the standard, the original version of which can be downloaded free from the official website of the FlexRay Consortium (). Instead, its aim is to act as an introduction and a detailed teaching presentation of the technical principles and operation of the FlexRay protocol. It is also aimed at giving newcomers an overall view of the concepts and applications.

The aims which FlexRay was intended to achieve (speed and security of communication, flexibility in operation, real time, distributed intelligence, network topologies, and so on) made it necessary to design the structure of the communication protocol so that it is directly related to the physical performance of the physical layer. When you read this book, always keep in mind the concerns generated by the physical layer (the medium and its management). Ideally, just as in music (see below), it would be necessary to present the communication protocol and the physical layer and their interactions simultaneously and in parallel … which is mechanically difficult for a publisher, however experienced!

Something else you should know is that the content of the FlexRay protocol is dense, and includes numerous technical concepts which collide with each other, become confused with each other and intersect with each other, which makes it difficult to choose a plan for presenting the various chapters.

Author's note

To cover this subject of ‘multiplexed networks’ correctly, this book describes many patented technical principles which are subject to the operation of licences and their associated rights (bit coding, communication techniques, and so on), and which have already been published in official, professional technical texts or communications, or during public conferences or seminars—but above all, which must be used according to the legal rules in force.

How to read this book

In a previous book (Multiplexed Networks for Embedded Systems: CAN, LIN, FlexRay, Safe-by-Wire), we provided an overview, which was complete at the time, of this evolving field, using long technical introductions on these subjects. Today, this book, which is entirely about FlexRay, is dense because virtually all the ‘real’ subjects—principles, components, applications, security, and so on—are approached in practical terms. Also, to avoid discouraging the reader who is trying to understand these devices, we have put great stress on teaching so that the link between theoretical, technological, economic and so on aspects can be constantly established.

The challenge is therefore to present everything in the clearest, most suitable manner. After long reflection and long oscillations, it has been necessary to choose a comprehensive presentation so that you, the Reader, can find your way easily through the maze of all these emerging communication principles and new protocols. We also advise you, before approaching the technical details which will be explained in the following chapters, to take the trouble to read the next few lines, which are intended to explain the why and how of the plan of this book and how to use it.

The aim of the introduction is to make your mouth water by giving a general survey of the applications which daily affect the motor vehicle and embedded systems of all types. Obviously, everything we have written in this book can be generalised to industrial applications of all kinds (control of machine tools and production lines, avionics, rail transport, building automation, transport of digital images, and so on).

The first part (A) is a reminder of the CAN protocol, a quick mention of the operation and contents of the TTCAN protocol and a review of the latest applications of ‘X-by-Wire’ type. We will briefly discuss the functional and application limits of CAN, and we will consider ‘event-triggered’ and ‘time-triggered’ communication systems, and all the implications which that consideration generates for so-called ‘secure real time’ applications.

In the second part (B) we will present, progressively, FlexRay and its protocol, in terms of communication cycles, decomposition of cycles into frames, format and content of frames, omitting any consideration of clock synchronisation between nodes.

Then, in the third part (C), we will go on to the analysis of the physical layer and the basic concepts of bit coding, propagation and topologies which can be used, and their effects. The problems of network synchronisation in operation and during the wakeup and startup phases are the subject of the fourth part (D). We will consider the architecture of a node, components of a FlexRay network, AUTOSAR and the range of associated hardware and software tools for providing support for development simulations, verification stages, production, maintenance, and so on in the fifth and final part (E).

A little music in this brutal world

Let us finish this introduction on a lighter (musical) note. Very serious discussions with some friends and FlexRay designers one day led us to the conclusion that a FlexRay system could be seen as a little like a musical score. The protocol description represents the melody in a treble key, and the physical layer represents the accompaniment in a bass key. In fact, with FlexRay as for reading a musical score, it is necessary to succeed in following the score not only by reading the two horizontal staves simultaneously, but also by reading the score ‘vertically’, to recreate the whole correctly. Additionally, like any well-informed musician, it is necessary to read ahead while playing! Welcome to FlexRay for musicians and future musicians!

I wish you good and productive reading throughout the pages of this book—above all, enjoy it, because I didn't write it for myself but for you! If there is still a shadow of a doubt about the subject and form of this book, your (constructive smiley) comments, remarks, questions and so on are always welcome by e-mail to my address, .


The subject of multiplexed communication systems and networks is growing day by day, and very many skilled people are working in these fields. Luckily, I have had the opportunity to meet many of them, and consequently it is very difficult for me to thank everyone individually.

Nevertheless, I must address some special thanks to several groups of people:

It would be ungrateful not to thank also the numerous colleagues in the profession, and motor vehicle and equipment manufacturers, whom I meet regularly either at working meetings or at ISO, for their remarks and comments about the editing of this book, thanks to whom we all hope that this subject of multiplexed buses will blossom as it deserves.

Finally, I am very glad to thank Ms Manuela Philipsen of the ‘Marcom’ team of NXP Semiconductors in Eindhoven, for the numerous documents and photographs which she has been kind enough to supply to me for years to illustrate these books. Even more finally, I am also immensely grateful to the Vector Informatik GmbH company of Stuttgart (Mr Uwe Kimmerley and the whole FlexRay team) and Vector France SAS of Paris (Mr Henri Belda, Mr Jean-Philippe Dehaene, Ms Hassina Rebaïne and Ms Rim Guernazi) for their technical and logistical support, their participation in the editing of certain chapters and for having had the kindness to agree to supply numerous very fine educational illustrations to enrich this book. In fact, this type and quality of teaching aid is fundamental to good distribution of knowledge, and in Vector's case is part of very rich support for professional training which is useful for spreading a technique and a technology. Setting up such support requires a large investment in time and money, and authorisation to publish them—even in part—really deserves to be welcomed as much as the quality of their content. So a big thank you for having done and authorised that.

Dominique Paret



 All (1 - Γ2) and (voltage) standing wave ratios included (naturellement).

List of Abbreviations

ABS anti braking system
ADC analogue to digital conversion
AP action point
Autosar automotive open system architecture
BD bus driver
BER bit error rate
BSS byte start sequence
CAN controller area network
CAPL Communication Access Programming Language
CAS collision avoidance symbol
CC communication controller
CDD CANdela Data Diagnostic
CDF cumulative distribution function
CHI controller-host interface
CID channel idle delimiter
CPU central processing unit
CPU/ECU central processing unit/electronic control unit
CRC cyclic redundancy check
CSEV channel status error vector
CSS clock synchronization startup
DLC data length coding
DLL dynamic link library
DPI direct power injection
DTS dynamic trailing sequence
ECC error correction code
ECU electronic control unit
EMB electromechanical braking
EMC electromagnetic compatibility
EPL electrical physical layer
EPLAN electrical physical layer application notes
ESD electrostatic discharge
FES frame end sequence
FIFO first in, first out
FSEV frame status error vector
FSS frame start sequence
FTDMA flexible time division multiple access
GTDMA global time division multiple access
HIL hardware in the loop
LIN local interconnect network
MTs macroticks
MTS media access test symbol
NIT network idle time
NRZ no return to zero
OEM original equipment manufacturer
OS operating systems
OSI open systems interconnection
OSI/ISO open systems interconnection/International Standard Organisation
PDF probability density function
PDUs protocol data units
PLL phase locked loop
PS protocol specification
RF radio frequency
RTE run time environment
SBCs system basic chips
SD dynamic segment
SHF super high frequency
SOC start of cycle
ST static segment
SW symbol window
SWCs software components
TDMA time division multiple access
TRP time reference point
TSL test set library
TSS transmission start sequence
TTCAN time-triggered communication on CAN
TT-E time-triggered external
TT-L time-triggered local
TTP/C Time Triggered Protocol Class C
Tx transmission
UHF ultra high frequency
VDR voltage-dependent resistors
VFB virtual functional bus
WCET worst case execution time
WUP wakeup pattern
WUS wakeup symbol

Part A

‘Secure Real Time’ Applications

Chapter 1

Reminders about the CAN Protocol

As an introduction to this chapter, we will remind you of some general points about all the architectures of embedded systems, and starting from now we will take a very surprising turn by passing judgement on the properties of the well-known controller area network (CAN) protocol, presenting its principal limitations and finally imagining solutions which open up new horizons for decades to come.

1.1 The Limitations of CAN

Firstly, the concept of CAN, which was designed almost 30 years ago, is perfect for current applications, and will remain perfect for very many applications. However, time passes, and some of the inherent limitations of CAN, which have been known since its genesis, are now clearly visible. They are:

It should be noted that all these points have been covered by the appearance of the FlexRay concept, which we will describe in detail later.

1.2 ‘Event-Triggered’ and ‘Time-Triggered’ Aspects

1.2.1 The Probabilistic Side of CAN

By its design and structure, the CAN protocol encourages transmission of communication frames when events occur at a node of the network. This is what is called an ‘event-triggered’ system. In fact, often a participant sends a message following an action, a reaction or a request for information as a function of the requirements of the intended application and/or of its own task.

As we explained in numerous previous works, CAN messages are prioritised (offline) by the system designer, using values which the designer has chosen to assign to the identifiers of the communication frames. On this principle, at a given instant, no node can be certain that its message is transmitted immediately, because of the conflict management and arbitration resulting from the values of the competing identifiers at this precise moment of access to the network. This type of concept and the management of it give transmission of messages on the network in CAN a strong ‘probabilistic’ emphasis, because it is subject to the arbitration procedure. The latter is a function of the respective values of the competing message identifiers at the time of the attempt to access, and then seize, the bus or medium, which makes the timing of this transmission – and the associated latency time – very dependent on the probability of the appearance of the respective values of the identifiers.

The only true CAN message which is truly ‘deterministic’ is the message with the identifier hex 0000, since, for this identifier value only, the latency time is strictly known, and its value is ‘one CAN frame minus one bit plus the inter-frame time (3 bits) …’, since, to within a bit, this (highest priority) message could not access the network last time round.

For other messages (identifiers other than hex 0000), that depends on big ideas of scheduling, obscure calculations of probability applied to the respective values of the activity model of the network, and to the appearance of the respective values of the competing message identifiers. Also, the probability of this arbitration phase taking place is excessively high, since each time the medium is occupied – as is very often the case – all the other nodes which have been unable to access it wait for the propitious moment to try to get it back, and all starting at the same moment, just after the inter-frame phase required by the CAN protocol, are all immediately subjected to the arbitration procedure.

The problem then occurs when what is wanted is to communicate – transmit or receive – definitely, at a precise, predetermined instant, so that the timing is deterministic. In principle, nothing in CAN permits this. Consequently, it is necessary to create new systems, certain actions of which are triggered spontaneously at precise instants. These are usually called ‘time-triggered’ (TT) systems; that is, in our case three principal concepts, TTCAN, TTP/C (or Time Triggered Protocol Class C) and FlexRay, which we will explain in detail below.

1.2.2 The Deterministic Side of Applications

In very many applications, it is or becomes necessary to trigger certain actions spontaneously at precise instants. Such systems are called ‘time-triggered’ or systems functioning in so-called ‘real time’ mode. When systems must function in ‘real time’ (which in principle does not exist and is merely an abuse of language), the big problem occurs when what is wanted is to be sure of communicating – transmitting or receiving – at a predetermined instant, or in specific time slots, thus adding a ‘deterministic’ aspect to communication.

As already mentioned, in principle nothing in CAN makes it possible to guarantee this. In these cases, it is therefore necessary to set up a mini real time ‘operating system’ of TT type, for example on the higher layers of the OSI (Open Systems Interconnection) model (at layer 5, ‘session’ or layer 7, ‘application’) or to integrate or encapsulate this type of function into a definition of the protocol which is capable of solving all or part of this problem.

To do this, customarily, so that information can circulate on the network, specific, well-defined time windows are used. How these time windows are implemented is, in principle, completely free and non-limiting. The only specific point consists of ensuring that all the participants are perfectly synchronised, so that each can talk or respond in its turn without overlapping into the time windows of its neighbours. To do this, it is generally necessary either to transmit a ‘reference clock’ cyclically to the whole network so that each participant resets its clock or to synchronise the clocks of all participants.




 We refer anyone who is interested in this subject to the numerous publications written by Mr Laurent George.

 To remove any doubt, the term ‘real time’ is customarily understood as actually implying ‘time with known latency’, that is it means that one is certain that at a precise instant the thing which is supposedly being done actually is. Also, very often the terms ‘real time’ and ideas of ‘deterministic’ systems are confused. How, in certain deterministic conditions, the whole functioning can be assimilated to an idea of ‘functioning in quasi real time’—that is, with deterministic access to the communication medium and known latency times—will be explained below.

Chapter 2

The TTCAN Protocol

In the early 1990s, the dominant position of CAN in the market, and the increasing complexity of embedded systems, rapidly caused a demand for protocols which guarantee responses in ‘real time’, deterministic solutions and greater security. Consequently, systems using ‘Global Time’ devices were designed. The first of them which was actually used in industry, in the automotive field, was the ‘TTCAN’ (time-triggered communication on CAN) protocol, which was proposed by the R. Bosch company and the ‘CAN in Automation’ (CiA) group in TC 22/SC 3/WG 1/TF 6 of ISO, before becoming, in early 2002, ISO Standard 11898-4.

2.1 TTCAN—ISO 11898-4

TTCAN forms a protocol layer at a higher level than that of CAN itself, without in any way modifying the structure of the data link layer (DLL) and physical layer (PL) of the latter. To do this, TTCAN is placed mainly at the level of layer 5, called ‘session’, of the Open Systems Interconnection/International Standard Organisation (OSI/ISO) model, which in other words comes back to saying that the structure of the TTCAN protocol was designed to be encapsulated in the transport protocol of CAN.

The aim of TTCAN is to define and guarantee the latency time of every message at a specified value which is independent of the load on the CAN network itself. This protocol can be implemented at two levels:

Given that the aim of this book is not to describe this particular standard in detail, we refer you to the official documents for fuller information. However, we will summarise the broad outline in a few paragraphs.

It should be noted that TTCAN comes between CAN and FlexRay, and that use of it can make it possible—in certain applications—to reduce the load (over time) on some existing CAN networks and structures, or to regulate them. Its description corresponds to a session layer (number 5) of the OSI model (between layer 2, ‘data link’, and layer 7, ‘application’), and is inserted into the original, overwritten CAN model. In short, to understand the CAN concept better, let us remind ourselves of the foundations of the session layer of the OSI model.

2.2 Session Layer

As a brief reminder, the OSI/ISO definition indicates clearly that: ‘The purpose of the Session Layer is to provide the means necessary for cooperating presentation-entities to organize and to synchronize their dialogue and to manage their data exchange. To do this, the Session Layer provides services to establish a session-connection between two presentation-entities, [and] to support orderly data exchange interactions’. This layer:

Thanks to it, references to different systems are made by symbolic names and not by network addresses. Also, it includes elementary synchronisation services and recovery at the time of an exchange.

2.3 Principle of Operation of TTCAN

TTCAN is based on a timed deterministic exchange, which is itself based on pre-established time windows of an operational cycle, also pre-established, and the overall operation of which can be visualised with the help of the matrix of lines and columns shown in . This matrix summarises the general principle of the operation of this protocol.

General principle of operation of the TTCAN protocol


All messages that must circulate on the network between the CAN nodes are organised like elements of an X by Y matrix. This system in the form of a timing matrix consists of time windows which are organised in ‘basic cycles’, with identical time values (shown by the whole of each of the lines X of the matrix), and in numerous time zones (windows) during which transmission is authorised (shown by the columns Y of the matrix). This matrix system thus defines the correlation between the time windows and the presence of messages on the network.

The principle of operation of TTCAN assumes that one of the nodes of the network is responsible for the organisation of the slicing and the time assignments which are considered. In fact, when the system starts, this node assigns to every node the time phase(s) which are reserved for it.

Consequently, the system becomes deterministic, since each of the nodes has the right to express itself at a precise moment, which it knows, and for a well-determined length of time. Obviously, this does not at all constitute a real time system, but if all the cycles are covered in full sufficiently quickly, the system quickly comes back to the same node, and this appears to all the participants like access to the network in ‘quasi real time’.

To be more explicit, here is an example, greatly exaggerated but quite representative of the principle which is used:

“From now until further notice, the duration of the basic cycle will be 1 hour, and here is the time window sequence for each of you:

you, node no. 2, you don't have much to say, you will talk from the hour (hh.00) to hh.05;

I, node no. 1, since everyone knows I'm a chatterbox, I'll talk from hh.05 to hh.20;

you, node no. 3, you'll talk from hh.20 to hh.25;

if you want to, everyone can talk from hh.25 to hh.30, under arbitration by CAN;

you, node no. 2, you still don't have much to say, you can talk again from hh.30 to hh.35;

you, node no. 4, you'll talk from hh.35 to hh.45;

you, node no. 2, you can talk again from hh.45 to hh.50;

you, node no. 5, you can talk from hh.50 to hh.55;

from hh.55 to the hour, nothing definite—everyone welcome—under arbitration by CAN;

and so that you all set your watches, I inform you that it is now very exactly 10.54.”

Through this very embellished example, we hope that you have understood the basic mechanism of TTCAN. You have certainly noticed in passing that, to avoid harmful effects caused by drift of the clock of each of the participants, each basic cycle begins with a reference message. Also, within one cycle, we have allowed node number 2 to speak several times, although it has little to say each time, but it has to provide information frequently. How time is distributed is, in principle, absolutely free, and left to the goodwill of the cycle manager. For obvious reasons of synchronisation and possible drift, the ‘time master’ must send the reference message periodically. Also, you will notice that the electronics of each node must be capable of maintaining a certain clock precision throughout the duration of a cycle, so that it does not overlap with the other participants, since new clock information will not be received until the start of a new communication cycle.

In a more structured manner, TTCAN defines that (see ):

Obviously, the daily reality in application is quite different, on the one hand because of a host of constraints because of the systems in use, and on the other hand because it is frequently necessary to reconfigure the time sequence because of external events, foreseen and not foreseen.

So there, summarised as simply as possible, in a few paragraphs, is the philosophy of the TTCAN concept. If you want more detail on this protocol, refer to:




 For those who do not speak ISO fluently, this means ‘Technical Committee 22 (Road vehicles), Subcommittee 3 (Electrical and electronic equipment), Working Group 1, Task Force 6’.

Chapter 3

Emergence of ‘X-by-Wire’ Systems

What strange, barbaric words! ‘High throughput’: no problem! ‘Redundant’ and ‘redundancy’ indicate that some functions, message transmissions, physical media, and so on are doubled, tripled, x-times-ed to provide the desired security in operation. That leaves ‘X-by-Wire’, so let's look at that.

3.1 High Throughput and X-by-Wire

To satisfy the more and more greedy requirements for rapid processing of information, future systems and concepts must be capable of supporting high communication bit rates, with everything that implies in terms of performance of the physical layer, transmission quality, synchronisation between nodes, and so on.

The generic term ‘X-by-Wire’ includes all types of application which implement ‘systems controlled by wire links’, which are also understood not to have ‘any other control which is carried out via a mechanical interface’. Actually this is not new! For several decades, numerous embedded systems used in the aviation industry have operated according to ‘… by wire’ models (for example the first Airbuses). For a long time, the control surfaces and flaps of aircraft have not been controlled mechanically using rods, hydropneumatic jacks and other mechanical systems. These controls have been replaced by electric motors which are controlled using wired networks, connected to each other and arranged in a bus topology or otherwise—and it even works correctly—otherwise, we would know! Surprising as it may seem, to ensure that the systems concerned are very safe, that can be done by taking a mass of structural precautions, sometimes without any physical and/or software redundancy.

3.2 Redundancy

Of course, to ensure a higher level of operational safety in all these systems, it is sometimes worthwhile to imagine devices with some supplementary redundancy, whether in communication, or in the physical layers, or in the two together. And in fact, the automotive world and other industrial application sectors are very interested in these technologies—with the start of mass production forecast for around the years 2012/2015—for the same reasons as those which guided their predecessors in aviation, progressively replacing mechanical controls with controls ‘by wire’. To begin with, goodbye to suspension springs that suffer fatigue (even on board a vehicle stopped on the roadside!), anti-roll bars to assist road-holding, steering columns that can pierce the stomach in the case of impact, steering racks, master brake cylinders that can leak, accelerator control cables that stick or break! And long live the weight reductions of equipment in vehicles—and therefore their excessive consumption and pollution—and the improvements of passive security in case of collision. And then, for example this technology will offer greater flexibility for overall mechanical design and exterior and interior design of vehicles (see some futuristic photographs in –). It will even be possible, on a single model, to make minor modifications so that vehicles with right-hand or left-hand drive are easily available, or a more innovative design of the instrument panel, or the possibility of getting rid of the brake and clutch pedals … and finally, the constant reduction of cost. In short, the future is ours!






After the fantastic predictions of our favourite crystal ball, which will become reality in volume within 6–10 years from now, it is now necessary to think about action, as we reflect on the numerous problems to be solved. That is what we propose to do now.

3.3 High-Level Application Requirements

Let us take up the story and examine our future embedded system. Let us begin by observing the trends of tomorrow's vehicle architectures and embedded systems.

3.3.1 The Number of Communication Systems is Growing

In case you didn't know, a high-range car already (in 2011) counts between 60 and 75 central processing units (CPUs) (!), and also has five or six CAN networks (high speed and fault-tolerant low speed) and six or seven local interconnect networks (LINs). Consequently:

3.3.2 The Electronic Architecture Must be Common to Several Vehicle Platforms

The electronic architecture must be common to several vehicle platforms, so that it can induce large synergies, rapid migration taking innovation with it and cost reduction. Every motor vehicle and equipment manufacturer is becoming more and more specialised in its particular fields of skill, and the direct consequence is the need to be able to design the electronic and electrical architecture of the intended system in a manner which is modular and capable of evolving at a variable scale or geometry (the famous idea of ‘scalable’). This structural elasticity (scalability) has implications at different levels:

3.3.3 Some Things the Architecture of the Communication Network and the Nodes Must Allow

The architecture of the communication network and the nodes must allow:

Let us look quickly at the functional requirements of these new technical and industrial strategies.

3.4 High-Level Functional Requirements

From the start of the project, depending on what applications are intended, all the possibilities of optimising devices must be used, up to the physical limits of the principles that are used and of the components of the physical layer.

3.4.1 Speed of Communication

The quantity of information to be transported is much greater, and it is richer in content and quality. Consequently, the communication bit rate (1 Mbit/s) of the CAN high speed network which has been used until now is no longer enough. The gross throughput required for these new systems is of the order of 10 Mbit/s on a single-channel medium (with a net throughput of about 7.5 Mbit/s compared with 500 kbit/s for CAN) or on a dual-channel structure with a higher throughput and providing possible redundancy.

3.4.2 Physical Layer

The physical medium which is used for communication must be capable of being supported by at least two different technologies, for example one of wired type (e.g. differential pairs) and the other of opto-electronic type (e.g. plastic optical fibres), and must make it possible to put the network nodes into sleep mode, and wake them up, via the medium. Also, the signals that circulate on the physical layer must not pollute the radio frequency band (low emission of radio-frequency disturbance), and must be highly immune to interfering external signals. Additionally, ‘containment errors’ must be managed using an independent bus monitoring element, for example a physical or software ‘bus guardian’.

3.4.3 Access to and Management of the Medium

From experience, in this type of concept, access to the medium in time is always an important and delicate point. To satisfy all the functional and security aspects of the network, the following are necessary:

3.4.4 Synchronisation Method

A reliable method of synchronisation—more precisely, globalisation of time—must be set up, to ensure that the operation of the various elements of the network is perfectly synchronised. To do that, several elements must be available, in particular:

Also, the system must be capable of supporting momentary disappearances and reintegrations of nodes of the network, and cold and hot restarts of the network.

3.4.5 Network Topologies

As will be explained in more detail in Part C, if an increased bit rate and reliability of communication are wanted, the topological aspect of the network becomes more and more important! It is therefore necessary to consider using new topologies, other than the everlasting ‘bus’ configuration which has kept thousands of users alive until now. We will therefore consider topologies with:

A fine syllabus, don't you think?

3.4.6 Requirements at System Level

On the basis of these different topologies and different performances which are required from the physical layer as explained above, it is also necessary to design a fault-tolerant system; that is, one which can tolerate faults and incidents in operation, has a dual transmission channel, detects its own errors and sends diagnostic messages. It is also necessary to think hard about setting up redundancies between the CPUs in each node, to ensure reliability of operation by multiple physical redundancies on the one hand, and redundancy of transmission on the other hand. Also, if only to make maintaining them, revising them, and so on easier, the systems must, sooner or later, be standardised (internationally by ISO if possible), interoperable, reusable (reuse being in fashion, as everyone knows), open to everyone, with no exclusive rights clause or payment of royalties, certified by recognised testing laboratories. In particular, they must offer a wide range of development tools during the design phase (emulators, simulators, and so on) and system integration phase (monitoring, fault injection, and so on), and of course have numerous component suppliers. In short, everyday stuff, the same old story—not forgetting the classic ‘better for less cost’.

So we have quickly described the functional framework of these new networks, which, as you have no doubt noticed, are very distant from CAN but complementary to it. Let us now look at what proposals can respond to it.

Part B

The FlexRay Concept and its Communication Protocol

For teaching reasons (so that everything is not mixed up!), the purpose of this second part is to present only the most general aspects of the FlexRay concept. Parts C and D of this book will fill in the missing points of the concept in detail. This part therefore presents:

A very specific application example offers a synthesis of the content of the chapters listed above. Also, as you will very quickly appreciate, there are many things that are not said and hidden techniques in one of the parts about modes of access to the medium. Which one? Wait and see! The technical appendix which resolves most of this unbearable suspense forms a whole separate chapter.