Environment for Brake by Wire System Development

Katharina Wennerström

Master’s thesis 20 p D-Level

Department of Computer Science and Electronics Mälardalens University, Västerås

Examiner: Denny Åberg

Supervisor: Peder Norin

October 5, 2006

Abstract In the automotive industry the safety critical systems in cars are increasing. These systems are called X by Wire system and their purpose is to assist the driver in different situations. These systems must be fail operational as they are deemed safety critical. If the system develops a fault, it might have catastrophic consequences such as injury or death of humans. I have looked closer on one of them, the “Brake by Wire system” which is based on a time-trigged protocol. The purpose of this thesis has been to study the Brake by Wire system and the ABS application. A part of this thesis has been dedicated the study of the communication system, the time trigged TTP/C real time communication protocol and compare it with two other time trigged solutions, TTCAN and FlexRay. Design of a Brake by Wire system with ABS based on TTP/C and also implement a very simple Brake by Wire system with ABS but without TTP/C where the hardware description language VHDL is used. Sammanfattning Inom bilindustrin ökar de säkerhetskritiska systemen i bilar. Systemen kallas ”X by Wire” och deras syfte är att hjälpa föraren i olika situationer. Systemen måste vara felfunktionsdugliga, eftersom de är bedömda säkerhetskritiska, om systemet utvecklar ett fel kan det ha katastrofala konsekvenser som skada eller död på människor. Jag har tittat närmare på ett av dem ”Brake by Wire” systemet som är baserat på ett tidsstyrt protokoll. Syftet med detta arbete är att studera ”Brake by Wire” och ABS applikationen. En del av arbetat har varit att studera kommunikationssystemet, det tidsstyrda TTP/S realtids kommunikations protokoll och jämföra med två andra tidsstyrda lösningar som TTCAN och FlexRay. Designa ett ”Brake by Wire” system med ABS baserat på TTP/C och också implementera ett mycket enkelt ”Brake by Wire” system med ABS, men utan TTP/C där det hårdvarubeskrivande språket VHDL används. Acknowledgement The work has been performed by Katharina Wennerström and it is the final part of the education at Mälardalens University in Västerås, Sweden, that leads to a Master of Science degree in Electronics. I would like to thank my examiner Denny Åberg and my supervisor Peder Norin at Mälardalens University. I would also like to thank Susanna Nordström and Mika Seppänen at Mälardalens University for there advices.

2

Table of contents 1 Introduction ............................................................................................................................. 5

1.1 Background ...................................................................................................................... 5 1.2 Problem formulation ........................................................................................................ 5 1.3 Delimitations .................................................................................................................... 6 1.4 Guide to Thesis................................................................................................................. 6

2 TTP/C and two other potential time-trigged alternative ......................................................... 7 2.1 TTP/C ............................................................................................................................... 7

2.1.1 TTP/C architecture .................................................................................................... 7 2.1.2 TTP/C communication .............................................................................................. 8 2.1.3 Fault tolerance strategy ........................................................................................... 11 2.1.4 TTP/C software ....................................................................................................... 12 2.1.5 Hardware CNI: AS8202NF TTP-C2NF Communication Controller ..................... 13 2.1.6 Advantages with TTP/C .......................................................................................... 14

2.2 FlexRay .......................................................................................................................... 15 2.2.1 Architecture............................................................................................................. 15 2.2.2 Frame Format .......................................................................................................... 16 2.2.3 Data transmission .................................................................................................... 17 2.2.4 Protocol operation ................................................................................................... 17 2.2.5 Error handling ......................................................................................................... 18

2.3 TTCAN........................................................................................................................... 18 2.3.1 Data transmission .................................................................................................... 18 2.3.2 TTCAN Implemention ............................................................................................ 20 2.3.3 Error handling and fault tolerance........................................................................... 21

2.4 Comparison between the TTP/C, Flexray, and TTCAN Protocol .............................. 22 3 Brake by Wire System with ABS.......................................................................................... 24

3.1. EHB (Electro Hydraulic Brake) .................................................................................... 25 3.2 EMB (Electro Mechanical Brake).................................................................................. 25 3.3 ABS (Anti-Lock Brake System) .................................................................................... 25

3.3.1 History..................................................................................................................... 25 3.3.2 How ABS Work ...................................................................................................... 25 3.3.3 What are the advantages and disadvantages of using ABS?................................... 26 3.3.4 Wheel speed sensor ................................................................................................. 26 3.3.5 Calculated brake distance with and without ABS................................................... 28

4 Design of the Brake by Wire System with ABS ................................................................... 29 4.1 The Brake by Wire design with TTP/C.......................................................................... 29

4.1.1 Communication in the wheel node between the Host and the CNI ........................ 30 4.1.2 The brake sensor...................................................................................................... 30 4.1.3 Pedal node ............................................................................................................... 31 4.1.4 Wheel node with ABS............................................................................................. 32 4.1.5 Wheel node without ABS........................................................................................ 34

4.2 Design without TTP/C implemented in this theses........................................................ 34 4.2.1 Direct communication between the pedal node and wheel node ............................ 34

4.3 Software ......................................................................................................................... 34 4.4 Hardware ........................................................................................................................ 35

4.4.1 HOST: Altera UP3 Education kit............................................................................ 35 5 Implementation of the Brake System with ABS ................................................................... 37

5.1 Pedal node ...................................................................................................................... 37 5.1.1 The brake sensor...................................................................................................... 37

3

5.1.2 Simulation of the pedal node................................................................................... 37 5.2 Wheel node..................................................................................................................... 37

5.2.1 Wheel simulation in node with locked wheel ......................................................... 37 5.2.2 Wheel simulation in node without locked wheel .................................................... 39

5.3 Communication between the pedal node and wheel node ............................................. 39 6 Summary and conclusions..................................................................................................... 40 7 Future Work .......................................................................................................................... 41 8 References ............................................................................................................................. 42

4

1 Introduction

1.1 Background Fault tolerant systems will become a big business area in the automobile industry in the future. The systems will assist the driver in critical situations and also help the driver with routine tasks. This is achieved by using fault tolerant techniques both in software [1] and hardware. Hardware fault tolerance is based on the used of redundant system. Many are hesitating because of the reliability and the safety concerns, because of that the conventional system have stood the test of time and are proven to be reliable but there is a clear trend to substitute mechanical, hydraulic or pneumatic system by computerized components in the automotive systems. The electronically controlled automotive systems are known as X by Wire. X by Wire is a generic term when bulky mechanical systems are replaced with sophisticated electrical components such as electronic sensors and actuators. X by Wire systems must be fail operational as they are deemed safety critical, because if the system develops a fault, it might have catastrophic consequences. The basic X by Wire systems are Throttle by Wire, Steer by Wire and Brake by Wire [2]. The current 14-volts bus has become insufficient in this new systems and the solution is to integrate a 42-volt bus that provides the necessary power [3]. A Brake by Wire system is based on time-trigged protocol, nodes, sensors and actuators. The Brake by Wire system transfer electrical signals down to a wire instead of using hydraulic fluid. If no hydraulic back-up is available it is a pure Brake by Wire system (Electro Mechanical Brake system) and it is very important that the system must continue to function in the event of a fault occurs. This has generated a need for fault tolerant computer systems at low costs [4]. A conventional ABS (Anti-Lock Brake system) that is used in must of the cars today is considered fail silent. If a fault in the electronic control system is detected, the control system is switched off, leaving the manual hydraulic back-up still operational. There is no such hydraulic back-up in the Electro Mechanical Brake system. The only safe car is a non-moving car so the task of creating a safe system is to decide an acceptable level of risk and then design the system from that point of view. The automobiles changed the world during the 20th century because of the greater mobility for people so the car is here to stay as an integral part of modern society.

