6 Time-Triggered Protocols FlexRay

6.1 Some General Remarks

CAN (controller area network), created more than 20 years ago, is perfect for today's applications, but inevitably the passage of time reveals some of its limitations. CAN is very much event triggered (i.e. communications are initiated by events), and it lacks a 'real-time' orientation, or in other words, a 'time-triggered' philosophy. To overcome this, the first response was to create an upper layer called 'TTCAN', triggered by temporal events, to help revive CAN

 The gross bit rate of CAN is limited to 1 Mbit s-1 and future applications will be more orientated towards gross bit rates of 5-10 Mbit s-1. So everything must be redesigned. it is rather difficult to create a network architecture/topology on CAN principles which provides redundancy of communications in the physical layer and thus offers the prospect of designing systems controlled entirely by links operating according to the well-known Xby-Wire ('all-by-wire') concept.

6.2 Event-triggered and Timetriggered Aspects

Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events. An event can be defined as "a significant change in state". The Time-Triggered Protocol (TTP) is a convention used to facilitate fault tolerant communications between distributed real-time computing platforms (Kopetz & Grunsteidl 1993). TTP is used in hard real-time, highspeed, safety critical applications. The protocol has been designed specifically for safety critical systems. There is a published fault hypothesis that guarantees to tolerate one arbitrary fault.

6.2.1 The intrinsically probabilistic aspect of CAN

the CAN protocol encourages the transmission of communication frames when events occur in a node: it is called an event-triggered system. This is because a participant often sends a message following an action or a request for information, as required by the application. CAN messages are ordered hierarchically by the system designer, using values that he assigns to the identifier values. This makes the transmission and its associated latency time very dependent on the probability of the appearance of the respective values of the identifiers. This means that CAN messaging is 'probabilistic' because it is subject to the arbitration procedure, which itself is dependent on the corresponding values of the identifiers of the messages

 The only truly 'deterministic' message is the message whose identifier is 0000 hex. the latency for this identifier only is known and is equal to 'one CAN frame, less one bit, plus the interframe time (3 bits)', For the other messages (with identifiers other than 0000 (hex)), it is a probability of the competing message identifiers. A problem arises if we want to be sure of communicating (transmitting or receiving) at a given instant - in other words, to be temporally deterministic. The principle of CAN means that this cannot be done. It is necessary to create systems in which certain actions are triggered deliberately at precise instants; these are commonly called time-triggered systems, including in our case the three concepts TTCAN, TTP/C and FlexRay,

6.2.2 The deterministic aspect of applications

In some applications, it is necessary for some actions to be triggered deliberately at precise instants: these are time-triggered (TT) systems, also known as 'real-time' systems. the major problem arises when we wish to be sure of communicating (transmitting or receiving) at a given instant or in a specific time slot... thus making the communication 'deterministic' in nature. the CAN principle is such that this cannot be achieved we must therefore establish, in the upper layers of the OSI (Open Systems Interconnect) model (layer 5, the 'session layer', or layer 7, the 'application' layer), a realtime (time-triggered) mini-operating system, To do this, we usually establish special time windows for data to be circulated in the network.

6.3 TTCAN - Time-Triggered Communication on CAN

TTCAN (time-triggered CAN), was proposed by the CAN in Automation (CiA) group and the Bosch company in the ISO TC 22/SC 3/WG 1/TF 6 at the beginning of 2002 and was to become the ISO 11898-4 standard.

6.3.1 TTCAN-ISO 11898-4

TTCAN is located primarily in the session layer of the OSI/ISO (International Standardization Organization) model This protocol can be implemented on two levels: - level 1 is limited to the transfer of cyclic messages; - level 2 supports what is known as a 'global time' system. Its specification corresponds to a session layer (5) of the OSI model (located between the data link layer 2 and the application layer 7),

Session layer
The ISO definition says '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 provides the functions for supporting the dialogue between processes, such as initialization, synchronization and termination of the dialogue the references to the different systems consist of symbolic names instead of network addresses.

Operating principle of TTCAN

