Simulation of a Time Triggered Protocol

David Bradbury Supervised by Agathe Merceron Basser Department of Computer Science University of Sydney, Australia

Submitted in partial fulfilment of the requirements for the degree of Bachelor of Computer Science and Technology (Honours).

Abstract
The Time-Triggered Protocol (TTP) has been presented as a suitable real-time communication protocol for use within electronic systems that permits the successful operation of safety critical applications. This paper details the implementation of a system that simulates the Time Triggered Protocol created from the official TTP/C specification. The system that was built demonstrates the inaccuracies and ambiguities of the official specification, possible solutions to which are presented in this paper.

II

Acknowledgements
I wish to thank my supervisor Agathe Merceron for her comments and encouragements throughout the duration of this project.

Cheers to the many honours students with whom I have studied this year. I cannot believe that after a whole year nothing has changed. We are still the same crazy people we were before we started and now I think we always will be.

Thankyou to my fellow collegiates at St Johns College for their support and also for making my stay at university over the last few years the best years of my life. With particular thanks to Ben Pullinger whose friendship over the years, and many unexpected visits have managed to keep me sane throughout this time.

Many thanks to Kerryn Kahler for her support during this year. You have been a great friend and you will certainly have many good times ahead of you at University and for the rest of your life.

Finally, thankyou to my parents Alan and Kerrie for their assistance over the duration of my time at University and for also always being there during the tough times. I thank you for your unfailing support without which none of this would have been possible.

III

Table of Contents
CHAPTER 1 CHAPTER 2 2.1 2.2 2.3 INTRODUCTION ____________________________________________ 1 BACKGROUND _____________________________________________ 5

CLASS C REAL-TIME COMMUNICATION SYSTEMS ___________________________ 5 EVENT AND TIME TRIGGERED COMMUNICATION SYSTEMS ____________________ 7 CONTROLLER AREA NETWORK (CAN) ___________________________________ 8 TIME TRIGGERED PROTOCOL (TTP) _______________________ 10

CHAPTER 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 3.3.1 3.3.2 CHAPTER 4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.2.4 CHAPTER 5 5.1 5.2

OBJECTIVES OF THE P ROTOCOL ________________________________________ 10 DESCRIPTION ______________________________________________________ 11 Protocol Processor _____________________________________________ 13 Communication Network Interface (CNI)____________________________ 16 Message Descriptor List (MEDL)__________________________________ 17 Logical Line Interface (LLI) ______________________________________ 20 Bus Guardian _________________________________________________ 20 APPLICATIONS _____________________________________________________ 21 Honeywell ____________________________________________________ 22 Audi _________________________________________________________ 22 METHODS ________________________________________________ 23

OBJECT ORIENTED M ETHODOLOGY _____________________________________ 23 Unified Modelling Language _____________________________________ 24 Object Oriented Analysis and Design _______________________________ 24 Extreme Programming __________________________________________ 28 TOOLS ___________________________________________________________ 30 Java_________________________________________________________ 30 Rational Rose 2000 _____________________________________________ 31 JUnit ________________________________________________________ 31 Borland JBuilder 3.0 ____________________________________________ 33 ANALYSIS AND DESIGN____________________________________ 34

SYSTEM FUNCTIONS _________________________________________________ 34 SYSTEM ATTRIBUTES ________________________________________________ 34

IV 5.3 5.3.1 5.4 5.5 5.6 5.7 5.8 USE CASES ________________________________________________________ 36 Protocol Processor _____________________________________________ 36 CONCEPTUAL M ODEL________________________________________________ 40 SYSTEM SEQUENCE DIAGRAMS ________________________________________ 40 CONTRACTS _______________________________________________________ 41 COLLABORATION DIAGRAMS__________________________________________ 41 CLASS DIAGRAMS __________________________________________________ 41 IMPLEMENTATION________________________________________ 43

CHAPTER 6 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.8 6.1.9 6.2 6.2.1 6.2.2 CHAPTER 7 7.1 7.2 7.3 7.4 7.5 7.6

TTPSIM__________________________________________________________ 43 Network Bus __________________________________________________ 43 Logical Line Interface ___________________________________________ 44 Bus Guardian _________________________________________________ 44 Communication Network Interface (CNI)____________________________ 45 Message Descriptor List (MEDL)__________________________________ 47 Protocol Processor _____________________________________________ 48 Host Computer ________________________________________________ 49 Simulation ____________________________________________________ 50 User Interface _________________________________________________ 51 MEDL TOOL ______________________________________________________ 52 Message Descriptor List _________________________________________ 53 User Interface _________________________________________________ 53 INVESTIGATION __________________________________________ 56

COLD START STATE _________________________________________________ 56 READY STATE _____________________________________________________ 58 MEMBERSHIP SERVICE _______________________________________________ 59 CRC CALCULATION OF I-FRAMES ______________________________________ 60 I-FRAMES IN NORMAL MODE __________________________________________ 62 MEDL SPECIFICATION _______________________________________________ 63 DISCUSSION ______________________________________________ 64

CHAPTER 8 8.1 8.2 8.2.1

OBJECT ORIENTED ANALYSIS AND DESIGN _______________________________ 64 EXTREME PROGRAMMING ____________________________________________ 64 Unit Testing___________________________________________________ 64

V 8.3 8.3.1 8.3.2 8.3.3 CHAPTER 9 CHAPTER 10 10.1 10.2 TOOLS ___________________________________________________________ 66 Rational Rose 2000 _____________________________________________ 66 JUnit ________________________________________________________ 66 Borland JBuilder 3.0 ____________________________________________ 66 CONCLUSIONS ____________________________________________ 67 FUTURE WORK _________________________________________ 69

TIME TRIGGERED P ROTOCOL __________________________________________ 69 BYTEFLIGHT _______________________________________________________ 69 APPENDIX ______________________________________________ 72

CHAPTER 11 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10

USE CASE: CONTROLLER _____________________________________________ 72 USE CASE: MESSAGE DESCRIPTOR LIST _________________________________ 73 USE CASE: COMMUNICATION NETWORK INTERFACE ________________________ 74 USE CASE: LOGICAL LINE INTERFACE ___________________________________ 74 CONTRACT : PROTOCOL PROCESSOR : SEND DATA __________________________ 76 CONTRACT: PROTOCOL PROCESSOR : READ DATA __________________________ 77 SYSTEM SEQUENCE DIAGRAM: PROTOCOL PROCESSOR: SEND DATA ___________ 78 SYSTEM SEQUENCE DIAGRAM: PROTOCOL PROCESSOR: READ DATA ___________ 79 COLLABORATION DIAGRAM: PROTOCOL P ROCESSOR: SEND DATA _____________ 80 COLLABORATION DIAGRAM: PROTOCOL P ROCESSOR: READ DATA___________ 81 REFERENCES ___________________________________________ 82

CHAPTER 12

VI

Table of Figures

FIGURE 1: THE STRUCTURE OF AN ELECTRONIC MODULE .......................................................... 12 FIGURE 2: AN EXAMPLE OF A TDMA SCHEME. ......................................................................... 13 FIGURE 3: THE PROTOCOL PROCESSOR ...................................................................................... 14 FIGURE 4: THE COMMUNICATION NETWORK INTERFACE.......................................................... 16 FIGURE 5: THE M ESSAGE DESCRIPTOR LIST ............................................................................. 18 FIGURE 6: THE BUS GUARDIAN.................................................................................................. 20 FIGURE 7: THE JUNIT TESTING SUITE ........................................................................................ 32 FIGURE 8: THE CONCEPTUAL MODEL......................................................................................... 42 FIGURE 9: THE COMMUNICATION NETWORK INTERFACE CLASS MODEL .................................... 46 FIGURE 10: THE MESSAGE DESCRIPTOR LIST CLASS MODEL ...................................................... 47 FIGURE 11: THE CLASS DESIGN DIAGRAM FOR THE PROTOCOL PROCESSOR ............................... 49 FIGURE 12: THE TTP/C SIMULATION........................................................................................ 51 FIGURE 13: THE MEDL EDITING TOOL ..................................................................................... 54 FIGURE 14: AN EXAMPLE OF AN OUT OF RANGE EXCEPTION ...................................................... 55 FIGURE 15: M EMBERSHIP CALCULATION .................................................................................. 61

Chapter 1 Introduction
The automotive industry is undergoing a tremendous change away from the use of traditional mechanical components to new drive-by-wire electrical systems [1]. This is seen both as a cost effective measure, with electrical systems costing far less than their mechanical counterparts, as well as an improvement to the overall safety of the vehicle, with the addition of intelligent assistance systems (eg. the Antilock Braking System, ABS) to assist the driver in critical situations [2]. These new systems must obviously support hard real-time control in a safety-critical environment whereby the systems will continue to operate despite the failures of any of their constituent parts [3].

In 1993 the Society for Automotive Engineers (SAE) imposed standards on the requirements for the implementation of safety critical control applications for use within automotive vehicles [4]. In an additional document from the same committee within the SAE it was determined that none of the existing communication protocols that were currently available for use in distributed fault-tolerant architectures were able to meet these requirements [5].

The Time-Triggered Protocol (TTP) has been presented as a suitable real-time communication protocol for use within electronic systems that permits the successful operation of safety critical applications [7]. Particular interest has been generated by the automotive industry in this new technology as TTP is both deterministic, synchronised and fault tolerant, a combination of properties that are not present in the communication protocols of current commonly used in-vehicle communication systems (CAN, A-BUS, VAN, J1850-DLC, J1850-HBCC) [3][6].

