Time-Triggered Protocol

The Time-Triggered Protocol (TTP) is an open computer network protocol for control systems. It was designed as a time-triggered fieldbus for vehicles and industrial applications.[1]

History

TTP was originally designed at the Vienna University of Technology in the early 1980s. In 1998 TTTech Computertechnik AG took over the development of TTP, providing software and hardware products. TTP communication controller chips and IP are available from sources including austriamicrosystems, ON Semiconductor and ALTERA.

Definition

TTP is a dual-channel 25 Mbit/s time-triggered field bus. It can operate using one or both channels with maximum data rate of 2x 25 Mbit/s. With replicated data on both channels, redundant communication is supported.

As a fault-tolerant time-triggered protocol, TTP provides autonomous fault-tolerant message transport at known times and with minimal jitter by employing a TDMA (Time-Division Multiple Access) strategy on replicated communication channels. TTP offers fault-tolerant clock synchronization that establishes the global time base without relying on a central time server.

TTP provides a membership service to inform every correct node about the consistency of data transmission. This mechanism can be viewed as a distributed acknowledgment service that informs the application promptly if an error in the communication system has occurred. If state consistency is lost, the application is notified immediately.

Additionally, TTP includes the service of clique avoidance to detect faults outside the fault hypothesis, which cannot be tolerated at the protocol level.

Critical Applications

TTP is often used in mission critical data communication applications where deterministic operation is a requirement. These operations include aircraft engine management and other aerospace applications. In these applications the TTP networks are often operated as separate networks with separate AS8202NF hardware interface devices and separate, but coordinated, configurations.

The TTP protocol offers the unique feature of having all nodes on a network know, at the same time, when any other node fails to communicate or sends unreliable data. The status of each node is updated to all nodes several times each second.

Technical details

Data communication in TTP is organized in TDMA rounds. A TDMA round is divided into slots. Each node has one sending slot, and must send frames in every round. The frame size allocated to a node can vary from 2 to 240 bytes in length, each frame usually carrying several messages. The cluster cycle is a recurring sequence of TDMA rounds; in different rounds different messages can be transmitted in the frames, but in each cluster cycle the complete set of state messages is repeated. The data is protected by a 24-bit CRC (Cyclic Redundancy Check). The schedule is stored in the MEDL (Message Descriptor List) within the communication controller.

SLOT

There is one (1) slot for each node in a TTP network. A node always transmits data (parameters) during its slot, even if the node has no data to send. However a node will only transmit the parameters that it is configured to send for the specific ROUND that the slot is in. A node may transmit parameters 1,2,3 in its SLOT during ROUND x and parameters 4,5,6 in its SLOT during ROUND y.

The slot for a node is determined when the TTP network is designed using PC based utilities TTP Plan and TTP Build. The definition that causes the AS8202NF to transmit specific data or parameters for a given SLOT and ROUND is contained in the MEDL.

ROUND

The TTP Round holds a slot for each node in the TTP network. The number of ROUNDS in CLUSTER CYCLE is defined using PC based utilities TTP Plan and TTP Build. This information is also contained in the MEDL.

Rounds exist because a node is not required to transmit all of its parameters during its slot. To distribute bandwidth between nodes, each node transmits selected parameters in different ROUNDS.

Cluster cycle

A Cluster Cycle is defined as having a number of Rounds. All nodes have transmitted all of their parameters at the end of a Cluster Cycle. The Cluster Cycle is defined as starting with the first bit of the first slot of the first round.

Balance Nodes, Slots and Cluster Cycles

The number of slots is defined by the number of nodes in the TTP network. However, the number of Rounds is determined by the network designer using the TTP Plan and TTP Build utilities.

Clock synchronization

Clock synchronization provides all nodes with an equivalent time concept. Each node measures the difference between the a priori known expected and the observed arrival time of a correct message to learn about the difference between the sender’s clock and the receiver’s clock. A fault-tolerant average algorithm needs this information to periodically calculate a correction term for the local clock so that the clock is kept in synchrony with all other clocks of the cluster.

Membership and acknowledgment

Time-Triggered Protocol attempts to transmit data consistently to all correct nodes of the distributed system and, in case of a failure, the communication system attempts to decide which node is faulty. These properties are achieved by the membership protocol and an acknowledgment mechanism.

Configuration Requirements

Each node connected to a TTP network is required to have configuration data sets resident, prior to the startup of the TTP network. The minimum number of data sets for each node is two (2). See hardware section and AS8202NF (below). Each node needs to know the configuration of every other node on the TTP network. For this reason, active nodes are not allowed to join an existing network without the update of configuration data sets of all nodes on the network.

