[attachment=1646]


Seminar on
TTCAN
Time Triggered Controller Area Network
[TTCAN]
Abstract
As early as the 1950s electronic elements started to appear in

passenger vehicles. Over the years the electronic content and

complexity continued to grow in vehicles. In 1983, it was formally

stated at Robert Bosch AG that a real-time communication page link was

required between three electronic control units: engine control,

automatic transmission control and the anti-skid braking system.
Despite the existence of a number of proprietary automotive

multiplexing protocols, a new serial communications protocol

emerged from Bosch's endeavor, the Controller Area Network (CAN).

In mid 1987 the first working silicon for CAN became available. In

1993 CAN was standardized by the International Standardization

Organization (ISO).

In time-triggered CAN the exchange of messages is controlled

essentially by the temporal progression of time. The exchange of a

specific message may only occur at a predefined point 'in relative'

time during time-triggered operation of the protocol. This

'benchmark' in time, to which all other communication transactions

are related, is defined by the start of frame (SOF) bit of a

specific message known as the reference message.
The reference message is transmitted either periodically (in time

triggered mode) or on the occurrence of a specific external event

(in event triggered mode).The reference message is recognized by

all nodes participating in the TTCAN network by virtue of its CAN

frame identifier. Each node synchronizes to the reference message,

which provides a reference point in the temporal domain for the

static schedule of the message transactions.
The static schedule sequence is based on a time division access

(TDA) scheme whereby message exchanges may only occur during

specific time slots or time windows.
When the nodes are synchronized, any message can be transmitted at

a specific time slot, without competing with other messages for the

bus. Thus the loss of arbitration is avoided, the latency time

becomes predictable. Apart from the synchronized communication

schedule, the TTCAN nodes operate according to the
Standard CAN protocol as defined by ISO 11898-1.
The TTCAN protocol is in the process of standardization by ISO

TC22/SC3/ WG1/TF6 describes TTCAN on system level. This paper

describes the implementation of TTCAN features into a CAN module

and the evaluation of a TTCAN network.
Introduction
CAN is the dominating network for automotive applications. New

concepts in automotive control systems require a time triggered

communication. This is provided by TTCAN, ISO 11898-4 . The main

features of TTCAN are the synchronization of the communication

schedules of all CAN nodes in a network, the possibility to

synchronize the communication schedule to an external time base,

and the global system time.
TTCAN nodes are fully compatible with CAN nodes, both in the data

link layer (ISO 11898-1) and in the physical layer; they use the

same bus line and bus transceivers. Dedicated bus guardians are not

needed in TTCAN nodes, bus conflicts between nodes are prevented by

CANâ„¢s non-destructive bitwise arbitration mechanism and by CANâ„¢s

fault confinement (error-passive, bus-off).
Existing CAN controllers can receive every message in a TTCAN

network, TTCAN controllers can operate in existing CAN networks. A

gradual migration from CAN to TTCAN is possible. The minimum

additional hardware that is required to enhance an existing CAN

controller to time triggered operation is a local time base and a

mechanism to capture the time base, the capturing triggered by bus

traffic.
Based on this hardware, which is already existent in some CAN

controllers, it is possible to implement in software a TTCAN

controller capable of TTCAN level 1. A TTCAN controller capable of

TTCAN level 2, providing the full range of TTCAN features like

global time, time mark interrupts, and time base synchronization,

has to be implemented in silicon.
A TTCAN controller can be seen as an existing CAN controller (e.g.

Boschâ„¢s C_CAN module) enhanced with a Frame Synchronization Entity

FSE and with a trigger memory containing the nodeâ„¢s view of the

system matrix.
The TTCAN test chip (TTCAN_TC) is a standalone TTCAN controller

and has been produced as a solution to the hen/egg problem of

hardware availability versus tool support and research. The

TTCAN_TC supports both TTCAN level 1 and TTCAN level 2; its time

triggered communication is not depending on software control.
The need for serial communication in vehicles
Many vehicles already have a large number of electronic control

systems. The growth of automotive electronics is the result partly

of the customerâ„¢s wish for better safety and greater comfort and

partly of the governmentâ„¢s requirements for improved emission

control and reduced fuel consumption.
Control devices that meet these requirements have been in use for

some time in the area of engine timing, gearbox and carburetor

throttle control and in anti-block systems (ABS) and acceleration

skid control (ASC).The complexity of the functions implemented in

these systems necessitates an exchange of data between them.
With conventional systems, data is exchanged by means of dedicated

signal lines, but this is becoming increasingly difficult and

expensive as control functions become ever more complex. In the

case of complex control systems, the number of connections cannot

