TTCAN - Time Triggered Controller Area Network

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. 

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. 

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 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 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.

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

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

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.

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. 

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.

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.

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.

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.

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.

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.

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:

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 the”wired 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. All”losers” 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.

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. 

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.