Upload
irshad-ahmed
View
217
Download
0
Embed Size (px)
Citation preview
8/4/2019 D G Seminar Ultimate
1/42
Seminar Report 2006 - 1 - TTCAN
Seminar on
TTCAN
Time TriggeredController Area Network[TTCAN]
SUBMITTED BY
Dhanya Govindan
S7-ECEROLL NO 11
DEPT OF ELECTRONICS AND COMMUNICATIONVIMAL JYOTHI ENGINEERING COLLEGE
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
2/42
Seminar Report 2006 - 2 - TTCAN
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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
3/42
Seminar Report 2006 - 3 - 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 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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
4/42
Seminar Report 2006 - 4 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
5/42
Seminar Report 2006 - 5 - TTCAN
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 anexternal 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 CANs non-destructive bitwise arbitration mechanism
and by CANs 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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
6/42
Seminar Report 2006 - 6 - TTCAN
A TTCAN controller can be seen as an existing CAN controller
(e.g. Boschs C_CAN module) enhanced with a Frame
Synchronization Entity FSE and with a trigger memory containing
the nodes 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 customers wish for better safety and greater comfort
and partly of the governments 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
7/42
Seminar Report 2006 - 7 - TTCAN
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 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 iscomparable to a printer or a type writer. CAN users still have to
define the language/grammar and the words/vocabulary for
communication.
CAN provides
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
8/42
Seminar Report 2006 - 8 - TTCAN
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 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
9/42
Seminar Report 2006 - 9 - 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 thecommunication 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 CANs nondestructive bitwise arbitration
mechanism and by CANs 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.
Boschs C_CAN module) enhanced with a Frame Synchronization
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
10/42
Seminar Report 2006 - 10 - TTCAN
Entity FSE and with a trigger memory containing the nodes view of
the system matrix (see Figure 1).
The TTCAN test chip (TTCAN_TC) is a standalone TTCANcontroller 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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
11/42
Seminar Report 2006 - 11 - TTCAN
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 thedevelopment 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
12/42
Seminar Report 2006 - 12 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
13/42
Seminar Report 2006 - 13 - TTCAN
Figure: Block Diagram of the TT_CAN
Figure: Frame Synchronization Entity
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
14/42
Seminar Report 2006 - 14 - TTCAN
Time Base Builder generates the local time from the nodes
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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
15/42
Seminar Report 2006 - 15 - TTCAN
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 FSEs 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
nodes 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 nodes 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,
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
16/42
Seminar Report 2006 - 16 - TTCAN
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 thelocal 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 nodes 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
17/42
Seminar Report 2006 - 17 - TTCAN
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 localsystem 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
18/42
Seminar Report 2006 - 18 - TTCAN
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 ReferenceMessage 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 nodes 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 messages 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
19/42
Seminar Report 2006 - 19 - TTCAN
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 nodes 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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
20/42
Seminar Report 2006 - 20 - TTCAN
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
nodes TU and the actual time masters 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:
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
21/42
Seminar Report 2006 - 21 - TTCAN
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 systems requirement; a plausibility check for thevalue 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
networks 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
22/42
Seminar Report 2006 - 22 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
23/42
Seminar Report 2006 - 23 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
24/42
Seminar Report 2006 - 24 - TTCAN
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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
25/42
Seminar Report 2006 - 25 - TTCAN
Figure 7 shows an example how the host application of the
time master can synchronize the TTCAN networks 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 basiccycle 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 masters EVT pin controls the
time gap:
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
26/42
Seminar Report 2006 - 26 - TTCAN
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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
27/42
Seminar Report 2006 - 27 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
28/42
Seminar Report 2006 - 28 - TTCAN
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. Thepriorities 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),
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
29/42
Seminar Report 2006 - 29 - TTCAN
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 availableagain.The method of bitwise arbitration using the identifier of themessages 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
30/42
Seminar Report 2006 - 30 - TTCAN
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-watchfunction, 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 CPUs interrupt line or may be directly connected to
an output port. The TMI output(s) can be used to synchronize the
application to the TTCANs 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
31/42
Seminar Report 2006 - 31 - TTCAN
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 measurethe 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
32/42
Seminar Report 2006 - 32 - 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 masters 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 networks 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 masters clock speed. In TTCAN level 1,
there is no automatic clock speed synchronization.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
33/42
Seminar Report 2006 - 33 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
34/42
Seminar Report 2006 - 34 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
35/42
Seminar Report 2006 - 35 - TTCAN
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 allowedto 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 masters reference
message. The reference message can be easily recognized by its
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
36/42
Seminar Report 2006 - 36 - TTCAN
identifier. Within TTCANs 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 timeinformation 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
37/42
Seminar Report 2006 - 37 - TTCAN
of the systems engineers 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 allowsalso 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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
38/42
Seminar Report 2006 - 38 - TTCAN
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 implementedthe 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
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
39/42
Seminar Report 2006 - 39 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
40/42
Seminar Report 2006 - 40 - TTCAN
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.
Dept of Electronics & Communication VJEC, Chemperi
8/4/2019 D G Seminar Ultimate
41/42
Seminar Report 2006 - 41 - TTCAN
References
1. http://www.can-cia.de
2. http://www.tttech.com
3. http://www.can.bosch.com
4. http://www.ttcan.com
5. http://www.can.com
6. http://www.bosch-semiconductors.de
Dept of Electronics & Communication VJEC, Chemperi
http://www.can.bosch.com/http://www.ttcan.com/http://www.can.bosch.com/http://www.ttcan.com/8/4/2019 D G Seminar Ultimate
42/42
Seminar Report 2006 - 42 - TTCAN