X-by-wire systems and time-triggered protocolsuser.it.uu.se/~annikak/exjobb/Report - Safety Critical... · Web viewand time-triggered protocols Abstract Electronic systems in vehicles

Author DateAnnika Karlsson 2002-11-20

X-by-wire systemsand

time-triggered protocols

X-by-wire systems andtime-triggered protocols 1(43)


ABSTRACTElectronic systems in vehicles are becoming more and more common. X-by-wire systems are electronic systems without mechanical backup where the x stands for safety related applications, e.g. steer- and brake-by-wire. When introducing electronics in safety critical parts of the vehicles control systems, such as steering and braking, it must be at least as safe as today’s systems. The use of techniques that simplifies construction of safety critical systems leaves less room for human error at design time. Transmission protocols are one of many techniques.

The automotive industry has started to develop a new type of protocol for message transmission, the time-triggered protocols. These new protocols are predictable and the messages are handled with static scheduling.

There are currently three different groups that are developing their own protocol. TTP – Time Triggered Protocol. FlexRay TTCAN – Time Triggered CAN

This master’s thesis is studying and comparing these three protocols, and explaining why there is a need for these kinds of protocols.



SAMMANFATTNING Elektronik i fordon blir allt mer vanligt. Allt fler system övergår från att styras mekaniskt till elektronisk styrning. X-by-wire system är elektronikst redundanta system som saknar mekanisk backup. X:et står för olika säkerhetsrelaterade funktioner som t.ex styrning och bromsning. När man inför elektronik i säkerhetskritiska delar av fordonet måste säkerheten i dessa system vara minst lika bra som de mekaniska system de ersätter. Att utveckla system med hjälp av tekniker underlättar vid design av säkerhetskritiska system begränsar männsikliga fel i processen. Överföringsprotokoll är en sådan teknik.

Fordonsindustrin har börjat utveckla en ny typ av protokoll för meddelande överföring; tids-styrda protokoll. Dessa protokoll är förutsägbara och använder sig av statisk schemaläggning av meddelandena.

Det finns för tillfället tre olika grupper som utvecklar var sin variant av tids-styrda protokoll. TTP – Time Triggered Protocol. FlexRay TTCAN – Time Triggered CAN

Detta examensarbete har studerat de tre protokollen och jämfört dem. Rapporten ger också svar på varför dessa nya protokoll är nödvändiga för x-by-wire system.



1 INTRODUCTION................................................................................................................................. 6

1.1 Structure of this thesis.................................................................................................................... 6

2 REAL-TIME SYSTEMS....................................................................................................................... 8

2.1 Soft and hard real-time systems......................................................................................................82.2 Safety Critical Systems................................................................................................................... 82.3 Safety............................................................................................................................................. 92.4 Forms of safety-related system.......................................................................................................92.5 Faults, error and failures................................................................................................................. 92.6 Fault management.......................................................................................................................... 9

2.6.1 Fault avoidance....................................................................................................................... 102.6.2 Fault removal.......................................................................................................................... 102.6.3 Fault detection......................................................................................................................... 102.6.4 Fault tolerance........................................................................................................................ 10

3 X-BY-WIRE......................................................................................................................................... 11

3.1 Two groups.................................................................................................................................. 12

4 TIME-TRIGGERED ARCHITECTURE...........................................................................................13

4.1 Event-triggered protocols............................................................................................................. 134.2 Time-triggered protocols.............................................................................................................. 13

5 THE PROTOCOLS............................................................................................................................. 15

5.1 CAN............................................................................................................................................. 155.2 TTCAN........................................................................................................................................ 17

5.2.1 Medium Access........................................................................................................................ 175.2.2 Elements of the protocol........................................................................................................... 185.2.3 Potential time masters.............................................................................................................. 205.2.4 Event synchronized initialization of basic cycles......................................................................21

5.3 TTP.............................................................................................................................................. 225.3.1 Media access........................................................................................................................... 235.3.2 Frame formats......................................................................................................................... 235.3.3 The message descriptor list......................................................................................................245.3.4 The controller state.................................................................................................................. 245.3.5 The communication network interface......................................................................................25

5.4 FlexRay........................................................................................................................................ 265.4.1 Architecture............................................................................................................................. 265.4.2 Sending and receiving.............................................................................................................. 265.4.3 Physical Media........................................................................................................................ 275.4.4 Frame formats......................................................................................................................... 275.4.5 Protocol operation................................................................................................................... 285.4.6 Media access........................................................................................................................... 295.4.7 Error management................................................................................................................... 30

6 A COMPARISON OF THE PROTOCOLS.......................................................................................31

6.1 Problems...................................................................................................................................... 32

7 FUTURE.............................................................................................................................................. 33

8 AN IMPLEMENTATION OF TTCAN LEVEL 1..............................................................................34



9 GLOSSARY......................................................................................................................................... 36

10 References............................................................................................................................................ 42



1 IntroductionEmbedded control systems are used in an increasing number of complex applications as aircraft control and automotive control. The benefits of the fly-by-wire technique have gotten the automotive companies to investigate the use of a similar technique in vehicles. In the automotive industry, the dependability of a system is not the only requirement. The cost of manufacturing has a big part of production. [22]

A software system is inherently complex. When designing safety critical systems software is not the first choice. Whenever it’s possible the use of mechanical systems are safer from a technical point of view. But you can’t remove all hazards from a system and make it completely safe. It’s a hazard to get in the car or take the bus in the morning but we do it anyway, because all other opportunities are less good. The task of creating a safe system is one of deciding on an acceptable level of risk and design the system from that point of view. A safe car is a non-moving car. If can’t move, you can’t hit anything with it, but on the other hand the car must be moving to get you anywhere.

When you replace the mechanical parts of a system by electronics, you can think that it’s a setback of the safety of the system. But the electronics can indeed help to make the system safer. The x-by-wire technology is aiming towards fault tolerant control systems that completely replace the need for mechanical backup. These systems cannot only control the vehicle; they can assist the driver in difficult situations on the road.

1.1 Structure of this thesisThis report will investigate the meaning of safety critical systems in general and x-by-wire systems for vehicles in particular. It will also take a deeper look at a few protocols for time-triggered real-time communication.

Chapter 2 The basic concept of real-time and safety critical systems are described.

Chapter 3 presents the x-by-wire technology.

Chapter 4 The architecture of even-triggered and time-triggered protocols are described and compared.

Chapter 5 is the main part of this thesis. Here TTCAN, TTP and FlexRay are described.

Chapter 6 discusses some of the similarities and differences of the protocols.

The future of the time-triggered protocols is addressed in chapter 7.

Chapter 8 presents the practical part of this thesis.



Chapter 9 contains a glossary.

Chapter 10 is where all references are stated.



2 Real-time SystemsA real-time system is a computer system where not only the correct computation is important. The time when the result is produced is equally important. For example if a traffic-light turns to green after yellow, it’s a correct behavior but if both direction of a crossing get a green light at the same time it could lead to a disaster.

2.1 Soft and hard real-time systemsReal-time systems can be divided into soft and hard systems. The difference between these two types is how strict the deadlines for the processes are.

If a missed deadline only decreases the performance but does no harm the system is said to be a soft real-time system. If it, on the other hand, is very important that all deadline will be met, and the consequences if they don’t are harmful to people or property, it’s a hard real-time system. A control system in a nuclear power plant is a hard real-time system. A safety critical system is often a hard real-time system.

2.2 Safety Critical SystemsWhat happens if something goes wrong in a system and what are the impacts on the surrounding world? If a calculation error occurs in a cash register in a supermarket, the customer or the store will loose money. That’s not a safety critical situation. At most the customer gets angry and refuses to pay the extra money, but there is no danger to the environment. If a calculation error occurs in the control system of a nuclear power plant, causing the heat to increase in the reactor, it’s definitely a safety critical situation.

Safety critical system can also be called safety related systems in literature in the field. Safety related systems are defined by Neil Brooks in ‘Safety Critical Computer System’:

A Safety related system is one by which the safety of equipment or plant is assured.

