Time Triggered Protocol TTP C

76 MARCH 1999 Embedded Systems Programming

fe

at

ur

e

R O S S B A N N A T Y N E

n this article I’ll discuss an advanced serial communications pro-tocol/system that has been developed for applications thatrequire highly dependable or fault-tolerant operation. “TTP”stands for “Time Triggered Protocol,” which describes the firstfundamental property of this new communication protocol:access to the communication medium is granted to the comput-

er nodes on a time-slot principle. The suffix “/C” indicates that this proto-col conforms to so called class C applications, classified by the Society ofAutomotive Engineers, Inc. (SAE). Class C applications are all electronicsystems of an automobile which are connected by a high-speed communi-cation bus.

This article will discuss the beginnings of TTP/C, the requirement forsuch a solution, some explanation of why no other suitable solutions exist,the principles of the communications system, and details on the actual ser-ial communications protocol message frames. Finally, I’ll describe sometypical applications of TTP/C.

TTP/C has been developed over the last 15 years from a research pro-ject at the Technical University of Vienna, directed by Professor HermannKopetz. The research project migrated into a European Community-fund-ed scientific project by a consortium that included Daimler-Benz, Volvo,Ford, Bosch, and Magneti-Marelli. The standard is open and a significantamount of advanced development work has been undertaken usingTTP/C. The references at the end of this article provide some moredetailed writing on the subject matter.

Typical TTP/C applications would include automotive brake-by-wire orsteer-by-wire systems, in which the systems must be “fail-operational,” as theapplications are safety-critical. “By-wire” systems transfer electrical signalsdown a wire instead of using a medium such as hydraulic fluid to transfer

Time TriggeredProtocol: TTP/CFault-tolerant, real-time performance is vital to the success of by-wire systems. Here is a solution that meetssafety-critical requirements.

I

Embedded Systems Programming MARCH 1999 77

muscular energy. A conventionalantilock braking system (ABS) is con-sidered “fail-silent”; if a fault in theelectronic control system is detected,the control system is switched off, leav-ing the manual hydraulic back-up stilloperational. If no such hydraulic back-up is available (as in the case of a by-wire system), the system must contin-ue to function in the event of a faultoccurring.

The automotive industry has iden-tified many good reasons to developby-wire systems: reduction in partscount, removal of hydraulic system,improved maintenance, increased per-formance and functionality, increasedpassive safety by removal of mechani-cal linkages to passenger compart-ment, fuel economy, and so on.Although several nontrivial challengesmust be overcome before by-wire sys-tems become the mainstream, manycompelling reasons exist for the tech-nology to be introduced—so the chal-lenges should be overcome relativelyquickly. The TTP overcomes the chal-lenge of fault-tolerant distributedembedded processing.

Additional interest is expected inseveral other applications that requirea high degree of dependability, partic-ularly in the fields of aeronautics, mil-itary, and medical systems.

Requirements for safety-critical systems Closed-loop control-orientated safetycritical applications usually execute acontrol cycle in a pre-defined timeperiod. For example an electronicbraking system usually executes a con-trol loop every 10ms or thereabouts.In this cycle, several sensor inputs areevaluated, an algorithm in which out-put control variables are calculated,then signals are sent to actuators at thewheel. The loop is then repeated. In

this type of system, regularity of infor-mation transfer is critical to maintaincontrol of the system.

The distributed embedded controlworld already supports several serialcommunications systems such as CAN(Controller Area Network), SAEJ1850-DLC, and SAE J1850-HBCCspecifications. Three categories ofcommunications systems are classifiedby the SAE: Class A is for low-speednetworks typically used in vehicle bodycontrols; Class B is for high-speed net-works but with no safety-criticalrequirement; and Class C systemsrequire certain stringent safety-criticalrequirements. The existing communi-cations protocols do not meet Class Crequirements, hence the TimeTriggered Protocol was developed.The additional requirements for ClassC are that they must be deterministicwith small and bounded latencies, all-fault scenarios must be accounted forwith a safe alternative operating mode,distributed clock synchronization(global time) must be supported, andthe bus is guarded against “babblingidiot” nodes.