be increased much further.
Moreover, a number of systems are being developed which implement

functions covering more than one control device. For instance, ASC

requires the interplay of engine timing and carburetor control in

order to reduce torque when drive wheel slippage occurs. Another

example of functions spanning more than one control unit is

electronic gearbox control, where ease of gear changing can be

improved by a brief adjustment to ignition timing.
Controller Area Network (CAN), an overview
CAN (Controller Area Network) is a serial bus system, which was

originally developed for automotive applications in the early

1980's. The CAN protocol was internationally standardized in 1993

as ISO 11898-1 and comprises the data page link layer of the seven layer

ISO/OSI reference model.
CAN, which is by now available from around 40 semiconductor

manufacturers in hardware, provides two communication services: the

sending of a message (data frame transmission) and the requesting

of a message (remote transmission request, RTR). All other services

such as error signaling, automatic re-transmission of erroneous

frames are user-transparent, which means the CAN chip automatically

performs these services.
The equivalent of the CAN protocol in human communication are e.g.

the Latin characters. This means a CAN controller is comparable to

a printer or a type writer. CAN users still have to define the

language/grammar and the words/vocabulary for communication.
CAN provides
¢ A multi-master hierarchy, which allows building intelligent

and redundant systems. If one network node is defect the network is

still able to operate.
¢ Broadcast communication. A sender of information transmits

to all devices on the bus. All receiving devices read the message

and then decide if it is relevant to them. This guarantees data

integrity as all devices in the system use the same information.
¢ Sophisticated error detecting mechanisms and re-

transmission of faulty messages. This also guarantees data

integrity.
TTCAN Definition
The TTCAN (time-triggered communication on CAN) protocol is a

higher layer protocol on top of the CAN (Controller Area Network)

data page link layer as specified in ISO 11898-1. It may use

standardized CAN physical layers such as specified in ISO 11898-2

(high-speed transceiver) or in ISO 11898-3 (fault-tolerant low-

speed transceiver).
Time-triggered communication means that activities are triggered

by the elapsing of time segments. In a time-triggered communication

system all points of time of message transmission are defined

during the development of a system. A time-triggered communication

system is ideal for applications in which the data traffic is of a

periodic nature.
CAN Vs TTCAN
CAN is the dominating network for automotive applications. New

concepts in automotive control systems require a time triggered

communication. This is provided by TTCAN, ISO 11898-4. The main

features of TTCAN are the synchronization of the communication

schedules of all CAN nodes in a network, the possibility to

synchronize the communication schedule to an external time base,

and the global system time.
TTCAN nodes are fully compatible with CAN nodes, both in the data

link layer (ISO 11898-1 [1]) and in the physical layer; they use

the same bus line and bus transceivers. Dedicated bus guardians are

not needed in TTCAN nodes, bus conflicts between nodes are

prevented by CANâ„¢s nondestructive bitwise arbitration mechanism and

by CANâ„¢s fault confinement (error-passive, bus-off).
Existing CAN controllers can receive every message in a TTCAN

network, TTCAN controllers can operate in existing CAN networks. A

gradual migration from CAN to TTCAN is possible. The minimum

additional hardware that is required to enhance an existing CAN

controller to time triggered operation is a local time base and a

mechanism to capture the time base, the capturing triggered by bus

traffic. Based on this hardware, which is already existent in some

CAN controllers, it is possible to implement in software a TTCAN

controller capable of TTCAN level 1.
A TTCAN controller capable of TTCAN level 2, providing the full

range of TTCAN features like global time, time mark interrupts, and

time base synchronization, has to be implemented in silicon. A

TTCAN controller can be seen as an existing CAN controller (e.g.

Boschâ„¢s C_CAN module) enhanced with a Frame Synchronization Entity

FSE and with a trigger memory containing the nodeâ„¢s view of the

system matrix (see Figure 1).
The TTCAN test chip (TTCAN_TC) is a standalone TTCAN controller and

has been produced as a solution to the hen/egg problem of hardware

availability versus tool support and research. The TTCAN_TC

supports both TTCAN level 1 and TTCAN level 2; its time triggered

communication is not depending on software control. All

synchronization mechanisms described in this paper are supported by

the TTCAN_TC.

Figure: TTCAN Controller Module
The cyclic message transfer of TTCAN level 1 can be implemented in

software, based on existing CAN modules. Depending on the CAN bit

rate and on the number of messages in the system matrix, the

software approach may result in a high CPU load. For the evaluation

of the TTCAN protocol, the hardware approach was chosen.
In parallel to the standardization process, Bosch develops an IP

module that implements the TTCAN protocol. This IP module, the