A system must not only be safe, it must be shown to be safe. If a system is going to be taken into use, the managers will have to trust it. To trust it, they want proofs of a safe and correct system behavior. No system can be absolutely safe, but the safety level of a system must be sufficiently high for the specific task it’s supposed to perform. In the power plant example, the system is safe if it’s turned off. Then there is no risk of overheating or malfunctioning. But this system doesn’t provide any electricity and hence it’s useless. The level of safety in a functioning power plant must be decided upon when the control system is developed.

One of the most desired properties of a safety related system is predictability. If the system is predictable you can foretell the systems behavior.



2.3 SafetySafety is not only a consideration of software development but must be a part of the whole system production and maintenance. For every change and every new system environment safety must be the first priority. Software developed for certain hardware and a certain use cannot always be adapted to new hardware and still keep the same safety level.

To get the best safety of a system all persons involved in the development should be a part of the development of safety regulations.

2.4 Forms of safety-related systemMost safety-related systems can be categorized as either a Control System or as a Protection System. A control system is used to control the operation of system and in some cases also provide safety functions.

A protection system is used to detect failures of another system. The primarily function of these kinds of systems is to prevent accidents from happening. They have also been called shutdown systems, as they make the monitored system shutdown if something severe happens.

2.5 Faults, error and failuresThis section will define terms of failure for safety critical systems.

FaultA fault is a defect within the system. There are two types, random and systematic.A random fault is appearing only once and is often related to hardware failure. A systematic fault is not random but is “built in” to the system. It could be the result of mistakes within the specification, design error or other.

ErrorAn error is the result of a fault appearing during operation of the system. The system has shown an unwanted behaviour.

FailureThe system fails to perform its required function.

A fault mustn’t lead to an error if it’s never activated during operation, and an error mustn’t lead to a failure if it’s possible to get back to a correct and safe state.

2.6 Fault managementWhen producing a safety critical system much effort must be put into making the faults affect the system as little as possible. There are some techniques for doing this, specialized at different aspects e.g. fault avoidance, fault removal, fault detection and fault tolerance.



2.6.1 Fault avoidanceFault avoidance techniques aim to prevent faults from entering the system in the first place. This is the primary aim of the entire development. Techniques as formal methods are great fault avoidance techniques when they can be applied. [23]

2.6.2 Fault removalFault removal is the techniques where you try to find all faults introduced into the system during the design phase. This is done before the system is taken into use. Extensive testing of both hardware and software is fault removal methods. [23]

2.6.3 Fault detectionThe fault detection methods are applied to systems in use, to try to detect fault before they lead to errors to minimize the effects on the system. A system that uses fault detection algorithms is more suitable for safety critical systems because they continuously try to find faults in the system. The methods include among others functionality testing that checks that the hardware still are performing according to its specification. Information redundancy aims to reveal errors in the data by using CRC, checksums and error correcting codes. [23]

2.6.4 Fault toleranceMany techniques for fault tolerance are dependant on the existence of fault detection techniques. Fault tolerance is a property associated with the ability of a system to endure fault without changing the behavior of the system. There are many techniques for fault tolerance including hardware and software redundancy. [23]



3 X-by-wireAn x-by-wire system is a safety related fault tolerant electronic system in vehicles without mechanical backup. The x stands for different safety related applications, e.g. steer- and brake-by-wire.

The purpose of an x-by-wire system is to assist the driver in different situations and to make it safer for all road-users. This increases the overall vehicle safety, as the driver doesn’t have to be concerned of the routine tasks anymore. Another advantage is the lower cost for production of this type of system. An x-by-wire system is also called a dry system, as the hydraulic fluids are no longer necessary. This leads to a simpler and more easily maintained system.

The automotive industry is developing new technologies to make the cars safer and more economical to drive. The use of electronics in the engine has reduced fuel consumption, and in brakes with EPS (Electronic Stability Program) assist the driver in difficult weather conditions makes driving safer. Today’s systems haven’t completely let go of the traditional mechanical technologies. They are left as a backup, if the electronic system fails. The research done today aims to remove the mechanical backup systems and replace them with fault tolerant safety critical systems. As the backup is removed, the electrical system must provide at least the same level of safety and availability as the old hydraulic/mechanical systems do. This is realized using electronic redundancy and replica determinism. This means that the redundant units must make equal decisions at the same time. [12]

By-wire systems have been used in the aircraft industry for some time and now the automotive industry is interested of the advantages that can bring. Apart from the safety issues, the cost for these types of system must decrease to be a good alternative to currently used technology. As there are many more cars than aircrafts manufactured, the price for each unit must be low enough to be competitive on the market. The systems in aircrafts are regularly maintained during the service of the aircrafts. This service is mandatory for aircrafts and is performed very often if you compare it to cars. It’s a fact that all cars don’t get the service they need. When you have this in mind you realize the importance of a truly fault tolerant system that doesn’t degrade over time.

Many car manufacturer already have some kind of x-by-wire system in their latest models and they are all very interested to develop this technique because it’s a cost effective way to make the cars safer than today. The x-by-wire system also gives the opportunity to monitor the activity of the system during operation or you can write data to a log for later.

There are several benefits of x-by-wire systems. For example, the controlling electronics in steering system can be placed anywhere. It’s no longer needed to be under the steering wheel. In fact, the wheel can be replaced with a joystick. When you can place the steering unit anywhere, it’s simpler to adapt the car to both right and left hand steering.



An x-by-wire system can also be easily upgraded or adjusted to different needs as the dynamics of the system is in the software. You just download the new software into the controllers. No parts must be replaced!

3.1 Two groupsElectronics in automotive systems increase. When moving from body-electronics to vehicle control the need for a secure transmission is greater. When your steering wheel is connected to the tires only by electronics, you have to be able to trust the system. The x-by-wire systems are often safety-critical and must be built on a reliable network architecture. The currently used transfer protocols don’t have the level of security that’s needed. This is the reason why automotive manufacturers want to develop new secure protocols, the time-triggered protocols.

Although x-by-wire systems can revolutionize the car manufacturing business, the cost for an individual manufacturer to develop all new technology needed is too high. Today, the industry has divided into two major groups developing two versions of a time-triggered protocol. Both groups agree that there is a great need for a standard in this field, but they disagree on which protocol that should set that standard.

The Time Triggered Architecture Group, which includes PSA Peugeot Citroen, Audi, Volkswagen, Honeywell and Delphi Automotive Systems, employs the Time Triggered Protocol (TTP) originally developed at the university of Vienna, Austria. TTP is based on the strict TDMA scheduling.

The other group is the FlexRay Consortium and they have developed its own protocol, FlexRay, based in part on the Byteflight system and on the time-triggered architecture. This protocol offers flexibility apart from the time-triggered communication. The members of this group are General Motors, DaimlerChrysler, BMW, Motorola, Philips Semiconductors and Bosch Automotive Group. [14] [15]



4 Time-triggered architectureFuture automotive systems seem to need more and more distributed computing. It’s not a single CPU doing all calculations, but a network of many micro controllers working together. This increases the demands on a dependable communication system.

A real-time requirement is that a task reacts on an event in a predictable way and within it’s given time limit. The network latency is an important factor when analyzing a system. If a communication medium should be used in a hard real-time system the latency must be predictable. In CAN the latency is depending on the busload and the priority of the task. A low priority task will have to wait for all tasks with higher priority. If it isn’t possible to determine the highest latency it’s impossible to tell if the task will finish before deadline every time. Run time calculations are especially difficult for low priority tasks and in networks with many nodes and a high message frequency.

In a safety critical system the calculations must be in an interval small enough to recognize that a message hasn’t arrived in time, so the fault recovery can start immediately.

4.1 Event-triggered protocolsThe currently used protocols in vehicles are event-triggered. This means that all activity is invoked by the occurrence of an event. For example, a sensor that senses a changing value immediately sends an event message to the controller of the sensor. The time of when this message is sent is not important only the delay until the new information reaches the controller. A system designed for transmission of event messages requires a dynamic scheduling strategy because the time of an invocation of a task can’t be predicted. CAN is an event triggered communication channel and is in more detail described in chapter 5. [7]