The unsuitability of the existingcommunications protocols stems fromthe fact that they are “event-trig-gered,” in that a precise moment intime when a message will be receivedisn’t specified. A communications pro-tocol can only be predictable if worst-case transmission time and jitter areknown at the time of the design andmeet the requirements of the applica-tion. Real-time control applicationsare very sensitive to jitter, and so it isan important parameter for develop-ing real-time distributed systems. Thetime delay between presenting a mes-sage to be transmitted at the sendersinterface and receiving the message atthe receivers interface is known as thetransmission time. Jitter is defined as

the variability of this transmission time(the minimum transmission timesub-tracted from the maximum transmis-sion time). The maximum jitterdepends on the longest message thatis possible to transmit.

The type of communications proto-col most suitable for ensuring regular-ity of information transfer is TDMA(Time Division Multiple Access).Using a TDMA scheme ensures thatnonpredictable message delays aren’tpossible, as message transmissions arescheduled at the time of the design.Each electronic control unit isassigned a time slot in which it’s givenexclusive access to the bus to sendmessages. As every control unit has itsown time slot, collisions are impossi-ble. Also, as each transmission has thesame priority for bus access, worst-casejitter can be easily calculated.

In time-triggered systems allactions are derived from the progres-sion of a globally synchronized timebase accessible to all nodes, whereas inevent-triggered systems, all actions arederived from the occurrence ofevents. Table 1 outlines the main dif-ferences between TTP/C and theCAN protocol.

TDMA-based systems transmit statemessages—for example, a switchbeing either on or off. State messagescan be observed for a longer period oftime than an event and are transmit-ted periodically. No new value over-writes an old value until the nextTDMA round, and the state informa-tion isn’t consumed when it’s read. Ina typical distributed embedded con-trol system in which a number of sen-sors are sampled or polled periodical-ly during the control cycle, state mes-sages prove to be the most suitablemessage type for closed-loop controlapplications. Events, on the otherhand, contain information that is valid

Although several nontrivial challenges must be overcome before by-

wire systems become the mainstream, many compelling reasons exist

for the technology to be introduced.

RU

PE

RT

A

DL

EY

ttp/c

at a particular point of time (until anoverriding event occurs). An exampleof such an event would be when apush-button switch is pressed andreleased. Event messages are typicallyqueued for consumption and con-sumed when read. These event mes-sages are more efficient in systemswith sporadic or rare occurences thatrequire observation.

The resource requirements for atime-triggered system are determinedbefore run time so the system willbehave predictably and be able to han-dle peak load situations deterministi-cally. Event-triggered systems are usu-ally more inefficient than time-trig-gered systems when the system is oper-ating at less than peak loading,because the system must be designed

to handle worst-case conditions thatmay rarely occur.

The Time Triggered Protocol wasdeveloped to meet the requirementsof deterministic communications, aswell as to support the fail-operationalor fault tolerant requirements that arecritical in systems which would other-wise exhibit catastrophic behavior inthe event of a fault.

Time Triggered ProtocolprinciplesA TTP/C-based network is shown inFigure 1. Four host controllers areshown. These hosts could be electron-ic control units in a vehicle networksuch as braking, steering, suspension,and powertrain. Each of the fournodes are composed of a host, CNI

(controller network interface), andthe TTP/C controller. Two buses arepresent to support redundancy; if afault develops on one bus, the alter-nate bus is available.

The host controller of each mod-ule runs the application software. Thesending of messages is controlled by ascheduling table called the messagedescriptor list. This list contains theinformation that controls access to thebus in any particular time slot. Thecommunications system and TTP/Ccontroller will operate autonomouslyfrom the host software, using the mes-sage descriptor list which is stored inthe CNI. Each node in the network issynchronized to a common globaltime. The CNI decouples the commu-nication network from the host andprovides a data-sharing interfacebetween the host and the TTP/C con-troller. This is best physically imple-mented with dual port RAM that canbe addressed by either the host or theTTP/C controller.