TT_CAN, is based on the existing C_CAN IP module and will be

available as VHDL code to be synthesized in FPGAs, supporting the

development of CAN based time triggered communication networks.
The C_CAN consists of the components CAN Core, Message RAM, Message

Handler, Control Registers, and Module Interface. The CAN_Core

performs communication according to the CAN protocol version 2.0,

as defined in ISO 11898-1.
The bit rate can be programmed to values up to 1MBit/s depending

on the used technology. For the connection to the physical layer

additional transceiver hardware is required. For communication on a

CAN network, individual Message Objects are configured. The Message

Objects and Identifier Masks for acceptance filtering of received

messages are stored in the Message RAM.
All functions concerning the handling of messages are implemented

in the Message Handler. Those functions are the acceptance

filtering, the transfer of messages between the CAN Core and the

Message RAM, and the handling of transmission requests as well as

the control of the module interrupt. The register set of the C_CAN

can be accessed directly by an external CPU via the module

interface. These registers are used to control/configure the CAN

Core and the Message Handler and to access the Message RAM.
Several Module Interfaces are available, including interfaces to

ARM, Motorola and Texas Instruments CPUs. Compared to the C_CAN,

the TT_CAN is expanded by two functional blocks, the Trigger Memory

and the Frame Synchronization Entity FSE. The Trigger Memory stores

the time marks of the system matrix that are linked to the messages

in the Message RAM; the data is provided to the Frame

Synchronization Entity.
The Frame Synchronization Entity is the state machine that controls

the time triggered communication. It synchronizes itself to the

reference messages on the CAN bus, controls the cycle time, and

generates Time Triggers. It is divided into five blocks, the Time

Base Builder TBB, the Cycle Time Controller CTC, and the Time

Schedule


Figure: Block Diagram of the C_CAN
Time Schedule Organizer TSO, the Master State Administrator MSA,

the Application Operation Monitor AOM, and the Global Time Unit

GTU.

Figure: Block Diagram of the TT_CAN

Figure: Frame Synchronization Entity
Time Base Builder generates the local time from the nodeâ„¢s system

clock and the time unit ratio. In TTCAN level 1, the TUR is defined

at configuration, in level 2; it is continuously adapted by the

GTU. The Cycle Time Controller gets the local time from the TBB,

the Frame_Synchronisation events from the CAN_Core, and the

reference messages from the Message Handler. It captures the

Sync_Mark and the Ref_Mark to generate the cycle time and controls

the sequence of the basic cycles in the matrix cycle.
Cycle Count (part of the reference message) identifies the actual

basic cycle inside the matrix cycle. Depending on whether the node

itself is time master (transmitter of reference messages), Cycle

Count is either generated from a cyclic counter or it is received

in the reference message.
The Time Schedule Organizer maintains the message schedule inside

a basic cycle and checks for scheduling errors. The schedule is

defined by data in the Trigger Memory. The data consists of time

mark (measured in cycle time), and function (trigger for

transmission or check of reception), and is linked to a message in

the Message RAM. The same time mark may be, selected by Cycle

Count, defined for different messages at different basic cycles of

the matrix cycle. Other time marks are defined for the Ref Trigger

and the Watch Trigger.
The TSO compares the time marks with the cycle time and activates

the Time Triggers for messages with matching time marks. The

function of the TSO depends on the actual operating state;

transmissions are disabled when the node is not synchronized to the

system. If the node is time master, the Ref Trigger causes the

reference message to be transmitted. The Watch Trigger becomes

active at the end of a basic cycle, when the expected start of a

new basic cycle (completion of a reference message) does not occur.
This event is causes the MSA to change the operating state.
The Master State Administrator controls the FSEâ„¢s operating state.

The operating state depends on whether the node is synchronized to

the network, whether it is (trying to become) time master or

whether it is a backup time master. The synchronization state

differentiates between synchronizing after the initialization, the

active mode, the loss of synchronization, and the fault recovery.
The function of the other blocks is monitored. In case of errors,

transmissions are disabled and the master state is resigned
The Application Operation Monitor checks the function of the

application program. The application controller has to serve the

Application Alive input regularly. If the application program

fails, the application watchdog causes the MSA to disable all

transmissions, preventing invalid data to disturb the system.
The Global Time Unit (TTCAN level 2 only) generates the nodeâ„¢s view

of the global time and controls the drift correction of the local

time. When the node is the first time master of the network, the

nodeâ„¢s local time is the global time. When the node is not

operating as time master, the difference between local Ref_Mark and

Master_Ref_Mark received in the reference message is compared and

defines the actual offset between the local time and the global