The event-triggered approach is good for many real-time applications, but not for safety-critical systems due to the lack of determinism, in synchronization and fault tolerance characteristics. In this case the consequences of a missed deadline can be disastrous so all safety-critical systems are hard real-time systems. These systems require a different architecture. The CAN bus is a good communications channel for soft real time systems, but for hard real-time systems time-triggered protocols have been developed.

4.2 Time-triggered protocolsThe time-triggered architecture was a result of the Time Triggered Architecture (TTA) project that was a cooperation of European industry and universities in the late 1990’s. In the time-triggered architecture all system activity is initiated by the progression of time. All nodes should be synchronized in time and every activity on the network is time stamped using the global time. The message-schedule can be made prior to system start because all messages are allocated time on the bus at the design level. This makes



the time-triggered systems deterministic, as they always send the messages in the same order. The static schedule is downloaded into the controllers. The communication subsystem knows then when to send messages and when a message on the bus is of interest for it’s own node. One of the main advantages for a time-triggered architecture are the composability, that reduces the need for testing when integrating a new part into the system. Composability means that a part of the system is isolated in the time and value domain in such way that it’s not affected by other parts of the system when they are put together. This is an important factor when designing safety critical systems. If the parts where affected by others, the system’s behaviour would change when a new unit was put into the system. If that would be the case, the system could end up unsafe after each unit. To prevent this, extensive testing must be performed. If a system is built up by composable units, this would be avoided, and the system development is made safer.

The time triggered architecture is designed to tolerate any single physical fault in any of the nodes without causing damage to the system. [8] If an error do occur, it must be contained in that subsystem and not propagate through the system. This means that each unit must provide its own fault avoidance and fault tolerance procedures. If a unit can’t produce right output anymore it must close down silently so it doesn’t causes any harm to the rest of the system. This is known as a fail-silent architecture.

The transparent fault tolerant structure of the time triggered architecture is based on redundant fail silent units that makes it an acceptable architecture for safety critical systems.

A summary of the characteristics of each type of protocolEvent-triggered Time-triggeredSoft real-time Hard real-timeNon deterministic DeterministicLow bandwidth for discrete messages

Low bandwidth for continuous signals Fault tolerant



5 The protocolsThe main part of this thesis is to study three promising time-triggered protocols. TTP and Flexray are each supported by a large group of automotive companies and TTCAN is developed by Bosch. Bosch is the company that in 1985 developed the CAN protocol, which is now a very common communications architecture in modern vehicles.

In this section the protocols will be described and compared. TTCAN is a higher level protocol on top of CAN, so it’s neccesary to describe the CAN protocol also.

5.1 CANCAN stands for Controller Area Network and was developed by Bosch in 1985. It has later been standardized internationally by ISO (ISO 11898). The CAN protocol corresponds to the first two levels of the OSI reference model. It was originally developed for non-safety critical real-time systems, such as body-electronics within vehicles.

A CAN network consists of nodes with a CAN interface and the CAN bus that connects them. The bus is a broadcast bus; i.e. all nodes will get all messages even if it’s not addressed to them.

CAN is event-triggered, which means that the nodes will send messages at the trigger of an event within the node. The time of when they are sent is not preidctable. If a sensor gets an indication that the value has changed, that node will send a message on the bus. This can result in message collisions, as every node, in the worst case, may send a message at the bus at the same time. To cope with this, CAN uses the technique CSMA/AMP (Carrier Sense Multiple Access with Arbitration by Message Priority) for media access. This is a more real-time adapted variant of CSMA/CD (Carrier Sense Multiple Access with Collision Detection). In CSMA/CD all nodes that sense a collision on the bus must stop sending and wait a random time before trying to send again. Even the most important message will be interrupted using this protocol. In CSMA/AMP every message to be sent is assigned a priority. A node can only begin send a message if the bus is free. If a collision is detected after beginning sending the message, all but the node sending the highest prioritized message must stop sending. This means that the most important message never gets interrupted. At worst it must wait for a free bus.

The decision of which message has the highest priority is made in the arbitration phase. The identifier of the message is the priority, and the lower the identifier, the higher the priority. A 0 is dominant and a 1 is recessive. If a node sends a 1 on the bus and senses a collision with a 0, it must stop sending. But if it senses a 1, it doesn’t know if it’s lower or higher than the other, and so they send the next bit of the identifier. At some point there will be only one node that’s still sending, and the message is sent.



In the CAN specification it’s also stated how error detection and management should be done. There are five different methods for discovering an incorrect message.

Monitoring. The sender checks that the bit sent is the same as on the bus. If a 0 is sent and a 1 is detected, an error has occurred.

Bitstuffing. CAN uses NRZ coding for efficient detection of error frames. An error frame starts with either six 1’s or six 0’s. No other messages will contain these strings as the transmitter inserts a stuff bit with the complementary value after five consecutive equal bits. The receivers remove this stuff bit.

Frame check. Every node checks the received frame against the specification. If an error is found, the node signals a ‘format error’.

ACK errors. All nodes should report if the reception of the message was correct or not by writing a 0 (ok) or a 1(not ok) in the ack field of the message. A 0 overwrites a 1, so the transmitter will only know if at least one other node received a correct message.

Cyclic Redundancy Check (CRC). A checksum is calculated over the message before sending and is transmitted together with the message. The receiver does the same calculations. If the checksum calculated is equal to the checksum received it’s likely that the message has arrived correctly. [6]

The CAN protocol is good enough for most real-time applications, but for safety-critical systems the event-triggered approach is too weak. The importance of messages arriving on time, or the instant reaction when they don’t, require a time-triggered protocol. The development of car electronics into x-by-wire systems without mechanical backup has motivated the development of time-triggered protocols such as TTP, FlexRay and TTCAN.



5.2 TTCANTTCAN is a higher layer protocol, above the unchanged CAN protocol, that synchronizes communication and provides a global time-base. With synchronized nodes, messages can be sent at specified times, known by all. This leads to a non-competitive environment and hence the latency is predictable. The TTCAN protocol is divided into two levels and is standardized as a part of the CAN standard in ISO 11898-4. All details are not yet set as this standard still is a working draft.

To achieve synchronous scheduling in a distributed system all activities must be referred to a common time base. In TTCAN all nodes hold a counter that represents the global time base. The counter is updated once every network time unit (NTU). A reference message is sent by a time master at a high frequency to allow the other nodes to adopt their updating frequency to keep the time-counters as synchronized as possible.

TTCAN implements the time-triggered architecture; hence the time-triggered schedule is determined prior to system start. The schedule consists of many time-slots. In each slot only one message can be sent, so the competition for the bus is avoided and the message latency is not dependent of the number of nodes connected to the network. The worst case latency can be calculated and the protocol is predictable. [5]

The TTCAN specification as it is today doesn’t handle all requirements for safety critical distributed systems (e.g. redundant communication). It’s good enough for use in x-by-wire with mechanical/hydraulic backup systems, but not yet for dry x-by-wire systems. [1]

An advantage with the TTCAN protocol is that a you can use tools already developed for CAN networks, e.g. CANalyzer, as CAN nodes can be passive nodes in a TTCAN network. They are not allowed to send any messages but can receive all sent messages. It will also be possible to set the mode of a TTCAN chip to work as an ordinary CAN node. This facilitates the integration of the new technology into a network, because the nodes can be upgraded and tested gradually.

5.2.1 Medium AccessTTCAN uses a version of the TDMA access method when sending or receiving messages. The Time-division Multiple Access (TDMA) bandwidth allocation scheme divides the time domain into smaller time slots, or time windows. Network nodes are assigned different slots when they have the right to use the bus for transmission. The sequence of time slots when all nodes can send their messages forms a basic cycle. Several different basic cycles can be forming a matrix cycle. All basic cycles are of the same size in the temporal domain, but can differ in the layout. When a matrix cycle is ended the transmission scheme starts over by repeating the matrix cycle.



