Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Fault Tolerant TTCAN

Fault Tolerant TTCAN

Ratings: (0)|Views: 21|Likes:
Published by POWERBASE

More info:

Published by: POWERBASE on Oct 26, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Fault tolerant TTCAN networks
B. Müller, T. Führer, F. Hartwich, R. Hugel, H. Weiler, Robert Bosch GmbH
TTCAN is a time triggered layer using the CAN protocol to communicate in a time trig-gered fashion. As TTCAN is based on CAN it uses the power of CAN´s error detectionmechanisms and robustness, but it also provides a step towards determinism andtime triggered technology.Future system architectures will include applications that need to access more thanone TTCAN controller. This article describes how to build fault-tolerant TTCAN net-works, in particular the mechanisms to synchronize different TTCAN busses. It isshown that it is very easy to implement a synchronized network of any reasonableredundancy level, even if non-trivial architectures (for instance more than a simpledual channel network) are involved. Moreover, this synchronization can be achievedeven when the individual TTCAN busses use different time bases without ever violat-ing the modular integrity of one single bus.
There is a variety of real-time bus-systemsthat are used to connect electronic controlunits in automation or in the automobile.Most of these communication protocolsare one channel systems, i.e. althoughthere are possibly some fault-tolerancemechanisms, there is no really redundanttransmission of messages. In some safetycritical applications however, redundantmessage transmission becomes a re-quirement.A time triggered variant of CAN, denotedin the sequel by TTCAN, is described bythe ISO standard 11898-4 (currently still adraft version). Essentially CAN and henceTTCAN is a one channel system, redun-dancy can only be provided by using mul-tiple TTCAN busses. However, comparedwith intrinsically redundant systems (e.g.FlexRay, TTP/C), the use of multiple sin-gle channel busses introduces the prob-lem of management of redundancy. Thismainly consists of synchronizing the dif-ferent busses, but it must also be ensuredthat the main services of a time triggeredcommunication system (providing a globaltime and a consistent schedule all over thenetwork) can be used by an applicationfrom either of the channels. This means itmust be possible for an application to treatthe set of different busses as one commu-nication system. In the paper it is shownthat the TTCAN interfaces allow to easilycombine TTCAN busses in a modular wayso that this can be achieved even in sys-tem architectures that go far beyond thestandard dual channel scenario.
As fault tolerant TTCAN networks consistof combinations of TTCAN busses we be-gin with a short description of the TTCANbus. The interested reader may find moredetailed descriptions in [1].
TTCAN Basics
Time triggered communication in TTCANis based on the reference message beingtransmitted regularly by the time master.Following the reference message there isa sequence of time windows that providethe time slots for individual messagetransmissions. There are three types oftime windows: exclusive time windows thatare exclusively reserved for one message,arbitrating time windows during whichmessages can compete for the bus by thenon-destructive arbitrating mechanism ofCAN, and free time windows that are re-served for future extensions of the net-work. The pattern of time windows follow-ing a reference message is called a basiccycle, i.e. each basic cycle starts with areference message and contains an off-line configured set of time windows.In TTCAN not all basic cycles necessarilyhave to be the same. It is possible to dis-tinguish different basic cycles by the cyclecount, a counter that is incremented eachcycle up to the maximum value after whichit is restarted again. Combining all thesedifferent cycles we get the so called matrixcycle which represents the completecommunication overview of a TTCAN net-work.
Figure 1 Example of a matrix cycle
TTCAN Timing
A TTCAN controller can be configured tosupport two levels, level 1 and level 2.Level 2 is an extension of level 1, and onlyin level 2 high end synchronization andglobal time are provided [1]. In the sequelwe will always consider level 2 networksalthough some of the mechanisms de-scribed below can also be used in level 1networks.Within a TTCAN controller we basicallyhave three time notions: local time, cycletime, and global time. All three times runwith the same rate but use different andvarying relative phases to each other. Lo-cal time is the controller internal basis forall other times.The basic network time unit is the socalled NTU and within a level 2 controllerthe local time counter must be able tocount even fractional parts of an NTU (witha fractional resolution of at least 3 bits).With each reference message, cycle timeis restarted. More precisely: The samplepoint of the SoF bit of any message gen-erates a (logical) frame synchronizationpulse in the network. On occurrence ofsuch a frame synchronization pulse eachcontroller captures the current value of itslocal time and, after identification of amessage as reference message, treatsthis value (the local reference mark) as thestarting point of cycle time, i.e. within acontroller we have
Cycle time = Local time Local referencmark.
Actually the fractional parts of this differ-ence are ignored as cycle time only countsNTUs.Byte 1: Next_Is_Gap bit and cycle count76543210
Next_Is_ GapReservedCycleCount (5)CycleCount (4)CycleCount (3)CycleCount (2)CycleCount (1)CycleCount (0)
Byte 2: Fractional part NTU_Res of Master_Ref_Mark and discontinuity bit76543210
Byte 3: Low byte of Master_Ref_Mark76543210
Byte 4: High byte of Master_Ref_Mark76543210
Figure 2: Reference message in TTCAN level 2
Global time is not only using the existencebut also the content of the reference mes-sage. Figure 2 shows the four mandatorybytes of the reference message, further
data bytes may be added by the applica-tion.By definition, at a given time, global time ina TTCAN network is what the currentmaster thinks it is. So within the referencemessage the master transmits the globaltime value including fractional parts (theMaster_Ref_Mark) that is valid at thepulse of the respective frame synchroniza-tion. The local offset - the difference be-tween the Master_Ref_Mark and the cor-responding local reference mark - givesthe difference between local and globaltime at the point of frame synchronization,hence the local approximation to globaltime is given by
Global time = local time +local offset 
.This even holds for the time master. Wesee that both cycle time and global timeare derived from local time, and both areresynchronized with every reference mes-sage. Again the fractional parts of this dif-ference are ignored as cycle time onlycounts NTUs.Moreover, each controller adjusts by useof the clock synchronization algorithm therate of its local time, so that it almost per-fectly matches the rate of the master:Within a TTCAN controller the rate of localtime is determined by the so called TUR(time unit ratio) variable, a variable thatindicates the (non-integer) ratio betweenan NTU and the local clock period. TURhas a configuration value within each con-troller, but a perfect adjustment to an os-cillator in another node can only occur ifthe TUR value is adapted so that the locallength of an NTU equals the global (themaster´s) length of the NTU as good aspossible. The TTCAN clock synchroniza-tion automatically computes the optimumTUR value by use of the global time givenby the master and therefore ensures thatthe different local times within the networkhave the same rate.
TTCAN Initialization
In a single channel TTCAN network therecan be up to 8 potential time masters, dis-tinguished by the three bit time masterpriority. The time master priority is givenby the three least significant bits of thereference message that is transmitted bythe respective potential time master. Al-though we do not describe the initializationprocedure in detail (see for instance [1]), itis important to note that eventually thepotential time master with the highest timemaster priority becomes the time master ofthe TTCAN network.
The Gap Case
Although it is possible to transmit the ref-erence message completely periodicallythis is not required in TTCAN. To supportthis the time master announces in the ref-erence message by use of theNext_Is_Gap bit that after the current ba-sic cycle there will be a gap of undeter-mined length. (However, the maximumlength of the gap is specified off-line). Atsome point the application initiates thetransmission of a reference message andso brings the gap to an end. This typicallyis synchronized with some applicationspecific event.
Figure 3: The gap
This feature is particularly useful if onewants to synchronize applications to proc-esses that are not periodic in the TTCANtime. Note that the gap does not influencecontinuity of global time, i.e. global time just continues to increase during the gapas it does during a cycle.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->