time.
The actual offset is updated at each start of a basic cycle; when

the node becomes time master, the last offset is kept, avoiding a

discontinuity in the global time. The Global_Ref_Mark (captured in

global time) is provided as Master_Ref_Mark for reference messages

to be transmitted. The GTU compensates the drift between the local

time and the global time by calibrating the local time. If the node

itself is the time master, no calibration is done. Each time a

reference message is completed, the actual length of the base cycle

is measured in local time (Ref_Mark - previous Ref_Mark) and in

global time (Master_Ref_Mark “ previous Master_Ref_Mark).
The difference between the two measured values divided by the

length of the base cycle shows the factor by which the local time

has to be calibrated in order to compensate the drift. The

compensation is performed by adapting the TUR the TBB uses to

generate the local time from the nodeâ„¢s system clock. The

calibration process is on hold when the node is not synchronized to

the system and is (re-)started when it (re-)gains synchronization.

Frequent significant changes in the measured drift indicate an

unreliable local time base. Time base errors are signaled to the

MSA, causing it to stop all TTCAN operations.
In order to synchronize different TTCAN networks, or to provide a

physical time base, the global time may be synchronized (via the

time master) to an external clock, e.g. GPS. The TTCAN

implementation is done in two steps. In the first step, only level

1 is implemented, without the global system time and drift

compensation of level2. In the second step, after the evaluation of

the TT_CAN IP module in a TTCAN network, a global time unit will be

added to the module.
Time Bases of the TTCAN Protocol
1. Local_ Time


Figure 1: Local_Time
Each node has its own time base, Local Time, which is a counter

that is incremented each Network Time Unit NTU. The length of the

NTU is defined by the TTCAN network configuration; it is the same

for all nodes. It is generated locally, based on the local system

clock period t-sys and the local Time Unit Ratio TUR. Different

system clocks in the nodes require different (non-integer) TUR

values. In TTCAN level 1, TUR is a constant and Local_Time is a 16

bit integer value, incremented once each NTU. The NTU is the CAN

bit time.
In TTCAN level 2, Local_Time consists of a 16 bit integer value

extended by a fractional part of N (at least three) bit. Local_Time

is incremented 2N times each NTU, providing a higher time

resolution than in level 1. TUR is a non-integer value and may be

adapted to compensate clock drift or to synchronize to an external

time base.
2. Cycle_Time
In the TTCAN network, the synchronization of the nodes is

maintained by so-called Reference Messages that are transmitted

periodically by a specific node, the time master. The Reference

Message is a CAN data frame, characterized by its identifier.
Valid Reference Messages are recognized synchronously

(disregarding signal propagation time) by all nodes. Each valid

Reference Message starts a new basic cycle and causes a reset of

each nodeâ„¢s Cycle_Time.
The value of Local_Time is captured as Sync_Mark at the start of

frame (SOF) bit of each message. When a message is recognized as a

valid Reference Message, this messageâ„¢s Sync_Mark becomes the new

Ref_Mark; Cycle_Time is the actual difference between Local_Time

and Ref_Mark, restarting at the beginning of each basic cycle when

Ref_Mark is reloaded.


Figure 2: Cycle_Time
Even in a software implementation of TTCAN, the capturing of

Local_Time into Sync_Mark at each SOF must be done in hardware (see

Figure 1). ISO 11898-1 specifies the necessary hardware interface

as an optional feature; it is already implemented in some CAN

controllers.
3. Global_Time
There are two levels of implementation in TTCAN, level 1 and level

2. In TTCAN level 1, the common time base is the Cycle_Time which

is restarted at the beginning of each basic cycle and is based on

each nodeâ„¢s Local_Time. In TTCAN level 2, there is additionally the

Global_Time which is a continuous value for the whole network and

is the reference for the calibration of all local time bases. The

time master captures its view of Global_Time at each Sync_Mark and

transmits that value in the Reference Message, as Master_Ref_Mark.
For all nodes, Global_Time is the sum of their Local_Time and their

Local_Offset, Local_Offset being the difference between their

Ref_Mark in Local_Time and the Master_Ref_Mark in Global_Time,

received (or transmitted) as part of the Reference Message. The

Local_Offset of the current time is master zero if no other node

has been the current time master since network initialization.


Figure 3: Global_Time
The phase drift between Local_Time and Global_Time is compensated

at each received Reference Message by updating Local_Offset.

Changes in Local_Offset show differences in the local nodeâ„¢s TU and

the actual time masterâ„¢s NTU.
The actual clock speed difference is calculated by dividing the