CAN use CSMA as stated in the previous chapter. TTCAN is a layer above the CAN protocol and in some time slots event messages are allowed. In these cases it is possible that more than one transmitter are accessing the bus at the same time. During these slots the original arbitration of the CAN protocol is used to grant access to the bus for the highest prioritised task. The medium access mechanism in TTCAN can be seen as TDMA with CSMA in some pre-defined time slots. [5] This feature makes the TTCAN protocol flexible, as some messages can be sent event-based but in predetermined slots.

5.2.2 Elements of the protocolThe TTCAN protocol consists of some core elements described in this section.[1][5]

The reference messageThe periodic communication is clocked by the transmission of a reference message from the time master. Redundant time masters implement the fault tolerance of this mechanism. The reference message is a regular CAN message with a special identifier known a priori. In TTCAN level 1 the first byte is reference information and in TTCAN level 2 the first four bytes contains synchronisation information and the global time. The last three bits of the reference message encode the sending node’s priority in the set of potential time masters. This priority determines which node will take over the time masters duty when the current time master fails. If an error occurs while sending a reference message it’s immediately re-transmitted.

The basic cycleThe period between two consecutive reference messages is called a basic cycle. The basic cycle contains time windows pre-defined for the transmission of messages in the system. The windows within a basic cycle can be of varying sizes but the length of a basic cycle is always the same. The time windows can be of different types to allow the transmission of both periodic state messages and spontaneous state and event messages. The messages sent is a standard CAN message with the CAN frame format described earlier.

The matrix cycleTo offer a more flexible time triggered system several basic cycles can build a communication matrix. If only one basic cycle was allowed it would be hard to adapt applications with different control loops and different deadlines to the communications protocol. The existence of a systems matrix allows for individual patterns among the applications running on the same network. The matrix cycle defines a messagetransmission schedule.

When the protocol has reached the end of the message transmission schedule it immediatelt starts over at the beginning of the schedule.



A node in a TTCAN network doesn’t need to know the whole system matrix. It’s sufficient if it has information of the messages it will send and receive. This leads not only to an optimization of memory usage in the nodes, but also facilitates the development of the schedule as a change in the schedule only needs to be downloaded into the controllers affected.

Window typesIn TTCAN there are three different types of time windows.

Exclusive time windows. These time windows are assigned to periodic messages. No other message can be scheduled in the same window. The automatic retransmission of CAN messages is not allowed in an exclusive time window.

Arbitrating time windows. This is a time window for spontaneous messages and can be assigned to more than one node. The possible bus conflicts are resolved using the CAN arbitration mechanism discussed earlier. Two or more arbitrating time windows can be merged if they appear directly after one another. A transmission of a spontaneous message in an arbitrating time window can only be started if there is sufficient time remaining. The automatic retransmission of CAN messages is also not allowed in an arbitrating time window.

Free time windows. During design of a transmission schedule it’s also possible to reserve time windows for future use. It could be either for new nodes or for giving existing nodes more bandwidth. A free time window can’t be assigned to a message unless it’s converted to either an exclusive or an arbitrating time window first.

Sending, receiving and network time unitWithin a basic cycle the time triggered actions are driven by the progression of time. This perception of time is called cycle time and is reset at the beginning of each basic cycle. The connection between the cycle time and the matrix time are called time marks. A time mark specifies the beginning of a time window and could be TxTriggers, for transmitting, or RxTriggers, for receiving. A time mark consists of a base mark, that determines the number of the first basic cycle after the beginning of the matrix when the messages must be processed, and a repeat count. The repeat count specifies the number of basic cycles between two successive transmissions/receptions of the message.

The granularity of the cycle time in a TTCAN network is the network time unit (NTU). The calculation of NTU is different in the two levels of TTCAN. In level 1 NTU is equal in duration to the nominal CAN bit time and is a fraction of the physical second (2-n) in TTCAN level 2.

Level differencesLevel 1 is a less demanding version of TTCAN where the timing is only based on the transmissions of reference messages. Each node has a local clock counter which is



updated once every NTU. There is no clock correction between reference messages to keep the clock at the same updating frequency, which means that there can only be low precision schedules. This level can be implemented as a software layer on top of CAN hardware.

The synchronization at level 2 is at a finer level. The NTU is a fraction of a physical second and is updated 2n times per second. This level also provides a global time that continuously is updated at the nodes and all nodes adapt their updating frequency to that of the time master by the use of a drift compensation algorithm. The global time can in turn be synchronized to an external clock, to allow TTCAN to be interfaced to other networks.

The reference message contains more information in level 2 but is downward compatible with level 1 as the information needed in level 1 is at the same place in the reference message at both levels. Doing this allows nodes of both levels to co-exist at the same network. Note that the precision of a network with both level 1 and 2 nodes must be adapted to level 1.

5.2.3 Potential time mastersThe time-triggered communication on CAN is based on the transmission and reception of the reference message. To ensure that the hard real time properties always are fulfilled, a rigid fault tolerance is implemented using up to eight potential time masters. The set of potential time masters is priority ordered. The priority is encoded in the last three bits of the reference message, and in a possible collision the arbitration mechanism of CAN ensures that the highest prioritized time master can send its message. To avoid collisions in the first place all potential time masters have a time-out value, Ref_Trig_Offset, which depends on their priority. When a basic cycle ends, all potential time masters wait for a new reference message. The minimum time that must pass is the time indicated in Ref_Trig_Offset. All potential time masters will try to release a reference message if the time has passed their Ref_Trig_Offset and will continue until one node succeeds. By using delays the highest prioritized node has time to send a new reference message before the others even try. This minimizes the collisions in the network and the time it takes to get a new official time master. [5] If a potential time master receives a reference message with a lower priority, it synchronizes to the current basic cycle and tries to send its own reference message at the start of next basic cycle. Because of the arbitration this message will win any collisions. In this way, it’s assured that it’s always the highest prioritized time master awake that controls the transmission of reference messages.

At start-up or reset of the system the time master must be found in the set of potential time masters. After a node has detected a power-on it must wait the maximum gap time plus the Initial_Ref_Offset interval. This value is dependent on the priority of the node. The time-out period prevents potential time masters from sending a reference message into a system if it detects a reset, when all other nodes still are working.



Nodes are synchronized after two consecutive reference messages and the time-triggered communication is started shortly after.

5.2.4 Event synchronized initialization of basic cyclesThe TTCAN protocol combines the event-triggered approach of CAN with the deterministic time-triggered approach by allowing a basic cycle to start at the trigger of an event. Setting the Next_is_Gap bit in the reference message indicates that the next reference message will be delayed until an event is observed or until a pre-defined maximum time has elapsed. This flexible feature allows the network patterns to synchronize applications to an external event or a non-periodic task. [4][5]



5.3 TTPTTP is used both in the automotive and aircraft industry. The mass production for cars makes the prices lower and it provides many arguments of the safety of the protocol, as the aircraft industry relies heavily on certification of safety critical components.

The studied version of TTP in this report is TTP/C since it’s developed for safety critical systems. The C stands for the SAE classification of the protocol. This class contains protocols with a speed of 125 kb/s – 1Mb/s, which are used for real time control. [11] There also exists a TTP/A version of the protocol, which is developed for not so strict real-time systems.

A TTP cluster consists of a number of nodes connected to each other by two replicated channels. Each node is considered to be fail-silent, i.e. it either functions correct or doesn’t interfere with the rest of the system if an internal failure has been registered. The nodes can be replicated and grouped into fault tolerant units (FTUs) to mask communication failures. The message transmission is replicated in both time and value domain by sending duplicate messages at two different channels at the same time. A FTU is designed to always perform the specified task regardless of an internal failure in one of its components. [13]

The TTP/C protocol allows different types of physical media. The protocol is described at the level above the physical layer, but must support both electric and optical physical media beneath.

As TTP/C is a time-triggered protocol the schedule for the system is decided before run-time. Each node keeps information of it’s own actions on the bus in a message descriptor list (MEDL). This descriptor list specifies when a node is supposed to transmit or receive a message. The MEDL is used both for knowing when to send or receive a message and for synchronization purposes. It’s used to make sure that all nodes have the same idea of where in the MEDL they are at any given moment. All nodes must have the complete MEDL downloaded into the controller, and can’t optimize the memory use by only download the node relevant information as in TTCAN and FlexRay.