The third segment of the node isthe actual TTP/C controller, whichconnects the node to the network.The TTP/C controller provides guar-anteed transmission times with mini-mal latency jitter, fault-tolerant clocksynchronization, and fast error detec-tion. In support of fault tolerance, theTTP/C also supports replica deter-minism as well as a replicated commu-nications channel.

The system is based on state mes-sage transmission; state messages cantypically be observed over a longerperiod of time than an event message,which would change every time thereis a new event, as opposed to periodi-cally. State messages are well suited toclosed-loop control type applications,in which inputs are usually required tobe sampled once per control cycle. Noqueuing of messages occurs in theCNI, as a new version of the state mes-sage overwrites the old one everyTDMA round. The Class B communi-cations protocols, which we discussedpreviously, operate using event-basedmessaging.


The resource requirements for a time-triggered system are

determined before run time so the system will behave predictably and

be able to handle peak load situations deterministically.

TABLE 1 Differences between TTP/C and CAN

Function TTP/C CANMulti-Master Bus ✔ ✔Medium Access Control TDMA CSMA/CAFlexible Bus Access limited (modes) 4Replicated Broadcast Buses 4 2 CAN controllersGlobal Time Base 4 softwareMembership Service 4 noBus Guardian 4 noReplica Determinism 4 noComposability 4 limited

FIGURE 1 Typical TTP/C-based system

Host

CNI

TTP/C

Host

CNI

TTP/C

Host

CNI

TTP/C

Host

CNI

TTP/C

ttp/c

Replica determinism is implement-ed by duplicating nodes, so that if onenode develops a fault, the signal fromthe node is replaced by a redundant

node that broadcasts the same resultin a different time slot. The main strat-egy for fault tolerance in the TTP/Csystem is fail-silence. A fail-silent archi-

tecture must deliver a correct outputor no output at all. When no output isgenerated, the hardware has devel-oped a fault. A number of error-detec-tion strategies, both in hardware andsoftware, must be employed in orderto ensure fail-silence. The TTP/C con-troller uses watchdogs as well as a busguardian which enables the bus driveronly during the nodes transmissionslot and disables it at all other times.This arrangement prevents the bab-bling idiot problem which can causehavoc in priority-based event triggeredsystems.

The second replica is groupedtogether in a cluster with the firstreplica, and is known as a fault-toler-ant unit (FTU). A system consisting ofthree FTUs is shown in Figure 2.

The same message is sent on bothchannels by the first replica at a par-ticular pre-defined timeslot and thenre-sent by the second replica at a laterTDMA slot. The second replica is com-pletely physically separate from thefirst replica.

Error detection is achieved at thereceiver side, since the arrival time ofall messages in the system is known atdesign time. If a message isn’t receivedat the expected time, this is regardedas a transmission error by all receivers.The global time base is thus critical tothe system, as the communicationsprotocol depends on the knowledgeof when every transmitted message isspecified. A synchronization algo-rithm is executed by each of the con-trollers in the network so that clockcorrection is possible and each nodein the system will always have an iden-tical notion of global time.

The concept of fail-silence in thecommunications system means that novoting system by several (minimumthree) components is required, as intraditional fault-tolerant computerarchitectures. This concept is impor-tant, as typical voting schemes involv-ing three or more CPUs are expensiveto implement in lower-cost applica-tions (such as the automotive indus-try). Each node focuses only on


The global time base is critical to the system, as the communications

protocol depends on the knowledge of when every transmitted

message is specified.

ttp/c

detecting faults within its own entity; ifa fault is detected, it switches itself off.

TTP/C message frametypesTwo types of frame exist in TTP/C: ini-tialization frames (I-frames) and nor-mal frames (N-frames). These framesare indicated in Figure 3.