differences between two consecutive Master_Ref_Marks (measured in

global NTUs) and two consecutive Ref_Marks (measured in local

NTUs). The clock speed drift is compensated by adapting the pre-

scalar (TUR) that generates the local NTU from the local system

clock
The factor df by which the local NTU has to be adjusted is

calculated according to the formula:

The calibration process is on hold when the node is not

synchronized to the system, it is (re-)started when it (re-)gains

synchronization. The necessary accuracy of the calibration is

defined by the systemâ„¢s requirement; a plausibility check for the

value of df ensures that the length of the NTU remains in a

predefined range. This calibration, together with the higher

resolution for the NTU, provides a high precision time base.


Figure 4: Drift Compensation
After initialization, before synchronizing to the network, each

node sees its own Local_Time as Global_Time, the Local_Offset is

zero. The actual time master establishes its own Global_Time as the

networkâ„¢s Global_Time by transmitting its own Global_Sync_Marks in

the Reference Message, as Master_Ref_Marks. When a backup time

master becomes the actual time master, it keeps its Local_Offset

value constant, avoiding a discontinuity of Global_Time.


Figure 5: Global Time Phase Adjustment
Synchronizing the Global_Time
When the TTCAN communication is initialized, the actual time master

may adjust the phase of Global_Time by adding an offset

(Global_Time_Preset, see Figure 5) to the transmitted

Master_Ref_Mark value, e.g. to synchronize to an external clock.

Any such intended discontinuity of Global_Time is signaled in the

Reference Message, by setting the Disc_Bit. Reference Messages with

a set Disc_Bit are not used for clock calibration.
The actual time master may adjust the speed of Global_Time by

adjusting its TUR value, the other nodes in the TTCAN network will

calibrate their own clocks. The external time base used for the

synchronization of Global_Time may be a reference clock like GPS or

the Global_Time monitored in another
TTCAN network.
Synchronizing the Cycle_Time
TTCAN has the option to synchronize the communication schedule to

specific events in the time mastersâ„¢ nodes. When the communication

is to be synchronized, the cyclic message transfer is discontinued

after the end of a basic cycle and a time gap may appear between

the end of that basic cycle and the beginning of the next, event

synchronized basic cycle. The current time master announces the

time gap by setting the Next_is_Gap bit in the Reference Message.

The time gap ends as soon as the current time master or one of the

potential time masters sends a Reference Message to start the

following basic cycle of the matrix cycle. The transmission of the

Reference Message will be triggered by the occurrence of a specific

event or after a maximum waiting time.
Time Schedule Organizer “ TSO
This block is a state machine that maintains the message schedule

inside a basic cycle. The TSO gets its view of the message schedule

from an array of time triggers in the trigger memory. Each time

trigger has a time mark that defines at which Cycle_Time the

trigger becomes active. A Tx_Trigger specifies when a specific

message shall be transmitted. An Rx_Trigger specifies when the

reception of a specific message shall be checked.


Figure 6: Time Trigger
A Tx_Ref_Trigger (_Gap) triggers the transmission of a Reference

Message; it finishes the current basic cycle and starts a new

cycle. Ref_Triggers are used by potential time masters only. A

Watch_Trigger (_Gap) has a Time_Mark with a higher value than the

Tx_Ref_Trigger (_Gap) and checks if the time since the last valid

Reference Message has been too long.
When in the last Reference Message the Next_is_Gap bit was set, the

TSO ignores Tx_Ref_Trigger and Watch_Trigger, it uses

Tx_Ref_Trigger_Gapand Watch_Trigger_Gap instead. In all other

cases, Tx_Ref_Trigger and Watch_Trigger are used,

Tx_Ref_Trigger_Gap and Watch_Trigger_Gap are ignored. The maximum

time allowed for a time gap is the difference Tx_Ref_Trigger_Gap -

Tx_Ref_Trigger.
Host controlled Synchronization
Figure 7 shows an example how the host application of the time

master can synchronize the TTCAN networkâ„¢s Cycle_Time. First the

host requests the time master to transmit a Reference Message with

the Next_is_Gap bit set. The time gap starts when the basic cycle

started by that reference Message is finished. The message schedule

is restarted when the host triggers the next Reference Message. If

the host fails to trigger the Reference Message within a specified

time, the TSO itself triggers the Reference Message when its

Cycle_Time reaches Tx_Ref_Trigger_Gap.

Figure 7: Host Synchronization of Cycle Time Phase
Automatic Synchronization
The implementation of TTCAN in hardware allows implementing some

additional features (not required by TTCAN protocol) that cannot be

provided in software. An Event Trigger input can be used to trigger

Reference Messages. In this mode, the time master transmits each