TTP/C provides the following services: Membership service Fault tolerant clock synchronization service Mode change support Error detection with short latency Distributed redundancy management[12]



5.3.1 Media accessAs TTCAN, TTP/C uses the medium access method TDMA. The time is divided into slots, which are allocated to smallest replaceable units (SRUs). A replaceable unit is an electronic module that is the smallest unit that is replaceable in case of a fault. It’s connected to the TTP/C network and it can only access the bus for transmission in a time slot exclusively allocated for it. A SRU can always monitor and receive message from the bus. [9]

A sequence of SRU slots forms a TDMA round. Several TDMA rounds executed after one another until the pattern is repeated are called a cluster cycle. The cluster cycle is repeated periodically throughout the execution of the system.

The SRU consists of a host computer, interfacing a TTP/C controller by the communication network interface (CNI), and an input/output interface to the sensors and actuators in the system. The CNI is a dual ported random access memory that acts as a buffer between the host computer, where the application is executed, and the controller, which handles the communication on the TTP/C network. When the application wants to send a message it is placed in the CNI at the correct point in time and the controller takes over and manages the transmission. When a message is received it is placed in the CNI for the application to fetch it when the time is right. The CNI also contains control and status positions so the application can control its controller and get information about the status of the complete network as well as the local controller. [9][10]

5.3.2 Frame formatsThe protocol contains two types of frames. I-frames (initialization frames) are used for system initialization and contain the internal state of the TTP controller. This state is called the controller state (C-state) and will be described below. A node can be integrated into the membership service after receiving an I-frame. The frames are sent both at the startup of the system and at a predefined time interval during normal operation. The latter is used to re-integrate nodes into the system after they have failed and restarted.

N-frames (normal frames) are used during normal operation and contain the data sent between nodes in the system. The destination address of the frame is not stated in the frame, but in the MEDL. This reduces the overhead and allows a more efficient bus usage. A node that knows that it’s supposed to receive the message does it, and the other nodes ignore the message. They don’t even have to check if the message is for them, as they know it isn’t. [13]



5.3.3 The message descriptor listThe schedule of messages to be sent and received is stored in a static data structure called a message descriptor list (MEDL) before system start. All TTP controllers act according to this list and the global time base keeps them synchronized. This guarantees that the bus is free to use for a node, which is assigned a timeslot for sending.

The structure of the MEDL is not set in the specification so it’s up to the manufacturer of the TTP controllers to decide. However, the functionality is defined and it must be provided by all implementations. The first word in the MEDL indicates the revision of the structure. The MEDL must have a structure that’s compatible with TTP/C. The MEDL contains two data structures: the Configuration Parameters and the Transmission Block.

Configuration Parameters contains five blocks with parameters for configuring the controller. The TTP/C Controller Configuration Parameters has information about the individual controller, the common cluster parameters and the startup. The Bus Guardian Parameters are implementation specific and normally consists of cold start and download parameters. The Reconfiguration Role List contains a parameter set for all valid roles that this controller can have. For each role there exists a logical name and timing information for the bus guardian that apply when the controller executes the specific role. When the controller is started it assumes the default role, which is the first entry in the list. The Mode Control Block contains Mode Change Entries. One Immediately that’s valid for all modes and a Deferred for each mode. The last block is the Implementation Specific Parameters. These parameters are not defined by the TTP/C protocol, but are controller specific.

Transmission block contains all information needed for transmitting and receiving frames.

5.3.4 The controller stateTTP uses controller states (C-states) to ensure consistency in the system. All nodes are forces to implicitly agree on their C-states. The C-state consists of three fields: the MEDL position, the time and the membership. If all nodes agree on this information the system is consistent. To enforce an agreement between sender and receiver the CRC of a message is calculated over both the message and the C-state. If the C-state information differs between the sender and the receiver the receiver can’t interpret the message and it will be discarded. [13]

The C-state information is sent periodically in I-frames to allow nodes to join the group during operation. The consistency check is also done for these frames. An I-frame is only valid if the CRC value is correct and the C-state contained in the message agrees with the local C-state of the receiver.



The C-state data structure contains three fields. The first word is time field, which is the current global time in macroticks. The second is the MEDL field, and contains the current mode and position in the MEDL. The last field is the membership vector, which can vary in size from one to four words according to the numbers of SRUs in the cluster. [9]

5.3.5 The communication network interfaceThe CNI is a dual ported RAM accessible for both the host and the communication subsystem. It can be divided into two major areas: status/control area and CNI message area.

The Status/Control Area is used for the host to check status and control the controller. The status fields are read-only for the host and consist of the C-state fields, null-frame vector, membership vector, frame diagnosis fields and TDMA related fields. The host has both read and writes access to the control fields. These contain fields for changing the mode, correcting the rate, turn the controller on, off or set it in a waiting mode and set startup and interrupt fields.

The Message Area is where the messages sent and received are placed before action is taken. A message is associated with a message status field, which contains information about the transmission and reception of the message.



5.4 FlexRayFlexRay is a protocol, which is a joint development activity of, among others, General Motors, BMW, DaimlerChrysler, Motorola and Philips. They aim to develop a protocol that implements a more flexible approach to the time-triggered architecture.

The time of a message round is divided into static and a dynamic segmens. In the static segment only messages already scheduled can be sent. Messages where the time is crucial to the operation (such as orders to the braking system) is sent in this segment. [18] The dynamic segment is for occasional burst transmissions, diagnostic information and ad hoc messages in general. The dynamic part is limited both in time and bandwidth consumption. The FlexRay system has support for both synchronous and asynchronous frame transfer by dividing the time into these two segments.

Although FlexRay is a broadcast protocol, the all information is not important for each node. A node disregard every message that’s not addressed for them.

The time is externally synchronized using a fault tolerant time synchronization algorithm at every node.

There is guaranteed frame latency time and jitter during the static part of the communications cycle, by using the time triggered architecture for this segment. [17]

5.4.1 ArchitectureThe FlexRay network consists of independent nodes connected through one or two communication channels. A node can either be connected to both channels or only one. Each node has it’s own unique identifier. A node that’s only connected to one channel may share the identifier number with a node on the other channel.

The nodes consist of a host, a communications controller, up to two bus guardians and bus drivers. The nodes can be configured to send and receive on one or two channels. A node that’s participating in safety critical communication must be attached to both cannels, while a diagnostic or other non-safety critical node can be attached to just one of the channels. [17]

5.4.2 Sending and receivingThe frame transfer in FlexRay is organized into a cycle called a communications cycle. This cycle is divided into a static and a dynamic part. The static and dynamic parts of the communications cycle are allowed to be empty, which result in different modes. It could be pure static, pure dynamic or mixed static and dynamic. [17]

Static



The transmission in the static part follows the TDMA strategy. The static part is divided into time slots, each represented by the ID of the node it’s allocated to. In each slot, only one node is allowed to send a frame. The length of the slot can be configured at scheduling but is a fixed value during operation. Nodes connected to both channels send the message frame simultaneously on both channels.

DynamicIn the dynamic segment, it’s allowed to send different frames on different channels at the same time. If a node is only attached to one channel, it can share a slot with other nodes that are only attached to the other channel. In a pure dynamic system the communications cycle starts with the SOC symbol (Start of Cycle). The bus access is done using frame priorities, based on the access scheme of ByteFlight. Higher prioritized frames will be sent before frames with lower priority.

Bus guardianThe frame transmission is started when the bus guardian gives access to the bus. This is only done in the dynamic segment or if the node is scheduled to send in the current slot. The transmission must be signaled on the bus, and at last the frame is sent. These steps are there to make sure that no one sends a frame on to an occupied bus, or sends a message in some other nodes slot. A frame it not allowed to be sent in a time interval so close to the end of the slot, that it would not complete in time. This mechanism must be implemented in the nodes.