Typical Configuration Data Sets for each node:

  1. TASM for AS8202NF (allows usage of MEDL)
  2. MEDL or Message Descriptor List for AS8202NF (defines data to be exchanged between all nodes)
  3. Compute Platform Configuration. (defines expected data and its utilization)

Data sets TASM and MEDL are created by utilities TTP Plan and TTP Build provided by TTTech. The third data set is often created by the customer and is platform and application specific.

Hardware

Interface to a TTP network requires the use of the AS8202NF device.[2] This device operates between the computer platform and the TTP network. The AS8202NF is required to be loaded with a TASM (TTP Assembler) and MEDL (Message Descriptor List) configuration data sets prior to operation.

The AS8202NF will communicate on one (1) or two (2) TTP networks.

It is not possible to design and implement a TTP network by simply buying the AS8202NF device. Each design requires license and data sets from TTTech.

Commercial applications

TTP has been integrated into a number of commercial applications.

Thales Rail Signalling Solutions

The electronic interlocking system “LockTrac 6131 ELEKTRA” was designed within a cooperation of Thales Rail Signalling Solutions division and TTTech.

LockTrac 6131 ELEKTRA is an electronic interlocking system that provides the highest levels of safety and availability. The system is approved according to CENELEC standards with safety integrity level 4 (SIL4) and offers basic interlocking functions, local and remote control, automatic train operation, integrated block functionality and an integrated diagnosis system. LockTrac 6131 has two software channels with diverse software, to ensure the high safety requirements. Before getting transmitted externally, the data are checked in the safety channel. A diagnosis device saves all relevant information to allow efficient maintenance in case of failure.

FADEC

The system has been used for FADEC (Full Authority Digital Engine Control) systems. 1475456456456 The Modular Aerospace Control (MAC)-based FADEC for The Aermacchi M346 is scalable, adaptable and fault-tolerant. The key technology enabler in this new FADEC is the use of TTP for inter-module communication. TTP removes the complex interdependencies among modules, simplifying initial application development as well in-service changes and upgrades. It allows all modules in a system to see all data all of the time, thus ensuring seamless fault accommodation without complex channel change logic.

TTP-based Modular Aerospace Control (MAC), which is a part of the F110 full authority digital engine control (FADEC) system of General Electric, is integrated on the Lockheed Martin F-16 fighter aircraft. TTP, which is used as a backplane bus, supports high levels of engine safety, operational availability and reduced life cycle cost. A significant advantage is that all information on the bus is available to both FADEC channels simultaneously.

Environmental systems

For the Airbus A380 TTTech developed the internal communication system for the cabin pressure control system, working together with Nord-Micro, a subsidiary of Hamilton Sundstrand Corporation.

In cooperation with Hamilton Sundstrand Corporation, TTTech developed a TTP-based data communication platform for the electric and environmental control system of the Boeing 787 Dreamliner. The TTP-designed communication platform prevents an overload in the bus system, even if several important events occur simultaneously. Additionally, TTP-based systems weigh less than conventional systems due to a lower connecter count and less wiring. Furthermore, the whole system is more flexible and has a greater modularity than conventional communication systems.

Controversy

In 2004, Joseph Mangan, a former employee of TTTech, created controversy surrounding TTTech's products on the Airbus A380 by asserting that there was danger that microprocessors in the plane could result in sudden decompression.[3] According to EADS, all parties have ensured through the most varied control channels that there is no safety deficit with regards to the scenario as described by Mangan.[4]

Autonomous vehicles

The two Red Team robotic vehicles competing in the 2005 DARPA Grand Challenge were implemented with "drive-by-wire" technology, in which on-board computers controlled steering, braking and other movements. Three TTP-based TTC 200 units controlled the parking brake and throttle and transmission functions, and one TTP-By-Wire Box controlled the service brake of the H1 Hummer H1ghlander. Drive-by-wire modifications controlled the acceleration, braking and shifting of the Sandstorm.

See also

References

  1. ↑ Kopetz, Herman; Grunsteidl, Gunter (1993-06-22 - 1993-06-24), "TTP - A time-triggered protocol for fault-tolerant real-timesystems", FTCS-23. The Twenty-Third International Symposium on Fault-Tolerant Computing, Digest of Papers, Toulouse, France: IEEE, pp. 524–533, doi:10.1109/FTCS.1993.627355, 0-8186-3680-7 Check date values in: |date= (help)
  2. ↑ http://www.ams.com/eng/Products/Sensor-Interfaces/Industrial-Bus/AS8202NF
  3. ↑ Peter Pae (27 Sep 2005). "A Skeptic Under Pressure". Los Angeles Times. Retrieved 25 Jul 2013.
  4. ↑ "Statement Regarding Claims". EADS. 5 October 2005. Archived from the original on 6 May 2007. Retrieved 2008-04-04.

External links

This article is issued from Wikipedia - version of the Wednesday, March 30, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.