If the reader is unfamiliar with the CAN protocol itself please refer to the CAN description page.
Event-triggered and time-triggered communication
In control networks, communications protocols can be divided into two fundamentally different principles of message transfer. These are, synchronous (time-triggered) and asynchronous (event-triggered) models. In an event-triggered system communication transactions are triggered by the occurrence of some external events, such as the pressing of a button or the firing of a fuel injector. This type of communication is essentially sporadic in nature where, for real-time operation, the message release period is quantified between worst-case and best-case time scenarios.
In a time-triggered system, however, message transactions are initiated based on the progression of time. Using such a principle each node member of the network is assigned a time when it may transfer a message on the network. Such a model is similar to a TDMA (Time Division Multiple Access) scheme with each node respecting the sense of global time which exists in the network ensemble. Each node possesses a local clock and a message transaction schedule which dictates when it may transmit and when it may expect to receive a particular message, as illustrated in Figure 1.
Figure 1. A generic time-triggered network
Here we present an overview of the new Time-Triggered CAN (TTCAN) protocol
Overview of TTCAN
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 recognised by all nodes participating in the TTCAN network by virtue of its CAN frame identifier. Each node synchronises 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.
Matrix Cycle
The network communications pattern may be mapped to a matrix structure as illustrated in Figure 2. The system matrix correlates the message transactions and the time windows in which they occur. The matrix is composed of Basic Cycles (rows of the matrix) and Transmission Columns (columns of the matrix). Each Basic Cycle commences with the occurrence of a Reference message, and has a duration equal to the interval between Reference messages. The complete matrix, consisting of all the Basic Cycles, is known as the Matrix Cycle. The Matrix Cycle describes the message transaction schedule, which is continuously repeated.
Figure 2. Matrix Cycle
A value Cycle_Count, which is transmitted in the Reference message, and observed by all network members, indexes the current Basic Cycles of the Matrix Cycle.
All time windows comprising a Transmission Column are equal in length. The progression of elapsed time in the interval between Reference messages is measured in Cycle_Time. The node which transmits the Reference message at the start of a Matrix Cycle acts as the network Time Master as it determines the points in time to which all other message transactions are referenced. The Time Masters view of time is referred to as the network's Global Time and all nodes try to adhere to this sense of time.
Message transactions may only occur within the boundaries of the time windows.
A Matrix Cycle is composed of time windows. The of time windows of the transmission are all of the same length (equal in the time domain) but may be of different type and contain different messages (i.e. differ in the data domain). There are three basic types of time windows:
- Free time windows
- Arbitrating time windows
- Exclusive time windows
Free Time windows
Free time windows are intervals in time where the bus is scheduled to be idle. No message transactions are scheduled to occur during these intervals, which are included to allow for future system expansion.
Tx_Enable window
Within an Exclusive or Arbitrating time window, the transmission of a message may only commence during an interval known as the Tx_Enable window, illustrated in Figure 3. If the bus is not idle during this initial phase of the time window, then the message will fail to be transmitted. This requirement is necessary to ensure that messages may not be released so late in a time window as to excessively delay the release of the subsequent message in the next time window.
Figure 3. Tx_Enable window
Arbitrating time windows
A set of messages from a number of different nodes may be assigned 'permission' to be transmitted within the same Arbitrating time window. Message collisions are resolved using CAN's native bitwise arbitration process. Several nodes may attempt to transmit during the Tx_Enable phase of an arbitrating time window. The automatic retransmit function of CAN is disabled and hence messages, which loose arbitration, may not re-try. The only exception to this rule exists in the case of merged arbitrating windows.
Merged Arbitrating time windows
Arbitrating time windows which are consecutive in a Basic Cycle may be merged to form a single large Merged Arbitrating time window. In this case the Tx_Enable trigger extends through the full length of the first Arbitrating time window and ends at the end of the last Arbitrating time window's Tx_Enable window. Retransmission of a message is allowed provided it commences within the Tx_Enable window and will complete before the end of the final Arbitrating time window, (see Figure 3).
Exclusive time windows
Only one message from a specific network node may be transmitted during an Exclusive time window. During this window there is no competition for the medium, as the window has been assigned to a single node which may exclusively use the medium to transmit its message during this time.
Network Time Unit
All Time Marks or instances in time with respect to network transactions are counted in Network Time Units (NTU). The nominal NTU value is the theoretical length in time of an NTU. The NTU length may be equal in duration to a CAN bit time in a Level 1 TTCAN implementation or may be related to a fraction of the physical second in a Level 2 TTCAN implementation. The Level 1 and Level 2 concept will be discussed later in the text.
Cycle Time
The reception of a CAN frame generates a Frame_Synchronisation pulse at the sampling point of the SOF bit, see Figure 4. This pulse is synchronous within the whole network if one neglects delays due to signal propagation time. At the occurrence of the Frame_Synchronisation pulse a nodes Local time is saved as Sync_Mark. When the Frame_Synchronisation pulse has been generated by a valid Reference message the current value of Sync_Mark is saved as Ref_Mark. A node's view of Cycle_Time is the difference between its Local time and Ref_Mark. Local time is reset (conceptually) at the occurrence of the Reference message SOF bit.
Figure 4. Cycle Time and Local Time
Sending and receiving messages
Message transmissions by a node are initiated by a Tx_Trigger entity which is a register set holding the necessary information relating to when a specified message is to be transmitted. A Tx_Trigger has four component data entities:
1. A pointer to a specific single message
2. The Transmission Column in which the message is to be transmitted
3. The Basic Cycle in which the message is to be first transmitted (Cycle_Count)
4. A Repeat Factor which determines at which position in the specified Transmission Column the message is transmitted again, provided it is repeated again, otherwise the Repeat Factor is not active
The reception of messages is verified in the TTCAN through the use of Rx_Triggers. These are register sets similar to Tx_Triggers, which store information relating to the expected arrival time of a specific message.
Message Status Counters
The Message Status Counters (MSC) registers provide an additional means of error detection during time triggered operation. Each MSC register is assigned to a specific message, which is either transmitted or received. Communications failure for this specific message results in the incrementing of the MSC, while correct communication will decrement the MSC. When the difference between any two MSCs is greater than 2 or when an MSC reaches 7, an error is flagged.
Time triggered and event synchronised operation
In a strictly time-triggered TTCAN communications network the Reference message is transmitted periodically in equidistant time windows. Once the Matrix Cycle has completed it simply starts again and repeats. However, TTCAN allows Basic Cycles to synchronise to the occurrence of an event in a Time Master. This procedure starts with the current Time Master transmitting a Next_is_Gap bit in the Reference message. The current Basic Cycle then takes place as normal and then a time interval with no network activity follows. The Matrix Cycle is effectively suspended. Network activity is resumed when a Time Master transmits a Reference message thus announcing the start of the next Basic Cycle. Figure 5 illustrates the principle. The idle interval between the stop of a Basic Cycle and the start of the next is referred to as a Gap Time, denoted t1 and t2 in Figure 5.
Figure 5. Time Triggered and Event Synchronised Operation
If the actual Time Master has failed during this gap interval then the gap will be terminated by a Reference massage from a potential time master. This mechanism is realised through the uses of a Watch_Trigger time-out monitoring for excessively long Gap Times
Level 1 and Level 2 TTCAN implementations
The TTCAN protocol provides two possible levels of synchronisation quality Level 1 and Level 2. In Level 1 the synchronisation tolerance is greater than in Level 2. Furthermore the NTU in Level 1 is equal in duration to a nominal CAN bit time and may be derived directly from the CAN protocol engine. However, in Level 2 the duration of an NTU is a predefined fraction of the physical second. Fig.6 provides some insight into Level 2 synchronisation mechanisms. With reference to the left-hand portion of Fig.6 , the line labelled C represents the ratio of oscillator periods to NTU ticks in the master node. This ratio is referred to as the Time Unit Ratio (TUR). NTU clocks in other nodes may run faster (line A) or slower (line E) than master node's clock, mainly due to the effects of oscillator drift. Local adjustment of the TUR for these clocks restores the time velocity consistency between nodes. Also illustrated on the left-hand portion of Fig.6 is the potential for phase differences between distributed clocks (lines B and D). Using a local offset register compensates for this potential error source. The right hand side of Fig.6 illustrates a conceptual implementation of these synchronisation mechanisms. Another feature of a Level 2 implementation is the ability to synchronise the TTCAN network to an external time reference such as that available from a GPS system. This feature helps in the realisation of complex tightly coupled applications distributed over multiple networks.
Figure 6. Time Unit Ratio and Local Offset
Fault tolerance of Time Master
All time-triggered communications on a TTCAN network are referenced to the occurrence of a Reference Message, which is released by the current Time Master of the network. Thus the protocol ensures the fault tolerant function of the Time Master. In the event of the Time Master failing another potential Time Master performs its synchronisation function by transmitting a Reference message. Any one of 8 nodes in a TTCAN network can act as a potential Time Master.