5.4.3 Physical MediaThe requirements of the protocol state that different types of physical media should be supported. For now, the environment must be compatible with the ByteFlight optical bit encoding as well as an encoding for an electrical physical layer. More information about ByteFlight is available at the official website www.byteflight.com.

5.4.4 Frame formatsIn FlexRay, there are two frame formats that must be supported. The FlexRay format can be used in pure static, pure dynamic and mixed mode. For pure dynamic systems the ByteFlight format must be supported. [17]

FlexRay formatA FlexRay frame consists of a 5 bytes header, a data segment and a 3 bytes CRC field.

Res Frame ID Sync DLC H-CRC NF CYCO Message ID Data CRC

4 12 1 7 9 1 6 16 0...1968 24

The first 4 bits of the header is for future expansions, and is not used. The frame Id must be unique in a cluster. It’s used for priority in dynamic

stages and is a slot reference in static stages. Sync tells if the clock is used for synchronization or not.


http://www.byteflight.com/


Data Length Code. This parameter is the number of bytes in the data field. Header-Cyclic Redundancy Check is calculated over the Sync and DLC fields. Null Frame indicates that the host has not updated the corresponding data

buffer before sending. Cycle Counter is increased simultaneously in all nodes by the communications

controller at the start of each new cycle. Message ID is configurable to be used as either an id or as the first 2 data

bytes. Data filed can contain 0-246 bytes of data, and is indicated in the DLC field. The CRC is calculated over the entire frame. [17]

ByteFlight formatThe ByteFlight frame is smaller than the FlexRay frame and supports only up to 12 bytes of data.

ID RES LEN DATA CRC FCE8 4 4 0...96 15 1

The first 8 bits of the header is the ID and it must be unique in a cluster. The next 4 bits are reserved for future expansions of the format. The LEN field tells how big the data field will be. LEN = 1...12 The DATA field can contain up to 12 bytes of data. The Cyclic Redundancy Check field consists of 15 bits. And the last bit is the FCB (Fill Completion bit) and is only used to fill the

complete word in the CRC field. It’s usually set to 0.

5.4.5 Protocol operationStart upThe nodes in the FlexRay network must synchronize at start-up, as all other time triggered protocols. The requirements specification does not specify how this should be done, only that the synchronization algorithm must be distributed in a mixed or pure static system. [17] In a pure dynamic system a node sending a SOC symbol initiates the startup sequence. It is essential that nodes that wake up later mustn’t interrupt the ongoing communication in the network.

Only a node that’s participating in the synchronization algorithm is allowed to initiate a start up. This means that only nodes connected to both channels are start up nodes.

The specification also states that a way of shutting down the system safely must be provided. How it’s supposed to be done is not yet specified. [17]

Clock synchronization



In the pure dynamic version of FlexRay a master performs the synchronization of clocks. That master sends a SOC and all other nodes synchronizes to that information.

The algorithm for the static, i.e. the time triggered version of FlexRay, is a bit more complicated. It’s a distributed algorithm and will be performed by all active nodes in the network. The Global_Time stored at each node consists of a cycle_counter and a cycle_time. The cycle_counter is always increasing and is counted in units of macroticks. The value can be implemented as an integer multiple of the internal clockticks in the node. The resolution of these macroticks of at least 1s must be achieved in automotive applications. The oscillators must also be built to stand the automotive environment and conditions without malfunctioning. The algorithm must be able to keep all fault-free nodes synchronized within a given precision.

The cycle_time is reset to 0 at each start of a new communications cycle and is used as the time reference in each cycle.

The nodes can send up to one message that contains synchronization information per communications cycle, and only correctly received synchronization frames are considered in the synchronization algorithm. The SYNC bit of the frame is set if the frame contains synchronization information.

The synchronization mechanism must be fault tolerant and scalable for the number of nodes supported by the protocol. The level of fault tolerance is dependent on the application and the number of nodes in the network. The mechanism must also prevent the network from forming cliques.

The clock deviations are calculated of the difference between actual and expected arrival time. The expected time is based on the node’s internal view of the global time. A frame that arrives outside of the expected ‘StartOfFrame’-window is regarded as invalid because the sending node is suspected to have synchronization problems. If half or more that half of the frames arrive outside the SOF-window the receiving node is assumed corrupted and must be taken of the network for later reintegration when the problem is solved. This mechanism prevents the formation of cliques.

The nodes should be able to synchronize to an external source, e.g. GPS, using hardware signals. [17]

5.4.6 Media accessIn the static segment FlexRay uses a TDMA scheme for accessing the communications channel. To prevent nodes from accessing the media when it isn’t allowed a bus guardian must be provided in hardware. The bus guardian is supposed to keep track of the valid access times and only allow traffic to be sent at those times. A bus guardian may only block the traffic on one channel, hence two bus guardians must be used when a node wants to use both channels.



The bus guardian is also supposed to detect timing errors within the node and take it of the network. This is part of the fail silent behaviour of the node. [17]

5.4.7 Error managementTo be defined as a safe protocol it must support error-handling techniques in a “never-give-up” philosophy. The protocol must be designed so that no reception of periodic messages will be missed. If it does, this shall be registered in the controller.

The hardware modules, nodes, should be built up of self-checking entities and the node it self must be fail silent. If errors are detected in one node at the network, these errors should not affect the rest of the system. [17]



6 A comparison of the protocolsThe time-triggered technology is the result of 20 years of studies mostly done at the university of Vienna. TTP is the commercialization of that technology made by TTTech Computertechnik AG. The same research is the base of the competing protocol FlexRay. This leads to a lot of similarities between the protocols, but then they are heading in different directions. FlexRay is created because there was a need for a more flexible way to do time-triggered communication.

TTCAN is the little unknown protocol in this comparison and is more seldom talked about in the papers. The battle of which protocol will set the standard are said to be between TTP and FlexRay. If not stated explicitly, the comparison of protocols in this chapter is between TTP and FlexRay.

General requirementsBoth protocol consortiums have recognized the following general requirements.

Higher bandwidth. The CAN bandwidth, which is limited to 500 kbit/second, is not adequate for future applications.

Determinism. In order to achieve predictability in the system determinism is needed.

Fault tolerance. The architecture must be fault tolerant to give the same safety as today’s mechanical systems.

Support for distributed control. Distributed control algorithms need synchronized communication.

Unification of bus systems within vehicles. There is a need to reduce the number of different bus architectures within the vehicle. One bus system will not be appropriate, but two or three must be enough.

TTP also have the important requirement of composability. Composability is the ability of different components to work together without endangering the system safety in either the temporal or value domain. TTP holds this requirement as one of the most important one to be fulfilled. FlexRay has not yet come to this in their specification, but mentions that composability is something they are working on for the FlexRay protocol

There is a fundamental conflict between flexibility on one hand and safety on the other. In a non-flexible situation a node is to send its messages at times defined prior to system start. If the messages doesn’t arrive in time error detection and recovery can start immediately. In the flexible situation when a node can send messages at will, the other nodes don’t know if a message is sent too late or not at all because they don’t have the information that a message will be sent. The immediate error detection mechanism cannot be used in this case. It’s easy to see that the first case is the safest situation, but on the other hand it’s the least flexible. The specification of TTP doesn’t accept any flexible communication on the network. Only pre-defined timeslots are allowed. This is the way they claim they can guarantee safety. FlexRay on the other hand claim they can allow flexibility using the ByteFlight



protocol and still provide a safety level high enough for x-by-wire systems. The ByteFlight protocol was originally developed for short time mission applications like airbag control. The flexibility of FlexRay dynamic segment doesn’t affect the time-triggered behavior of the static segment.

When it comes to efficiency and data throughput, TTP is the most effective protocol with a data efficiency of 70-80%. This can be achieved because the specification allows a larger data field in a messages frame than FlexRay does. FlexRay reached 50 % of data efficiency when tested at the same time as TTP. The speed of transmission is also higher in TTP, with 25 Mb/s compared to 10 Mb/s in FlexRay. [19] In the latest available FlexRay specification the data field of the FlexRay frame format has been increased and is now at the same level as TTP.

