Time-triggered CAN

The TTCAN (time-triggered CAN) protocol (standardized in ISO 11898-4) 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.

TTCAN benefits

TTCAN provides mechanisms to schedule CAN messages in a time-triggered way as well as in an event-triggered way. This allows using CAN-based networks for closed-loop control. Also the real-time performance in CAN-based in-vehicle networks increases with the use of TTCAN.
In vehicles data traffic must usually be both event-triggered (e.g. a temperature change in the cooling mechanism) and time-triggered (e.g. the status of the brakes). In order not to have to develop two different network systems the ISO defined the TTCAN protocol.

Basic TTCAN functionality

The TTCAN protocol is realized in software in a higher layer on top of CAN. This is why in a TTCAN network messages can be transmitted both event-triggered as well as time-triggered. The transmitted frames do not need any additional overhead in the CAN frame. The time-triggered control and thus the synchronization of the involved control units within the network are done via a reference message. All participants of the TTCAN network identify the reference message by its identifier. As soon as the first bit of the frame (Start of Frame: SOF) is recognized, the local time unit is synchronized. The accuracy of the local time units depend only on the physical signal propagation of the bus line and is thus neglectable. The individual TTCAN participants are configured to know when to send their frames after having received the reference frame.
The time between two reference frames is called the basic cycle. Basic cycles are not always identical in order to be able to transmit messages at different periodic frequencies. The system matrix comprises several basic cycles and is repeated indefinitely until the vehicle is turned off.
For some applications it is necessary that the reference frame is sent corresponding to an event. For these cases a bit is inserted in the basic cycle, which discontinues the periodic transmission of messages until the event has taken place. This is done e.g. to synchronize communication and motor rotation.

Within a basic cycle there are exclusive windows, during which only one node may send a frame. Apart from that there are free windows and arbitrating windows, for which the nodes compete for bus access just as in the regular CAN communication. Several arbitrating windows can be merged (merged windows). The end of an arbitrating window is always predictable. Thus the advantages of event-triggered communication can be combined with those of time-triggered communication.
This is especially interesting for off-highway vehicles such as forestry vehicles or forklifts.

These vehicles often use the higher-layer protocol CANopen. Therefore there are intentions of implementing TTCAN-specific objects in the CANopen standard. Also a specific TTCAN transmit mode for process data objects (PDO) is planned. CANopen networks are also used for separate vehicle add-ons such as fire fighting equipment, cranes and add-on devices for municipal vehicles.
The sending of CAN frames in TTCAN (level 1) between two reference frames is triggered by the local time units. Since there may be minimum time differences despite the initial synchronization, a system designer may implement a level 2 TTCAN network. In level 2 TTCAN a reference frame includes a time-stamp (Master_Ref_Mark). This means that after at least two times receiving of the reference frame the nodes can resynchronize according to the time-stamp. Thus a synchronization accuracy of 1 µs is achievable. This should suffice even for high requirements of vehicle builders.

Should the sender of the reference frame fail, another node automatically takes over the task of sending it. Up to eight potential time givers are installable. In case a higher-ranking time master has been replaced by a lower-ranking time master but returns to the network, it automatically tries to become time master again. The TTCAN specifications provide the procedure of the return/take over of a time master.

If the time stamp is provided by an external clock (e.g. GPS), the time is given as part of a second. An internal time base in regular operation depends of the bit rate of the CAN network. With an external time base even several TTCAN networks of other systems may be synchronized with a TTCAN network.

The TTCAN protocol also defines an error level state machine as well as several error modes. The ISO 11898-4 also defines all "visible" interfaces. Scheduling tables are locally implemented in every node and must be configured before system start-up.

TTCAN implementations

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 configurators). 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 microcontroller 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 CANopen standard in order to enable the usage of TTCAN hardware within CANopen networks. This entails the definition of a further transmission mode for PDOs and a new communication object (TREF). The CANopen extensions are due for publication with the official release of the TTCAN standard.

Further literature on TTCAN