1.2 Problem formulation The main goal of this Master’s thesis work is to develop a simple Brake by Wire system with ABS that will be used in future laboratory experiment in the course Digital systems. The goals for this thesis are to:

• Study the TTP/C concept and compare it with other time trigged solutions as TTCAN and Flexray.

• Study the Brake by Wire and the ABS application. • Give a deeper theoretical/practical knowledge about the hardware description language

(VHDL) and development tools. • Design a Brake by Wire system with ABS based on TTP/C and a system without TTP/C

who is implemented in this thesis.

5

• Implement a very simple Brake by Wire system with ABS but without TTP/C. • Write the Masters thesis report.

1.3 Delimitations In my design I have described the system with TTP/C but I am not going to implement the system with TTP/C instead I implement the nodes without TTP/C. The wheel node and pedal node will communicate directly to each other.

1.4 Guide to Thesis Chapter 1 presents general background theory to most of the subjects touched in this report. Chapter 2 treats the TTP/C concept. A description of the TTP/C software tools and the TTP/C hardware is also given. TTP/C are also compared with FlexRay and TTCAN. Chapter 3 presents the Brake by Wire system with ABS. Chapter 4 describes the design of the simple Brake by Wire System with ABS based on TTP/C and the design without TTP/C that has been developed and implemented during this Master’s thesis work. Chapter 5 describes the implementation of the very simply Brake by Wire System with ABS. Chapter 6 describes my personal conclusions and thoughts. Chapter 7 gives example of future work on the Brake by Wire developed in this thesis. Appendix A contains the VHDL code for the pedal node and the wheel node. Appendix B contains simulation results for the pedal node and the wheel node.

6

2 TTP/C and two other potential time-trigged alternative “In contrast to classical event-triggered communication systems, the Time-Triggered Protocol involves a continuous communication of all connected nodes. All events are safely processed according to schedule without data collision.” [5] The design ensures that an overload in the bus is prevented even if many important events occur at the same time. Because the Brake by Wire system is safety critical you exceed the limitations for event trigged protocol and can’t use them. You must use a time trigged protocol. I will study the TTP/C that is a time-trigged protocol and compare it with two other time-trigged protocols Flexray and TTCAN who I also describe briefly.

2.1 TTP/C TTP/C is a time-triggered class C low-cost communication protocol for fault-tolerant real-time systems. It is specially designed for X by Wire applications that are safety critical and is developed by Vienna University of Technology. Class C indicates that it satisfies the SAE classifications for safety critical control applications. The application domains are automotive control systems, aircraft control systems, industrial and power plants. TTP is based on 25 years of development work [5]. “In a TT architecture all systems activities are initiated by the progression of a globally synchronized time. It is assumed that all clocks are synchronized and every observation of the controlled object is time stamped with the synchronized time.” [6]

2.1.1 TTP/C architecture A TTP/C node (See figure 2.1) consists of a host computer and a communication controller and they are communicating through an interface (CNI). TTP/C is designed for systems with four or more nodes and can contain up to 64 nodes, but systems with two or three nodes that are active members in the clock synchronization work practically well. Each node is connected to communication buses.

Figure 2.1 Node configuration [7]

7

TTP/C topology: The possible topology can be bus, star or any combination of the two (See figure 2.2). Also are multiple stars or sub buses supported. You combine the highest safety level with minimal cost when you use a redundant star topology with a Bus Guardian integrated into the star.

Figure 2.2 A star with central bus guardians and a bus with local bus guardians [8]

2.1.2 TTP/C communication A TTP/C system is built by first defining the message schedule (See figure 2.3).

Figure 2.3 The TTP/C communication schedule for the Brake-by-Wire system [6] I-frames are only used for reintegration of lost members. A TDMA (Time Division Multiple Access) is a full communication cycle where every meeting member speaks. The sequence of sending slots within the nodes is called a TDMA round. After a decided (usually two) number of cycles (TDMA) the same message is repeated and that is called a cluster cycle. The clock synchronization is based on the TDMA principle and all nodes in the cluster know when a certain node has to send a message. The TDMA message schedule is stored locally in each node in the MEDL (MEssage Descriptor List) and each node knows exactly when it’s time for the other nodes to send as they read the schedule. No space is allocated for spontaneous messages in

8

the sending cycle and this means that an alarm that is an asynchronous message has to wait until the next cycle before being sent. Message descriptor list (MEDL): MEDL that is the schedule of messages that is to be received and sent is stored in a static data structure in the local memory of the communication controller. The list contains information of when the node is allowed to send message and when the node is expected to receive message. All controllers act according to the list and the global time base keeps them synchronized and this guarantees that the bus is nodes that are assigned a timeslot for sending. MEDL contains two data structures: the Configuration Parameters and the Transmission Block. Frame format: The TTP/C contains two kinds of frames (See figure 2.4, 2.5, 2.6 and 2.7). Those are I-frame (Initialization frames) and N-frames (Normal frames). I-frames are used to initialized the system and contain the internal state of the TTP controller and the N-frame are used for ordinary messages. A frame consists of three fields: a four bit header, a data field and a CRC-field. The first bit in the header tells if it is an N or I frame. The other three in the header are used for changing mode in the system. The data field contains data up to 16 byte and at last the CRC field. Information about name of the message and the sender is not included because such information can be read directly from the MEDL-list.

Figure 2.4 Frame format [7]

9

Figure 2.5 N - frame [7]

Figure 2.6 I - frame [7]

10

Figure 2.7 CRC calculation [7] Clock synchronizations: The system needs a global time base. To form this time base the clocks in the systems need to be synchronized. There is a distributed algorithm for the time synchronization and one of the requirements for the algorithm is that every node start to communicate at the beginning of its sending slot. Membership service: Membership gives timely and consistent information of the state of all nodes and it is a function for the correct operation of the communication system. It informs all nodes about the operational state of each node within the round. It uses an implicit acknowledgment scheme and is encoded in the CRC that protects the frames. After sending a frame the node watches the following frames to see if it is still considered as a member of the cluster. A node that sends false or no data losses its membership and are excluded from membership until they restart with a correct protocol state. Acknowledgment: After the data transmission it is important for the node X to get feedback from the other node to see if the receiver has accepted the transmission. TTP/C checking the membership list of the first and maybe the second successive sender. If these nodes show node X in their membership the transmission was successful, otherwise node X will be informed that the transmission was unsuccessful. Communication speed: The communication controllers available today supports a transmission of 25 Mbit/s synchronous and 5 Mbit/s asynchronous but the TDMA bus access scheme is collision free and gives no limit to the data rate.