TTCAN is based on a deterministic temporal exchange, based on a time window of a pre-determined operating cycle All the messages travelling in the network between the CAN nodes are organized as elements of an X x Y matrix. This matrix time system consists of time windows organized in 'basic cycles', identical time values (represented as the totality of each row of the matrix) and numerous time intervals (windows) during which transmissions are authorized (repre-sented by the columns of the matrix). it defines the relationship between the time windows and the presence of messages in the network.

 The TTCAN operating principle is based on the fact that one of the nodes of the network is responsible for organizing the time division and allocation involved. This is because, when the system starts up, one of the nodes allocates the reserved time phase(s) to precise moment known to it, for a closely specified period. Clearly, this does not constitute a real-time system at all, but if the complete cycle is executed quickly enough, there is a rapid return to the same node, and to all the participants this appears to be 'quasi-real-time' network access.

 Being the controller of the system, I call myself node 1, and I decide unilaterally to allocate the following time phases to the other four participants in the network. To do this, I start by sending them a minimum information required for the correct operation of the system, by means of a special generic message called a 'reference message', using a special identifier, indicating the following. The time interval of the basic cycle will be 1 h from now on and until further instructions. This is the time window sequence for each of you: node 2, you do not have much to say, so you can talk from 00 to 05; I, node 1, am known to be very talkative, so I shall speak from 05 to 20; node 3, you will talk from 20 to 25;

 all of you can talk from 25 to 30, subject to CAN arbitration; node 2, you do not have much to say, so you can talk again from 30 to 35; node 4, you will talk from 35 to 45; node 2, you can talk again from 45 to 50; node 5, you can talk from 50 to 55; from 55 to 00 it is free for all, everyone is welcome to talk - subject to CAN arbitration. So that you can synchronize your watches, I shall now tell you that it is 10.54 precisely.

 each basic cycle starts with a reference message given node 2 several chances to talk because, though it does not say much, it has to report information frequently; the choice of time distribution is absolutely free and left to the discretion of the cycle manager. for obvious reasons of synchronization and possible drift, the reference message must be sent periodically by the 'time master'.

TTCAN specifies that periodic messages are included in exclusive time windows, occasional messages are included in arbitrating time windows, and free time windows are reserved as free spaces for all traffic. the time sequence often has to be reconfigured according to external events, whether expected or unexpected.

6.4 Towards High-Speed, X-byWire and Redundant Systems

What are these strange and outlandish terms? High speed, no problem there. Redundant and redundancy imply a degree of doubling or tripling of functions, message transmissions, physical media, etc. to provide the desired security of operation. But what about 'X-by-Wire'?

6.4.1

High speed

To meet increasing data processing requirements, future systems and concepts must be able to support high communication bit rates, with all that this implies in terms of physical layer performance, transmission quality, internode synchronization, etc.

6.4.2

X-by-Wire

The generic term X-by-Wire conceals all applications using 'systems controlled by wire links', and therefore not having 'any control provided via a mechanical interface'. hydraulic actuators and other mechanical systems; these have been replaced by electric motors controlled by wire networks, interconnected and arranged in bus and other topologies

6.4.3 Redundancy
an even higher security of operation of all these systems requires multiple levels of additional redundancy with mechanical controls being progressively replaced with control 'by wire' The benefits are a reduction in weight of on-board equipment, resulting in lower fuel consumption, reduced pollution and improved passive safety provision in case of impact. this technology will allow greater flexibility in the overall mechanical design and external and internal styling of vehicles

 Redundancy in engineering is the duplication of critical components of a system with the intention of increasing reliability of the system, usually in the case of a backup or fail-safe.

6.4.4 High-level application requirements

Globally, the number of communication systems is increasing. a top-range car now (in 2005) has 60-70 CPUs (!) and also has 5 or 6 CAN networks (high speed + fault tolerant, low speed) and 6 or 7 LINs (local interconnect networks). the number of gateways between systems is increasing; topologies are becoming increasingly complex; there are more and more very high-level interactions between the different systems; the electronic architecture must be common to a number of vehicle platforms,

 As each manufacturer or equipment maker is becoming increasingly specialized in its own specific fields of competence, the electronic and electrical architecture of a planned system must be designed on a modular basis, and in such a way that it can evolve with a variable scale or geometry (the well-known concept of 'scalability'). This structural elasticity has several implications at different levels: - different models and brands of modules must operate on different platforms (effect on scalability and costs); - the interfaces that are created must be completely open (increase in the number of applications);

 the application agreement becomes essential throughout the product design process; the complexity of systems is reduced by more carefully specified interactions between applications; the architecture of the communication network and the nodes must permit - the manufacture of economy vehicles and top-range models on the same platform; - the support of communications by simple, double or mixed/combined physical communication channels; - clear visibility of the network for each field of application (chassis, security, power systems, environmental detection, etc.); - the use of inexpensive components (for example, piezoelectric resonators instead of quartz ones).

the functional requirements of these new technical and industrial strategies

High efficiency From the outset, and depending on the planned applications, the devices must be optimized in every possible way, up to the physical limits of the principles followed and the components of the physical layer.