The Time Triggered Protocol has been developed over the past fifteen years by the Technical University of Vienna and has been built upon by several projects including the Brite Euram Project "X-by-Wire" [3]. TTP has undergone many changes throughout this period including being refined to satisfy the SAE Class C requirements for hard real-time fault-tolerant communications. Presently the Time Triggered Protocol Class C (TTP/C) specification is a document of some 140 pages of natural language description, the maintenance of which has recently been transferred from the Technical University of Vienna to the company TTTech (http://www.tttech.com/) [8]. This maintenance has been conducted concurrently with a range of different research works that have aimed to formally specify particular aspects of TTP in order to validate the English description. This project is an extension of such research.

Previous simulations of the Time Triggered Protocol that have sought to validate properties of the protocol have been conducted at the Technical University of Vienna. This has included a study of the protocols behaviour under the occurrence of rare events using discrete Petri-net models, which examined the protocol for the occurrence of deadlocks and unallowed states [9]. A successive project involved the development of a simulation environment for the Time Triggered Protocol running the exact same protocol source code that is executed on the target hardware. This environment provides the ability to conduct regression testing in the case of changes to the protocol source code and also permits the construction of a suite of reference test sets for protocol conformance testing [10].

This project applies the object-oriented paradigm to the design and implementation of a software simulation of the official TTP/C specification.

The objectives of the simulation are twofold. From simulations that have been undertaken previously, no attempt has been made to investigate the ability to create a TTP/C communication system based purely on the official specification. This project aims to highlight the accuracies and inaccuracies of the natural language specification document that describes the Time Triggered Protocol, particularly to determine whether this description is correct, complete, or unambiguous. Additionally, this project aims to investigate the validity of some basic aspects of the specification, including the membership function and the start up process, and provide an insight into possible extensions or modifications to the specification.

In order to successfully complete these objectives it was determined at the beginning of the project that the final system must be able to satisfy the following requirements:

The system must provide an accurate simulation of the entire Time Triggered Protocol as described precisely in the official protocol specification. This involves simulating all of the components of the protocol including the controller, host computer, and the network bus.

An extensive investigative validating methodology must be applied throughout all phases of the software development life cycle in order to assert the system properties defined in the specification.

3 The system must provide a simple and clear graphical user interface. In order to determine the success of a simulation it is necessary to have all of the available data from all controllers participating in the simulation visible to the user.

The system must be able to support modifications to the simulation parameters. This is necessary in order to accommodate a varying number of controllers under changing conditions, thus permitting scenario-based simulations of the protocol.

The system must be interactive. In order to investigate all aspects of the simulation it is necessary to be able to change the state of the scenario at anytime during execution.

This paper describes the analysis, design, implementation, and investigation of a simulation of the Time Triggered Protocol. Descriptions of each chapter are briefly mentioned below.

Chapter 2 provides the rationale behind the need for communication systems that are capable of supporting safety critical applications. The most widely used automotive communication system, the Controller Area Network, is discussed here with reference to the inability of that protocol to satisfy the SAE class C requirements for the implementation of safety critical applications in automotive vehicles.

Chapter 3 details the Time Triggered Protocol, which has been presented as a communication system for use in automotive applications. A review of the objectives that were used in the creation of the protocol as well as an examination of the mechanisms involved in the protocol is included. Finally some examples are given of the Time Triggered Protocol being used in industry.

Chapter 4 explains the methodologies that were followed in the development of the simulation of the Time Triggered Protocol. This includes the description of two software engineering processes that were selectively combined throughout the development of the project. A range of tools that were used to support the use of these processes during development are also detailed in some depth.

Chapters 5 and 6 detail the analysis, design, and implementation of the simulation of the official specification of the Time Triggered Protocol, using the methodologies and tools described in Chapter 4.

4 Chapter 7 describes the investigation component of the project, which involved the examination of specific aspects of the official specification that were raised during the implementation of the simulation. Possible solutions to problems encountered in the specification are also detailed.

Chapter 8 discusses the effectiveness of the methodologies and tools that were used throughout the development of the project.

Chapter 2 Background
Currently automobiles that contain intelligent assistance systems such as the Antilock Braking System (ABS) and the Electronic Stability Program (ESP) contain both electronic systems in addition to the existing mechanical system. When a problem occurs within one of these assistance systems it is a rather simple m echanism that detects the incorrect behaviour of the system and shuts down the service, allowing the mechanical backup to continue operation.

Vehicles containing the new drive-by-wire electrical systems are being designed without mechanical backup components, thus creating a need for a greater standard of safety requirements for in-vehicle systems. When a fault occurs within a component of any of the installed systems there must be mechanisms in place such that the vehicle will remain functioning normally and effectively. For example, given a failure in one of the four actuators responsible for braking at each wheel, the braking system must have the ability to handle the fault and continue operation [3].

Obviously, the safety requirements involved here are extremely great, however, the benefits of utilising drive-by-wire systems are also numerous. The brake-by-wire project [3] identified the following advantages over the current use of mechanical components and intelligent systems:

Intelligent assistance systems could be installed with only software and sensors, thus without requiring expensive mechanical or hydraulic components.

Easier adaptation of assistance systems as compared with current hydraulic interfaces through the use of electrical interfaces.

A reduction in packaging problems. Improved safety through the removal of mechanical links between component parts (eg. between the brakes and the engine).

A reduction in the need for fluids (eg. Brake Fluid, Power Steering Fluid) resulting in lower maintenance and also benefiting the environment.

A reduction in costs during production.

2.1 Class C Real-Time Communication Systems

For a communication system to operate effectively within an automobile while supporting safety critical applications, different requirements than those used in other systems must be applied [2]. In

6 response to changes in the use of electrical systems within automobiles, the Society for Automotive Engineers (SAE) specified a set of requirements for communication systems that are to be used with safety critical applications [4]. Three classes for vehicle communications were identified, covering body electronics (SAE class A, B) and system electronics (SAE class C). The requirements for class C communication systems are detailed below with references to both [3] and [12].

Regularity of Information Transfer Safety critical applications usually execute in a rather fixed manner by collecting input, processing this input, and acting according to the output of the processing. This regularity displays a pattern whereby large amounts of data are exchanged periodically. A real-time system must be able to handle the cases when failures occur within the system, a situation that usually results in irregular communication taking place. This must be handled without effecting the regular operation of data transfer within the system.

Minimal Message Latency The latency of information exchange is calculated as the difference between the time at which a controller sends data and the time at which that data arrives at the receiving controller. The latency that is achieved by a communication system is dependent upon many physical aspects such as the bandwidth of the media used, and the media access method. The range for allowable latency is defined by the applications that are running within the system and can be as small as the one-millisecond range.

Fault-tolerance The system must be able to continue to provide its function after the occurrence of a fault. This behaviour must be guaranteed up to a known number of faults.

Robustness The communication system is a vital component and as such the design should tolerate electromagnetic interference as well as recover from blackout scenarios with minimal latency.

Error detection In a typical system many c ontrollers will cooperate to provide a single service. In cases where a controller fails it is the responsibility of the remaining controllers to detect the failure and react appropriately. A membership agreement between controllers is necessary to provide this capability.

Acknowledgement and Atomic Transmission It is important that controllers detect whether the receiver of a transmission from the sending controller did so correctly. An acknowledgement scheme is required in order to provide this functionality. Additionally, the network must ensure atomic transmission, such that a message sent on the network is received by all recipients or by none.

Testing Each subsystem that exists as a part of the communication system must be able to be tested independently of the other subsystems. Also, the integration of any subsystem into the existing system should not have any side effect on the correct operation of the system.

Configurability and Composability During the integration of subsystems it is important to maintain all of the properties of the subsystems already within the integrated system. This not only includes maintaining the properties of the new subsystem, but also the existing subsystems.

2.2 Event and Time Triggered Communication Systems

The two main approaches to the design of distributed real time systems rely on event triggering (e.g. CAN), time triggering (e.g. TTP), or a combination of these (e.g. Byteflight, see Chapter 10 Future Work) to control system actions [2].

In an event triggered system temporal control signals are derived primarily from non-time events occurring outside or inside of the system [11]. The system is designed for the transmission of event messages. Event messages are messages that are transmitted directly following an event and contain information regarding that event. Once an event occurs in such a system, the signalling of events

from the controller to the host computer is made through the use of an interrupt mechanism. All scheduling and communication decisions in an event-triggered architecture have to be made dynamically during protocol execution, with the appropriate application being executed according to the current event that took place within the network.

In an event triggered system it is the responsibility of the host computer to decide when a message must be sent [12]. If more than one controller attempts to send a message at the same time and the network bus consists of only one channel, then a conflict for access to the network bus occurs.

8 Different solutions to this problem have been implemented including a random access technique (Ethernet) and by message priority (CAN); however, the problem stems from the fact that temporal control in an event triggered system depends on the behaviour of all controllers within the system, thus these types of systems cannot be thought of as being composable. That is, the system does not have the ability to integrate new subsystems without the possibility of effecting the ability of the network to function as a whole.

Architectures based on time triggering have all of their activities initiated by the progression of time. Time triggered systems implement a time division multiple access (TDMA) method in order to gain access to the network bus [11]. This operates successfully by giving each controller an amount of time in which they have exclusive sending rights in the network. All controllers have a synchronised clock that prevents any controller transmitting out of turn, which results in the notion of a shared global time within the system. Here each controller in the network refers to this global time to determine at which point a message is to be sent. All tasks and communication actions within a time-triggered system are periodic and state variables are sampled at predefined points in time. These types of architectures are less flexible than event triggered systems, however, they are easier to analyse and test [7].

2.3 Controller Area Network (CAN)

CAN is an event-triggered communication system and is currently the most widely used communication system for supporting automotive applications. The controller area network was designed by the automotive component supplier Bosch, and was first implemented in the Mercedes Benz S-class Model in 1991. CAN has since been adopted by v arious companies including BMW, Volvo, VW, Renault, PSA, and others. The main motivation behind the invention of CAN was to simplify the large amount of wiring needed in modern vehicles. This was due to the fact that the wiring harness in a vehicle is frequently the most complex and expensive electrical system component. The Volvo S80 saves more than one kilometre of wire by employing a 250 kbps CAN powertrain control bus linked to a 125 kbps CAN body electronics bus to manage 18 electronic control units [2].

As stated previously, CAN is an event-triggered communication system. For messages to be transmitted in a CAN system the host computer must request the controller to transmit a message and either the channel must be idle or the message to be transmitted must have a higher priority than

9 other messages that are being sent at the same time. The system uses the carrier sense multiple access/collision avoidance (CSMA/CA) technique for accessing the network bus.

The following frame types are used by CAN: Data Frames are used to transmit data during the regular operation of the system. Remote frames are used to request the transmission of a message from another controller. Error frames are used when the sending or receiving controller detects an error during transmission. Overload frames are used by receiving controllers to delay the next sending controller from transmitting.

When CAN networks were originally used they were restricted to using only 10% of the potential capacity of the physical medium in order to ensure a level of responsiveness by all controllers. This is unacceptable for the majority of current real time systems [2].

CAN systems demonstrate a wide latency jitter, which degrades the responsiveness of the system. This can result in the phenomena of orphans where a receiver misses a message due to timing out before the message arrives, leading to degraded system performance [2].

Despite their limitations CAN communication systems have been shown to be highly reliable, with the CAN 2.0 protocol specification stating that the chance of an undetected transmission error was calculated at less than 4.7x10-11 . This equates to approximately one error every 1000 years in a vehicles lifetime. In an evaluation of CAN SAE J1939 conducted by the US National Highway Traffic Safety Administration, no failures were recorded in 71 million transmissions during a 4000km trip, despite the network bus being purposefully loaded to capacity [2].

In a report by the SAE [5] CAN was determined to be unsuitable for use as a class C communication system as it had not been designed to meet the demanding requirements for supporting safety critical applications, such as drive-by-wire systems. Additionally, as

highlighted earlier, in the same report the SAE identified that none of the other commonly used communications systems were suitable, citing same reasons of being inadequate in terms of being deterministic, synchronised, and fault-tolerant [3].

10

Chapter 3 Time Triggered Protocol (TTP)

Previously the aircraft domain has been the technology leader in the field of fault-tolerant real-time systems [1]. An example of a time-triggered protocol used in the aircraft industry is the ARINC 659 standard developed by Aeronautical Radio Inc. The implementation of ARINC 659 by Honeywell, called SAFEbus, is built into the Boeing 777 Airplane Information Management System [10]. The expensive nature of these types of time-triggered systems have prevented their use outside of the aircraft industry and due to the increasing need for these types of distributed fault tolerant systems in the automotive industry, a number of communication systems have been developed in an attempt to fulfil this demand.

The unsuitability of commonly used in-vehicle communication systems to fulfil SAE class C requirements as well as the expensive nature of communication systems used in other industries, as discussed previously, has lead to the investigation of the Time Triggered Protocol for use in supporting safety critical applications [3].

The Time Triggered Protocol is an integrated communication protocol for time-triggered architectures designed to support the interconnection of the electronic modules of distributed fault tolerant systems. As discussed above, in a time-triggered architecture the communication system decides when to transmit a message according to a predetermined schedule within each controller, which specifies the times at which messages should be transmitted [8].

This section gives a summary of the Time Triggered Protocol taken from the official specification [8] and also the original Time Triggered Protocol description [7].

3.1 Objectives of the Protocol

The primary objective during the design of the Time Triggered Protocol was to develop an integrated protocol that provides all of the services required by automotive on board real-time networking applications. Additionally, the following goals were also considered in the design of the protocol.

Message Transport With Predictable Latency In a real time system the temporal accuracy of information is affected by the duration of the protocol execution. A good real time protocol must have a low maximum execution time and a

11 small variability of the execution time under all specified load and fault conditions. It must handle time-triggered periodic messages and event-triggered sporadic messages.

Fault Tolerance The protocol must tolerate all transient and permanent controller and channel failures that are listed in the fault hypothesis without violating the functional or temporal specification.

Temporary Blackout Handling A temporary blackout is the temporary interference of some powerful external disturbance with the operation of the control system. The protocol should detect and handle temporary blackouts promptly.

Clock Synchronisation The establishment of a global time base with known precision is one of the basic services that must be provided to distributed real-time applications.

Distributed Redundancy Management The removal of failed controllers and the reintegration of spare controllers and repaired controllers has to be controlled by a redundancy management protocol.

Support for rapid mode change In many real-time applications a set of different operational modes can be distinguished, eg. Start-up, normal operation, emergency, etc. The protocol should support the consistent and rapid change from one mode to another.

Minimal Overhead In many real-time applications the communication bandwidth is limited. The protocol should provide the specified service with minimal overhead, both in message length and the number of messages.

3.2 Description
A TTP/C network, also referred to as a cluster, consists of a number of electronic modules that are connected to a network bus that consists of two replicated communication channels. An electronic module consists of a host computer, the network bus, a controller, and an input/output interface to the sensors in the vehicle. A controller operates autonomously without any control signals from the

12 host computer and is comprised of the protocol processor, the message descriptor list (MEDL), and an independent hardware unit that exists within the controller called the bus guardian. The contents of the controller are bounded by two interfaces. The controller utilises a communication network interface (CNI) to interface with the host computer and a logical line interface (LLI) to communicate with the network bus. This is illustrated in Figure 1.

Figure 1: The structure of an electronic module

Access to the network bus in a TTP/C network is controlled by a cyclic time-division multiple access (TDMA) schema derived from the notion of global time. A possible media access scheme using the TDMA schema is shown on the following page in Figure 2. A TDMA round is defined as a sequence of slots in which all controllers send one message. (Note that on occasion controllers are referred to as SRUs, meaning the smallest replaceable units that must be changed in the case of a fault occurring in a cluster). Multiple TDMA rounds in which the same transmission sequence is enforced, but possibly different messages are transmitted, form a cluster cycle. After the completion of a cluster cycle the transmission starts again at the beginning of that same cluster cycle.

13

Figure 2: An example of a TDMA scheme.

During operation of a cluster the protocol synchronises all controllers such that their internal time is within an allowable precision range of the global time. Controllers operate by executing certain actions at times specified by the MEDL. The MEDL contains the necessary information for the controller to operate in the cluster. This includes the following information: The time at which a message must be transmitted as well as the memory location from where the data is to be retrieved. The time at which a message must be received as well as the memory location from where the data is to be stored. Other miscellaneous protocol information.

The TTP/C protocol differentiates amongst two different types of frames that can be transmitted by a controller. I-Frames are used for the initialisation of controllers and also for the reintegration of restarted controllers. They contain the C-state field (controller state field) that identifies the controllers understanding of the state of the cluster including the current sending slot, the global time, and the current membership (see Protocol Processor below). N-frames are used during normal protocol operation for transmission of application data.

Each component of the controller is detailed below.

3.2.1 Protocol Processor

The protocol processor executes the TTP/C protocol code. In order to provide its service the protocol processor must have direct relationships with the message descriptor list, the communication network interface, and the bus guardian as seen in Figure 3.

14

Figure 3: The protocol processor

The processor moves through a series of different states as the protocol is executed. These states are identified briefly below.

Freeze State

This is the initial state of the controller at power on. The execution of the TTP/C protocol is halted until the controller is turned on by having the host computer set the Controller On field within the CNI.

Init State

The controller enters the init state after it has been turned on by the host computer setting the Controller On field within the CNI. In the init state the controller initialises all of the fields within the CNI.

Listen State

The controller enters the listen state after the controller has finished initialisation. In the listen state, the controller listens for activity on the network bus for the duration of the listen timeout.

Cold Start State

The controller can enter the cold start state only if the Cold Start flag is set within the controllers MEDL, and the controller received no frames from the network bus for the duration of the listen timeout. The controller assists in the integration of other controllers by sending I-frames on the network bus. The controller continues in the cold start state until it receives a valid response from

15 another controller or the maximum number of I -frames to be sent in cold start has been reached, in which case the controller transits to the listen state.

Ready State

The controller enters the ready state when it has synchronised on a valid I-frame received from another controller. The controller attempts to acquire its allocated slot by continually checking the Reintegration Allowed flag in the MEDL.

Active State

The controller enters the active state when it has acquired its allocated slot. In this state the controller transmits I-frames and N-frames according to the entries of the MEDL.

Passive State

The controller enters the passive state upon a failure of the host computer. In this state the controller is synchronised within the cluster but does not send any frames on the network bus.

Await State

The controller enters the await state when the host computer sets the Controller Await field within the CNI. Instead of executing the protocol code the controller waits for download.

Self Te st State

The controller performs self-tests as specified by the Built In Self-Test (BIST) enable field within the CNI. This enables the host computer and the controller to ensure that the controller is behaving correctly.

Download State

In this state the controller retrieves application data for the host computer or a new MEDL for the controller using the network bus. A different protocol for transmission is used during the download state than is used during normal TTP/C protocol execution.

Reconfigure State

The controller changes the role of the controller within the current cluster at the request of the host computer. Reconfiguration is not required to be supported by all controllers.

16 Membership Function As well as ensuring that specific actions are executed when particular parts of the MEDL have been reached, the protocol processor maintains the membership service that is used by the protocol as a mechanism for implicit acknowledgement. The membership service informs all controllers present in the network about the current operational state of each controller. A membership vector that is stored in the C-state field of the CNI is used to record whether a controller is operational. The membership service relies on a series of CRC checks over the contents of frames that are received from other controllers. From the results of these CRC checks, a calculation is made as to the membership of the current controller.

3.2.2 Communication Network Interface (CNI)

The main purpose of the CNI is to store messages received from controllers in the network. The CNI is the interface of the controller that is visible to the system programmer of the host computer. It is located in a memory area that allows simultaneous random access by the controller and the host computer. However, the CNI is physically located within the actual controller. The CNI can be seen as containing three distinctly separate components as illustrated in Figure 4.

Figure 4: The Communication Network Interface

The Status Area

The fields that are contained within the status area are read-only fields for the host computer. These fields contain the necessary information for the controller to execute the TTP/C protocol. In particular this contains the current state of the controller and the data associated with the controllers view of the current network operational state, including the C-state field that contains the

17 membership vector used in the membership calculation and also the current cluster mode of operation.

The Control Area

The control area contains the fields that are permitted to be modified by the host computer during protocol execution. They include fields that identify whether the host computer is functioning correctly and also the fields that allow the host computer to alter the current cluster mode of operation. The majority of fields contained within the control area are read-only for the controller. There are some fields, however, that are special cases and they may be written by both the host computer and the controller; this includes the Controller On flag that is cleared by the controller when the controller transits into the freeze state, and set by the host computer in order to start protocol execution by the controller.

The Message Area

The message area physically follows the previous areas within the CNI. For every slot that is present within a TDMA round, an entry exists within the message area to store both the received frame during that round as well as fields that are filled in with data concerning the reception of the frame. Also, the possibility exists that a message area layout may contain space for two frames received in a single slot on both channel A and channel B, rather than storing a single frame that was transmitted redundantly on both channels. The reception of frames overwrites the values present in the message area with the contents of the current frame. The message area also stores the data from the host computer that is to be transmitted on the network bus.

3.2.3 Message Descriptor List (MEDL)

The MEDL is the data that defines the TDMA schema for the cluster. Each controller within the cluster must have a personalised MEDL that describes the controllers actions for the duration of the clusters operation. The cluster design is the data model that describes the communication pattern of a cluster of controllers. It is from this cluster design that the personalised MEDLs are derived. A basic assumption of the protocol properties is that there are no design faults in the controller or the MEDL. This requires stringent properties to be maintained between personalised MEDLs to ensure compatibility. One such property is that the personalised MEDLs may differ in local aspects; however, they must never differ in any cluster wide aspect. These properties must be checked before the controller is used within the cluster since no allowance for the checking of MEDL semantics is made during the protocol execution. During execution, however, syntactic checking using the stored CRC fields within the MEDL as well as any o ther additional mechanisms

18 that are implemented constantly check the MEDL for any hardware failures in the MEDL memory. The MEDL is divided into several blocks of data as illustrated in Figure 5.

Figure 5: The Message Descriptor List

Parameter Block

This area contains the controller information. This includes fields such as the Cold Start Flag identifying that this controller is permitted to transit to the cold start state, as well as other fields identifying the individual configuration of the controller.

Bus Guardian Parameter Block

The actual layout of the bus guardian parameters for a controller is dependent upon the actual implementation of the bus guardian, which is not defined in the official TTP/C specification.

Reconfiguration Role List

The role list contains a parameter set for all valid roles that can be assumed by this controller. Reconfiguration of a controller allows a controller to alter its role within the cluster, allowing a controller to take over the role of a more critical component upon failure of another controller. Reconfiguration is optionally supported within controllers and according to the official specification

19 the feature does not have to be implemented. If a controller does support reconfiguration, t ere are h multiple entries within the role list; otherwise there is only one entry present. The first entry in the role list is the controllers default role that is entered at startup.

Mode Control Block

The header of transmitted frames includes three mode-change bits that have the ability to change the mode of the network to one of six modes as specified by the mode control block. Mode changes can occur within three immediate modes (executed during the current slot) and three deferred modes (executed at the end of a cycle). The mode control block contains one immediate mode change entry for all modes and one deferred mode change entry for each mode, each mode control entry contains the three permitted mode changes that are specified in the frame header.

Implementation Specific Parameter Block

The implementation specific parameter section contains control information for the controller which is not specific to TTP/C but to the controller design.

Transmission Block

The transmission block has the form of a matrix of (up to) 31 columns. The slot control section forms the first column of the matrix. The next column contains the mode address section for the startup mode with the remaining columns containing the mode address sections for the (up to) 29 application modes that can be accessed by mode changes.

Each slot within the cluster cycle requires one slot control entry and one mode address entry where the slot control entry is valid for all modes, while the mode address entry is valid for only one specific mode. The slot control entry specifies those fields that must be identical regardless of the cluster mode. This includes the MEDL position that identifies the controllers sending slot within a TDMA round, and the clock synchronisation flag that specifies when the clock synchronisation algorithm is to be executed. Alternatively, the mode address entry contains information regarding the current slot, whose parameters may change depending on the current cluster mode. This includes fields such as the I-Frame Flag indicating that the controller is to send only I -frames in the current slot and the Mode Change Permission field that restricts the modes that may be changed to from the current cluster mode.

During normal operation, the transmission block is traversed in a cyclic manner. At the end of a slot the controller switches to the next row of the transmission block. If the end of the cluster cycle is

20 reached, the controller continues with the first row of the transmission block, starting a new cluster cycle.

3.2.4 Logical Line Interface (LLI)

The LLI is the connection between the controller and the network bus. The protocol does not rely on a particular physical layer and as such the protocol is restricted to only specifying the logical line interface. Within a cluster, bit encoding and decoding is based on the modified frequency modulation code with all controllers supporting frame transmission and reception at 500 kbits/s, 1000 kbits/s, and 2000 kbits/s. Higher bit rates are also possible comprising of 5, 10, 20, and 100 Mbits/s.

3.2.5 Bus Guardian

The bus guardian is a subsystem of the controller that protects the network bus from transmission failures. The bus guardian mediates between the logical line interface and the protocol processor and uses the message descriptor list to determine when the protocol processor is permitted to access the bus. These relationships are illustrated in Figure 6.

Figure 6: The bus guardian

According to the official specification, the actual implementation of the bus guardian is left to the controller designer, however, the following requirements must be fulfilled.

21 Babbling idiot avoidance

The bus guardian must prevent the scenario where a controller within the cluster is transmitting more often than specified, or all the time, thus stopping the operation of other controllers within the cluster.

Fail silence

The bus guardian must prevent the transmission of any controller outside of its sending slot.

Common mode failure avoidance

The bus guardian must use a separate clock source than that used by the controller. In the case of a shared clock, a drop in the clock speed during transmission allows one controller to utilise one large transmission phase resulting in a type of babbling idiot behaviour.

Continuous function

The bus guardian must operate in all of the controller states not only the synchronised states.

Error detection

The bus guardian must be able to indicate to the controller any error that is detected.

Error containment

After the detection of an error the bus guardian must prevent any further transmissions from the controller. The controller must be restarted in order to begin transmitting again.

Fault coverage

The bus guardian must be located as close as possible to the physical channels in order to achieve the highest possible fault coverage.

3.3 Applications
Recently the Time Triggered Protocol has been adopted by companies in both the aerospace and automotive domain for use with safety-critical applications. These major break throughs in the usage of the Time Triggered Protocol has brought great industry attention to examine the quality of the various communications protocols that are designed specifically for safety critical systems and question the properties that they contain. Two companies that have recently agreed to use the Time Triggered Protocol are detailed below.

22

3.3.1 Honeywell
In August 2000 Honeywell and TTTech announced they would partner in the manufacture of aircraft engine electronic control systems, based on the use of the Time Triggered Protocol [17]. The benefits of such a change away from the use of existing communication systems include the ability of airlines to benefit from lower total product life-cycle costs, especially operating and maintenance costs. The use of the Time Triggered Protocol allows the design, implementation, and maintenance of fault-tolerant systems with faster turn-around times at lower system costs. Honeywell sees the main areas where this technology would be applied as being in the automotive, aerospace, industrial control and railway industries with the first series of applications of TTP starting in the year 2001. This agreement should see the Time Triggered Protocol given large industry exposure due to Honeywells reputation as the worlds leading supplier of flight critical systems.

3.3.2 Audi
Automotive manufacturer Audi will use the Time Triggered Protocol for data exchange among incar electronic systems starting with the 2004 or 2005 model year [18]. Willibert Schleuter, head of electrical engineering at Audi, called TTP "by far the most mature solution on the market. [It] fulfils all requirements we have for our in-car communication networks [and] provides the means to handle the complexity and advanced functions of future systems. In addition, TTP gives us improved data throughput and further enhances overall system dependability." The communication protocol is to be used for the latest in electronic automobiles with steer-by-wire and brake-by-wire systems implemented as standard in future vehicles.

23

Chapter 4 Methods
This project sought to apply the object-oriented paradigm to the design and implementation of a software simulation of the Time Triggered Protocol. This involved a large amount of investigation into the analysis of the Time Triggered Protocol and further to this a large amount of time was invested in the design and implementation of the simulation that followed.

The main methods that were utilised during the development of this project were the Unified Modelling Language (UML), and a simplified development process that was a combination of aspects of an object-oriented development process introduced by Craig Larman [14] and also the software development process used in the Extreme Programming methodology [16]. Additionally, a range of tools were used within the project that supported development with these methods that include the lightweight unit testing suite JUnit, the Rational Rose UML modelling tool, and the JBuilder java integrated development environment.

This section describes both the methods and the supporting tools as they were used in the development of this project.

4.1 Object Oriented Methodology

The essence of object oriented analysis and design is to emphasise considering a problem domain and logical solution from the perspective of objects [14]. The benefits of utilising an object-oriented approach to analysis and design can be summarised as follows:

Increases the uniformity between the results of the analysis and design phases whilst also reducing the differences between differing types of development by handling operations and attributes as a single entity.

Encourages the use of abstraction in analysis and design, providing a much more robust version of the software when subjected to later modifications.

The concept of objects representing physical real world objects promotes easy interaction between analysts, designers, users, and other external parties.

24 The reuse of all components such as source code and analysis work reduces the overall development time.

This section identifies the methodologies that were used in the development of the simulation as well as the tools that were used to support these methodologies.

4.1.1 Unified Modelling Language

The Unified Modelling Language (UML) is a language for specifying, visualising and constructing the artifacts of software systems [15].

The UML Summary [19] states that developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. We build models of complex systems because we cannot comprehend any such system in its entirety. As the complexity of systems increase, so does the importance of good modeling techniques. There are many additional factors of a projects success, but having a rigorous modeling language standard is one essential factor.

In the face of increasingly complex systems, visualisation and modeling become an essential component of all development processes. The UML is a well-defined and widely accepted response to that need. It is the visual modeling language of choice for building object-oriented and component-based systems.

UML was used for this project as it is currently seen as the industry standard for the modelling of object-oriented systems. As well as this there are a number of excellent CASE tools that are available for use in conducting the actual modelling of a system using UML.

4.1.2 Object Oriented Analysis and Design

UML does not define a process by which software development should be undertaken. This was done purposefully in order to guarantee the acceptance of UML by the software producing industry without having to dedicate to a certain process since often different development p rocesses are used depending on the differing nature of the problem domain.

The development process used for the analysis and design of this project was based on the process proposed by Craig Larman. For a more extensive coverage of ideas covered here readers are

25 referred to [14]. This process is an iterative incremental development process based on the currently popular idea of using multiple development cycles in order to refine the produced system. The advantages of using such a process are numerous, particularly the notion that early feedback is generated during development that can be inserted back into the development of the system, ensuring all implemented components are produced to meet the system requirements.

Plan and Elaborate Phase

The plan and elaborate phase of development includes the initial conception, investigation of alternatives, planning, and specification of requirements.

System Functions and Attributes

The phase begins with an examination of the problem domain and the system functions and attributes. In this context system functions are seen as the services that the system is intended to provide whereas the system attributes are viewed as the non-functional system qualities including items such as response time and fault tolerance. System functions are separated into distinct groups of related functions and are then categorised as evident or hidden according to whether they visibly contribute to the system or are hidden from the view of the users. Also optional functions of lesser value internally to the project are labelled frill to identify that they are not a necessity to the completed project, for example, aesthetic requirements could generally be labelled frill. System attributes are most useful when they are related to the functions specified previously. They are classified according to their importance to the project in terms of wants and needs as well as specifying whether they are a boundary constraint, for example, fault tolerance, or a detail, such as the operating system platform that is being targeted.

26 Use Cases

Use cases are utilised by this software process to assist in the understanding of the system requirements, and attempt to answer the question of what are the domain processes? A use case is a narrative document that describes the sequence of events of an actor using a system to complete a process - they are stories detailing the usage of a system. Use cases are not considered requirements or functional specifications but instead are regarded as an illustration of system requirements. UML formally specifies notation for use cases even though use cases themselves are not considered as object-oriented artifacts. They are included because they are frequently used as a method of requirements gathering in a large number of well-known software development processes (eg. the unified process, process mentor). The process used here differentiates between brief high-level use cases, and extended use cases that are more detailed and that are used to obtain a deeper understanding of the requirements involved. A further differentiation is seen in the classification of essential use cases and real use cases, where essential use cases are expanded use cases that are free of implementation details and in opposition to this, real use cases are used to concretely describe the design. Use cases are then ranked, with higher-ranking use cases needing to be addressed earlier in the development of the system. This ranking is dependent upon many characteristics; however, largely those use cases that significantly affect the core components of the system are addressed first.

Analyse Phase

The analyse phase of development includes the identification of the major concepts involved in the problem domain as well as the identification of system operations and what functionality is required by the end system.

Conceptual Model

The process used in the object-oriented analysis and design of this project utilises the conceptual model for the specification of major objects used in the system. The conceptual model is used in an attempt to determine what are the concepts and terms. A conceptual model illustrates meaningful concepts in the problem domain and is regarded as the most important artifact that is created during object-oriented analysis. It includes a description of the concepts that are involved in the development of a system, illustrating the major areas that will need to be addressed throughout the ongoing design of the system. Concept identification is a complex topic where objects and concepts are extracted from descriptions of the problem domain and can be as varied as physical objects, mechanical components, and organisations. After identifying concepts, associations that are

27 indicative of a relationship are added as a connection between concepts. Finally, attributes of the identified concepts are created that are needed to satisfy the information requirements of the current use cases under consideration. The final model is a good approximation of the problem domain and is the first artifact to illustrate the concepts, terminology, and relationships involved in the project.

System Sequence Diagrams

The process uses system sequence diagrams to further investigate what should be built into the system in an attempt to determine what are the system events and operations. These diagrams illustrate events that occur from actors to the system. A system sequence diagram is a picture that shows, for a particular scenario of a use case, the events that external actors generate, the order in which they were generated, as well as any internal events that are generated by the system. Here the differentiation is made between system events and system operations, where a system event is an external input event generated by an actor to the system and a system operation is an action of the system that is made in response to a system event.

Contracts

Contracts are used by the process to help define the system behaviour through describing the effect of operations on the system. Contracts are used to determine what the system operations do. Contracts are created after the completion of all prior artifacts discussed previously.

A contract can be seen as a document that describes exactly what a system operation will achieve whilst leaving the details of how this will be accomplished to later documentation. Contracts are frequently written using pre-conditions and post-conditions in order to identify the changes in the system that occur with the execution of this operation.

Design Phase

The design phase of development concentrates on describing the software components that are to be later implemented in the system. The focus moves from trying to understand the problem domain to completing the whole picture of the system by modelling the objects that will be used by the final system. Finally, these models are used to create the class model for the project.

Collaboration Diagrams

The process uses collaboration diagrams to illustrate message interaction between objects defined in the conceptual model. In particular, collaboration diagrams are important for assigning

28 responsibilities to objects which are then to be used in the class diagrams (see below). A responsibility is defined as a contract or obligation of a type or class [14]. After having determined the responsibilities of the system through contracts and system sequence diagrams, these responsibilities are then implemented using methods which either provide the entire content of the responsibility alone or act together with other methods. In order to ascertain the correct responsibilities, the process makes use of several design patterns, labelled GRASP patterns by the process author, which allow different types of responsibility assignment according to the type of objects involved. The collaboration diagrams are used to show all of the aspects of the system that are required to be present in order to meet the requirements of the system. This is also used to fill in any features that were over looked in the conceptual model.

Class Diagrams

The analysis and design process uses class diagrams only upon completion of all of the collaboration diagrams; that is, once all of the responsibilities have been assigned. The class diagram is intended to illustrate the methods of each class, their attribute type information, and attribute visibility between classes. This is in addition to the collaboration diagram specifying the basic associations and attributes. In contrast with the conceptual model, the class diagram shows definitions of software entities rather than real-world concepts. Also, the intentions of the two diagrams are different, with the conceptual model concentrating on the goal of analysis of the problem domain and the class diagram being more concerned with describing software components.

4.1.3 Extreme Programming

Extreme Programming is a relatively recent software development methodology whose primary focus is on continuous and concurrent cycles of software development. In contrast with the Waterfall and the Iterative Incremental model for software development, this process divides the task of software development into possibly hundreds of very short iterations. Extreme Programming is also characterised by the simultaneous execution of all phases of the development process within these iterations.

Kent Beck developed Extreme Programming in response to the frequent failure of software projects in the software development industry. The first project to be developed using Extreme Programming practices was the C3 project at Daimler Chrysler where Kent Beck was brought in following the failure of the previous development team to produce a usable pay roll system. Using practices including small development iterations, an extensive testing methodology, and pair

29 programming of all production code, the team delivered a new system on time and within budget. From this project Extreme Programming was born.

The Extreme Programming methodology consists of a number of different components that contribute towards the end goal of developing a software product that is flexible, easily tested, and meets the requirements of the customer. Although pair programming, a major constituent of the methodology, was not used, a number of practices were able to be implemented. The Extreme Programming practices that are most relevant to this project are discussed below.

Small releases

The Extreme Programming methodology demands a continuous flow of releases. By providing small and frequent releases there is the possibility of gaining feedback early in the development cycle such that the final product is the highest quality that could be produced given the time restrictions.

Simple Design

The Extreme Programming methodology recommends that only the simplest design required to fulfil the functionality required of the current development cycle be implemented. This means that whenever you hear yourself or someone else saying, Someday we're going to need..." you should restrict operations to what is needed in the current development cycle only. By keeping the simplest design possible you ensure that you complete the current iteration on time, you do not increase the maintenance of the system code unnecessarily, and most importantly you are concentrating on delivering what the customer has requested, and not on what they might need in the future.

Relentless Testing

The Extreme Programming methodology requires that everything that could possibly break must be tested. By using unit tests (detailed below) the resulting system proceeds with the developers knowing that the system always works in the manner in which it is required. This is of particular advantage when components of the software are modified at a later date, through testing every possible aspect of the system it is guaranteed that if all the tests pass after the integration of new code the system fulfils all of the previous system requirements.

30 Unit Tests

The Extreme Programming methodology requires a mechanism that facilitates the automatic detection of flaws introduced into the system through the integration of the products of the separate development cycles. Therefore Extreme Programming teams build an extensive network of automated tests for all developed components. These tests must run perfectly with any new component before the component may be introduced into the system. Unit testing is a form of white box testing where the developer uses their knowledge of the internals of the system to design tests for the system. Extreme Programming recommends the following approach to the development of unit tests and project code: 1. Create a test class and name this class so as to identify it as a test case for the class being tested. 2. Write a method that creates an instance of the class being tested along with any set up code necessary for the test. 3. Write the test and use assertions to verify the state of the class under test. 4. Run the test. 5. Modify the class being tested to pass the test. 6. Integrate the code into the system.

4.2 Tools
A number of tools were used throughout the duration of this project including a visual debugger, modelling tools, and testing suites. This section identifies the different tools that were utilised.

4.2.1 Java
The Java programming language was used to create the simulation of the Time Triggered Protocol. By using a clean object-oriented language the ability to apply the analysis and design o the system f became a relatively simple matter.

Since the project would handle a number of threads of execution, Java was chosen for its ability to use threads in a convenient fashion without large amounts of overhead in programming. This allowed a concentration on the mechanisms behind the Time Triggered Protocol rather than programming conventions for a particular language.

31 The Java programming language is supported well by many tools that were invaluable to this project, including Rational Rose (see below) which, when combined with the included Java plug-in, permitted the import and export of java source files to and from Rose models; as well as the JUnit unit testing suite (see below) that provided the basis for the unit testing component of the project.

The Java Development Kit 1.3 was used in the development of this project on a high-end machine running the Windows Millennium Edition operating system. Performance on low-end machines was found to be quite unacceptable, and due to minor differences between the virtual machine implementations, particularly thread implementations, between Windows and Unix/Linux

machines, the system was not able to run effectively on these other platforms. However, since cross platform portability was not an issue in the development of the simulation this was not seen as an issue throughout the development of the project.

4.2.2 Rational Rose 2000

Rational Rose is a CASE tool used for the development of UML diagrams produced by Rational Software Inc. (http://www.rational.com/) and is a single piece of software in the Rational range of development products. Rational Software is the organization that was created by the three amigos responsible for the development of the UML standard for modelling of object-oriented systems, Booch, Jacobsen, and Rumbaugh.

Through the use of a software tool for UML modelling created by the developers of the standard this project can assume that the models created herein are compliant with the UML specification.

Rational Rose was utilised in this project as it provides extensive support for all of the models required by the processes described above, including use cases, conceptual models, sequence diagrams, collaboration diagrams, and class models.

Additionally, Rational Rose is capable of both forward engineering source code, that is, creating source code skeletons from UML models that have already been created, as well as being capable of reverse engineering source code to reveal the associated UML model.

4.2.3 JUnit
The author of the Extreme Programming methodology, Kent Beck, wrote the testing framework SUnit for the Smalltalk programming language, which fulfils the minimum requirements for a unit-

32 testing suite. This tool is now available for several different languages including Java, PERL, CPP and Visual Basic.

Figure 7: The JUnit testing suite

The Java unit-testing suite JUnit was used during the project as a light-weight testing suite to facilitate the development of a suite of unit tests for the developed system. For each component produced absolutely every possible imaginable test was written, in line with the extreme programming methodology.

From the JUnit documentation, If a program feature lacks an automated test, we assume it doesnt work. This seems much safer than the prevailing assumption, that if a developer assures us a program feature works, then it works now and forever.

JUnit provides a class TestCase from which all other test cases can inherit. The application systematically executes all methods within the test case that begin with the word test displaying the results within the JUnit graphical user interface as seen in Figure 7. Because of the simple design of JUnit the implementation of unit tests within the Java programming language is a very easy task.

33

4.2.4 Borland JBuilder 3.0

Borland JBuilder 3.0 was utilised at various stages of this project for its debugger and also for its graphical user interface builder.

The advanced visual debugging facilities that are found within the JBuilder development environment make it one of the best development tools for java programmers available. The software uses an interface similar to that found in Microsoft development environments, ensuring that programmers familiar with these environments will be able to make the transition to using the JBuilder environment quickly and painlessly.

The advanced graphical user interface builder that is used within JBuilder assists with the menial task of developing basic user interface components such as menus, buttons, etc. saving a large amount of development time by not concentrating too much on the construction of the user interface.

34

Chapter 5 Analysis and Design

As discussed previously, the analysis and design of the system was undertaken using an objectoriented approach. This section details the artifacts that were produced through the use of this approach. The artifacts themselves are located in the appendix of this paper.

5.1 System Functions

The Time Triggered Protocol is for use in fault-tolerant real-time systems, as such the following services should be provided by the system.

Ref # R1.1 R1.2

Function Provide predictable message transmission

Category Hidden

Provide implicit message acknowledgement Hidden in group communication

R1.3 R1.4

Provide a clock synchronisation service

Hidden

Provide rapid fault detection at the sender Hidden and receiver by the provision of a responsive membership service

R1.5 R1.6

Provide redundancy management Provide support for rapid mode changes

Hidden Hidden

5.2 System Attributes

To effectively create a simulation of the Time Triggered Protocol the following attributes were determined that must be contained within the final system.

Attribute simulation

Details and Boundary Constraints (detail) The system must provide an accurate simulation of the entire Time Triggered Protocol

35 simulation of the entire Time Triggered Protocol as specified exactly in the official specification. This involves simulating all of the components of the protocol including the Controller, Host

Computer, and Network Bus. (detail) An extensive must be investigative applied validating all

methodology

throughout

phases of the software development life cycle. This is required in order to assert the properties defined in the specification that must be met by the developed system. fault tolerance (boundary constraint) simulation must be able to tolerate the failure of any controller (boundary constraint) simulation is able to tolerate failure of the network bus (boundary constraint) simulation can tolerate

invalid behaviour of a controller, in particular, avoidance of the babbling idiot scenario user interface (detail) The system must provide a simple and clear graphical user interface. In order to

determine the success of a simulation it is necessary to have all of the necessary data available and visible to the user. interactivity (detail) The system must be interactive. In order to investigate all aspects of the simulation it is necessary to be able to change the state of the scenario at anytime during execution. changeability (detail) The system must be capable of

modifications to the simulation parameters. This is necessary in order to accommodate a varying number of Controllers under changing conditions.

36 operating system (detail) software implementation of controller with Java using the Microsoft Windows Millennium Edition operating system.

5.3 Use Cases

Due to the varying relationships that occur between the multiple components of a controller, the use cases that were created as a part of this project were examined from the point of view of each component. The appendix contains the use cases that were created for the controller, the message descriptor list, the logical line interface, and the controller network interface.

Through the in depth examination of the interactions between individual components, the requirements for the final simulation can be extracted. This also allows the development of the system to advance into the next stage of analysis, investigating the operations involved in the system.

5.3.1 Protocol Processor

System Boundary

The system boundary is defined to include only the Protocol Processor. This allows the other components of the Controller encompassed by the Message Descriptor List, the Bus Guardian, the Communication Network Interface, and the Logical Line Interface; to be modelled external to the Protocol Processor. The Host Computer and the Network Bus do not participate in Use Cases with the Protocol Processor.

37 Use case Diagram

Use cases Send Data Communication Network Interface, Message Descriptor List, Bus Guardian, And Logical Line Interface.

Use case: Actors:

Type: Description:

primary The Protocol Processor reads a Message from the Communication Network Interface and writes a Frame to the Logical Line Interface. The Message Descriptor List is used by the Protocol Processor to determine when to send data on the Network Bus.

Use case: Actors:

Read Data Communication Network Interface, Message Descriptor List, Bus Guardian, And Logical Line Interface.

Type: Description:

primary The Protocol Processor reads a Frame from the Logical Line Interface. The Protocol Processor writes the Message contained in the Frame to the Communication Network Interface. The Message Descriptor List is used by the Protocol Processor to determine when to read data from the Logical Line Interface.

38 Extended Use Case: Send Data

Use case: Actors:

Send Data Communication Network Interface, Message Descriptor List, Bus Guardian, And Logical Line Interface.

Type: Description:

primary The Protocol Processor reads a Message from the Communication Network Interface and writes a Frame to the Logical Line Interface. The Message Descriptor List is used by the Protocol Processor to determine when to send data on the Network Bus.

Notes:

Although they are referenced in this Extended Use Case, the Host Computer and the Network Bus do not participate directly in Use Cases with the Protocol Processor.

Typical Course of Events Actor Action System Response 1. This use case begins when the system reads the data from the Message Descriptor List and determines that the Host Computer may send data on the Network Bus. 2. The Communication Network Interface 3. The system reads the Message from the contains the Message that is to be Communication Network Interface.

transmitted on the Network Bus. 4. The system creates a Frame that contains the Message read from the Communication Network Interface. This frame is written to the Logical Line Interface. 5. The Logical Line Interface contains the Frame that is to be transmitted on the Network Bus.

39 Alternative Courses Step 4. If the Protocol Processor attempts to send data to the Logical Line Interface at a time that is not specified in the Message Descriptor List then the Bus Guardian prevents the data from entering the Network Bus. The Bus Guardian signals an error to the Controller which then forces the Controller to conduct internal checks to ensure correct operation.

Extended Use Case: Read Data

Use case: Actors:

Read Data Communication Network Interface, Message Descriptor List, Bus Guardian, And Logical Line Interface.

Type: Description:

primary The Protocol Processor reads a Frame from the Logical Line Interface. The Protocol Processor writes the Message contained in the Frame to the Communication Network Interface. The Message Descriptor List is used by the Protocol Processor to determine when to read data from the Logical Line Interface.

Notes:

Although they are referenced in this Extended Use Case, the Host Computer and the Network Bus do not participate directly in Use Cases with the Protocol Processor.

Typical Course of Events Actor Action System Response 1. This use case begins when the system reads the data from the Message Descriptor List and determines that the Host Computer may read data from the Network Bus. 2. The Logical Line Interface contains the 3. The system reads the Frame from the Frame that was read from the Network Bus. Logical Line Interface. 4. The system writes the Message contained in the Frame read from the Logical Line Interface to the Communication Network Interface.

40 5. The Communication Network Interface contains the Message that is to be read by the Host Computer. Alternative Courses Step 3. The Frame received by the Protocol Processor is used in the calculation of the group membership service to determine which Controllers are currently in operation. If an invalid, empty or absent frame was received then this data is used in the calculation.

5.4 Conceptual Model

The conceptual model illustrated on the next page in Figure 8, was created from the use cases developed previously, and also with reference to the official specification. The conceptual model for this project demonstrates the basic relationships between components that are involved in the system, as well as including for the first time in the development of the project, all of the internal components of a controller interacting together. Although this model is not a complete model, it provides the basic framework for analysing the components interacting as a whole, instead of individually as was done with the use cases.

The model is a good approximation of the problem domain and is the first artifact produced within the project that illustrates the concepts, terminology, and relationships involved in the simulation of the Time Triggered Protocol.

5.5 System Sequence Diagrams

System sequence diagrams were created with reference to the use cases and the conceptual model that was developed previously. These were used to aid in the discovery of the systems events and operations.

Two sequence diagrams were created to further investigate the process by which the components of a controller cooperate to allow the sending and receiving of data in a cluster. These diagrams are available in the appendix. Sequence diagrams were invaluable in the understanding of the interactions between components, particularly the way in which events occur over time, that has great implications for the final design of the project.

41

5.6 Contracts
Contracts were used in this project to gain a greater understanding of the system operations of sending and receiving data between controllers in a cluster. These contracts are located in the appendix. The contracts that were developed, describe the requirements for the implementation of these system operations in the final project. This is done with reference to the creation of relationships between the objects involved in these operations.

5.7 Collaboration Diagrams

Collaboration diagrams were used to determine the messages that are sent between objects that occur in the conceptual model and also to begin to assign responsibilities to objects within the system. Collaboration diagrams were prepared for the two actions of sending and receiving data between controllers. Using the already created conceptual model, the collaboration diagrams that were prepared indicate the functionality that is required of each component present in the simulation.

The collaboration diagrams that were prepared discovered that the relationship between the MEDL and the protocol processor and the bus guardian was of great interest, and that to ensure that the spirit of the official specification was maintained, it would be inappropriate to remove the relationship that interconnects the MEDL with these two objects. Indeed, it was observed that a tightly coupled design between these components would be necessary to ensure the bus guardian truly behaved as an independent entity as described in the specification.

5.8 Class Diagrams

The extreme programming methodology subscribes to the idea of using a combination of all phases of development concurrently. It was at this stage of the project with only a partially completed design for the system, that the implementation was started. Keeping in touch with the ideals of the extreme programming methodology, the design, implementation and testing of the system were combined, such that the simulation was created with the most important aspects delivered in the final product, as the deadline for this project approached.

42

Figure 8: The conceptual model

43

Chapter 6 Implementation
6.1 TTPSIM
In accordance with the extreme programming principles applied throughout this project, the implementation of the simulation was completed through designing, implementing, and testing the system concurrently. This section describes the final product of these combined phases of development and identifies the issues involved in the implementation of each of the components within the simulation.

6.1.1 Network Bus

The network bus was implemented as a single class that runs on its own dedicated thread within the simulation. All participating controllers in the network share the network bus object between them accessing it concurrently. This class is representative of the two replicated channels of the network bus as specified in the official TTP/C specification, with the component implemented with the capability of storing two Frame objects.

The network bus was created such that the class itself is capable of detecting a collision. This is implemented correctly by ensuring that during every tick of the simulation there is only one frame present on each of the replicated channels. The collision detection mechanism is implemented as simple flags that indicate whether frames have already been received in the current tick, thus this detection mechanism is limited to the current tick only and additional mechanisms must be put in place to determine whether a collision occurs during a TDMA slot. The network bus is not capable of doing this since it has no access to the MEDL or CNI, which contain both the duration of the slots and the current cluster time respectively. In the case of a collision an exception is thrown to the controller where alternative action may optionally be taken.

Due to the thread-based implementation of the controllers within the simulation, controllers that are listening on the network bus must be provided with some mechanism to be notified when the network bus has received data. The use of individual threads for each controller raises the possibility that a controller may attempt, during a single tick, to read from the network bus before the sending controller can transmit. This results in an error condition within the simulation.

To prevent this event from occurring, a system exists whereby controllers can register themselves as listeners with the network bus to be notified of any arrival of data. This solution is based on the Observer pattern, which involves defining a one to many dependency between objects so that

44 when one object changes state, all of its dependents are notified and updated automatically [20]. Of course, it is not necessary for the network bus to signal the listeners as soon as a frame is received, since there may be multiple transmitting controllers in a tick and the network bus has been created such that it may check for the collision condition.

The mechanism operates by waiting for a signal from the simulation. Upon being notified of a tick occurring within the simulation, the network bus notifies all waiting parties that the network bus can be safely checked for data without risk of a sending controller transmitting after this checking has been done. The only restriction on successful operation of the mechanism is that the network bus must always be notified of a tick within the simulation before the controllers in the network are notified, in order to avoid the erroneous condition described above. This is guaranteed by ensuring that the Network Bus always has the highest priority thread over the priorities of the individual threads of the controllers.

For the network bus to operate correctly, the object must be cleared before the beginning of a tick in order to ensure that controllers in the current tick do not also receive frames that were received by controllers in the previous tick. The ability to do this is dependent on the notification mechanism described above. The network bus is cleared after all listening controllers have accessed the network bus, and before any sending controllers are given the opportunity to transmit.

The specification states that an invalid frame is a frame that is syntactically invalid. An assumption made within the simulation is that invalid frames are not possible on the network bus. This can be assured since frames are guaranteed to be delivered correctly by the network bus. However, valid frames that are not correct, for example incorrect CRC, are still a possibility in the simulation, as well as the reception of null frames, where no frames are detected as being transmitted.

6.1.2 Logical Line Interface

The logical line interface is a simple passive class that facilitates communication between the bus guardian and the network bus. The logical line interface class contains methods that allow the transmission and reception of data between these two objects.

6.1.3 Bus Guardian

Due to the complex nature of the simulation, and the fact that the simulation c oncentrates more on the main aspects of the TTP/C protocol such as the protocol processor, it was determined late in the development of the project that the bus guardian would not be implemented as described in the

45 official specification. Instead, the bus guardian would become a passive class identical in many respects to the logical line interface class.

The bus guardian was implemented as a simple passive class that mediates between the protocol processor and the logical line interface. The bus guardian class contains the necessary methods that allow the transmission and reception of data between these two objects.

6.1.4 Communication Network Interface (CNI)

The communication network interface class is one of the most complex components of the TTP/C specification due to the numerous fields that are contained within this component of the controller. The CNI was modelled as a package of classes for this reason and the final layout of the classes within the CNI package can be seen in Figure 9 on the next page. The CNI contains the three major areas as defined in the specification, these being the status area, control area, and message area. Within these areas further classes were created to hold all of the necessary data.

Of utmost importance to the implementation of the CNI was the read-only protection of the control area with regard to the protocol processor, and the read-only protection of the status area with regard to the host computer.

The only main issue in the development of the CNI was the way in which data was written to the CNI by the host computer when the current controller needs to send data on the network. The TTP/C specification describes the Non-Blocking Write (NBW) protocol for this purpose. This protocol was not used in the TTP/C simulation due to the simple nature of the host computer in the simulation. The host computer is always guaranteed to send identical packets of length specified in the MEDL and thus this issue is of no concern to the operation of the simulation.

This introduces one of the assumptions made during the simulation, that the host computer will always be functional within the cluster, thus, the host computer will always write correct data to the CNI field.

46

Figure 9: The communication network interface class model

The CNI contains two fields that are of great importance to the protocol execution, these being the membership vector used in determining which controllers sent successfully in the previous round (used in the membership calculation), and also the null-frame vector used in determining which controllers sent nothing in the previous round. In this simulation these vectors were set to a fixed length of the maximum size for these structures, which is 64. This was done to simplify calculations involving membership internally within the simulation. Due to the way in which java treats arrays as references, great care had to be taken in the simulation to ensure that arrays were copied when being transmitted, otherwise the identical array was used by all controllers in the cluster.

47

6.1.5 Message Descriptor List (MEDL)

Along with the communication network interface, the implementation of the message descriptor list was extremely complex. A large amount of the official specification is dedicated to describing the many fields that are contained within this component of the controller. As a consequence, the MEDL was modelled as a package of classes for this reason. The final layout of the MEDL package is illustrated in Figure 10. The component consists of a series of blocks represented by classes, with major fields within those blocks becoming additional classes in the MEDL package.

Figure 10: The message descriptor list class model

Initially, the MEDL was designed to be a static data structure; in other words, the data structure would be created with all values hard coded into the simulation. This meant that only one MEDL could be used with the simulation, and to change any of the parameters within the MEDL the source code for the MEDL package would need to be modified and the application recompiled.

In the formulation of requirements for the final system, one of the requirements considered was that the system must be able to support the modification of simulation parameters. This functionality is

48 necessary in order to accommodate a varying number of controllers under changing conditions, permitting scenario-based simulations of the protocol. Since another of the major requirements of the simulation is that multiple scenarios must be able to be modelled using the system, the data that is used by the controllers in the network (the MEDL) must be able to be changed. This meant that a structure for an ASCII input file for the MEDL needed to be created, such that multiple different MEDLs could be used within the simulation by providing a different data file as an input to the application.

The modifications that were made to the MEDL involved both the addition of methods to all classes within the MEDL package to allow reading in a portion of a data file that contains the necessary fields of the MEDL and additional code to permit them to initialise their internal data using this data file.

Of utmost importance in the implementation of the MEDL was the requirement that the data contained within the MEDL remained constant at all times throughout the simulation. Allowing only a single initialisation of MEDL data for the duration of the applications execution enforced this.

A number of simplifications were made during the implementation of the official TTP/C specification. Due to the simplification of the bus guardian described above, the bus guardian no longer maintains a strong role within the system, thus it no longer requires the bus guardian parameter block within the MEDL.

It was determined early in the project that reconfiguration was also not required to be supported by the application in order to provide the basic TTP/C service. In this case, the Role List class was created to support only one role, the default role that is entered at startup.

6.1.6 Protocol Processor

The protocol processor was implemented using a number of classes utilising the State design pattern as described in [20]. The state design pattern allows an object to alter its behaviour when its internal state changes. Thus the protocol processor appears to change its class although it remains identical. The class diagram for this component of the project can be seen in Figure 11.

49

Figure 11: The class design diagram for the protocol processor

The states that the protocol processor proceeds through are modelled on an abstract state that contains a single exec() method. Each state is responsible for the complete behaviour of the controller for each time tick signalled by the simulation.

The protocol processor is the only component of the controller that runs on its own thread within the simulation. Internally, the processor contains references to all the objects that are required for effective operation of the class including the bus guardian, message descriptor list, and the communication network interface. The controller operates by using a waiting mechanism that is described in the following section on the simulation, and is similar to the waiting mechanism described previously for the network bus.

Due to the requirement to limit the extent of the project and to concentrate only on the most important aspects of the official TTP/C specification, a number of states were not implemented in the final simulation. These states include the await state, the self-test state, the download state, and the reconfigure state. According to the specification, the download state and the reconfigure state may be optionally implemented. Due to the minimal nature of the host computer in the simulation it was found to be unnecessary for the await state or self-test state to be implemented in the simulation.

6.1.7 Host Computer

In the simulation, the host computer was designed to have a minimal role. This was done such that the focus of the project could be directed more towards the controller and the interaction between controllers.

50

The host computer does not execute as a separate thread within the simulation, and as such a mechanism had to be created whereby the host computer was able to execute. This was achieved by modelling the interrupt line as a class that facilitated communication from the controller to the host computer. The controller uses the interrupt line during protocol execution in order to signal ticks of the global time and also to signal interrupt conditions to the host computer. When an interrupt occurs, the host computer gains control of the thread of execution and is able to execute during the current tick.

The host computer is responsible for starting the simulation by setting the Controller On field within the communication network interface to force the controller to execute a state change transition away from the freeze state. Other than starting the controller, the only other role of the host computer within the simulation is to update the host lifesign field within the communication network interface in order to let the controller know that the host is operating correctly.

One of the basic assumptions that the simulation makes is that the host computer cannot fail during a simulation. This assumption was required in order to reduce the number of variables affecting the results of the investigation into the properties of the Time Triggered Protocol.

6.1.8 Simulation
The simulation class can be considered as the middle tier component of the project, which is responsible for the appropriate startup and execution of a simulation scenario. As discussed previously, a scenario is defined by the contents of an ASCII MEDL input file that contains the individual MEDLs for all participating controllers in the cluster. The simulation class begins a simulation by creating the network bus object that is to be shared between all controllers and then for every MEDL present in the input file the class creates a controller on its own thread.

The simulation proceeds by using a waiting mechanism similar to that used by the network bus described above. When a controller has completed all of its actions during the current tick of protocol execution, the controller waits for a signal from the simulation class. Either after a userdefined period of time has elapsed or the user indicates that the simulation should proceed (see User Interface below), the next tick is signalled to all objects waiting on the simulation clock through the use of the java native thread method notifyAll().

51 The simulation executes for an infinite amount of time and is not restricted by any limitations on the duration of the simulation.

6.1.9 User Interface

As discussed in the analysis phase of development, the project must fulfil a number of requirements in order to be considered successful. The implementation of those requirements that are concerned with the user interface are discussed here.

Figure 12: The TTP/C Simulation

It was determined that the user interface for the simulation must display all of the necessary data available from all of the controllers participating in the simulation. This had to be done in order to allow the user to visibly identify all aspects of the current state of the network with regard to each controller. This is important for the user to ascertain whether the simulation is operating effectively under the current scenario. To this end, the user interface was designed with the most important fields of each controller visible to the user as illustrated in Figure 12.

52 For each controller present in the network, the user interface displays a range of data. This includes the protocol state and the fields of the C -state structure in the CNI. This includes the current time, the MEDL slot position, the current cluster mode, the deferred mode change field, and the membership vector. Additionally, with each clock tick within the simulation a detailed summary of what has occurred in the current tick and also what occurred in the previous tick is available. This summary correctly illustrates the actions of the controller in these ticks.

An additional requirement of the system is that the user interface must be interactive. In order to investigate all aspects of the simulation it is necessary to be able to change the state of the scenario at anytime during execution. This objective was accomplished by creating the user interface such that modifications can be made to the current state of the network by interactively changing the data of any of the participating controllers. This means that the protocol state or any visible field of the C-state structure may be modified at any time during protocol execution within the simulation.

As well as this functionality, the simulation is capable of running in a continuous mode, a single stepping mode, or a combination of these two modes. This is possible through the use of the three buttons at the bottom of the main window. The first button permits continuous execution of the simulation with ticks of the global time occurring at 1-second intervals. The middle button signals a solitary tick to the simulation allowing users to single step through the simulation. The button at the far right of screen in Figure 12 halts the simulation temporarily, allowing a mixture of both modes of execution of the simulation.

A limitation of the user interface is that in continuous mode the time allowed between ticks must be fixed at an interval that permits the complete execution of all controllers. When run on low end Unix machines the simulation signalled ticks too quickly resulting in controllers missing out on ticks of the global time and the simulation becoming unsynchronised, which breaks one of the basic assumptions made in this project, that ticks of the global time will be delivered to all controllers simultaneously. This can be worked around by using only the single stepping mode of operation.

6.2 MEDL Tool

One of the requirements on the system, as discussed previously, was that the simulation must be able to execute different scenarios. This functionality was provided in the simulation itself through the implementation of ASCII input files for the MEDLs that are used by the controllers in a simulation.

53 An issue exists in the actual development of the MEDLs for use within the simulation. A single MEDL in an ASCII input file contains approximately 100 lines of text. In order to manually edit a file containing three or four MEDLS the user must have extreme patience and diligence to scan through the entire contents of the file, as well as being very accurate in the creation of the file such that all values are correct and are within allowable ranges. It was these issues that drove the project to additionally develop an application that was capable of creating and editing MEDL files independently of the simulation software. This tool would not only have to permit the visual editing of MEDL files but also check them for validity for use with the TTP/C simulation.

6.2.1 Message Descriptor List

It was determined that in accordance with object-oriented principles, the tool would be created using the existing MEDL package used in the TTP/C simulation. The implementation of a tool that is capable of creating and editing the input files for the simulation required modifications to the entire package of classes in order to allow the reading and writing of MEDLs to disk. This meant that for each class in the MEDL package a new method write() was added such that the output produced by this write method would be compatible with the already present read() methods. The combination of these methods allowed the creation of MEDLs using the existing package as well as the ability to write these files to disk for use within the TTP/C simulation.

Additionally, by using the already existing package of classes, it was not necessary to enforce the validity of the values being inserted into the MEDL since the package already contained strong input checking to prevent any invalid values from being present within the MEDL. In cases where invalid values are found, a Runtime Exception is thrown to the calling class, which is handled by the user interface. Thus automatic checking of existing or edited MEDLs can be guaranteed.

6.2.2 User Interface

For the tool to be effective, the user interface must display the contents of the MEDL files such that all of the fields may be visible and editable without having to spend large amounts of time searching through the large quantity of data present in the MEDL. A tree display was chosen to illustrate the data found in the MEDL as this container lends itself well to the structured style of format present in the MEDL package. The final product is illustrated in Figure 13 on the following page.

The tool allows the interactive editing of the MEDLs present in the file by double clicking on any of the fields present on the screen, resulting in an input popup dialog box. An incorrect value that is

54 not within the allowable range for the field being edited results in a message similar to that shown in Figure 14. From this information the user can proceed to re-enter the value.

The MEDL editing tool was an essential part of this project as it provided the ability to modify MEDL files used by the simulation with a single mouse click. This meant that a complex scenario could be created with any number of controllers in a small amount of time, saving large amounts of time during implementation. During the investigation component of this project, the tool was again invaluable as it permitted single field changes in individual MEDLs without having to manually edit cryptic text files. The reuse of software components in the production of the tool was the initial proof of the successful application of object-oriented methods to this project.

Figure 13: The MEDL editing tool

55

Figure 14: An example of an out of range exception

56

Chapter 7 Investigation
The investigation of properties of the official specification was limited to researching those aspects of the specification that seemed unclear and ambiguous. These aspects were discovered during the implementation of the simulation from the specification, where the building of the system relied heavily on the clear understanding and interpretation of the specification. Possible solutions to the problems that were encountered along with descriptions of the actual problems are presented below.

7.1 Cold Start State

This part of the investigation centred on the synchronisation of a controller in the cold start state. The start-up of a cluster was one of the most important functions that was encountered in the actual implementation of the simulation. This is described in some detail in the official specification in section 9.3 - Detailed Description of the Protocol States [8]. A problem was encountered with the implementation of the cold start state that is described in section 9.3.3 Cold Start State [8].

A controller enters the cold start state if both of the following conditions are met: the cold start flag is set for this controller in the MEDL, permitting the controller to enter the cold start state; and there has been no activity detected on the bus for the duration of the listen state timeout.

Once a controller has entered the cold start state, the controller sends a single I -frame (initialisation frame) and listens for activity on the network bus for the duration of the cold start state timeout. The excerpt from the specification that is relevant to the problem experienced in implementing the cold start state is given below: (from the official specification, Section 9.3.3 - Cold Start State [8]).

If an I-frame indicating startup mode which was sent by another controller has been received correctly an I-frame is received correctly if both the receiving controller and the sender are set in the membership and both of them agree upon the global time and the current MEDL position before the cold start timeout has expired, the controller transits into the active state and resets the Iframe counter to zero.

Thus in accordance with the specification, for a controller to transit from the cold start state to the active state, an I-frame must be received during the cold start timeout that indicates startup mode and also fulfils the following conditions:

57 1. The membership vector within the I-frame has both the current controller and also the sending controller set in the membership. 2. The time field within the I-frame agrees with the current controllers time field. 3. The MEDL position within the I-frame agrees with the current controllers MEDL position.

The problem that was encountered was that the cold start state in section 9.2 - Controller States and State Transitions [8], is identified as an unsynchronised state. Thus upon reception of an I-frame indicating startup mode there is no possibility of the I-frame fulfilling any of the conditions described above for the following reasons: 1. The membership bit for the sending controller cannot be tested. This is due to the fact that we are not keeping track of the current MEDL position and the global time, the two fields required to determine the current sending slot, and from this the bit position in the membership vector of the sending controller. 2. The two controllers time fields will disagree. This is due to the fact that the global time is not being incremented. However, the sending controller is in a synchronised state which does increment the global time. 3. The two controllers MEDL positions will disagree. This is caused by the cold start state controller not incrementing the MEDL position, thus the sending controller that is in a synchronised state, updating the MEDL position, will not agree with the current controllers MEDL position.

This problem can be addressed by referring to the cold start state as a synchronised state. This is because the controller will be able to meet the criteria above only if the controller is monitoring the current state of the cluster. This is the behaviour of a synchronised state.

To remedy the problem, Table 9.1: States of the Controller [8], in the specification must be modified to reflect this change in stance over the synchronisation of the cold state controller. This modification is visible in the shaded field of Table 1 below.

No. 3

State Cold Start

Host Up

CO Field On

Sending I-Frames

Synchronized Yes

Table 1: Cold start state of the controller

Another problem was found to exist within the Cold Start State specification. Once a controller in the cold start state receives an I -frame in startup mode correctly which fulfils the criteria set above,

58 the specification states, the controller transits into the active state and resets the I-frame counter to zero.

This behaviour, once implemented, resulted in cold start controllers being unable to synchronise within the cluster due to the fact that the controller does not change from the cold start mode to the startup mode, does not set the membership bit for the sending controller in the membership vector, and the null-frame vector is not updated for the sending controller.

The following modification is recommended to the last line of the fourth paragraph in section 9.3.3 - Cold Start State [8], the controller transits to the active state, sets the MEDL mode to startup mode, sets the membership bit for the sending controller, updates the null-frame vector for the sending controller, and resets the I-frame counter to zero."

These modifications were implemented in the cold start state of the simulation, from which point onwards the simulation worked correctly for controllers in that state.

7.2 Ready State

This part of the investigation focussed on the synchronisation of a multiplexed controller with own membership and the experience of communication system blackouts within the simulation. The purpose of the ready state is to allow a newly synchronised controller to acquire the sending slot associated with the controller. Following is an extract from the official specification section 9.3.4 Ready State [8].

A controller with own membership acquires an SRU slot and transits out of the ready state if The controller is allowed to integrate into this slot (flag RA in the current s in the MEDL lot is set), The membership flag is cleared, indicating that no other SRU has acquired this slot, and The null-frame flag of the requested SRU slot is set, meaning that during the last TDMA round no activity has been observed on any of the two channels in this SRU slot.

Due to the final requirement described above, it is impossible for multiplexed controllers with own membership to acquire a slot until at least one TDMA round has passed. This is because it takes a

59 single TDMA round to determine that no activity was observed for the duration of the requested slot.

Section 9.5 of the specification [8] states that a communication system blackout occurs when there has been no observed transmission activity in the last TDMA round. Thus, for the case where a cluster contains only multiplexed controllers with own membership, the TDMA round following initial synchronisation will always result in the cluster experiencing a communication system blackout due to the absence of transmissions in the round d irectly proceeding the round in which a cold start I-frame is sent.

The addition of a footnote to section 9.3.4: Ready State [8] should be made in order to demonstrate the need for non-multiplexed controllers in a cluster such that the case described here is avoided. A possible description for the footnote is given below.

In the case where the cluster design consists of many multiplexed controllers with own membership, care must be taken to avoid communication system blackouts in the TDMA round following synchronisation due to the single TDMA round that is spent in the ready state by these controllers.

7.3 Membership Service

This component of the investigation observed the membership function described in the official specification in section 8.3 - Implicit Acknowledgement [8]. The membership function is described briefly in this paper in section 3.3.5 Protocol Processor. From the specification the membership service informs all SRUs of a cluster about the operational state of each SRU within the latency o f one TDMA round. Due to the provision of a CRC32 polynomial function in the Java API, this was given preference over the implementation of the CRC16 polynomials described in the official specification. This was the only simplification made to the implementation of the membership function in the project. The membership service was found to operate effectively and performed as described in the official specification. However, Figure 8.3: Acknowledgement Scheme that is provided in the section on the membership function does not illustrate the complete picture.

In order to combine the English language description of the membership function with the data of the provided tables and figures, a UML state diagram was constructed as a method of displaying all of this data. Now that UML has become the industry standard for the development of diagrams and models for software architectures, it is appropriate that this be used as often as possible in

60 documents within such domains. It is important to use UML wherever possible in new documentation in order to further encourage the easy understanding of documents without the need to learn new methods of diagramming. The UML state diagram that was created is illustrated on the following page in Figure 15.

7.4 CRC Calculation of I-Frames

The investigation of the membership function lead to the examination of the way in which the CRC is calculated over the contents of an I-frame. Two seemingly different descriptions are given in the specification that deals with this calculation.

In section 8.2.2-CRC Calculation of I-Frames, the specification states that "The frame CRC of Iframes is calculated over the schedule ID (contained in the MEDL), the frame header and the data field (containing the current C-state)".

This seems to be contrary to what is stated in section 8.3-Implicit Acknowledgement, "I-Frames carry the C-state of the sender in the data-field and do not include it in the CRC calculation".

The specification is ambiguous as to whether the C-state present in I-Frames is used in the calculation of the CRC for I-Frames.

In correspondence received from the employees at TTTech regarding this issue, it was discovered that as stated in section 8.2, the computation of the I-frame CRC does include the C-state, however, the sentence in section 8.3 is misleading and should be changed.

The following correction will be made to the next version of the official specification.

I-frames carry the C -state of the sender in the data field; the CRC calculation of I-frames therefore does not need to additionally add the C-state to the frame CRC for the implicit acknowledgement (as is done for N-frames).

61

Figure 15: Membership Calculation

62

7.5 I-Frames in normal mode

This part of the investigation examined the mechanism through which I-frames are transmitted in the normal operation of the cluster. This is the secondary purpose of I-frames in the protocol to permit the reintegration of controllers. In the official specification, section 5.8 - MEDL Design Guidelines demands there have to be at least two SRUs that are sending I -frames in each cluster cycle. This part of the project investigated the scenario when all of the controllers in the network responsible for sending I -frames in normal mode have failed, and the impact of this on the operation of the cluster.

As expected, the failure of controllers to transmit I-frames in normal mode resulted in the ineffective operation of the cluster with controllers being unable to reintegrate into the cluster.

There are two possible mechanisms for avoiding this situation. The first deals with MEDL design and the second involves addition to the protocol source code.

The first way of surviving this problem is to ensure that within a cluster cycle every controller in the network t ansmits at least one I-frame in normal mode. This guarantees that as long as there are n r controllers that are present in the cluster, there will always be n I-frames transmitted in that cluster cycle. Thus to fulfil this requirement of the specification, a minimum of two controllers is required.

The second mechanism for avoiding this scenario is through the introduction of additional source code to the protocol. Possible solutions to this problem are presented here. The solutions presented require that during the normal operation of a cluster, whenever an I-frame is received, the I-frame counter is incremented. At the end of a cycle the controller checks the value of the I -frame counter to ensure it is not zero. If the I-frame counter is zero, a range of different actions may be taken.

The controller executes a mode change to the startup mode, such that all controllers will begin sending I-frames. This will possibly permit the failed controllers to re-enter the cluster, or any other controllers that were absent. The problem with this solution is that if the controllers responsible for transmitting I-frames do not reintegrate then the cluster will not return to the normal mode for any large duration of time.

Role change of the controller to one of the failed controllers that was responsible for sending Iframes in the cluster. This will provide the missing I-frames to the cluster, however, this is done at

63 the expense of an existing controller, and if the failed controller is not as important in the cluster a s the existing controller, then the overall effectiveness of operation of the cluster is reduced.

The final solution is to allow controllers to send I-frames instead of N-frames during their slots if the I-frame counter becomes too small. This solution does not require reconfiguration to be supported by the network or any protocol state changes to be executed by the controllers in the cluster. The disadvantage being that data requiring transmission would not reach its destination.

The final solution presented above was tested briefly in the simulation and was found to have some merit. However, due to the requirement that any data being sent at the time would not be transmitted, this solution may have little benefit to communication systems supporting safety critical applications. Further research would be required to investigate the validity of such a mechanism.

7.6 MEDL Specification

The MEDL is an important component of the TTP/C specification. Indeed, the introduction to the section on the MEDL details well the fact that one of the basic assumptions of the protocol properties is that there are no design faults in the controller or the MEDL. As a result this means that the MEDL design must be perfect and error free before being implemented.

Although the tool that was created for this project was helpful in the creation and editing of MEDLs for use with the simulation, the necessary calculations that must be made and enforced throughout MEDL design are not enforced by the program, for example, ensuring that the length of the TDMA round stored in the parameter block is actually the sum of the individual slot lengths for a round.

It is difficult to guarantee that any cluster design is perfect, given the wide range of variables within a single MEDL that may not be appropriate for the type of operation required of a system.

I believe that it is worthwhile to include some online checking of MEDL semantics either as a part of normal protocol execution, or added as a built in self-test for the controller. Since the controller relies on the MEDL data for correct operation, a higher value must be placed on its contents.

64

Chapter 8 Discussion
The previous chapter examined the investigation that was conducted into selected properties of the official specification that were found to be inaccurate or ambiguous. This chapter examines the effectiveness of the methodologies and tools that were used during the development of the simulation of the TTP/C specification.

8.1 Object Oriented Analysis and Design

The use of object-oriented principles throughout the entire project was invaluable to the final product. Through the use of UML diagramming and also the exhaustive investigation of the properties of the system, a complete understanding of the specification resulted. This was important due to the complex nature of the problem domain and the many relationships that are described in the specification that exist between the components of a controller.

The simple process that was used in the analysis and design of this project suited the project well. Since the project was developed by a single individual, the scope for using an industry standard software engineering process (e.g. Process Mentor) was not found to be suitable. Instead, the process that was used was well explained, clear, concise, and compact. Development of software need not focus on the strict adherence to complex development processes and this project is an example of how well simple processes can be applied to medium scale software projects.

8.2 Extreme Programming

The extreme programming methodology uses pair programming as one of its key practices. Although this aspect of extreme programming was not used, the project was developed successfully through the use of all of the other features of this development process. Important to the success of this project was the combination of design, implementation, and testing in small development cycles to produce the final product. The use of this practice resulted in the development of an application that is as close as possible to the original requirements of the system. However, the most heavily used aspect of extreme programming during this project was unit testing which is discussed below.

8.2.1 Unit Testing

During the implementation of the simulation more than 500 unit tests were written for the individual components of the system. Unit tests were a very important component of the

65 development of the system. Their use was particularly apparent during the modification of the MEDL package of classes during the implementation of the MEDL editing tool as well as numerous other occasions when modifications were made to the source code of system components, to guarantee that the existing code had not been broken by the addition of the new code.

By maintaining a number of unit tests that cover the e ntire project there can be no dispute when a piece of code added breaks the unit tests. Since the unit tests ran at 100 percent before the code was integrated, the new code obviously broke the tests. Similarly, by having a 100 percent coverage of unit tests we can modify existing code without worrying about breaking other dependent components. If the unit tests still run at 100 percent after integration then we can be sure that our modification has not broken the project.

The construction of unit tests is a lengthy process that in most cases requires significantly more time and effort to create, and debug the tests, than it does to implement the actual class being tested. This hinders the advancement of the project, and when deadlines loom, it is feasible t at unit testing may h be removed from the project, in order to deliver on time. It is quite unreasonable to use the practice of unit testing under such conditions. This was particularly apparent in this project, where near deadlines, the number of unit tests written did not cover the total behaviours of the created classes.

Although the Java code used in the simulation passed all of the unit tests that had been written this does not guarantee the correct behaviour of the simulation. Unit tests are only effective if you can guarantee that the entire behaviour of the system under test has been accounted for. A small number of bugs were encountered in this project due to the coverage of unit tests being insufficient.

Finally, unit tests were found not to be useful in the testing of the final system to guarantee the correct interaction of components. Unit testing is an excellent mechanism for individual component testing whereby the properties of a single class can be tested to ensure that the class provides the required functionality. However, unit testing cannot be used easily with integration testing of classes, particularly those with complex relationships or implementations. This was particularly visible in this project where the thread based implementation of the controllers made it very difficult to assert basic properties of the system through the use of unit testing.

66

8.3 Tools
8.3.1 Rational Rose 2000
The Rational Rose UML modelling tool was used extensively throughout the project, the ability of the application to reverse engineer class models from source code was found to be extremely helpful. This feature was used particularly during the development of the protocol processor where constant reference was made to both the MEDL and CNI packages to determine the location of a particular data field.

8.3.2 JUnit
The JUnit testing suite made the creation of unit tests for the simulation very simple, and the fast execution of those unit tests meant that the unit tests could be run frequently, guaranteeing compliance of new code with the existing system. The 500 unit tests that were written for the project could be executed in well under 3 seconds using the command line and in 10 seconds using the graphical user interface.

8.3.3 Borland JBuilder 3.0

This integrated development environment was found not to be as useful as expected. The software itself performs rather slowly, and the graphical user interface creation tool frequently crashed during operation. Despite this the tool was used on several occasions for its tremendous visual debugging feature. This was a highly useful tool during the project as it gives the developer incredible control over the execution of their application within the virtual machine. Borland JBuilder 4.0 was released at the end of this project, and after an initial investigation it seems that the features that were found to be ineffective in this project, have been improved on greatly.

67

Chapter 9 Conclusions
The project described herein can be divided into clear sections. The first section of the project involved the accurate implementation of the official specification of the Time Triggered Protocol. This was achieved through the successful application of object-oriented methodologies and tools to analyse, design, and build a software simulation of the Time Triggered Protocol. The remainder of the project was spent investigating the protocol itself to determine the validity of the specification, particularly whether the description is correct, complete, or unambiguous.

The object-oriented methods that were used in this project were applied throughout the entirety of the project development. The benefits of utilising such methods became clearly obvious during the design and implementation phases of development where the object-oriented paradigm permitted the easy translation of the large English language specification document into a collection of software models and documents describing the architecture of the system. Object-oriented methodologies now have a range of supporting tools that make for radically quick and thorough development, without which this project would not have succeeded as it has; this has included the use of the Rational Rose modelling tool and the JUnit light-weight unit testing suite.

The simulation that was developed met all of the requirements that were created during the initial stages of the project. The system provides an accurate simulation of the entire Time Triggered Protocol as specified exactly in the official specification of the protocol. An investigative methodology was applied during the project to assert system properties through the use of extensive unit testing of system components throughout the development. The system was implemented with a clear graphical user interface that permits the modification of simulation parameters during simulation execution. The system is interactive, allowing either continuous operation or single step modes of operation. In addition to the developed simulation, the project involved the creation of a tool to assist in the creation and editing of MEDLs for use with the simulation. This tool provided a clear and simple interface to the contents of a MEDL, demonstrating the need for strong cluster design tools in the implementation of TTP/C networks.

The purpose of the simulation of the Time Triggered Protocol was to examine the completeness of the official specification. Unfortunately, the specification seems to be somewhat ambiguous and incomplete in a large number of areas. In this project I identified problems with the specification of the cold start state and how it must be identified as a synchronised state otherwise the protocol

68 would not operate as described in the specification, as well as this, the mechanism for entering the active state from the cold start state was not identified correctly. I discussed the communication system blackout phenomena that occur in clusters of multiplexed controllers with own membership, and the addition of a warning to the specification of the ready state. The use of I -frames in normal mode was investigated and a possible new solution to this problem presented using intelligent controllers that have the ability to send I-frames instead of N-frames under certain conditions. Finally, this paper examined the calculation of the CRC of I -frames and the contradictory nature of two parts of the specification.

Throughout this project it has become clear that the TTP/C specification is somewhat limited in its ability to be implemented directly from the English language document into either software or hardware. Although the specification is only a working document and is not intended for general distribution, the fact that companies have agreed to install this technology in future products (e.g. Honeywell, Audi) means that a definitive and accurate specification should be available that describes the operation and implementation of the communication protocol. TTP/C has been shown to be a promising architecture for use with safety critical control applications; however, further progress needs to be made in developing a more accurate specification for the protocol.

The simulation that was created here is based only on the information available in the specification. The company TTTech who maintains the source code used in the hardware implementation of controllers has the ability to specify the protocol in a greater amount of depth given the time to do so. This company obviously does not have the resources to address all issues surrounding the protocol. Indeed, the company actively encourages the research of Universities and other Institutions to validate the protocol through their support of the TURN program (TTTech University Research Network). During the investigation component of this paper, an ambiguity in the description of the calculation of the CRC over I-frames was discovered. This was reported to the company TTTech at which point the ambiguity was corrected and an invitation was issued for membership of the TURN program. This now allows for the corrections that are made within this paper to be included in the official specification.

69

Chapter 10 Future Work

10.1 Time Triggered Protocol
The work completed within this project was limited in some aspects due to the enormous complexity of implementing a communication system from a specification. Numerous aspects of the official specification were not dealt with by this project including an examination of the bus guardian that protects the network bus from erroneous transmissions by the controller, the reconfiguration of a controller to fulfil a different role within the cluster, and also the download protocol state that involves the download of MEDL data using a stand alone point-to-point protocol.

This paper highlights the fact that further research must be undertaken to better specify the Time Triggered Protocol. Further to this work, an analysis of possible changes to the protocol based on comparisons with other newer communication systems such as byteflight (see below) is also a definite possibility, with the recent emergence of several new communication systems that are competing with the Time Triggered Protocol.

The simulation presented in this document is only that, a simulation. It is an approximation of a TTP/C implementation based on the descriptions given in the official specification. The source code used to implement the actual controllers in hardware has been developed over a number of years by researchers and developers. Further work needs to be done on the part of the employees at TTTech to refine the specification based on their implementation and the source code that is used in the working implementation of the protocol.

This paper marks only the beginning of simulating the protocol to determine its correctness. System properties in this project were asserted through the use of extensive testing methodologies. These have limitations however, which mean that we cannot conclusively say that an aspect of the protocol is correct due to this testing. Future work will need to be done using formal verification techniques and temporal logic to prove the protocols correctness.

10.2 Byteflight
The Time Triggered Protocol is not the only communication system that is being looked at for use in supporting safety critical applications. One of TTPs major competitors is byteflight. The byteflight protocol is one of the new breeds of communication protocols that combine aspects of both the event-triggered and the time-triggered architectures. As well as investigating the use of

70 TTP, future work may include research into the suitability of byteflight as a communication system that supports safety critical applications. The brief description of byteflight included here was referenced from [21] and [22].

BMW developed byteflight as an attempt to combine the best qualities of both event-triggered and time-triggered protocols that would provide all of the functionality required of a communication system that is to be used with safety critical applications. In cooperation with Motorola to produce byteflight processors, BMW will be incorporating byteflight into mass production in 2001 to support the networked passive safety system.

Event-triggered protocols such as CAN only transmit data when a transmission request is present. Bus access is usually controlled by priority or by chance. Latency times can only be calculated statistically for an event-triggered system and thus they are not suitable for hard real-time requirements. The advantage of byteflight is the flexible use of bandwidth by different controllers and the ease of system expansion.

Communication systems that are based on time triggering, such as TTP, grant transmission time to each node in accordance with a pre-defined sequence. With these protocols latency times for the messages are deterministic. The number of messages is defined by the number of time slots and therefore cannot usually be modified during protocol execution. Assignment of the bandwidth to different controllers is permanent, such that later expansion to include new nodes or functionality requires reconfiguration of the entire system.

The byteflight protocol unites the advantages of event-triggered and time-triggered protocols. It guarantees deterministic latencies for a specific number of high priority messages as observed in time-triggered protocols, and flexible use of transmission bandwidth for low priority messages using event-triggered access methods. It is also possible to configure a byteflight system to execute as a purely event-triggered or purely time-triggered system. Additionally, the protocol permits easy expansion of the electronic modules attached to the network and also the modification of existing modules.

The byteflight protocol uses minislotting as its media access strategy. This involves the use of an event occurrence to begin a TDMA period. The basis for communication in a byteflight system is the use of synchronisation pulses that form the common time base for all controllers. In between the signalling of these pulses any controller is permitted to transmit data.

71

Recently there has been fierce rivalry between vendors of the different communication protocols. According to [21], the deterministic behaviour of the byteflight protocol, flexible use of bandwidth, expandability of the system, high data transmission rates and data integrity, high level of communication interference immunity made possible by fibre optic transmission, the possibility of download via the data bus, and the capability of online diagnosis pre-destine this protocol to become a transmission protocol standard in the automotive arena. The byteflight protocol promises much and according to researchers at BMW this communication system is of far greater use than other protocols such as TTP. The additional backing of huge companies such as BMW and Motorola will ensure that byteflight continues to be developed and implemented for many years to come.

In a paper released by TTTech [23] a comparison of TTP against both CAN and byteflight presented valid arguments for the use of TTP over these other protocols. One such argument against byteflight is that there is no mechanism for message acknowledgement in the protocol; the strategy implemented involves frequent retransmission without acknowledgement.

Obviously there will be great competition between all communication systems that can be used to support safety critical applications. As future research is completed into the abilities of each protocol, a single standard should emerge at some time in the near future.

72

Chapter 11 Appendix
11.1 Use Case: Controller
System Boundary The initial system boundary can be defined to include only the Controller, which is responsible for the transmission and reception of data to and from the Network Bus and the Host Computer. The Host Computer has the ability to start the Controller. The Host Computer and the Controller both have the ability to stop the Controller. Use case Diagram

Use cases Start Host Computer primary The Host Computer starts the Controller.

Use case: Actors: Type: Description:

Use case: Actors: Type: Description:

Stop Host Computer primary The Host Computer or the Controller stops the Controller.

Use case:

Send Data

73 Actors: Type: Description: Host Computer, Network Bus primary The Host Computer writes a Message to the Controller. The Controller writes a Frame to the Network Bus.

Use case: Actors: Type: Description:

Read Data Host Computer, Network Bus primary The Controller reads a Frame from the Network Bus. The Host Computer reads a Message from the Controller.

11.2 Use Case: Message Descriptor List

System Boundary The system boundary is now defined to include only the Message Descriptor List (MEDL), which contains a priori knowledge of which nodes are to be sending or receiving data from the Network Bus according to the global time. The Protocol Processor uses the MEDL to determine when to send and receive data. Additionally, the Bus Guardian uses the MEDL to determine when to permit the Protocol Processor to access the Logical Line Interface. Use case Diagram

Use cases Use case: Actors: Type: Description: Read Data Protocol Processor, Bus Guardian primary The Protocol Processor or the Bus Guardian reads data from the Message Descriptor List.

74

11.3 Use Case: Communication Network Interface

System Boundary The system boundary is now defined to include only the Communication Network Interface (CNI), which is responsible for the storage of data that is transmitted by the Protocol Processor and the Host Computer. Use case Diagram

Use cases Use case: Actors: Type: Description: Send Data Host Computer, Protocol Processor primary The Host Computer or the Protocol Processor writes to the Communication Network Interface.

Use case: Actors: Type: Description:

Read Data Host Computer, Protocol Processor primary The Host Computer or the Protocol Processor reads from the Communication Network Interface.

11.4 Use Case: Logical Line Interface

System Boundary The system boundary is now defined to include only the Logical Line Interface (LLI), which is responsible for the storage of data that is transmitted by the Protocol Processor and the Network Bus. Additionally, an independent hardware unit, the Bus Guardian permits access to the Logical Line Interface.

75 Use case Diagram

Use cases Use case: Actors: Type: Description: Send Data Protocol Processor, Network Bus primary The Protocol Processor writes to the Logical Line Interface. The Logical Line Interface writes to the Network Bus.

Use case: Actors: Type: Description:

Read Data Protocol Processor, Network Bus primary The Logical Line Interface reads from the Network Bus. The Protocol Processor reads from the Logical Line Interface.

Use case: Actors: Type: Description:

Control Access Bus Guardian primary The Bus Guardian has the ability to deny write access to the Logical Line Interface.

76

11.5 Contract: Protocol Processor: Send Data

Name: Responsibilities: Send Data The Protocol Processor reads a Message from the Communication Network Interface and writes a Frame to the Logical Line Interface. The Message Descriptor List is used by the Protocol Processor to determine when to send data on the Network Bus. Type: Cross References: Notes: System System Functions: All This contract begins when the Protocol Processor reads the data from the Message Descriptor List and determines that the Host Computer may send data on the Network Bus. Although they are referenced, the Host Computer and the Network Bus do not participate directly in actions with the Protocol Processor. Exceptions: If the Protocol Processor attempts to send data to the Logical Line Interface at a time that is not specified in the Message Descriptor List then the Bus Guardian prevents the data from entering the Network Bus. The Bus Guardian signals an error to the Protocol Processor which then forces the Protocol Processor to conduct internal checks to ensure correct operation. Outputs: The Protocol Processor outputs a Frame containing the Message onto the Logical Line Interface. Pre-Conditions: The Message to be sent contains valid data within the set size limits for transmission that is specified in the Message Descriptor List. Post-Conditions: If the Host Computer successfully sent a Message to the Communication Network Interface, a Message was created (instance creation) The Message was associated with the Communication Network Interface (association formed) If the Protocol Processor successfully read a Message from the Communication Network Interface, a Frame was created (instance creation) The Frame was associated with the Message. (association formed) The Frame was associated with the Logical Line Interface (association formed)

77

11.6 Contract: Protocol Processor: Read Data

Name: Responsibilities: Read Data The Protocol Processor reads a Frame from the Logical Line Interface. The Protocol Processor writes the Message contained in the Frame to the Communication Network Interface. The Message Descriptor List is used by the Protocol Processor to determine when to read data from the Logical Line Interface. Type: Cross References: Notes: System System Functions: All This contract begins when the Protocol Processor reads the data from the Message Descriptor List and determines that the Host Computer may read data from the Network Bus. Although they are referenced, the Host Computer and the Network Bus do not participate directly in actions with the Protocol Processor. Exceptions: The Frame received by the Protocol Processor is used in the calculation of the group membership service to determine which Controllers are currently in operation. If an invalid, empty or absent frame was received then this data is used in this calculation. Output: Pre-conditions: Post-conditions: If the Logical Line Interface successfully read a Frame the Frame was associated with the Logical Line Interface (association formed) If the Protocol Processor successfully read a Frame from Logical Line Interface a Message was associated with the Communication Network Interface (association formed) Message None.

78

11.7 System Sequence Diagram: Protocol Processor: Send Data

79

11.8 System Sequence Diagram: Protocol Processor: Read Data

80

11.9 Collaboration Diagram: Protocol Processor: Send Data

81

11.10

Collaboration Diagram: Protocol Processor: Read Data

82

Chapter 12 References
[1] S. Poledna. The Time-Triggered Communication Protocol TTP/C. Real-Time Magazine 98-4 (pg 98-102), 1998.

[2] D. Marsh. Drive by wire fuels network-highway race, EDN Europe, 2000.

[3] B. Hedenetz and R. Belschner Brake-by-wire without Mechanical Backup by Using a TTP-Communication Network SAE International Congress and Exhibition, Detroit, 1998.

[4] J2056 I.R. Class C Multiplexing, Part 1 JUN93 Applications Requirements, Society of Automotive Engineers, 1994.

[5] J2056 I.R. Class C Multiplexing, Part 2 APR93 Survey of Known Protocols, Society of Automotive Engineers, 1994.

[6] Markus Krug, Anton V. Schedl. New Demands for Invehicle Networks. Proceedings of the 23rd EUROMICRO Conference, 601-606, 1997.

[7] H. Kopetz, G. Grunsteidl, TTP A Time-Triggered Protocol for Fault-Tolerant Real-Time Systems. Proc. 23rd IEEE International Symposium on Fault-Tolerant Computing. IEEE Press (pg 524-532), 1993.

[8] H. Kopetz TTP/C Protocol - Specification of the TTP/C Protocol, Confidential, 1999.

[9] R. Nossal, L. Lercher. Simulation of a Time-Triggered Protocol for Fault-Tolerant Real-Time Systems, Technical University of Vienna, 1994.

[10] R. Pallierer, T. Galla. TTPSIM: A Versatile Simulation Environment for TTP/C, Technical University of Vienna, 1998.

[11] H. Kopetz. A comparison of CAN and TTP, Technical University of Vienna.

83

[12] E. Dilger, T. Fuhrer, B. Muller. The X-By-Wire Concept: Time Triggered Information Exchange and Fail Silence Support by new System Services, SAE, 1997.

[13] H. Kopetz. Fault Management in the Time Triggered Protocol (TTP), Technical University of Vienna.

[14] C. Larman. Applying UML and Patterns, Prentice Hall, 1997.

[15] G. Booch, I. Jacobsen, J. Rumbaugh. The UML specification documents, Rational Software, 1997.

[16] R. Jeffries, A. Anderson, C. Hendrickson. Extreme Programming Installed, Public Final Draft, 2000.

[17] R. Graham. Honeywell and TTTech partner to develop future aircraft electronic systems with TTP, Press Release, Honeywell Engines & Systems, 2000.

[18] P. Clarke. Audi to adopt TTP for safe auto electronics, EETimes.com, 2000.

[19] UML Summary, Version 1.1, Rational Software, 1997.

[20] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable ObjectOriented Software, Addison Wesley, 1994.

[21] J. Berwanger, M. Peller, R. Griessbach. Byteflight A New High-Performance Data Bus System for Safety Related Applications, BMW AG, EE-211, 2000.

[22] Byteflight Specification, BMW AG, EE-211, 2000. (http://www.byteflight.com/)

[23] Comparison CAN vs. Byteflight vs. TTP/C. TTTech, 2000.