2.1.3 Fault tolerance strategy The important feature of the TTP/C is its ability to guarantee that no single fault of a node can disturb the communication. TTP/C provides two serial communication channels to ensure messages arrive if the channel is broken. It must support error handling in a “never giving up technique” and no receiving of message will be missed. The node must be fault silent and the nodes must be self checking entities. If an error occur and be detected it should not affect the rest of the system.

11

Fault Management in TTP/C: Once a node fails following three methods are mostly used to reconfigure a replicated (spare) node to take over the functions of the one that failed [9].

• Native Real Shado • Native Multiplex Shadow • Active Replication

SOS faults: Is detected as a fault by some components and no fault by others. This fault must be removed from the system, because a distributed error detection mechanism can not be relied upon to pick them all up and handle them appropriately. Babbling idiot fault: If a node tries to monopolize the shared communication bus by sending more than allowed it is called a “babbling idiot”. The only reliable way of detecting and tolerating this fault is to have a separate Bus Guardian which protects the bus from an illegal access. Bus Guardian: The Bus Guardian protects the communication channels from a timing failure. The Bus Guardian enforces the bus protection by applying reasonable checks to the bus interface signal.

2.1.4 TTP/C software TTP tools are a development environment for fault tolerant real time systems. The software components are needed to build the application from a design level and the application designers does not need to deal with details on the code level. TTPtools contain (See figure 2.8) [5]:

• TTPplan is an overall cluster design tool • TTPbuild is an node and design tool • TTPftcom is a fault tolerant layer • TTPos an embedded operating system • TTPload a download tool • TTPview an on line monitoring tool • TTPMatlink is a rapid prototypimg platform for TTP applications not used in this thesis

because Altera UP3 Education kit will be used for the host. .

12

Figure 2.8 Software tool suites [7]

2.1.5 Hardware CNI: AS8202NF TTP-C2NF Communication Controller This Communication Controller (See figure 2.9 and 2.10) is not used in this thesis but it is briefly described for future work.

Figure 2.9 CNI

13

Figure 2.10 Block diagram (AS8202NF) [10] “The AS8202NF communication controller is an integrated device supporting serial communication according to the TTP® specification version 1.1. It performs all communication tasks such as reception and transmission of messages in a TTP cluster without interaction of the host CPU. TTP provides mechanisms that allow the deployment in high-dependability distributed real-time systems. It provides the following services: · Predictable transmission of messages with minimal jitter · Fault-tolerant distributed clock synchronization · Consistent membership service with small delay · Masking of single faults' The CNI (communication network interface) forms a temporal firewall. It decouples the controller network from the host subsystem by use of a dual ported RAM (CNI). This prevents the propagation of control errors. The interface to the host CPU is implemented as a 16-bit wide non-multiplexed asynchronous bus interface.”[10]

2.1.6 Advantages with TTP/C • High speed: The speed is 25 Mbit/s and higher speed is possible. • High data efficiency: It is between 70 – 90 %. • Flexible: It has individual slot size. • Safe: The fault hypothesis is clear. • Deterministic: The operations are time trigged. • No peak load: The operations are scheduled. • Reliable transmission: The Bus Guardian stops interference. • High availability: There are two dependable channels. • Efficient controls: Clock synchronization service • Modularity (location transparency): Membership service • Twisted communication: Acknowledgement • Fire wall: The CNI (Communication Network Interface) forms a temporal firewall. • Reduced after sales cost: Because of the high quality are the after sale cost reduced.

14

2.2 FlexRay FlexRay is a high speed, deterministic and fault tolerant communication system that will support the growing demands of future safety applications in cars and is one solution for the safety critical system as Brake by Wire system. Both BMW and DaimlerChrysler who started the FlexRay Consortium in 1998 as a result of them realizing that the current solutions did not meet their needs for future applications including the fact that X by Wire system now intended to use FlexRay in advanced series production application within the next few years. Today the FlexRay Consortium consists of seven members (BMW, Bosch, DaimlerChrysler, Freescale, General Motors, Philips and Volkswagen).

2.2.1 Architecture The network consists of nodes that are independent and connected through one or two communication channel (buses) (See fig 2.11).

Figure 2.11 FlexRay Bus system and node architecture [11]

FlexRay can support various types of topologies, such as Bus type, Star type, and Hybrid type (See figure 2.12).

Figure 2.12 Examples of the three different topologies The node consists of a host computer that is the part of the node where the application is executed and a communication controller that is an electronic component that is responsible for implementing the protocol aspects of the FlexRay communications system (See figure 2.13)[12].

15

Figure 2.13 A node with FlexRay controller The nodes has separate bus Guardian for each bus and the node can send and receive on one or two channel that depends on the configuration. But a node that is participating in a safety critical communication must be attached to both. Each node has its own unique identifier, but a node that only is connected to one channel may share the identifier number with a node on the other channel. FlexRay is a broadcast protocol and the nodes disregard messages that are not addressed for them.

2.2.2 Frame Format The FlexRay frame is divided into three segments. The segments are Header, Payload, and Trailer (See figure 2.14).

Figure 2.14 FlexRay Frame Format [13] Header:

• The Reserved is a reserved bit for future expansion. • The Payload preamble indicator is a bit that indicates the existence of vector

information in the payload segment of the frame. • The Null frame indicator is a bit that indicates whether or not the data frame in the

payload segment is NULL. • The Sync frame indicator is a bit that indicates the existence of synchronous frame.

16

• The Start-up Frame Indicator is a bit that indicates whether or not the node sending frame is the start-up node

• The Frame ID identifies a frame. • The Length contains the number of words which are transferred in the frame. • The Header CRC is used to detect errors during the transfer. Is calculated and specified

by the host. • The Cycle indicates the cycle count of the node that advances incrementally each time a

Communication cycle starts. Payload:

• The valid range for Data is from 0 to 254 bytes.

Trailer:

• The CRC It is calculated and specified by the hardware. It changes the seed value on the connected channel to prevent incorrect connections.

2.2.3 Data transmission The frame transfer in FlexRay is organized into a communication cycle. The communication cycle is divided into two parts, a static and a dynamic part. The length of those segments is defined in the configuration. The communication cycle is shown over a given time period (See figure 2.15).

Figure 2.15 FlexRay Communication Cycle [14] Static part: This part is for high priority messages and the transmission follows the fixed TDMA strategy. It sends and receives message with time triggers at fixed length and it is protected with Bus Guardian and there is guaranteed frame latency time and jitter during the static part of the communications cycle. Nodes that are connected to both channels send synchronously on both [13]. Dynamic part: This part is for lower priority messages and sending in rising order of ID following the flexible TDMA strategy. It sends and receives messages with event triggers according to the Byteflight protocol at variable length and it is not protected by Bus Guardian because the timing sending is undetermined. It is allowed to send different frames on different channels at the same time and higher prioritized frames will be sent before frames with lower priority.