The reason why the comparison is only about TTP and FlexRay is that TTCAN is not yet at the same security level as the others. The TTCAN protocol doesn’t support redundant communication yet, which is one requirement for real fault tolerance. The protocol is still under development and this may be added to the protocol in the future.

6.1 ProblemsWhen reading about the different protocols I ran into some problems with information gathering. The FlexRay consortium doesn’t post the latest version of the specification on their website, so the comparison of the protocols can be a bit unfair. There is also a problem to find articles on the subject that’s not written by one of the parties. This is very noticeable when you read the articles and find that the own protocol is always much better than the others. TTP is the group that has written the most of the material I have found, but I have tried to read between the lines to get the real picture. The Hansen Report is neutral reports, which investigate the market of time-triggered protocols.



7 FutureThe Hansen report foresees an advantage for FlexRay in the battle between protocols. Although the flexibility of FlexRay is appealing when companies will decide on which protocol to use, they like it best for its commercial attributes. In FlexRay there are no royalties linked to using or implementing the protocol. All members of the FlexRay consortium are free to use any material, and are obliged to contribute with knowledge.

But on the other hand, FlexRay is still at the development stage, and TTP have already reached prototype production. Developers in automotive companies can buy and test TTP chips provided by the TTP member Austria Microsystems, but have to wait until 2004 to try the first FlexRay prototypes. [16]

TTCAN is supposed to release their TTCAN IP module the third quarter 2002.

CostThe TTP hardware manufacturers must pay a license fee to the TTA Group on a non-discriminative basis. The manufacturing companies also pay royalties per sold product. This business model is very similar to the license model of CAN. The automotive companies and other higher-level user will not have to pay any license fees if they buy the components from a licensed manufacturer.

TTCAN uses the same licensing model as used for CAN. Both CAN and TTCAN are developed by Robert Bosch GmbH.

FlexRay will only have the license fee for hardware manufacturer, and no royalty fee.



8 An implementation of TTCAN level 1The practical part of my master’s thesis is a test implementation of TTCAN level 1. In this project I’ve learned a lot about the internal structures of a time-triggered protocol.

TTCAN level 1 is the only time-triggered protocol that can be implemented in software based on CAN cards. The other protocols need hardware supported time synchronization. Because the time synchronization of TTCAN is done using only the reference message, and no clock correction algorithms, this is a low precision protocol. The time windows must be sufficiently large to prevent nodes to send in wrong time slots. The large time windows must compensate for the difference in the perception of time in the nodes.

The program I created was a simulation of the TTCAN protocol where three nodes could send time-triggered messages to each other over a simulated CAN network. The CAN simulation tool is only available from the company, CC Systems AB, where I worked during my thesis studies.

The background material I based my TTCAN implementation on is the working draft of the ISO 11898-4 standard: Road vehicles – Controller Area Network (CAN) – Part 4: Time triggered communication. [21]

The program I made is crating three nodes that should be able to communicate using TTCAN. When the nodes are created they immediately start to connect to other nodes on the network. One node sends reference messages until it has received two correct answers. The other nodes are listening for reference messages and answers with an acknowledgement if they receive one. When they have received two correct reference messages they continue to the communications phase.

In the communications phase each node reads triggers from their schedule that resides in a file, and starts the internal clock. In the main loop in the program the nodes check the time against the triggers they have stored in a trigger list. If a trigger is valid, they act on it and status information is printed in the window of the node. A trigger is valid if the local time is more or equal to the trigger release time, and if there is time left to send a message.

The program continues until you stop the master node, that’s sending the reference messages. The the other nodes doesn’t receive the next cycles reference message in time and stops. You can also stop the program by closing down all nodes using the stop buttons in each window.

My program was demonstrated on my thesis presentation using this transmission schedule.Time (sec) 0 4 5 9 10

1415 19

Basic cycle #1 Node 1 Node 2



Basic cycle #2 Node 1 Node 3In this schedule the time is divided into four time slots and we use two basic cycles. The first node sends a message in the first slot in both cycles, the second node sends in the last slot in the first basic cycle, and the third node sends in slot number two in basic cycle number two.

The total time of each slot ande the total time of the schedule is very large, only because a human should be able to se each message transmitted. All nodes print status information in their window when they send a message.

Start window

Node 1 just started.



Glossary

AArbitrating time window Time window assigned to messages that share the same time

window.

BBasic cycle Row of the system matrix of several consecutive time windows

Bus Consists of one or several channels.

Bus Driver A bus driver connects a communication controller to one channel.

Bus Guardian An independent unit that protects the bus from timing failures of the controller. Can be part of the controller silicon or an external unit.

Byteflight Communication network developed by BMW AG, Motorola, ELMOS, Infineon, Siemens EC, Steinbeis Transferzentrum für Prozessautomatisierung, IXXAT. See http://www.byteflight.com

CCAN Controller Area Network. Developed by Bosch in 1985.

Channel A channel is a physical connection between several communication controllers. A redundant channel consists of two channels connecting the same communication controllers.

Controller State (C-state) The internal state of the controller, consisting of the current time, current position in the MEDL, the current cluster mode, a pending deferred mode change (DMC) and the current membership.

Class C Control applications that are safety critical (e.g., anti lock brakes), used by theSAE.

Clique Set of communication controllers having the same view of certain system properties, e.g., the global time value, or the activity state of communication controllers.

Cluster The set of nodes sharing a bus in a TTP/C system. Synonym for network in FlexRay.

Cluster Cycle The sequence of different TDMA rounds. Each cluster mode may have



cluster cycles of different length.

Communication Network Interface (CNI) The interface between a TTP/C controller andthe host computer.

Communication Controller A communication controller is connected to one or two channels where it can send and receive frames.

Communication Cycle Periodic data transfer mechanism. Structure and timing arestatically defined. However, a static and a dynamic segment allows for the transmission of both, state and event information.

Controller See Communication Controller.

CRC Cyclic redundancy check.

CSMA/AMP Carrier Sense Multiple Access with Arbitration by Message Priority.

CSMA/CD Carrier Sense Multiple Access with Collision Detection.

Cycle Counter Contains the number of the current communication cycle in FlexRay.

Cycle time Contains the time within a communication cycle in units of macroticks in FlexRay. Same as cluster time.

Cycle_Time Difference between the local time of a frame syncronization entity and the time when a

reference message arrived.

Cycle_Count Number of the current basic cycle of the matrix cycle

DDeferred Mode Change A mode change that is deferred until the beginning of the next

cluster cycle.

Deferred Mode Change Field (DMC) A field in the C-state that stores pending deferredmode changes.

Dynamic Segment Segment of the communication cycle where frames are transmitted according to a mini-slotting algorithm. The sending order is defined by a statically determined identifier. Identifiers with smaller numbers have priority over identifiers with higher numbers. A communication cycle may consist of the static segment only.



EExclusive time window Time window assigned to a specific message transmitted

periodically without competition for the CAN bus in TTCAN.

FFail-Silent A node is called fail silent, if it either

operates correctly by sending correct (both in value and time domain) frames

or sends frames which all receivers can reliably detect as incorrect (e.g. by

means of a checksum)or sends no frames at all.Thus a fault in a fail-silent node is detectable by all receivers without additionalrequirements, like TMR voting.

FTU Fault tolerant unit.

FlexRay Consortium Develops FlexRay. Include BMW, DaimlerChrysler, General Motors, Philips, Motorola, Bosch, Ford and Mazda.

Frame A frame is one complete transmission of information on a communication channel. A frame is delimited by two interframe gaps.

Free time window Time window free of messages scheduled in the system matrix. (TTCAN)

HHost The computer within a node that executes the application software.

IInitial_Ref_Offset Initialisation value for the node that specifies the maximum time to wait

for a reference message before sending its own.

J

K



LLevel 1 / level 2 Levels of implementation of TTCAN ( ISO 11898-4), where level 2 is an extension of level 1.

MMatrix cycle Cycle of all basic cycles in the system matrix, consecutive from the first to the

last basic cycle. (TTCAN)

MEDL See Message Descriptor List.

Member node A member node is a real member node (a non-multiplexed node) or avirtual member node (a set of multiplexed nodes). Each member node is assigned to one unique node slot of a TDMA round.