Reference Message with Next_is_Gap bit set. The input level at the

time masterâ„¢s EVT pin controls the time gap:

Figure 8: Automatic Synchronization of Cycle Time Phase
How the TTCAN network functions
When data are transmitted by TTCAN, no stations are addressed, but

instead, the content of the message (e.g. rpm or engine

temperature) is designated by an identifier that is unique

throughout the network. The identifier defines not only the content

but also the priority of the message. This is important for bus

allocation when several stations are competing for bus access.
If the CPU of a given station wishes to send a message to

one or more stations, it passes the data to be transmitted and

their identifiers to the assigned CAN chip (Make ready). This is

all the CPU has to do to initiate data exchange. The message is

constructed and transmitted by the CAN chip. As soon as the CAN

chip receives the bus allocation (Send Message) all other

stations on the CAN network become receivers of this message (

Receive Message). Each station in the CAN network, having received

the message correctly, performs an acceptance test to determine

whether the data received are relevant for that station (Select).

If the data are of significance for the station concerned they are

processed (Accept), otherwise they are ignored.
A high degree of system and configuration flexibility is

achieved as a result of the content-oriented addressing scheme. It

is very easy to add stations to the existing CAN network without

making any hardware or software modifications to the existing

stations, provided that the new stations are purely receivers.
Because the data transmission protocol does not require physical

destination addresses for the individual components, it supports

the concept of modular electronics and also permits multiple

reception (broadcast, multicast) and the synchronization of

distributed processes: measurements needed as information by

several controllers can be transmitted via the network, in such a

way that it is unnecessary for each controller to have its own

sensor.


Non-destructive bitwise arbitration
For the data to be processed in real time they must be transmitted

rapidly. This not only requires a physical data transfer path with

up to 1 Mbit/s but also calls for rapid bus allocation when several

stations wish to send messages simultaneously.
In real-time processing the urgency of messages to be exchanged

over the network can differ greatly: a rapidly changing dimension

(E.g. engine load) has to be transmitted more frequently and

therefore with less delay than other dimensions (e.g. engine

temperature) which change relatively slowly. The priority at which

a message is transmitted compared with another less urgent message
is specified by the identifier of the message concerned. The

priorities are laid down during system design in the form of

corresponding binary values and cannot be changed dynamically. The

identifier with the lowest binary number has the highest priority.

Bus access conflicts are resolved by bitwise arbitration on the

identifiers involved by each station observing the bus level bit

for bit. In accordance with thewired and mechanism, by which the

dominant state (logical 0) overwrites the recessive state (logical

1), the competition for bus allocation is lost by all those

stations with recessive transmission and dominant observation.

Alllosers automatically become receivers of the message with the

highest priority and do not reattempt transmission until the bus is

available again. The method of bitwise arbitration using the

identifier of the messages to be transmitted uniquely resolves any

collision between a number of stations wanting to transmit, and it

does this at the latest within 13 (standard format) or 33 (extended

format) bit periods for any bus access period. Unlike the message-

wise arbitration employed by the CSMA/CD method this nondestructive

method of conflict resolution ensures that no bus capacity is used

without transmitting useful information. Even in situations where

the bus is overloaded the linkage of the bus access priority to the

content of the message proves to be a beneficial system attribute

compared with existing CSMA/CD or token protocols: inspite of the

insufficient bus transport capacity, all outstanding transmission

requests are processed in order of their importance to the overall

system (as determined by the message priority).The available

transmission capacity is utilized efficiently for the transmission

of useful data since gaps in bus allocation are kept very small.

The collapse of the whole transmission system due to overload, as

can
occur with the CSMA/CD protocol, is not possible with CAN. Thus,

CAN permits implementation of fast, traffic-dependent bus access

which is non-destructive because of bitwise arbitration based on

the message priority employed.
Time Measurement in TTCAN
In TTCAN level 1, there are two time bases, the Local_Time and the

Cycle_Time. In level 2, there is additionally Global_Time. The host

application has read access to all time bases; it can store the

actual time value read at specific events, e.g. controlled by an

interrupt service routine. A hardware implementation of TTCAN

permits some features that are not possible in a software

implementation, like bus-time-based interrupts, a stop-watch

function, and the event trigger EVT.
When EVT is high at the end of a basic cycle, a time gap is

started. The Reference Message to end the time gap is triggered at

the next falling edge of EVT (see Figure 8). If the falling edge

does not occur within a specified time, the TSO itself triggers the

Reference Message when its Cycle_Time reaches Tx_Ref_Trigger_Gap.

No time gap is started when EVT is low at the end of a basic cycle;