2.2.4 Protocol operation Start up: The nodes have to bee synchronized when they start up and the synchronization algorithm must be distributed. Only nodes that are connected to both buses are started up and are

17

allowed to initiate a start up as they are participating in a synchronization algorithm that is included in the start up. Clock synchronization: In order to implement synchronous functions and optimize the bandwidth by means of small distances between two messages, the distributed components in the communication network require a common time base (global time). For clock synchronization, synchronization messages are transmitted in the static segment of the cycle. With the aid of a special algorithm, the local clock-time of a component is corrected in such a way that all local clocks run synchronously to a global clock.” [15]

2.2.5 Error handling There are three error processing levels, normal active, normal passive and fault.

• Normal active: The bus controller operates normal. There is no error detected. • Normal passive: The detected error can possibly be fixed. In this state, a bus

controller is not allowed to transmit any data it just listens to the bus and tries to reintegrate itself.

• Fault: A fatal error. The controller stops completely operating.

2.3 TTCAN Traditional CAN communication is event based. Asynchronous events are trigged by applications in the nodes that initialized each transmission session. That is in many cases a strategy that is efficient but there is applications that require a guaranteed access to the communication with a fixed period rate and for that is TTCAN developed. TTCAN (Time Trigged CAN) is a further development of CAN who was developed by Robert Bosch in 1986. It is a higher layer protocol on top of the unchanged CAN specified in ISO 1189-1[TTCAN]. It uses the CAN error detection mechanism and robustness and it also provides a step towards determinism and time trigged technology. It synchronizes communication and provides a global time base. The TTCAN protocol realises a global static schedule based on a TDMA structure. Time is divided into time window and messages are scheduled for transfer with in the limit for those time windows.

2.3.1 Data transmission Messages can be transmitted both time and event trigged. The scheduling tables that are locally implemented at each node must be configured before the system starts up. The basic cycle: It contains time windows predefined for the transmission of messages in the system. The period is between the two reference messages and is always the same, but the size of the time window can vary. The time windows may be of different types to allow the transmission of both time trigged messages and event messages. The system matrix (See figure 2.16): The system matrix contain several basic cycles and is repeated indefinitely until it is turned off. The systems matrix allow for individual pattern among the applications running on the same network. The matrix cycle defines a message transmission schedule and when it has reached the end of the message transmission schedule it starts immediately at the beginning again of the schedule. The node doesn’t know the complete system matrix. It’s enough that it has information only of the messages it will send and receive. There

18

will be an optimization of memory usage in the nodes and that change in the schedule only needs to be downloaded into the controllers that are affected.

Figure 2.16 TTCAN system matrix [16] Time Window: There are three different types of time windows Exclusive time window, Arbitrating window, and Free time window. Exclusive Window: Exclusively reserved for one message assigned to periodic messages, without competition for the CAN network access Automatic retransmission of messages that could not be transmitted successfully is disabled and that guaranteeing that messages in exclusive time windows are not delayed Arbitrating Window: This is a time window for impulsive messages. The message can be assigned to more than one node. Two or more arbitrating time windows can be combined if they appear directly after one another. The possible bus conflicts are resolved by using the CAN arbitration mechanism Free window: For future extensions of the network Clock synchronization: It is based on the time master schema. At the beginning of each round the SYNC frame with CAN ID 0 is a transmitted. The TTCAN protocol is divided into two levels: Level 1: The sending of CAN message in TTCAN between two reference messages is triggered by the local time units. There is no time correction between reference messages to keep the time

19

at the same updating frequency, which means that there can only be low precision schedules. The reference message only contains control information in one byte the rest of the CAN message can be used for data transfer. Level 2: The reference frame includes a time stamp, e.g. the global time information of the current TTCAN time master. It covers 4 bytes while downwards compability is guaranteed and the remaining 4 bytes are open for data as well. After at least two times receiving of the reference frame the nodes can be resynchronize according to the time stamp.

2.3.2 TTCAN Implemention Bosch has developed an IP module that implement the TTCAN protocoll and it is based on the existing C_CAN IP module (See figure 2.17)

Figure 2.17 Block diagram of the TTCAN [16] The two blocks that the TTCAN is expanded with is the trigger memory and the frame synchronization (See figure 2.18). The trigger memory stores the time marks of the system matrix that are linked to the messages in the message RAM then the data is provided to the frame synchronization entity. The frame synchronization entity controls the time triggered communication and it is a state machine. It controls the cycle time, generates time triggers and synchronized it self to the reference message on the CAN bus. The frame synchronization is divided into following six blocks:

20

• TBB: Time Base Builder • CTC: Cycle Time Controller • TSO: Time Schedule Organizer • MSA: Master State Administrator • AOM: Application Operation Monitor • GTU: Global Time Unit

Figure 2.18 Frame synchronisation entity [16]

2.3.3 Error handling and fault tolerance Two TTCAN channels are used. Alternative resources can produce the same messages and when the time master nodes fail another node will become the time master node. The TTCAN protocol defines an error status as well as several error modes (See figure 2.19).

21

Figure 2.19 Error state transition diagram [17]

2.4 Comparison between the TTP/C, Flexray, and TTCAN Protocol TTP/C Flexray TTCAN Acknowledgement service Yes Not included in the

protocol, can be implemented in the application if needed

Yes

Availability Components available, development tools available from TTTech

Development samples available supported by FlexRay-Group

Components available

Clock synchronization Single fault tolerant distributedformally verified offset correcting synchronization (with four or more nodes), optional rate correction to external referenctime

Fault-tolerant distributeoffset and rate correctinSynchronization

Master-slave synchronization, cluster internal or driven by externaevents

Communication speed The speed is up to 25 Mbit/s, but higher speed is possible

10 Mbit/s planned, but higher speeds is possib

1 Mbits planned and higher speed is not possible due to CSMA/CD access

22

Data efficiency 70-90 % 40-70 % 20 % Detection of: “Babbling idiot”

Yes, by the Bus Guardians Yes, by the Bus Guardians

Protection against nodes thanot send complete messages

Detection of: Failed nodes

Yes by the membership servic No No

Faults detected

Bit errors on the bus, transmit and receive faults

Bit errors on the bus

Bit errors on the bus, transmit and receive faults

Fault Hypothesis and Fault Tolerance Strategy

Tolerates all single hardware faults, two redundant communication channels

Tolerates some single hardware faults, no fault hypothesis

No systematic fault tolerance, no redundant channels

Identifiers No, all transmission are time trigged and are without identifiers.

Yes Yes

Maximum frame length fordata

Up to 240 bytes Up to 254 bytes Up to 8 bytes

Membership service Yes Not included in the protocol, can be implemented in the application if needed

No

Safety aspects Class C Class C Class B Support www.ttagroup.org

www.tttech.com www.flexray.com www.can-cia.de/can/ttcan