Membership The information about which nodes in the cluster are currently operational,based on correct transmission activity.

Membership Failure The event when an operational node fails, as judged by a majorityof nodes in a cluster.

Message Application data transported within a frame. Several messages may be packed together to constitute a frame.

Message Descriptor List (MEDL) In an abstract form, the complete communication design of the TTP/C cluster. In a personalized form, the data structure in the controller that contains the control data for the controller. The contents of the MEDL determine when a particular frame has to be sent or received or what mode change is permitted at any given point in time.

NNetwork time unit (NTU) Unit measuring all times, and provides a constant of the whole

network.

Next_is_Gap A bit in the reference message that indicates if next reference message will be delayed.

Node A node may contain one or more communication controllers.

NRZ Non Return to Zero physical layer coding scheme.

O



PPotential time master Frame synchronisation entity in TTCAN that is allowed to send a

reference message by system configuration.

Q

RReference message Message (data frame) that starts a basic cycle in TTCAN.

Ref_Trigger_Offset Parameter used to modify the time mark within a reference trigger to send a reference message.

SSlot A slot is the smallest time interval of a TDMA schedule.

SOC Start of Cycle. Defines the start of a communication cycle in the pure dynamic mode, and the start of communication for start-up.

SOF Start of Frame. An optical or electrical physical layer may require different start of frame sequences.

SRU Smallest replaceable unit.

Static Segment Segment of the communication cycle in FlexRay where frames are transmitted according to a statically defined TDMA scheme. A communication cycle may consist of the static segment only.

System matrix Form containing all messages of all nodes in the network, organised as components, and consisting of time windows, organised in basic cycles (rows of the matrix) and transmission columns (columns of the matrix). The system matrix specifies the correlation between messages and time windows. (TTCAN)

TTDMA Time Division Multiple Access. Media access scheme used by the time triggered

protocol family – bus access is divided into non-intersecting time slots which are

statically assigned to the communicating nodes in a cluster.

TDMA Round The sequence of node slots in a cluster.



Time mark Mark within a frame synchronisation entity specifying an instant of Cycle_Time (in NTUs) at which a certain action is expected or planned. (TTCAN)

Time master Frame synchronisation entity in TTCAN sending the reference message.

Time window Amount of time allocated for a specific transmission column in the system matrix. (TTCAN)

TTA Group Develops TTP. Inculdes Airbus, Audi, TTTech, Renault, PSA Peageot Citroën, Austria Microsystems, and NEC.

TTCAN Time triggered Controller Area Network.

TTP Time triggered Protocol.

U

V

W

X

Y

Z



9 References

1. T. Fuehrer, B. Mueller, W. Dieterle, F. Hartwich, R. Hugel, M. Walther: Time Triggered Communication on CAN (Time Triggered CAN – TTCAN). http://www.can.bosch.com/docu/CiA2000Paper_1.pdf Accessed: 2002-04-12 14:00

2. T. Fuehrer, B. Mueller, F. Hartwich, R. Hugel: Timing in the TTCAN Network. http://canopen.de/can/ttcan/hartwich2.pdf Accessed: 2002-04-12 14:00

3. T. Fuehrer, B. Mueller, F. Hartwich, R. Hugel: CAN Network with Time Triggered Communication.http://canopen.de/can/ttcan/hartwich1.pdf Accessed: 2002-04-12 14:00

4. T. Fuehrer, B. Mueller, F. Hartwich, R. Hugel, H. Weiler: Fault tolerant TTCAN networks. http://canopen.de/can/ttcan/mueller.pdf Accessed: 2002-04-12 14:00

5. G. Leen, D. Heffernan: TTCAN: a new time-triggered controller area network. Microprocessors and Microsystems, Volume 26, Issue 2, 17 March 2002.

6. O. Markström, M. Wallmyr: Utvärdering av högnivåprotokoll för CAN (Evaluation of high level protocols for CAN). Uppsala University, Department of Computer Science.

7. H. Kopetz: A comparison of CAN and TTP. 1998. http://www.vmars.tuwien.ac.at/php/pserver/extern/searchpaper.php

8. C. Scheidler, G. Heiner, R. Sasse, E. Fuchs, H. Kopetz, C. Temple: Time Triggered Architecture (TTA). http://www.vmars.tuwien.ac.at/projects/tta/papers/DBTU_emmsec97/DBTU_emmsec97.html Accessed: 2002-04-12 14:00

9. TTTech Computertechnik AG: Specification of the TTP/C protocol. 1999. http://www.tttech.com Accessed: 2002-04-12 14:00

10. H. Sivencrona, J. Hedberg, H. Röcklinger: Comparative Analysis of Dependability Properties of Communication Protocols in Distributed Control Systems. 2001. http://www.sp.se/electronics/rnd/palbus/Reports/PALBUS_10_2.pdf Accessed: 2002-04-12 14:00

11. G. Leen, D. Heffernan, A. Dunne: Digital networks in the automotive vehicle. IEE Computing & Control Engineering Journal, December 1999, pp. 257 – 266

12. Th. Ringler, J. Steiner, R. Belschner, B. Hedenetz: Increasing System Safety for By-Wire applications in Vehicles Using a Time-Triggered Architecture. 1998. SAFECOMP’98 LNCS 1516, pp. 243-253, Springer-Verlag.

13. H. Kopetz, R. Hexel, A. Krueger, D. Millinger, R. Nossal, A. Steininger, C. Temple, T. Fuerher, R. Pallier, M. Krug: A Prototype Implementation of a TTP/C Controller. http://www.vmars.tuwien.ac.at/php/pserver/extern/searchpaper.php

14. Charles J. Murray: Automotive groups dived on road to data bus. 2001-09-27. EETimes.

15. RTD info 23: Fly-by-wire cars. http://europa.eu.int/research/rtdinf23/en/innov2.html Accessed 2002-03-06 10:15.

16. The Hansen Report on Automotive Electronics. FlexRay Protocol Picks Up Support. Vol. 15, No. 5. June 2002. http://www.hansenreport.com

17. FlexRay Consortium: FlexRay Requirements specification, version 2.0.2. 2002-04-09. http://www.flexray.com/htm/zips/FlexRay_ReqSpec_2_0_2-final-web.zip


http://www.flexray.com/htm/zips/FlexRay_ReqSpec_2_0_2-final-web.zip

http://www.hansenreport.com/

http://europa.eu.int/research/rtdinf23/en/innov2.html

http://www.vmars.tuwien.ac.at/php/pserver/extern/searchpaper.php

http://www.sp.se/electronics/rnd/palbus/Reports/PALBUS_10_2.pdf

http://www.tttech.com/

http://www.vmars.tuwien.ac.at/projects/tta/papers/DBTU_emmsec97/DBTU_emmsec97.html

http://www.vmars.tuwien.ac.at/projects/tta/papers/DBTU_emmsec97/DBTU_emmsec97.html

http://www.vmars.tuwien.ac.at/php/pserver/extern/searchpaper.php

http://canopen.de/can/ttcan/mueller.pdf

http://canopen.de/can/ttcan/hartwich1.pdf

http://canopen.de/can/ttcan/hartwich2.pdf

http://www.can.bosch.com/docu/CiA2000Paper_1.pdf


18. DimlerChrysler Media Services: In focus hardware concepts – Electronics on the road to success. 2002-07-02.

19. H.Kopetz: A comparison of TTP/C anf FlexRay. October 2001.20. H.Kopetz: Fault containment and error detection in TTP and FlexRay. Augusti 2002.21. ISO/CD 11898-4: Road vehicles – Controller Area Network (CAN) – Part 4: Time

triggered communication. April 2002.22. R. Pallier: Validation of Distributed Algorithms in Time-Triggered Systems by

Simulation. 2000.23. N. Storey: Safety Critical Computer Systems. 1996. Addison-Wesley


Documents

X-by-wire systems and time-triggered protocolsuser.it.uu.se/~annikak/exjobb/Report - Safety Critical... · Web viewand time-triggered protocols Abstract Electronic systems in vehicles