the functional requirements of these new technical and industrial strategies

Speed of communication Because of the larger amount of data to be conveyed, and the increase in the content and quality of the data, the bit rate of the high-speed CAN network (1 Mbit s-1) used hitherto is no longer sufficient. The gross bit rate required for these new systems must be of the order of 10 Mbit s-1 on a 'single-channel' medium (net bit rate approximately 5 Mbit s-1) or on a 'two-channel' structure at a higher rate with the possibility of redundancy.

the functional requirements of these new technical and industrial strategies

Physical layer The physical medium used for the communication must be capable of being supported by at least two different technologies, for example wire (differential pairs, for example) and optoelectronic (plastic optical fibres, for example. signals travelling along the physical layer must not pollute the radio-frequency band (low emission of radio interference) and must have a high immunity to external signals. containment errors must be managed with the aid of an independent bus monitoring element, called the 'bus guardian'.

the functional requirements of these new technical and industrial strategies

Medium access and control the temporal access to the medium is always an important and complicated matter in this kind of concept. In order to meet all the functional and security requirements of the network - the transmission of 'static' or 'real-time' data must be deterministic - the transmission of event-triggered 'dynamic' data must also be provided for and ensured;

- there must not be any interference between the aforementioned 'static' and 'dynamic' transmission modes in any circumstances; - the transmission principle must be totally free of any arbitration system; - the bandwidth (the bit rate) of the network must be variable, and it must be capable of being allocated dynamically; - it must be possible to send different and complementary ('differential') data during the same time slot over two physically different communication channels; - different nodes can use the same time slot in different channels.

the functional requirements of these new technical and industrial strategies

Synchronization method A reliable synchronization method must be established to ensure perfect synchronization between the operations of the different elements in the network. This requires the provision of a number of elements, particularly - what is known as a 'global time' device, using distributed synchronization and/or triggered by a time reference ('time triggered'); - synchronization provided by a master ('master synchronization').

the functional requirements of these new technical and industrial strategies

Network topologies if we want to improve communication bit rate and reliability, the topological aspect of the network becomes increasingly important. to consider new topologies, in addition to the everlasting 'bus' configuration. - passive bus ... as before! - passive star networks, - active star networks and their possible serial connection, - and finally, a nice mixture of active stars and passive buses.

the functional requirements of these new technical and industrial strategies

System-level requirements to devise a system which is fault tolerant, with a double transmission channel, capable of detecting its own errors and sending diagnostic messages. consider the establishment of redundancy between the CPUs in each node, to ensure reliability of operation based on a combination of multiple physical redundancy and transmission redundancy. This summarizes the functional context of these new networks which are very different from CAN but complementary to it. We shall now look at some proposed systems for meeting all these requirements.

6.4.5 TTP/C - time-triggered protocol

The TTP/C system, a member of the great family of timetriggered protocols (the 7/ C' indicates that it meets the criteria of class C of the SAE - Society of Automotive Engmeers - for the real-time and fault-tolerant aspects of communication in the car industry) TTP/C is designed on the principle of TDMA (time division multiple access) to the medium TTP/C was not originally intended for motor vehicle applications, but for industrial applications in general

6.5 FlexRay
FlexRay is a new automotive network communications protocol under development by the FlexRay Consortium. It is positioned above CAN and MOST in terms of both performance and price. Its prominent features are: - high data rates (10 megabits per second) - time- and event triggered behavior - redundancy and fault-tolerance The protocol specifications are in review stage. The first production vehicle with FlexRay was the 2007 BMW X5, though it was only used for the pneumatic damping system. Full use of FlexRay is expected in 2008, with the introduction of the BMW X6, the world's first production vehicle to fully utilize the FlexRay system.

6.5.1 The origins

CAN, TTCAN, TCN, TTP/C and Byteflight, whether any one of them was capable of meeting all the technical and application requirements stated above. The conclusions leading to the development of a new proposal, called 'FlexRay'. The findings concerning the existing solutions are summarized below: - CAN is not fast enough for the new applications required, and it is difficult to make the transmission truly deterministic and redundant. FlexRay will not replace CAN, but will operate as an addition to it.

 TTCAN inevitably has the same fault of limited speed as CAN. It also fails to provide - support for optical transmission; - a redundant transmission channel; - a fault-tolerant global time; - a bus guardian. For TTP/C, the content of the data carried by the frame is considered too small. In spite of the use of TDMA for the bus access, there are not many properties in common with FlexRay. Also, TTP/C provides no flexibility, by comparison with FlexRay, regarding - the combination of synchronous and asynchronous transmission sections; - the multiple transmission slots for a single node in the synchronous section; - nodes acting on single, double or mixed channels; Byteflight does not offer enough functionality.

6.5.2 The FlexRay Consortium

the car manufacturers the equipment manufacturer the chip makers

6.5.3 The objective of FlexRay

the objective of the FlexRay Consortium has been to create a communication system for controlling and monitoring applications at three different levels: at high bit rates, complement and supplement the applications limited by the bit rate of CAN; capable of implementing X-by-Wire solutions; developing solutions offering redundancy: - by sending the same messages several times, - by providing two separate communication channels transmitting the same data in parallel, - or by having two communication channels transmitting complementary data in normal time, so as to provide a speed apparently higher than the physical bit rate of the protocol; capable of serving all future electronic functions in motor vehicles.

Topology
FlexRay must support communications implemented using topologies of the following type: - single-channel, - two-channel, - bus, and bus with stubs, - passive and active stars, - multiple stars with optional sub-buses, - and all combinations of the above.

Communications
have a large digital data transmission bandwidth (10 Mbit s-1); transmit data in synchronous and asynchronous modes (scaleable); carry deterministic data transmissions in the network, with known and guaranteed message latency and jitter; have different simultaneous speeds, using simple bandwidth allocation for the nodes; be able to carry out static and dynamic segmentation of data transmission - for distribution of requirements; - for distribution of areas of functionality; - for supporting a configurable number of transmission time slots for each node and for each operating cycle;

Communications
support variable geometry hardware and software redundancy (single-channel, two-channel and combined system); support the sleep mode and wake-up of participants via the network; support power consumption management for the participants in the network; detect and signal errors very quickly; withstand synchronization errors of the global time base; provide fault-tolerant and time-triggered services by means of hardware devices;

Communications
manage error containment in the physical layer by means of an independent bus guardian; be capable of supporting the presence of a decentralized bus guardian in the physical layer (all topologies combined); be such that the protocol is independent of the use of a central bus guardian (optional bus guardian, no interference); permit the addition of new nodes to an existing system without the need to reconfigure the existing nodes. The configuration data must comply with the need-to-know principle (via a special intrinsic 'knowledge search' device).

Security requirements
For X-by-Wire systems, FlexRay must be able to manage redundant communications; provide deterministic network access (synchronous redundancy); avoid collisions for bus access; provide an option for variable geometry redundancy (single-channel, two-channel and combined system); operate by a 'never give up' strategy, thus ensuring that any unavailable communication system automatically disables distributed backup mechanisms; be such that the restarting of a node in an operating system implies much more than the simple restarting of its communication; maintain communication as long as the communication between other nodes is not compromised.

Security requirements
Maximum security can only be achieved by a combination of the hardware (two-channel architecture, independent bus guardian, fault-tolerant CPUs. It is also necessary to ensure the robustness of the system against transient faults and external radiation; a minimum of radiation external to the systems, EMC (electromagnetic compatibility) protection, etc.

Application requirements
FlexRay must ensure that the application is always fully responsible for any decision in terms of network security or availability; always takes the final decision; is always in control of the communication system maintains reception as long as possible because a break in communication is a critical decision that must also be taken at the application level; is capable of providing different operating modes in respect of communication: - normal or continuous operation; - operation in dedicated degraded mode: warning: continuous operation, but with notification to the host node; reduced operation with errors: stoppage of transmission and notification; fatal error: operation stopped. All the pins and the bus guardian are switched to fail-safe status; is such that the nodes can be configured to survive several cycles without receiving communication frames.

 These general parameters and these requests will enable future requirements to be met for three classes of application - class 1 - communication with high bandwidth; - class 2 - deterministic communication with high bandwidth; - class 3 - deterministic and redundant communication with high bandwidth. new hierarchies of networks used in on-board applications of the FlexRay, the use of CAN as a subbus of FlexRay and the use of LIN as a sub-bus of CAN.

6.5.4 The FlexRay protocol

On 30 June 2004, three reference documents: version 2.0 of the protocol, the physical layer and the bus guardian . final version, 2.1 (May 2005), includes some additional refinements and minor modifications.

Protocol handling
The original document describing the FlexRay 2.0 protocol contains 224 pages; FlexRay, its operating principle is radically different from that of CAN and other protocols FlexRay was designed to provide a communication system in which collisions for access to the medium are impossible The physical layer does not provide any means of resolving these collisions, and therefore the application layer must take over to handle such problems.

In order to provide the system with the greatest flexibility of application, it is necessary A) to allow operation in 'real time communicate at a precise, thus making collisions impossible; B) to allow communication at a variable bit rate if required, and thus to require an unspecified communication time. These two points are totally contradictory. FlexRay follows TTCAN in proposing communication based on communication 'loops', called 'communication cycles', in which access to communication is provided synchronously in time slots

 This principle of access to the medium by compliance with predetermined time slots (TDMA) structurally eliminates any possibility of message collision ('collision avoidance') FlexRay combines two paradigms, the first being time controlled and the other controlled by external events. create two completely distinct areas inside a 'communication cycle': one is called the 'static segment' and the other is called the 'dynamic segment',

Communication cycle
Communication in FlexRay takes place with the aid of recurring communication cycles, each comprising a 'static segment', a 'dynamic segment', an 'optional symbol window' and finally a phase in which the network is in idle mode, called the network idle time (NIT). This cycle is initialized by the network manager node.

Communication frame
It comprises three very clearly separated data fields: the header; the payload, i.e. the field containing the useful load (data); the trailer, i.e. the end of frame field.

Header
Having started with a sequence called the frame start sequence (FSS), consisting of 8 bits with a value of '0' without a start or stop bit, the header is encoded in 40 bits (5+11+7 + 11+6), making a total of 5 bytes The meanings of the first 5 bits are as follows: - reserved = 1; - payload preamble indicator; - null frame indicator; - synchronization frame indicator: '0' indicates the transmission of a normal frame; ' 1' indicates the transmission of a synchronization frame to be used for synchronizing the clocks; - start-up frame indicator.

 Frame identifier (frame ID). encoded in 11 bits (from 1 to 2047, '0: illegal), defines two very important communication parameters: - first, the position of the time slot in the static segment; - second, the priority level in the dynamic segment. A low value indicates a high priority. Payload length. The 7 bits indicate the number of words (16 bits) transmitted in the payload field (maximum 254), i.e. from 0 to 123. Header CRC. The CRC of the header field is encoded in 11 bits to protect the length and the synchronization bit with a Hamming distance of 6. Cycle counter. This field encoded in 6 bits (giving 64 values) indicates the number of the current communication cycle and acts as a 'continuity index' for the communication.

Payload field
The payload field, carrying the useful data (from 0 to 254 bytes), consists of the static and dynamic segments for the FlexRay protocol;

 Static segment. the portion of the medium access is controlled and monitored by a static time division multiple access (TDMA) principle. The purpose is to provide deterministic communication, to define the semantics (the sense or meaning) of status messages and to manage the distributed systems and control closed loops. The payload field is initially divided into equal time slots, including some reserved spaces, which are well known and well structured, and therefore start and end at precise instants defined mainly by application groups (clusters). Each time slot is identified by a unique identifier (ID). Thus, we have provided time-distributed medium access (TDMA); avoided the creation of collisions; designed a real-time system because the latencies are known; designed a system with known bandwidth for a given bit time.

 Dynamic segment. during which medium access is controlled and monitored by 'mini-slotting', also known as flexible time division multiple access (FTDMA). In this segment, medium access is allowed dynamically according to the priority level assigned to the nodes having data to transmit, via the value of the frame ID contained in the message header. The purpose of this segment is to provide communication within limits of time and bandwidth. This segment will also be initially divided into equal mini time slots, which start and end at precise instants. Each of the nodes is then free to vary the duration of the slots according to the quantity of data that it wishes to transmit,

End of frame field

End of frame field the frame concludes with an end of frame field containing a single 24-bit CRC field. This protects the integrity of the frame with a Hamming distance of 6. Access to the medium two possibilities depending on the form of network access: - via the static segment, for 'quasi-real-time' tasks enabling multiple time slots to be used for each node if necessary during the same communication cycle, - via the dynamic segment, for asynchronous eventtriggered ('spontaneous') tasks, subject to arbitration and with a bandwidth that can be adapted dynamically during operation according to the operating requirements of the system;

 This diagram shows the set of two segments, static and dynamic, of the communication frame, This choice is based on the desired allocation of bandwidth according to the operating requirements of the planned system, the 246 data bytes of the payload being divided into two segments of adequate size.

 each participant in the network requiring 'quasi-real-time' access must be assigned its own time slot in the static segment. application A (front right-hand brake) can communicate during the first time slot, application B (suspension) can communicate during the second time slot, application E (clutch control) can communicate during the fifth time slot and so on.

 there will be no overlapping of time slots, the system integrator is quite free. The same equipment maker/supplier 'X' for applications A, E, H, etc. and a second company ' Y' for the other applications