13-08-2014, 04:35 PM
SEMINAR REPORT ON TTCAN
TTCAN.docx (Size: 28.98 KB / Downloads: 19)
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.
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.
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).
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.
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.
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.
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