only falling edges that occur during a time gap can trigger a

Reference Message.
Time Mark Interrupt
Local_Time, Cycle_Time, and Global_Time can be compared to a

time mark interrupt register. When the selected time value matches

the register value, an interrupt is generated. This event may

trigger the CPUâ„¢s interrupt line or may be directly connected to an

output port. The TMI output(s) can be used to synchronize the

application to the TTCANâ„¢s Cycle_Time or Global_Time.
Stop-Watch
An input port may be used to trigger the capturing of Local_Time,

Cycle_Time, or Global_Time to a stop-watch register. Once it has

been triggered, the stop-watch register remains unchanged until the

host CPU has read its contents and has enabled the next triggering.

This allows the clocking of events in a TTCAN network time base

without interrupt response time jitter and without CPU load.
Synchronization of several TTCAN Networks
Time mark interrupt, stop-watch, and event trigger can be used for

the synchronization between application and TTCAN network as well

as for the synchronization between different TTCAN networks.

Figure 9: Basic Cycle Phase Measurement
When a node is connected to more than one TTCAN network, e.g. as a

gateway node with two TTCAN controllers, it can measure the

differences in the clock speed and in the phases of Cycle_Time and

Global_Time by connecting the time mark interrupt output (TMI) of

one TTCAN controller to the stop-watch input (SWT) of the other

TTCAN controller (see Figure 9). The difference between the time

mark interrupt register in the TTCAN controller connected to TTCAN

network 1 and the stop-watch register in the TTCAN controller

connected to TTCAN network 2 shows the phase shift between the two

communication schedules.
When this TTCAN node is time master in one of the networks, it can

synchronize the two communication schedules by triggering the time

masterâ„¢s EVT input with the TMI output of the other TTCAN
Controller.

Figure10: Communication Schedule Synchronization
It is not necessary that both TTCAN networks operate with the same

basic cycle length; they may use different cycle lengths and may

operate on different CAN bit times.
A time master can adjust the networkâ„¢s clock speed by modifying its

actual TUR value. A figure 11 show an example where the node is

time master in network 2 and calibrates its clock to the same speed

as the NTU in network 1. In TTCAN level 2, the other nodes in the

same network will automatically synchronize their local clock

speeds to the time masterâ„¢s clock speed. In TTCAN level 1, there is

no automatic clock speed synchronization.

Figure 11: Clock Synchronization of TTCAN Networks
When a node is time master in one of the TTCAN networks, it can

adjust clock speed and clock phase of that network until the

synchronization with the other network is achieved. When the

gateway node is not time master, it transmits the results of the

measurements to the time master that will perform the

synchronization.
Any number of TTCAN networks that are connected by (a chain of)

gateway nodes can be synchronized that way, providing a common

Global_Time for the combined fault tolerant system
The basic cycle and its time windows
The period between two consecutive reference messages is called the

basic cycle. A basic cycle consists of several time windows of

different size and offers the necessary space for the messages to

be transmitted.

Figure “ The reference message starts the TTCAN basic cycle.
The time windows of a basic cycle can be used for periodic state

messages and for spontaneous state and event messages. Any message

that is sent has the CAN data format and is a standard CAN message.

A time window for periodic messages is called an exclusive time

window.
Within exclusive time windows the beginning of the time window

determines the sending point of a predefined message of a node. If

the system was properly specified and the off-line design tool

analyzed the communication pattern, no conflicts will happen.

However, even in the error case of a conflict, the CAN protocol

properties (bit arbitration, only sending when the bus is idle) are

valid.
The system engineer has to decide off-line which message must be

sent at which exclusive time window. To provide higher flexibility

to the system designer, an exclusive time window may be repeated

more than once within a basic cycle. The automatic retransmission

of CAN messages is not allowed in exclusive time windows.
A time window for spontaneous messages is called an arbitrating

time window. Within an arbitrating time window the bitwise

arbitration decides which message of which node in the TTCAN

network will succeed on the bus. At design time it is allowed to

schedule more than one message for an arbitrating time window.
So the application can decide at runtime if it would like to use an

arbitrating window for a message to be sent and which message

should be sent in a certain arbitrating window. The automatic

retransmission of CAN messages is also not allowed within

arbitrating time windows.

Figure - Exclusive time windows and arbitrating time windows of a

TTCAN basic cycle.
During the design phase it is also possible to reserve free time

windows for further extensions of the network. They can be changed

to arbitrating or exclusive time windows if new nodes need further

space for communication or the bandwidth has to be extended for

existing nodes.
The Reference Message
TTCAN is based on a time triggered and periodic communication which

