C. Ebner, H. Kopetz, D. Millinger
Real-Time Systems Group,
Vienna University of Technology
Treitlstr. 3/182/1, A-1040 Vienna, Austria
dietmar@vmars.tuwien.ac.at
The application area of embedded real-time systems is rapidly growing due to the attractive price/performance ratio of embedded computer systems. Even in cost sensitive mass market applications like automobiles, research activities are focused on distributed real-time systems for comfort-functions, like driver information systems and for safety-critical functions like computer controlled braking and steering. While the requirements of non safety-critical applications are covered by standard commercial real-time systems, the level of fault-tolerance required for safety-critical applications cannot be covered by these architectures at reasonable cost.
In fault-tolerant applications, which have to provide the fail-operational property, the active replication of computational nodes, communication structures, and sensors/actuators is a common solution. The paradigm of event-triggered communication and task activation makes the cost effective implementation of active replication of system components a difficult task. As a solution, the time-triggered paradigm was developed. The Time-Triggered Architecture (TTA) is the consequent extension of the time-triggerd paradigm into the field of distributed safety-critical real-time systems.
The resulting architecture includes a fault-tolerant real-time communication system (TTP/C), a time-triggered field bus (TTP/A) and a time-triggered operating system (TTOS). The presentation of this architecture is the goal of a demonstration object built by the Real-Time Systems Group at the Vienna University of Technology.
The following section describes the Time-Triggered Architecture with its fault-tolerant communication protocol TTP/C, the fieldbus protocol TTP/A and the operating system TTOS. A TTA application is described finally.
The time-triggered architecture (TTA, [Kop97a]) is a distributed architecture for the implementation of fault-tolerant real-time systems. The TTA is characterized by the fact that the control signals of the communication system and the processing nodes are derived from the progression of a global time base. In the TTA a real-time system is decomposed into a set of subsystems called clusters.
The TTA distinguishes between environmental clusters (ECluster) and computational clusters (CCluster). Examples of environmental clusters are the controlled object, i.e., the process that is to be controlled, or the operator. A computational cluster consists of a set of distributed communicating nodes. In general, a node (Figure 1) consists of three subsystems: a host subsystem, a communication controller and a process I/O subsystem. The communication interface between the host computer and the communication controller is called the communication network interface (CNI). The interface between the host computer and the process I/O subsystem is referred to as the controlled object interface (COI).
Every node in a computational cluster of the TTA has a synchronized clock with a precision in the sec range. The fault-tolerant clock synchronization is a service of the time-triggered protocol that controls the communication among the nodes of a cluster. In the time-triggered communication system the sending of messages is controlled by the scheduling table of the communication controller that contains the information which node is allowed to access the communication channel at what point in time. This information is generated a priori (i.e., before run-time), and is static common knowledge to all nodes in the system. Using this common knowledge, a host can synchronize the reading of an analog value from the controlled object with this a priori known send time. Since the transmission schedule is free of conflicts, the transmission time to the receiver is constant and known. The uncontrollable jitter in a time-triggered system is reduced to the precision of the global time. In a time-triggered system there is no "send message command" to be executed in the host computer. The host computer stores the data it intends to transmit into the provided shared memory of the CNI, knowing at which future point in time the message will be transmitted.
The communication system operates autonomously and deterministically without any control command from the host computers. The temporal properties of the CNI, i.e., the points in time when a particular message will be sent and when a particular message will arrive, are precisely specified and will not dynamically change depending on the system load. This precise specification of the temporal properties of the CNI is the basis for the composibility and testability of time-triggered systems. If the application software of a host is validated with respect to its local CNI then it will also operate predictably in a distributed system, since the system integration does not have any effect on the temporal properties of the local CNIs [KN97].
The Time-Triggered Protocol (TTP/C) [Kop97b, KG94], is a TDMA (time-division multiple access) based protocol organized into a set of TDMA rounds. Each node is allowed to send a message in each round. A communication mode determines the set of message frames transmitted by each node during a TDMA round. By means of a mode change, the communication mode of the complete cluster can be switched consistently. TTP/C provides the following services across the CNI:
The available discrete component TTP controller contains a special device, a bus guardian with its own clock, which assures that even a faulty controller cannot monopolize the bus by sending babbling idiot messages.
The most important interface in the TTA is the communication network interface (CNI), [KK95, Krü97] between the TTP/C communication controller and the host subsystem of nodes. Nodes communicate by the exchange of state messages across the CNI. A state message can be viewed as a distributed state variable that always contains the most recent temporally accurate [KN97] version of the real-time data. A new version of a state message overwrites the previous version, there is no queuing of messages in the CNI. The points in time when an incoming state message is updated or when an outgoing state message will be fetched from the CNI, as well as the duration of the transmission, is known a priori to all communication partners.
The CNI is implemented in a dual ported RAM (DPRAM) where the TTP controller writes/reads the data from one side and the host subsystem from the other side. In addition to the state data, the CNI contains a set of status and control words to inform the host about the operation of the protocol.
In the TTA, nodes are replicated to reach the level of dependability required in a safety-critical application [LVSK92]. Fault-tolerant units (FTU) are formed by active replication of nodes that operate in tight synchronism, called replica determinism [Pol95]. Node level faults in the time-domain are masked by the deterministic timing behavior of the communication protocol. In the value-domain, node level faults are masked either at the sender side by internal self-checking mechanisms that guarantee the fail-silence property of a node [LVSK92, Kop94], or at the receiver by voting over the received message versions transmitted by the nodes of the FTU. Transmission faults are masked by redundant message transmission on replicated busses and CRC protection. It is the main purpose of the FT-layer to hide all fault-tolerance mechanisms in the TTA from the application in order to simplify the application development process and to keep complexity out of application code.
In systems with an FT-layer there are two CNIs, the basic CNI and the FTCNI. The FT-layer is embedded between these two CNIs (Figure 1). The two CNIs are syntactically identical and semantically similar. The host application accesses FTU messages at the FTCNI.
Figure 1: Structure of a Node in the Time-Triggered Architecture
The extension of the TTA properties up to the host level of a node results in a real-time host operating system that guarantees a highly predictable, jitter-free timing behavior of the task set and that supports fault-tolerance mechanisms at the host software level and at the node level. The requirements of such an OS are developed and described in [KDK89] and implemented in the MARS operating system. The Time-Triggered Operating System (TTOS) is an adapted and extended version of the MARS OS.
The requirement of a predictable timing behavior of the executed tasks leads to a special task model, the simple tasks [Kop97a]. In this model there are no blocking communication and synchronization mechanisms available during the task execution. Once the task is started, the task cannot be stopped until it finished its execution by itself (see Figure 2). The execution of a task is suspended only by preemption. The point in time when the task execution of a given task is started is determined by a scheduling table, the task description list (TADL). The TADL is generated before runtime and stored in the local non-volatile memory of the host computer. The time-base used by the TTOS dispatcher is derived from the global time base of the TTP/C communication system. Therefore all TTOS nodes in a TTP cluster execute their task sets in tight time synchronism.
All synchronization requirements of a task set, like mutual-exclusion and precedence constraints must be fulfilled by the time controlled task activation pattern. The pre-runtime scheduling tool, which generates the TADL for a given node obeys the synchronization requirements of the task set by producing task execution intervals (task start time to worst case task finish time) that fulfill the synchronization requirements. Message communication of tasks is not performed during task execution, receive-messages are received before runtime and transmit-messages are transmitted after the worst case task finish time of the task (Figure 3). This ensures a deterministic and jitter-free communication behavior of a task. All communication actions are controlled by time and not by task code executed at a given host.
TTP/A (the time-triggered protocol for low-cost class A [SAE91] applications) has been chosen to serve as the communication network for the integration of the sensors and actuators in the TTA demonstrator. TTP/A transports the information between the controlled object interface (COI) of a TTA node and the sensors and actuators attached to this node. TTP/A is based on the following constraints, which are typical for class A communication protocolls:
Whenever the remote reception of a control command is disturbed by a transient or permanent error, the remote node (the sensor or actuator) has to detect such an error within a short latency and autonomously transits to a safe state without any delay caused by communication retries. The error detection latency should be in the same order of magnitude as the end-to-end response time of the application [Kop97a, Section 1.3.3,].
TTP/A is based on the standard UART (Universal Asynchronous Receiver and Transmitter) interface. This interface is provided by nearly all single chip microcontrollers. The hardware of the UART interface is optimized to the point where it is very difficult for a custom built controller to reach the same low cost level. This kind of interface allows for a free selection of devices on the market that are best suited for the intended application.
In order to reduce the cabling effort a single wire communication medium is used. The single wire imposes a number of constraints for the protocol designer. First, it only allows one sender at a particular interval in time. Second, the limited bandwidth of a single wire (approximately 10 Kbps) requires high data efficiency of the protocol. Third, a single wire operation is exposed to a non-negligible number of transient transmission errors. Therefore, the protocol must provide effective means to manage these transient errors.
For cost reasons only one standard microcontroller per electronic control unit (ECU) is affordable in class A body electronics (in contrast to safety-critical applications, where redundant nodes or separated application- and communication-controllers are often commonly used).
Figure 4: Software Structure within a TTP/A ECU
Hence the application has to share memory and CPU with the communication protocol and the operating system. Figure 4 shows how these components are embedded in a node.
The main responsibility of the protocol is to send and receive application data elements. This task comprises packing data elements into messages, transmitting and receiving messages, and detecting transmission errors. The message transmission is organized as follows (for a detailed description see [Ebn96]).
The TTP/A slot is the smallest unit in terms of protocol execution, which is visualized in Figure 5. At (Send Data Timeout) one node starts the transmission of a message that is received by all correctly operating nodes at the latest at (Data Processing Timeout). The interval is called Inter-Frame Gap (IFG). A defined sequence of slots is called a TTP/A round (Figure 5). In the first slot of a round the Fireworks Frame is sent by a dynamically assigned master. The Fireworks Frame includes a number determining the sequence of messages of the current round. A detailed description of the message sequence and the appropriate message scheduling can be found in [Nos97].
The software tasks of the application and the protocol are statically scheduled in the same way as the bus access scheme. Due to the static scheduling of all tasks the TTP/A OS must provide only two basic services: a globally synchronized timebase and the task dispatching.
Each node needs a local view of a global timebase to be able to derive the point in time when tasks have to be activated. In TTP/A a central master synchronization is used. The central master synchronization is usually avoided because the master is a single point of failure. TTP/A requires a master anyway and it is assured that if the current master fails a new master will be assigned within a defined time interval. The reception of the Fireworks Frame sent by the master is used as a synchronization event.
The second main function of the OS is the invocation of application and protocol tasks at predefined points in time. The OS sets timeouts ( Action Times when to raise a timer interrupt. At the action times the OS checks in the statically defined task list whether a task chain containing one or more tasks has to be started. After having finished all tasks of a chain the OS performs the tasks of the background chain until the consecutive action time arrives.
The TTP/A gateway transfers TTP/A data messages between the connected TTP/A busses and the TTP/A gateway CNI. The gateway executes the TTP/A protocol for each attached TTP/A bus and handles the data transfer between the gateway CNI and the communication ports. The gateway CNI is structured similary to the TTP/C CNI. A detailed description of the TTP/A gateway can be found in [Hol98].
For evaluation and presentation of the Time-Triggered Architecture a toy sized model (scale 1:4) of a car was built by the Real-Time Systems Group at the Vienna University of Technology. The key features of the car model include four wheel drive, four wheel steering and a radio control (RC) system, by which the speed and the steering of the car model can be remotely controlled (see Figure 6). The internal state of the car model is monitored at a remote workstation. The electronic control system has been designed as a distributed real-time control system. Regardless of its scale, the operation of parts of the electronic control system is assumed to be safety-critical. In the following sections the design and technical details of the car model are described.
The design steps choosen for the car model are based on the design process suggested for the TTA [Nos97]. The first step requires a decomposition of the complete car model application. Then the communication relations between the decomposed units are defined. Finally, the internal structure of the units are designed.
The first phase in the design of the car model is the global design of the electronic equipment [Nos97]. During this phase the internal structure of the complete system is developed. Therefore the system is subdivided into clusters (see Section 2). The communication relations between these clusters are determined by identifying gateways between the clusters. Next, the internal structure of the clusters is developed and the nodes of the clusters are identified. Finally, the cluster internal communication relations between the nodes of a cluster are planned.
The rules for identifying clusters are given in [Rec92]; clusters are structures with high internal complexity and low external communication activity. Applying this rule, the complete electronic control system of the car is included in one computational cluster, the car-control cluster. Around this cluster there are three environmental clusters. The RC-operator cluster contains the RC-operator and interfaces to the car-control cluster by the radio signal receiver. The internal structure of this cluster is of no further concern. The next environmental cluster is the car hardware. This rather complex cluster contains the complete car hardware and its static and dynamic state. The car-control cluster interfaces to this cluster via sensors and actuators for steering and driving. Finally, the monitoring and diagnosis environmental cluster communicates with the car-control cluster via a digital radio up-link.
Figure 7: Clusters of the Car Model
The internal structure of the car-control cluster is mainly determined by the placement of computation nodes and the structure of communication links between the nodes. At this level the same design rules from [Rec92] are applied. High complexity and high communication rates are packed in nodes. Two high speed and complex tasks can be identified in the car-control cluster. The wheel speed control loop for each wheel and the RC-signal decoding at the interface to the RC-operator cluster. Therefore, a computation node is assigned to every wheel module and a node is assigned to the RC-operator interface (main node). One node is assigned to the interface to the monitoring and diagnosis cluster. The resulting cluster structure is shown in Figure 8.
The fault-tolerance requirements of real-world automotive applications include the toleration of at least one single independent component failure. According to the fault-tolerance strategy of the TTA, every node and every sensor/actuator in the car-control cluster has to be replicated to provide such a level of fault-tolerance. The main node with its RC-sensors is therefore setup in two-fold redundancy. The four wheel modules provide application specific redundancy, because in case of a single wheel module failure, a safe state can be reached with the remaining three functioning wheel modules. Therefore for the wheel modules no redundancy was implemented.
The communication relations between the nodes in the car-control cluster can be described by the means of transactions. A transaction is a concatenated sequence of computation and communication actions. The computation actions are performed at the computation nodes and communication is performed via the TTP/C and the TTP/A busses.
Figure 9 shows the transactions of the car-control cluster. The control transaction starts at the RC-sensors, which read the RC-receiver output, process these values and transmit the data via TTP/A. The main nodes receive the TTP/A sensor messages at their COI, convert the values and transmit them in TTP/C sensor messages. The main nodes themself receive the sensor messages again. One message version of main node 1 and one version of main node 2. Then an agreement protocol is performed, which generates agreed sensor values that are used by the main node-software to calculate control values for drive and steering for each wheel module. These control values are transmitted by the main nodes in TTP/C control messages. The wheel nodes receive the control messages and check the consistency and state of the messages.
The TTP/C control message values are the set-point values for the local control loop performed by the wheel nodes. The actual physical values are provided by the TTP/A sensor messages. Based on these values, the wheel control loop generates TTP/A actuator messages, which are transmitted via TTP/A to the steering and drive actuators.
The wheel monitor transaction transfers the wheel state information from the wheel sensors back to the main nodes and to the diagnosis module. The state information is checked by the main nodes to ensure the proper operation of the wheel hardware. The diagnosis node transmits the state information to a monitoring workstation.
Figure 9: Car Control Cluster Transactions
The following design step in the global design specifies the TDMA medium access patterns of all nodes in the car-control cluster. First, transmission slots are assigned to the nodes. Every node gets exactley one transmission slot. This results in a TDMA cycle, where every node has one sending slot. Several TDMA cycles can be concatenated forming a cluster cycle [ea97]. Next, for every transmission slot of a node in the transmission cycle, messages are assigned which are transmitted during this slot by the sending node. In the car model, the transmission cycle consists of 2 TDMA cycles, resulting in a transmission cycle with 16 slots.
The main nodes are assigned to slot one and slot three of the TDMA cycle. For experimental reasons, the slots two and four are free. The wheel nodes get the slots five, six, seven and eight. The resulting TDMA cycle and the transmitted messages are shown in Figure 10.
Figure 10: TTP/C MEDL for the Car-Control Cluster
Based on the transactions performed in the car-control cluster, the message contents of the TTP/C messages can be assigned. The main nodes transmit two types of messages, sensor messages and the control message. The control message contains the speed and steering control values for all wheel modules separately. The sensor message contains the local sensor input values of each main node. These values are exchanged among the main nodes for sensor agreement.
The fault-tolerance model selected for the redundant main nodes requires the main nodes to operate in replica determinism. Thus, they have to maintain an equal internal state (history state, h-state) and they have to reach an agreement over the sensor input from the RC-receivers. The h-state is required for h-state recovery of reintegrating main nodes. Sensor input value agreement is required between the two main nodes to maintain replica determinism [Pol94].
The four wheel nodes transmit the measured wheel speed, the steering angle and the internal component state.
A wheel module consists of the complete wheel hardware including a wheel computation node, a TTP/C communication module, a TTP/A gateway, a TTP/A bus, a drive engine with control electronics, a speed servo, and the two sensors. The TTP/A bus connects the engine control electronic, the steering servo and the both sensors with the TTP/A gateway. Via this gateway, the wheel node software and the I/O devices attached to the TTP/A bus exchange their messages. The wheel node computer executes the wheel node software based on the time-triggered operating system TTOS. The wheel node software communicates with the other nodes via the TTP/C controller attached to the node.
Figure 11: Wheel Module Hardware Structure
The software executed at the wheel node is scheduled to run periodically. The wheel control loop software provides a control loop for the speed of the car model. The requested speed value is read from the TTP/C control message and the measured speed value is read from the TTP/A speed state message. From the difference between the two values a new TTP/A speed control value for the drive engine control electronics is derived.
The TTP/A angle state and speed state messages are read by the wheel state management software and transmitted to the main and diagnosis module via the TTP/C communication system. Additionally, the internal aliveness state of the wheel node components is determined and transmitted. The main nodes use this information to determine the state of the complete car model.
Figure 12 gives an overview of the software structure. Both software modules are implemented in the control task and executed periodically about every .
Figure 12: Wheel Node Software
The FT-layer is responsible for the hiding of all fault-tolerance mechanisms in the TTA. Thus it has to hide the replication of the main control messages from the wheel node application software. At the wheel node, the FT-layer performs two operations. In slot 4, the FT-layer copies the wheel state message from the application space to the basic CNI at the TTP/C controller. In slot 13, the FT-layer reads the four versions of the control message transmitted by the main nodes 1 and 2, selects one correct version and copies this version to the application space.
The TTP/A sensor and actuator bus comprises four nodes as shown in Figure 11. Each sensor and actuator node is based on a universal TTP/A node (Figure 13). The layout of the PCB has been designed in a way that allows for using the node for the four intended purposes.
Figure 13: TTP/A Sensor and Actuator Node
The following paragraphs describe the communication between the wheel computation node and the sensor and actuator nodes and focuses on the functionality of the sensors and actuators.
The wheel node communicates with the TTP/A nodes at the wheel and vice versa via the TTP/A gateway and the TTP/A bus (Figure 11).
The length of the TTP/A round determining the period of the messages is given by the length of the intervals s, s, and s. The length of the resulting TTP/A round is thus s.
The wheel speed is captured with a two channel optical encoder, using a codewheel with 500 counts per revolution (the encoder generates 500 pulses per revolution). The encoder module is attached to the inner end of the wheel axle and directly mounted on the PCB of the TTP/A node. The encoder generates digital waveform outputs, where channel A is in quadrature with that of channel B (90 degrees out of phase). Channel A is connected to two timer input captures (TICs) of the controller. One TIC detects rising edges, whereas the second TIC detects falling edges. These two values are used to determine the wheel speed. Channel B is connected to a third TIC detecting rising edges. This input is used in conjunction with the value of the rising edge of channel A to derive the direction.
Periodically executed, the task for reading and processing the inputs from the encoder checks whether there is a matching pair of rising and falling edges. If a valid pulse is detected, the revolutions per minute are derived from the length of the pulse. The current direction is determined from the relative position of the rising edge at channel B to the corresponding edge at channel A. Assuming that the wheel speed must not exceed 1000 revolutions per minute the most significant byte (MSB) of the high byte can be used to indicate the direction.
The steering angle (the wheel position) is captured with a linear tracking potentiometer. The potentiometer is directly mounted on the PCB of the TTP/A node and connected to the steering arm. The input from the potentiometer (in the 0 ...5 V range) is converted by an on-chip 8-bit ADC. The ADC provides a resolution of 256 steps.
The TTP/A node controlling the servo (the wheel position) is directly placed on the servo and hard-wired with the inputs of the servo. These inputs are ground, power and a puls-width modulation (PWM) channel. The accepted PWM signals are corresponding to the PWM output of common RC receivers shown in Figure 14.
Figure 14: PWM Signal for Actuators
The servo accepts PWM signals with a duty cycle from 1000 s to 2000 s at a period of 20 ms. These two values are corresponding with the end positions of the servo with an effective steering angle of about 90 degrees.
The functionality of the engine node is the same as for the servo node node with small differences. The PWM output is fed into an OEM module that converts the PWM signal into the proper voltage and current for driving the electric engine.
The main module consists of two replicated nodes with replicated sensors and replicated RC-receiver modules. The signals of the RC-receiver are decoded by TTP/A nodes, which communicate with the main nodes via a TTP/A gateway. The TTP/C busses connect the two main nodes with the other nodes of the car model. One main node is connected to a radio transceiver module. Via this radio link, the main node transmitts diagnostic data to a monitoring workstation. Figure 15 shows the main module structure.
Figure 15: Main Module Hardware Structure
The main module software is structured into two software modules. The sensor value conversion module reads the RC-sensor values from the TTP/A gateway and converts them to a standard value range. These converted values are transmitted on the TTP/C bus. Both main nodes receive their own sensor values and the values of the partner node. The agreement and control value calculation module performs an agreement algorithm over the sensor messages and uses the resulting values as input for the calculation of the speed and steering control values for all four wheel nodes.
The steering values and the speed values are calculated to ensure a geometrical correct steering and speed of every single wheel. For example, if the car drives through a curve, due to the smaller radius, the wheels at the inner side of the curve will have to steer a smaller radius and will have to drive at lower speed than the outside wheels. A detailed description of the main module software can be found in [Gse98].
The aliveness state information received from the wheel nodes, together with the state information from the main nodes are utilized to the determine the overall state of the car model. Failures of components are mapped to degrated modes of operation of the car model. The following table (Table 1) shows the different modes of operation and the component failures that determine the modes.
| Mode of Operation | Component Failures |
| Fully Operational | No Component |
| Fully Operational | One RC Sensor |
| Limp Home | One Wheel Node |
| Limp Home | One Wheel Sensor |
| Limp Home | One Main Node |
| Stop | All Other Component Failures |
Figure 16: Main Module Software
The RC-sensor bus is based on the TTP/A protocol and connects the receiver channels of the RC-receivers to the main nodes in the TTP/C network. Three receiver channels have to be decoded, converted to an a priori defined data format, and transmitted to the main module. The topology of the RC-sensor bus is shown in Figure 15. The three channels of interest are channel one, which receives the speed information (Drive Channel), channel two receives control information (Control Channel), and channel 3, which receives the steering information (Steering Channel). The following paragraphs describe the communication scheme for the communication between the receiver nodes and the main node, and explains the setup and functionality of the receiver nodes.
The RC-receiver provides the current position of an RC-channel as PWM-signal. This signal is similar to the PWM-signal shown in Figure 14, i.e., a duty cycle of 1000 s to 2000 s for the end positions and 1500 s for the neutral position, and a period of 20 ms. The RC-receiver channel is connected to two timer input captures (TICs) of the controller. One TIC is configured to detect rising edges, the other TIC detects falling edges. The application task, which is periodically executed checks whether the current two TIC values represent a valid pulse length. If a pulse with a length between 1000 and 2000 s is detected, the task will write the high and low byte of the corresponding value (1000-2000) to the CNI.
At the main nodes, the FT-layer performs several actions. As seen in Figure 17, in slot 1, the FT-layer copies the wheel FL (Front Left) state message from the CNI at the TTP/C controller to the FTCNI. The other wheel node state messages are copied in the slots 10 (RR), 14 (FL) and 16 (RL). The sensor messages generated by the sensor conversion task are copied from the FTCNI to the TTP/C CNI in slot 15. In slot 2 and 4, the sensor messages are received again by both main nodes. The control message generated by the agreement and control task is transmitted by the FT-layer in slot 8.
Figure 17: Timetable of Main Node Tasks and FT-layer
This report gives a detailed description of the structure and a possible application of the Time-Triggered Architecture (TTA) by the example of a car model. The Time-Triggered Protocol TTP/C is used to interconnect the computation nodes of a distributed real-time control system, which is responsible for the control of steering and driving of the car model wheels. The TTP/A fieldbus protocol is utilized to connect sensors and actuators via a gateway to the computation nodes. The software tasks running at the nodes are controlled by a time-triggered operating system (TTOS). Fault-tolerance mechanisms are implemented at several levels. In TTP/C redundant message transmission at redundant busses ensures a reliable message communication. CRC codes are utilized to detect transmission faults and the deterministic timing behavior at the communication interface is used to detect timing errors at the host and at the communication system side. The replication of the main nodes demonstrates the fault-tolerance capabilities of both the TTP/C protocol and the TTOS. A Fault-Tolerance Layer, located between TTP/C and TTOS, is responsible to hide the underlying node level fault-tolerance mechanisms from the application and even from the host operating system. The car model demonstrates the operation and the implementation of the Time-Triggered Architecture in one single application.