Time and/or event trigged Only time trigged both both Topology Bus or star Bus or star Bus or star Typical applications X by Wire system with 4 to 64

nodes and high safety requirements

Brake by Wire system with safety requiremen

Embedded network with 2 t10 nodes, soft real time requirements and loop timeof 5 to 50 ms, but with deterministic message for control cycles or higher busutilization.

Table 2.1 Comparison between TTP/C, FlexRay and TTCAN [18]

23

3 Brake by Wire System with ABS The Brake by Wire system means that the mechanical system is replaced by an electromechanical braking system. Brake by Wire was originally used for aircraft and military purposes only. It has many advantages for implementing in new car designs because the pedal movement can be generated arbitrarily. The ideal is that the pedal should behave like a conventional brake pedal [19]. An automotive mechatronic system is typically very complex to design and to optimise due to the multi domain characteristics of the mechatronic and to the safety critical nature of the system [20]. One advantage for the ABS (Anti-lock Brake System) that was introduced in cars in the 1980s is that it can be implemented in a more flexible way through control algorithms that are implemented in the software. ABS helps the driver to take better control over the car during an emergency stop and will shorten the brake distance with a few exceptions for example on snowy surfaces. Some of the biggest advantages to use Brake by Wire system is:

• There are shorter braking and stopping distances • There are no pedal vibration during ABS mode • The pedal feel is optimized • Less installation effort because of the improved packaging • The large vacuum booster is eliminated

There are two categories of Brake by Wire system (See figure 3.1). EHB (Electrical Hydraulic Brake) and EMB (Electrical Mechanical Brake) system.

Figure 3.1 A possible example of a Brake- by Wire architecture using TTP/C [7]

24

3.1. EHB (Electro Hydraulic Brake) In EHB system the hydraulic link between the brake pedal and the wheel brake are separated. There is no mechanical connection between the brake pedal and the hydraulic brake system. The brake pedal node sends electrical signals to an actuator that acts on the hydraulic brake callipers at each wheel and the pressure is applied by a computer-controlled high pressure pump and actuator solenoids. Conventional brake actuation (booster and hydraulic fluid) is replaced by an actuation unit with a pedal feel simulator and sensors for detecting the driver's intentions. Sensors measure the motion and driver's force on the brake pedal, and transmit that data to the ECU (pedal node) who calculates the optimum hydraulic pressure for each wheel and applies exactly the amount of braking force needed.

3.2 EMB (Electro Mechanical Brake) The system is a pure Brake by wire system without mechanical backup. The brake fluids and hydraulic lines are eliminated entirely. The braking force is generated directly at each wheel by electrically driven actuators. There are no mechanical or hydraulic back-up systems and the system must be fault-tolerant because the reliability is critical. EMB requires a fault-tolerant communication protocol (i.e. TTCAN, Flexray or TTP/C), a dependable power supply and some level of hardware redundancy.

Some advantages of the Electro Mechanical Brake system [6]:

• Noiseless, even in ABS mode • Reduced costs during line production because of simple assembly • Easier adapting of assistance system like ABS, ESP (Electronic stability program) etc. • More environmentally friendly because there are no brake fluid

3.3 ABS (Anti-Lock Brake System) ABS (Anti-Lock Brake Systems) has been around in cars for several years. The effectiveness of ABS varies widely depending on the system design, road conditions and the driver's response. The purpose of the system is to allow the driver to maintain steering control and to shorten braking distances. Without ABS wheels can lock up during a quick stop. ABS prevents the wheel to lock up and helps to keep the vehicle under control. It helps to retain steering control in situations where the driver would otherwise lose it.

3.3.1 History Bosch, a German company, had developed Anti-Lock Braking technology since the 1930s. The system first appeared in trucks and German limousines from Mercedes-Benz. Later was the ABS introduced on motorcycles. ABS was first developed for aircraft. Dunlop's Maxaret system that was an early and fully mechanical system system introduced in the 1950s, is still in use on some aircraft models. The first car who was sold worldwide to have ABS fitted as standard, was the Ford Granada Mk 3 in 1985 [21].

3.3.2 How ABS Work ABS is not on under normal braking conditions and it will not influence on normal braking actions. The ABS monitors wheel speeds using sensors mounted at each wheel. A computer checks the difference between the speed at each wheel and the speed of the car. If it determines

25

that a wheel is about to be locked, the computer sends signals to the actuator for that wheel, which regulate the brake pressure to prevent the wheel to lock up (See figure 3.2). “New brake force set points could be sent every 10 msec, which is needed for an ABS control loop. The brake control ECU’s sends their status and the current brake force” [6]

Figure 3.2 Example of how one single brake with ABS could operate [22]

3.3.3 What are the advantages and disadvantages of using ABS? Advantages of ABS:

• It is simple to use ABS: you push the brake pedal and then the computer takes over. No matter what the surface is the ABS adapts to it.

• ABS allows the driver to steer his/her vehicle out of potentially damaging situations. • Stopping distance on most road surfaces is in general reduced by ABS.

Disadvantages of ABS:

• Stopping distance on snow is somewhat longer. The vehicle is still possible to steer which is important.

• Cost and complexity of the electromechanical ABS system.

3.3.4 Wheel speed sensor A broad spectrum of velocity sensors is available from the manufactures. The speed wheel sensor is used in the control of ABS. In this thesis I simulate a Gear tooth speed sensor (See figure 3.3).

26

Figure 3.3 Gear tooth speed sensor [23] The gear tooth senses the variation in flux found in the airgap between a magnet and a passing gear teeth. It is necessary to provide a source of energy when a tooth moves across the magnet. The flux will become attracted to the lower reluctance path provided by the ferrous steel structure and then the measured flux density between the face of the sensor and gear tooth will increase. The modern approach is to convert the signal to a digital value and then perform signal processing to create a digital output [24]. Tyres have different dimension but I calculate with the same tyre dimension that I got on my car (195/65). A typical perimeter for that dimension is 199.2 cm. I’ve got 48 cogs and between every cog I travel 4.15 (199.2/48) cm with the car. The pulse frequency depends on the wheel velocity (See table 3.1 and figure 3.4). Wheel velocity

km/h m/s cycles /s 0 0 0 10 2,78 67 25 6,94 167 50 13,89 335 100 27,78 669 130 36,11 870

Table 3.1 Wheel speed sensor Velocity (m/s) = cycles/s*(wheel perimeter/Z) Wheel perimeter = 1,992 m (my cars tyre dimension) Z = 48 (number of teeth I used in this thesis).

27

Wheel velicity sensor (130-10 km/h)

0

0,002

0,004

0,006

0,008

0,01

0,012

0,014

0,016

0 20 40 60 80 100 120 140

km/h

Cyk

le le

ngth

(s)

Series1

Wheel velocity sensor (10-0 km/h)

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0 2 4 6 8 10 12

km/h

cykl

e le

ngth

(s)

Series1

Figure 3.4 Wheel speed sensor 130-0 km/h