is clocked by a time masterâ„¢s reference message. The reference

message can be easily recognized by its identifier. Within TTCANâ„¢s

level 1 the reference message only holds some control information

of one byte, the rest of a CAN message can be used for data

transfer. In extension level 2, the reference message holds

additional control information, e.g. the global time information of

the current TTCAN time master. The reference message of level 2

covers 4 bytes while downwards compatibility is guaranteed. The

remaining 4 bytes are open for data communication as well.
The System Matrix
Practice has shown that applications include many control loops and

tasks with different periods. They all need individual sending

patterns for their information.

The TTCAN basic cycle would not offer enough flexibility to satisfy

this need. The TTCAN specification allows using more than one basic

cycle to build the communication matrix or system matrix of the

systems engineerâ„¢s needs. Several basic cycles are connected to

build the matrix cycle. Most patterns are possible, e.g. sending

every basic cycle, sending every second basic cycle, or sending

only once within the whole system matrix.TTCAN specification allows

also another useful exception. The system matrix is highly column

oriented. It may make sense to ignore the columns in the case of

two or more arbitrating time windows in series.
The most important constraint for this construct is that the

starting point of a spontaneous message within this merged

arbitrating window is not allowed if it will not fit in the

remaining time window. The start of the next periodic time window

must be guaranteed. This is the task of an off-line design tool

used to build TTCAN system matrices. The automatic retransmission

within a merged arbitrating time window is allowed as long as the

constraint already described above is satisfied.
Future
After the ISO had submitted their TTCAN standard proposal for

international standardization the first few manufacturers started

implementing the TTCAN protocol. Bosch had already implemented it

in an FPGA successfully and presented it at a TTCAN workshop of the

CAN in Automation (CiA) international users and manufacturers

group. Due to market responses Bosch has by now implemented the

TTCAN module in a chip.
The TTCAN stand-alone chip with integrated TTCAN level 1 and level

2 (with time correction) is pin-compatible to the company's CAN

controller CC170 and Intel's 82527. It is available for the

evaluation of TTCAN interfaces and for the development of TTCAN-

compatible control units and software tools (e.g. bus analyzers and

configurations). The controller provides different interfaces to

host controllers by Intel and Motorola. Samples have been available

since July 2003.
Basically all CAN controllers that support single-shot mode or are

able to support the cancellation of a transmission request are able

to support level 1 of TTCAN in software. For level 2 they

additionally require the ability to time-stamp the Start of Frame-

bit and send the time-stamp within the very same frame. For reasons

of performance enhancement it makes sense to realize the protocol

functions in hardware.
First CAN controllers with partial TTCAN support have been

announced by Atmel. The 8-bit T89C51CC01/2 provides 15 message

objects that are adjustable via filter masks. The message objects

may optionally be transformed to a FIFO, which prevents the erasure

of received but not yet processed data.
The NEC CAN micro-controller family has provided the hardware

requirements for TTCAN since the mid-nineties with the patented

SOF-synchronization, which is necessary to implement TTCAN. The

company is still working on a hardware version of a standalone

TTCAN module.
Hitachi has implemented the protocol in a chip, which is being

tested by an independent institute for conformity to the standard.
CiA members are currently working on extending the CAN open

standard in order to enable the usage of TTCAN hardware within CAN

open networks. This entails the definition of a further

transmission mode for PDOs and a new communication object (TREF).

The CAN open extensions are due for publication with the official

release of the TTCAN standard.
Conclusion
TTCAN is based on the most successful automotive control network to

date. It appends a set of new features to the existing CAN protocol

through the introduction of a session layer protocol onto the CAN

protocol stack. The original CAN protocol may exhibit performance

limitations in certain hard real-time applications. The time-

triggered solution provided by TTCAN offers improved reliability,

determinism, and synchronization quality for current and future

hard real-time distributed applications. Many semiconductor

manufacturers have recognized the benefits and potential market for

TTCAN, and are currently working on their TTCAN compliant devices.

TTCAN promises to offer design engineers a new robust solution to

hard real-time distributed applications.
References
1. http://can-cia.de
2. http://tttech.com
3. http://can.bosch.com
4. http://ttcan.com
5. http://can.com
6. http://bosch-semiconductors.de


CONTENTS
Abstract
Introduction
Controller Area Network (CAN), an overview
TTCAN Definition
CAN Vs TTCAN
TTCAN Controller Module
Time Bases of the TTCAN Protocol
How the TTCAN network functions
Time Measurement in TTCAN
Synchronization of several TTCAN Networks
The basic cycle and its time windows
The Reference Message
The System Matrix
Future
Conclusion