N-frames are transmitted periodi-cally during normal operation of thesystem and contain application data.Three fields are present in the frame:a control field, data field, and cyclic

redundancy check (CRC) field. Clocksynchronization occurs just prior tothe control field. It is inevitable thatlocal timebases drift apart; therefore, aresynchronization strategy is imple-mented using the control field. Thecontrol field in the N-frame consists ofan initialization bit which indicatesthat it is a normal frame. The modebits are also contained in the controlfield, and indicate the operating modeof the system. The next field in the N-frame is the data field, which can con-tain up to 16 bytes of application data,

depending on the operating mode.Finally, a CRC field consists of twobytes. The CRC is a slightly differentcalculation for the N- and I-frames,and makes it posssible for the receiverof the frame to detect errors in trans-mission. A normal frame is acceptedonly if the receiver and sender agreeon the mode, global time, and nodemembership (which nodes are activeor inactive, and which have a bit set to1 or 0).

Neither the I-frame nor the N-frame have any identifier to indicatefrom which node they were transmit-ted. The message sender is impliedfrom the time of sending.

I-frames are used for system initial-ization and contain data on the inter-nal state of the TTP controller for itsassociated node in its data field. Thisinformation is known as the C-State(controller state). In TTP/C, all nodesare forced to implicitly agree on theirC-states. The C-State contains informa-tion about the current operatingmode, TDMA slot, global time, andthe membership status. If the C-stateof the sender isn’t identical to the C-state of a receiver, the message will bedisregarded by the receiver, due to thedifferent CRC.

Continuous clock synchronizationwithout any overhead to the framelength is acheived by executing anaveraging algorithm periodically ateach node. The node is given access toa global time base transmitted in the I-and N-frames. The receiver knowsapriori the sending time of each framefrom each node, so the disparitybetween the specified send time andthe observed receive time indicatesthe time difference between sendingand receiving nodes. Thus the appro-priate distributed time bases can betweaked to ensure uniform globaltime.

Because real-time distributed sys-tems typically have different operatingmodes such as start-up, normal oper-ating, emergency, and so on, TTP/Csupports rapid mode changing. At anygiven time, the ensemble of nodes in


FIGURE 3 Frame types

Control CRCData (max. 16 Bytes)

Control CRCC-State (max. 10 Bytes)

N-Frames (Normal Frames): • Periodic transmission of state messages• Majority of frames during normal operation

I-Frames (Initialization Frames): • Startup phase: periodic lifesign of sending node• Normal operation: at predefined intervals to facilitate reintegration of recovering nodes

No identifier!Message contents are derivedfrom time of sending.

FIGURE 2 Fault-tolerant units

HostCPU

HostCPU Host

CPU

HostCPU Host

CPU

HostCPU

TTP TTPTTP TTP

TTP TTP

FTU 0 FTU 1 FTU 2

Duplicatedbroadcast buses

Fault-tolerant units (FTUs):Groups of actively replicatednodes

Communication Subsystem

Host Subsystems

ttp/c

the system will be operating in a par-ticular mode. A mode change is per-mitted when any node indicates that amode change should occur using themode bit in its control field.

ApplicationsA number of by-wire projects, mainlyin the automotive industry, are beingdeveloped using the TTP/C protocol.TTP/C has been shown to be a suit-able communications protocol forsuch applications because it satisfiesthe requirements of safety-criticalcommunications systems by beingdeterministic, providing redundancy,and guarding against a fault whichresults in a single node monopolizingthe bus. The architecture is also com-posable, which allows the behavior ofan overall system to be predicted fromthe subsystem properties. Therefore,


FIGURE 4 Possible steer-by-wire architecture using TTP/C

U

T T

T

Front-wheel steer-by-wire • 3 tie rod actuators, each 50% of necessary power• 2 driver feedback actuators• steering angle and steering wheel sensors

Optional rear-wheel steering

HostCPU

HostCPU

HostCPU

TTP

TTP

TTP

TTP TTP