3.3.5 Calculated brake distance with and without ABS The most common calculation formula in the automotive industry is the ECE rules, Annex 13 [25]. Formula for brake distance (on dry road): Stop distance (with ABS) = Velocity*Velocity/25.92*Brake friction maximum (with ABS)*9.92 Stop distance (without ABS) = Time to start braking (without ABS) + Velocity*Velocity/25.92*Brake friction maximum (without ABS)*9.92 Brake friction maximum (with ABS) = 0.92 Brake friction maximum (without ABS) = 0.71 Time to start braking (without ABS) = 0.1*Velocity I have calculated the brake distance with and without ABS. The brake slow down is supposed to be uniform so the middle value will be included in the calculations. At the velocity 130 km/h it takes 72.17 s to stop the car with ABS (See table 3.2).

Velocity Brake distance with ABS (m) Brake distance without ABS (m) 10 0,427037179 1,427037179 25 2,66898237 5,16898237 50 10,67592948 15,67592948 100 42,70371792 52,70371792 130 72,16928328 85,16928328

Table 3.2 Calculated brake distance with and without ABS

28

4 Design of the Brake by Wire System with ABS This chapter describes the design of a simple Brake by Wire system with TTP/C and a simple system without TTP/C that will be implemented in this thesis.

4.1 The Brake by Wire design with TTP/C The Brake by Wire system consists of five nodes and is implemented as an EMB (Electro Mechanical Brake) system (See figure 4.1).

FR

Wheel node

FL

Wheel node

Pedal node

BL

Wheel node

BR

Wheel node

Wheel Velocity

Brake Actuator

Brake Force Wheel

Velocity

Wheel Velocity

Brake ActuatorBrake

Force

Wheel Velocity

Brake Actuator

Pedal Force

Brake Force Brake

Actuator

Brake

Force Figure 4.1 The Brake by Wire design There are four wheel nodes and one pedal node. The nodes are connected by two replicated buses. A lot of status messages have to be sent over the data bus to keep the Brake by Wire system as fault tolerant as possible. The pedal node is the node that contains all important information of the system including the managing of the ABS. The pedal node samples sensor values from the pedal, calculation of how much the wheel brake should apply on each wheel and checks if the ABS should be activated. When the brake values have been calculated they are sent as messages to the different wheel brake nodes. The pedal node also collects status information from the nodes.

29

The wheel nodes that are placed at each wheel simulate the wheel velocity and real brake force because wee don’t have any real wheel. It also sends status message about the node to the pedal node.

4.1.1 Communication in the wheel node between the Host and the CNI This is done in the component FLCNIhost that must be implemented in every node in future work but not in this thesis because we don’t use TTP/C. . Data Address Mode Comment FL_BUS_OK 0000 0101 0000 in 1=true, both buses is ok FL_NODE_OK 0000 0100 0000 in 1=true, node FL is ok FL_BRAKE_OK 0000 0011 0000 in 1=true, desired brake value=real value FL_WHEELVEL 0000 0010 0000 in Wheel velocity FL_BRAKEFORCE 0000 0001 0000 in Real Brake force FL_BRAKE 0000 0000 0000 out Desired Brake force Table 4.1 Host Front Left Wheel node It is the same addressed for the other Wheel nodes. But for the back right wheel you use BR, for the left right wheel node you use BL and for the front right node you use FR instead of FL.

HOST

Data CEB WEBOEBREADYB INTB

RAM_CLK_TESTSE USE_RAM_CLK

Address

CNI TTP/C

Figure 4.2 communications between the CNI and the host CNI (Communication Network Interface) – AS8202NF

