Image Processing Reference
In-Depth Information
The TTCAN protocol is conceptually placed above the unchanged CAN. It allows time-triggered
exchanges to take place in a (quasi-)conventional CAN network. It is worth noting that because
TTCAN relies directly on CAN (they adopt the same frame format and the same transmission pro-
tocol), it suffers from the same performance limitations as the underlying technology. In particular,
is it is not practically feasible to increase the transmission speed above Mbps, and the same draw-
backs concerning the limited network extension still hold. However, because of the time-triggered
paradigm it relies on, TTCAN is able to ensure strictly deterministic communications, which means
that, for example, it is suitable for the first generation of drive-by-wire automotive systems—which
are provided with hydraulic/mechanical backups. TTCAN will be likely unsuitable for the next gen-
eration steer-by-wire applications. In those cases, in fact, requirements on both fault tolerance and
available bandwidth are noticeably more severe.
15.5.2 Protocol Specification
Unlike new-generation automotive protocols (e.g., FlexRay [FR]), which rely on distributed syn-
chronization mechanisms, TTCAN is based on a centralized approach, where a special node called
thetimemaster(TM)keepsthewholenetworksynchronizedbyregularlybroadcastingaref-
erence message (RM), usually implemented as a high-priority CAN message. Redundant TMs
canbeenvisagedsoastoprovideincreasedreliability.Inparticular,uptoeightpotentialTMs
canbedeployedinaTTCANnetwork.Atanytimeonlyonenodeisallowedtobetheactual
(current) TM, whereas the others behave as backup TMs. The procedure for (re-)electing the cur-
rent TM operates in a completely dynamic fashion, and ensures that a faulty master is replaced
on-the-fly.
Transmission of data is organized as a sequence of basic cycles (BCs). Each BC begins with the
RM, which is followed by a fixed number of time windows that are configured off-line and can be of
the following three types:
•
Exclusive windows
: Each exclusive window is statically reserved to one predefined mes-
sage,sothatcollisionscannotoccur;theyareusedforsafety-criticaldatathathavetobe
sent deterministically and with no jitters.
•
Arbitration windows
: Such a kind of windows are not preallocated to any given message,
thus different messages may be potentially competing for transmission; in this case, any
possible collision that might occur is solved thanks to the nondestructive CAN arbitration
scheme.
•
Free windows
: hey are reserved for future expansions of TTCAN systems.
The beginning of each time window corresponds to a time trigger defined in one (or more) produc-
ing nodes. So that the boundaries of time windows are never exceeded, TTCAN controllers should
disable the automatic retransmission feature of CAN (which would send a message again, when-
ever the contention is lost or transmission errors are detected) by default. he only exception occurs
when there are several adjacent arbitrating windows. In this case, they can be merged together so as
to provide a single, larger window, which can accommodate a number of asynchronously generated
messages in a more flexible way. he only constraint is that, transmission in such merged arbitrating
windows is only allowed if the message can be sent completely in the time that is left before the end
of the window.
Despite it seamlessly mixes both synchronous and asynchronous messages (in exclusive and arbi-
trating windows, respectively), TTCAN is indeed very dependable: in fact, besides the intrinsically
deterministic time-driven access to the shared communication support, should there be a temporary
lack of synchronization and more than one node tries to transmit in the same exclusive window, the
arbitratingschemeofCANisusedtosolvethecollision.