TTP

TTP

HostCPU

HostCPU

FTU

FTU

HostCPU

HostCPU

ttp/c

independent development, testing,validation, and certification of subsys-tems (nodes) may be accomplished.

A possible steer-by-wire architec-ture is shown in Figure 4. The TTP/C

communications network is used toconnect the steering actuators (motorcontrollers) at the front of the vehicle,the steering control unit mountednear the steering wheel, and the actu-ator units on the rear wheels (motorsused for four-wheel steering). Threereplicated nodes are present at thefront actuator. These nodes receiveinformation on intended steeringangle from the main control unit anddrive motors, which control the angleof the wheels. Feedback on angle andmotor torque is returned to the maincontroller, and additional actuatorsare used to provide a comfortablelevel of steering wheel feedback to thedriver. The main controller also con-sists of two nodes because steering is asafety-critical application.

A high level of redundancy is antic-ipated to be required on a steer-by-wire system, as no direct mechanical

connection will exist between the dri-ver and the wheels.

Brake-by-wire is another applica-tion that can be developed using theTTP/C communications protocol. An

example of a brake-by-wire architec-ture is shown in Figure 5.

The system illustrates wheel nodesthat control actuation of brakingmotors as well as providing the inter-face with the wheel speed sensors. Itmay be the case that a fault-tolerantunit isn’t required at the wheel node,because a catastrophic event may notoccur if one of the wheel nodesinhibits itself. It should be possible tobrake the vehicle to rest safely with anythree wheel nodes operational. Themain central control unit consists oftwo replica controllers. The main con-trol unit must be redundant because ifa fault develops, a catastrophic situa-tion could occur.

Automotive and beyondTTP/C wasn’t developed to competewith existing serial communicationsprotocols; rather, it was developed to

address new, advanced systems whichwill emerge and possess requirementsthat cannot be met by today’s popularevent-triggered Class B protocols.Both Class B and Class C systems willcoexist in modern vehicles with a com-munications gateway that will allowthem to share information. Althoughthe initial applications are likely to bein the automotive market, many unre-lated fields may require robust net-work operation that can continue tooperate as normal if a node stopsworking correctly.

As with other popular serial com-munications protocols, the TTP/Ccontroller module is planned to beintegrated along with other functionson microcontrollers or as a stand-alone entity that can be designed intonodes in a given system. esp

Ross Bannatyne graduated from theUniversity of Edinburgh, Scotland, withhonors in Electrical Electronic Engineeringand is currently a systems engineeringmanager for Motorola’s TransportationSystems Group in Austin, TX.

Recommended ReadingDaimler-Benz AG, B.Hedenetz, and R.

Belschner, “Brake-by-wire without

Mechanical Backup by Using a TTP-

Communication Network,” SAE

Congress Conference Proceedings,

1998.

Kopetz, H., “Fault Management in the

Time Triggered Protocol (TTP),” SAE

Congress Conference Proceedings, 1998.

Koptez, Hermann. Real-Time Systems:

Design Principles for Distributed

Embedded Applications. Dordrecht, The

Netherlands: Kluwer Academic

Publishers, 1997.

Kopetz, H., “Should Responsive Systems

Be Event-Triggered or Time-Triggered?,”

IEICE Transactions on Electronics,

November 1993.

Robert Bosch GmbH, E. Dilger, T. Fuhrer, B.

Muller, and S. Poledna, “The X-By-Wire

Concept: Time-Triggered Information

Exchange and Fail Silence Support by

New System Services,” SAE Congress

Conference Proceedings, 1998.


A high level of redundancy is anticipated to be required on a steer-by-

wire system, as no direct mechanical connection will exist between

the driver and the wheels.

FIGURE 5 Possible brake-by-wire architecture using TTP/C

HostCPU

TTP FTU

HostCPU

TTP

HostCPU

TTP

HostCPU

TTP

HostCPU

TTP

HostCPU

TTP

Documents

Time Triggered Protocol TTP C