4.1.2 The brake sensor The pedal force will be simulated with a tri-terminal potentiometer where the mid-terminal output voltage is connected to an A/D converter that translate the analogue value to a digital value and the size of the input sensor value is 10 bits. The A/D converter can preferrably be connected to socket J2 [27]. I`ve got 11 I/O pins there and also voltage feeding. I need 10 bits for the pedal value and an A/D converter with 5 V feeding that convert the input signal. The monitoring could be as follow. 1. One of the pins is connected to the A/D converters in signal for converting start activated.

30

2. Wait at least the time it takes for the A/D converter to convert a new value. 3. Read that value at the other 10 I/O pins.

4.1.3 Pedal node The function of the pedal node is to read the sensor value of the brake pedal, calculate the brake force for the four brake actuators and manage the ABS function. To sort out the most incorrect values only pedal position value between 100 and 1023 are used when the brake force is calculated. The calculated brake value has been calculated according to an earlier thesis work [26]. I calculate the brake value in the component Pedalcalbrake as follow when the pedal position is 0-99 and 924 - 1023 the calculated brake force is not valid = “00000000000”, in other case when pedal position is (100 – 899) the calculated brake force is (150 to 949) and when the pedal position is (900 – 923) the calculated brake force will be (1150 – 1173) (See table 4.2, figure 4.3) with one exception and that is when the wheel is locked (the wheel velocity is 0 km/h, the ABS function will start and the calculated brake force value will be set to “00000000001” until the wheel has locked up and that will be independent of the value of the pedal sensor. Brake sensor value (base 2)

Brake sensor value (base 10)

Calculated brake force value(base 2)

Calculated brake force value(base 10)

0000000000 0 00000000000 0 0011000010 50 00000000000 0 0001100011 99 00000000000 0 0001100100 100 00010010110 150 1000100110 550 01001011000 600 1110000011 899 01110110101 949 1110000100 900 10001111110 1150 1110001111 911 10010001001 1161 1110011011 923 10010010101 1173 1110011100 924 00000000000 0 1111111111 1023 00000000000 0

Table 4.2 Pedal sensor value and the calculate brake force value

31

Brake force

0

100

200

300

400

500

600

700

800

900

1000

0 500 1000 1500

Calculated brake force

Ped

al s

enso

r

Figure 4.3 Calculated brake force

4.1.4 Wheel node with ABS Receive calculated brake force and send real brake force and wheel velocity to the pedal node. Depending on the calculated received brake value the actuator brake harder or release the brake. The regulation of a brake actuator will typically be controlled using feedback from sensors in the brake actuator. As I have no real actuator there will be no code written for how to translate the requested brake force value into control signals for an electromechanical actuator. In this node the wheel velocity will be simulated as a pulse where the pulse length depends on the velocity. This pulse frequency will be read and translated into a km/h value in the node, a value that is then sent to the pedal node. The test case that will be simulated is a situation when you drive in 130 km/h and you have to stop immediately (See figure 4.4 and 4.5). The ABS system will go on twice when you brake after 0.24 seconds and after 0.5 seconds. It will be locked in 0.1 seconds each time. The brake slow down is supposed to be uniform so I use the mean value in the calculation. At the velocity 130 km/h it will take 4.0 seconds to stop the car. Brake stop time at 130km/h = 72.17/(65/3.6) = 4.0 s

32

Brake with ABS

0

20

40

60

80

100

120

140

0 1 2 3 4 5

Time (s)

Whe

el V

eloc

ity (k

m/h

)

Series1

Figure 4.4 Wheel velocity simulation

S i mul a t e d whe e l v e l oc i t y ( 13 0 - 10 k m/ h)

-0,002

0

0,002

0,004

0,006

0,008

0,01

0,012

0,014

0,016

0 50 100 1

k m/ h

50

S i mul a t e d whe e l v e l oc i t y ( 10 - 0 k m/ h)

0

0,2

0,4

0,6

0,8

1

1,2

0 2 4 6 8 10 12

k m/ h

Figure 4.5 Simulated wheel (cycle length) When I simulate I step up the pulse length and I assume that the cog is 1/5 of the pulse. At 130 km/h are the cycles 1000/s and the length of each cycle are 1000 (µs) and the clock frequency is 5 MHz (See table 4.3).

Cycles/s Pulse length (µs) Low (µs) High (µs) 1000 1000 200 800

999-501 + 0.4 + 1.6 500-101 + 4 + 16 100-51 + 40 +160 50-11 +400 + 1600 10-6 +4000 +16000 5-1 +40000 +160000 0 0

Table 4.3 How the length of the cycles steps up

33

4.1.5 Wheel node without ABS Receive calculated brake force and send some status message. When FL wheel is locked the brake force will be shared at the other three wheels. None of these nodes will have locked wheel. This is done in the component FRWheelsim. For back wheel BL and BR are used. The wheel simulations are the same as for the wheel with ABS with the exception that the wheels never lock and in component (See figure 4.7).

S i mul a t e d whe e l v e l oc i t y ( 13 0 - 10 k m/ h)

0

0,002

0,004

0,006

0,008

0,01

0,012

0,014

0,016

0 50 100 150

k m/ h

S i mul a t e d whe e l v e l oc i t y ( 10 - 0 k m/ h)

0

0,2

0,4

0,6

0,8

1

1,2

0 2 4 6 8 10 12

k m/ h

Figure 4.7 Simulated wheel without ABS (cycle length) In component FRpulsevelocity you check the pulse length and translate it to a velocity in km/h that will be sent to the pedal node.

4.2 Design without TTP/C implemented in this theses The system that will be implemented in this thesis is very simple and we don’t use TTP/C. The system consist of 2 nodes the Pedal node and one wheel node with ABS. The nodes will be the same as the nodes with TTP/C the only difference is the communication between the wheel node and the pedal node and that there is only one wheel node.

4.2.1 Direct communication between the pedal node and wheel node The communication happens during use of the IC2 bus, as the memory hang on. Only two wires are needed. I take out the signals on JP18, pin 4 and 5 according to table 17 on page 43. According to table 15 they are connected to pin 21 and 20 on the FPGA and these should be connected between the nodes as 4 and 5 on the pedal node to 4 and 5 on the wheel node. The I2C-funktion lies in the FPGA:n. Maybe there will be a ready VHDL component to realise the block. [27] In this thesis there are only the nodes for a future Brake by Wire system with TTP/C that are implemented. The nodes that will be implemented will communicate directly to each other.

4.3 Software I use Alteras Quartus II software for designing high performance architectures FPGA and the programming language VHDL (Very High Speed Integrated Circuit Hardware Description Language).

34

4.4 Hardware The design in this thesis will be implemented in a Field Programmable Gate Array (FPGA). The FPGA device is a Cyclone provided by Altera.

4.4.1 HOST: Altera UP3 Education kit The Altera UP3 education is shown in (See figure 4.8 and 4.9).

Figure 4.8 Altera UP3 Education kit “This board provides a powerful educational support and also a low cost solution for prototyping and rapidly development products. The board serves a means for hardware as well as software development. It gives scope to a hardware design engineer to design, prototype and test hardware design using VHDL” [27]

35

Figure 4.9 UP3 Board top view

36

5 Implementation of the Brake System with ABS The implementations of the tasks are made in the programming language VHDL [28], [29]. I use Alteras Quartus II. All tasks that are used by the pedal node and the wheel nodes are declared in Appendix A and the simulation results are declared in Appendix B. In this thesis there are only the nodes for a future Brake by Wire system with TTP/C that are implemented. The nodes that will be implemented will communicate directly to each other. When I simulate I use device EP1C12F256C6.

5.1 Pedal node See the code in Appendix A and the simulation result in Appendix B.

5.1.1 The brake sensor Not implemented.

5.1.2 Simulation of the pedal node Simulating the pedal node with the input (brakesensor) according to table 4.2 I have the correct output value (calculated brake force FLbrake). When the wheel velocity (FLwheelvel) is 0 km/h I also have the correct output value for the calculated brake force (“00000000001”) independent of the pedal sensor value. When reset = 1 or outside the range 100-923 is the calculated brake force = “00000000000” (FLbrake).

5.2 Wheel node See the code in Appendix A and the simulation result in Appendix B.

5.2.1 Wheel simulation in node with locked wheel The real brake force value will be set to the calculated brake value that I receive from the pedal node in the wheelnodetop. In component FLwheelsim I calculate the total pulse length and high pulse length according to table 4.2. Pulseno 0 is the same as 1000 cycles/ s (See table 5.1) and pulsno 1000 are the same as 0 cycles/s (the car has stopped). The clock frequency 200 ns are used. After 0.24 s and 0.50 s will the wheel be locked in 0.1 s. In table 5.1 I show some value for the signal Pulseno and the value that will be simulated for Totpulse and Highpulse.

37

T Tt TH W S Il TTtk

Pulseno

Totpulse Highpulse Time (s)

0 5000 1000 0.0001 5010 1002 0.004

60 5600 1120 0.24061 5610 0 0.24485 5850 0 0.34086 5860 1172 0.344

124 6240 1248 0.496125 6250 0 0.500149 6490 0 0.596150 6500 1300 0.600499 9990 1998 1.996500 10000 2000 2.000501 10100 2020 2.004899 49900 9980 3.596900 50000 10000 3.600901 51000 10200 3.004949 99000 19800 3.796950 100000 20000 3.780951 110000 22000 3.784989 490000 98000 3.956990 500000 100000 3.960991 600000 120000 3.964993 900000 180000 3.972995 1000000 200000 3.980996 2000000 400000 3.984999 5000000 1000000 3.996

1000 100000 0 4.000

able 5.1 Totpulse and Highpulse are calculated in component FLwheelsim

otpulse and Highpulse are the signals that are sent to component FLpulseout that will simulate he pulse.

otpulse - Total size of the pulse ighpulse – Size when the pulse is high

hen the brake is not on or reset is set the output value will be according to Pulseno = 0.

imulating the result was according to table 5.1 (See Appendix B test of wheel).

n component FLpulseout the pulse is simulated. The total length of the pulse is = Totpulse and ength when pulse is high = Highpulse (See table 5.1).

he component FLpulsetovelocity counts the pulse and translates it to a value (1000-0). he clock pulses are counted between every time the wheel pulse trigs (positive flank) and

ranslates it to an integer with the range of 1000 to 0. 1000 is 130 km/h, 500 is 65 km/h and 0 is 0 m/h. between 0.244 – 0.344 s and 0.500 – 0.600 is the wheel velocity 0 km/h. Only if the

38

velocity is greater than 32.5 km/h (300 = 6 ms) I check if the wheel is locked. This is due to the fact that if the velocity is lower there will be problems cause of the long pulse length, and if the pulse length is longer than 1 s (0.13 km/h) I assume that the car has stopped. Pulse length (ms) (no of

cycles*200ns) Wheel velocity Time (s)

1.000 ms (5000) 1000 (130.00 km/h) 0.0001.002 ms (5010) 999 (129.87 km/h) 0.004

>1000 ms (> 5000000) 0 km/h 0.244-0.3341.200 ms (6000) 900 (117.0 km/h) 0.400

>1000 ms (> 5000000) 0 km/h 0.500-0.600 2.000 ms (10000) 500 (65.00 km/h) 2.000

10.000 ms (50000) 100 (13.00 km/h) 3.60020.000 ms (100000) 50 (6.50 km/h) 3.800

100.000 ms (500000) 10 (1.30 km/h) 3.960200.000 ms (1000000) 5 (0.65 km/h) 3.980

1000.000 ms (5000000) 1 (0.13 km/h) 4.000Table 5.2 The velocity of the wheel The test result when I simulate the wheel node is in Appendix B wheelnode where pulseout is only temporary to see the pulse that is simulated from component FLpulseout.

5.2.2 Wheel simulation in node without locked wheel This is not implemented in this thesis as wee only got one wheel node FL, but for future use I explain the implementation. The brake force is shared when FL wheel node is locked and the wheel will never be locked in those nodes.

5.3 Communication between the pedal node and wheel node Not implemented.

39

6 Summary and conclusions One of the goals with this thesis was the development of a simple platform that will be applied for educational purpose (practical training) in the course Digital System given at Mälardalens University, specific a very simple Brake by Wire system. In this moment there are only the pedal node and the wheel node with ABS that are implemented, but the communication between them is an important part and one solution is to implement TTP/C as the communication system between the nodes in a complete Brake by Wire system with four wheel nodes. The simpler way to solve the communication is that the pedal node and the wheel node will communicate directly to each other. The function in the nodes can also be developed further where more thing are checked etc. The other goal was to study the communication system. The requirements on class C real time communication systems makes it impossible to use the wide spread event driven communication protocols. The time trigged architecture and its fault tolerant time trigged protocol provides a solution for new functions as Brake by Wire. I don’t think TTCAN is adequate for safety critical application, but TTP/C and FlexRay offers a solution. I think that FlexRay is the biggest opponent to TTP/C in the future car industry. The reason why TTCAN is not considered a possibility is because it is solely event based and does not eliminate the risk in the way that TTP/C and FlexRay does. My guess is though, that in the future, it will still be used by the car industry as a complementary system. Even if it is not an alternative to the safety critical systems, the cars may carry a mixture of TTCAN along with TTP/C or TTCAN along with FlexRay. Human control is essential and for most safety critical systems, when they are developed, the safety must be acceptable. There are many aspects to be considered: cost, weighed both to organizational goals as profit and acceptability risk for humans.

40

7 Future Work Implement a complete system with TTP/C. Wheel simulation in node without locked wheel is not implemented in this thesis because wee only got one wheel, but for future use it is explained in 5.3.2. It would be possible to steer a real wheel with the simulated wheel velocity value that are simulated in the wheel node. A unit that brake the wheel could be connected to the wheel and that brake value could be read to the wheel node as the real brake force instead of today when the real brake force value will be set to the calculated brake value from the pedal node. Implement the status messages and it is possible to send the status message to some display at the driver’s instrumental panel.

41

42

8 References [1] Michael R. Lyu, Software Fault Tolerance, ISBN 0 471 95068 8, John Wiley & Sons Ltd, 1995 [2] E Touloupis, J A Flint and D D Ward, Safety-Critical Architectures for Automotive Applications, University of Loughborough, 2003 [3] Nathan Ray Trevett, X-by-Wire, New Technologies for 42V Bus Automobile of the Future, April 2002 [4] E Touloupis, J A Flint, V A Chouliarias and D D Ward, A TMR_PROCESSOR ARCHITECTURE FOR SAFETY-CRITICAL AUTOMOTIVE APPLICATIONS, University of Loughborough, [5] http://www.tttech.com [6] Th. Ringler, J. Steiner, R. Belschner and B. Hedenetz, Increasing System Safety for by-wire Applications in Vehicles by using a Time Triggered Architecture, University of Stuttgart, 1999 [7] http://staff.iha.dk/foh/Foredrag/TTPFlexRay-LunaForedrag.pdf [8] A Platform for Safety-Critical Applications, TTTech Computer technik AG, 2005 [9] Pimentel, Juan R. A Fault Management Protocol for TTP/C, The 27th Annual Conference of the IEEE Industrial Electronics Society, 2001 [10] AS8202NF TTP-C2NF Communication Controller Data Sheet Rev.1.4, July 2005 [11] http//embsys.technikum-wien.at/projects/steacs/publications/pubs/preprint_DDECS04.pdf] [12] Kosov, Sergey, FlexRay communication protocol, (Wakeup and Startup), http://www-wjp.cs.uni-sb.de/lehre/seminar/ss05/reports/kosov-report.pdf [13] http://www.fujitsu.com [14]http://zone.ni.com/devzone/conceptd.nsf/webmain/0D17AEEAED870FE486256F3C00407B73] [15] http:/www.ixxat.de/introduction_flexray_en,16540,5873.html [16] www.can-cia.de/can/ttcan [17] Leen, G. Heffernan, D. Modeling and verification of a Time-trigged Networking Protocol, April 2005 [18] http://www.tttech.com [19] Hildebrandt, A.; Sawodny, O.; Trutschel, R.; Augsburg, K.; American Control Conference, 2004. Proceedings of the 2004 Volume 2, 30 June-2 July 2004 Page(s):1463 - 1468 vol.2 [20] Ross, F. Wikander, J. Mechatronic design and optimisation methodology, KTH, 2003 http://www.md.kth.se/~fredrikr/AM2D/mekmote2003.pdf [21] Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/Anti-lock_braking_system [22] http://www.geocities.com/nosro/abs_faq/#Motivation%20and [23] http://www.cherrycorp.com/english/sensors/op_speed.htm [24] http://www.melexis.com/Asset.aspx?nID=3721 [25] http://www.automotorsport.se [26] Bruce, Maria, Distributed Brake-by-Wire based on TTP/C, Department of Automatic Control Lund Institute of Technology, June 2002 [27] UP3 Education kit, Reference Manual, Cyclone edition, ver 1, Altera [28] Sjöholm, S, Designing ASIC/FPGA with Top Down Design Flow and VHDL, ISBN 91-88834-12-31, Arkitektkopia, Västerås, 2001 [29] Sjöholm A, Lindh L, VHDL för konstruktion, ISBN 91-44-01250-0, Studentlitteratur, Lund, 1999 tredje upplagan