TTEthernet

(Redirected from TTTech)

The Time-Triggered Ethernet (SAE AS6802) (also known as TTEthernet or TTE) standard defines a fault-tolerant synchronization strategy for building and maintaining synchronized time in Ethernet networks, and outlines mechanisms required for synchronous time-triggered packet switching for critical integrated applications and integrated modular avionics (IMA) architectures. SAE International released SAE AS6802 in November 2011.

Time-Triggered Ethernet network devices are Ethernet devices which at least implement:

  • SAE AS6802 synchronization services for advanced integrated architectures, fail-operational and safety-critical systems
  • time-triggered traffic flow control with traffic scheduling
  • per-flow policing of packet timing for time-triggered traffic
  • robust internal architecture with traffic partitioning

TTEthernet network devices are standard Ethernet devices with additional capability to configure and establish robust synchronization, synchronous packet switching, traffic scheduling and bandwidth partitioning, as described in SAE AS6802. If no time-triggered traffic capability is configured or used, it operates as full duplex switched Ethernet devices compliant with IEEE802.3 and IEEE802.1 standards.

In addition, such network devices implement other deterministic traffic classes to enable mixed-criticality Ethernet networking. Therefore, TTEthernet networks are designed to host different Ethernet traffic classes without interference.

TTEthernet device implementation expands standard Ethernet with services to meet time-critical, deterministic or safety-relevant requirements in double- and triple-redundant configurations for advanced integrated systems. TTEthernet switching devices are used for integrated systems and safety-related applications primarily in the aerospace, industrial controls and automotive[1] applications.

TTEthernet has been selected by NASA and ESA as the technology for communications between the Orion MPCV and the European Service Module, and is described by the ESA as being "prime choice for future launchers allowing them to deploy distributed modular avionics concepts".[2] It has also been selected as the backbone network for NASA's Lunar Gateway[3] to which ESA is a key stakeholder.

As an increasingly used network architecture in the space industry, European Cooperation for Space Standardization published ECSS-E-ST-50-16C on September 30, 2021.[4]

Description

edit

TTEthernet network devices implement OSI Layer 2 services, and therefore it claims to be compatible with IEEE 802.3 standards and coexist with other Ethernet networks and services or traffic classes, such as IEEE 802.1Q, on the same device. Three traffic classes and message types are provided in current TTEthernet switch implementations:[5]

  • Synchronization Traffic (Protocol Control Frames - PCF): Time-Triggered Ethernet network uses protocol control frames (PCFs) to establish and maintain synchronization. The PCFs traffic has the highest priority and it is similar to rate-constrained traffic. PCF traffic establishes a well-defined interface for fault-tolerant clock synchronization algorithms.
  • Time-triggered traffic: Ethernet packets are sent over the network at predefined (scheduled) times and take precedence over all other traffic types. The occurrence, temporal delay and precision of time-triggered messages are predefined and guaranteed. Also, "synchronized local clocks are the fundamental prerequisite for time-triggered communication".[6][note 1]
  • Rate-constrained traffic: Ethernet packets are configured so that they can keep maximum latency and jitter in a closed system. They are used for applications with less stringent determinism and real-time requirements. This traffic class guarantees that bandwidth is predefined for each application and delays and temporal deviations have defined upper bounds.
  • Best-effort traffic (incl. VLAN traffic): Packets are sent via FIFO queues to egress ports. There is no absolute guarantee whether and when these messages can be transmitted, what delays occur and if messages arrive at the recipient. Best-effort messages use the remaining bandwidth of the network and have lower priority than the other two types.
 
Three Message Types / L2 Traffic Classes

Three traffic classes cover different types of determinism - from soft-time best-effort traffic to "more deterministic" to "very deterministic" (max.latency defined per VL) to "strictly deterministic" (fixed latency, μs-jitter), thus creating a deterministic unified Ethernet networking technology. While standard full duplex switched Ethernet is typically best effort or more deterministic, time-triggered traffic is bound only to the system time progression and traffic scheduling, and not to priorities. It can be considered the highest priority traffic, above the highest priority 802.1Q VLAN traffic.

Fault-tolerance

edit

TTEthernet (i.e. Ethernet switch with SAE AS6802) integrates a model of fault-tolerance and failure management [citation needed]. TTEthernet switch can implement a reliable redundancy management and dataflow (datastream) integration to assure message transmission even in case of a switch failure. The SAE AS6802 implemented on an Ethernet switch supports the design of synchronous system architectures with defined fault-hypothesis.

The single-failure hypothesis, dual-failure hypothesis, and tolerance against arbitrary synchronization disturbances define the basic fault-tolerance concept in a Time-Triggered Ethernet (SAE AS6802-based) network.

Under the single-failure hypothesis, Time-Triggered Ethernet (SAE AS6802) is intended to tolerate either the fail-arbitrary failure of an end system or the fail-inconsistent-omission failure of a switch. The switches in Time-Triggered Ethernet network can be configured to execute a central bus guardian function. The central bus guardian function ensures that even if a set of end systems becomes arbitrarily faulty, it masks the system-wide impact of these faulty end systems by transforming the fail-arbitrary failure mode into an inconsistent-omission failure mode. The arbitrarily faulty failure mode also includes so called "babbling-idiot" behavior. Time-Triggered Ethernet switches therefore establish fault-containment boundaries.

Under the dual-failure hypothesis, Time-Triggered Ethernet networks are intended to tolerate two fail-inconsistent-omission faulty devices. These devices may be two end systems, two switches, or an end system and a switch. The last failure scenario (i.e., end system and switch failure) means that Time-Triggered Ethernet network tolerates an inconsistent communication path between end systems. This failure mode is one of the most difficult to overcome.

Time-Triggered Ethernet networks are intended to tolerate transient synchronization disturbances, even in the presence of permanent failures. Under both single- and dual-failure hypothesis, Time-Triggered Ethernet provides self-stabilization properties. Self-stabilization means that synchronization can reestablish itself, even after a transient upset in a multitude of devices in the distributed computer network.

Performance

edit

Time-triggered traffic

edit

Time-triggered traffic is scheduled periodically, and depending on the architecture, line speed (e.g. 1GbE), topology and computing model with control loops operating at 0.1–5(+) kHz, using a time-triggered architecture (TTA) model of computation and communication. Hard real-time is possible at application level due to strict determinism, jitter control and alignment/synchronization between tasks and scheduled network messaging.

In L-TTA (Loosely TTA) architectures with synchronous TTEthernet network, but with local computer clocks decoupled from system/network time the performance of control loops may be limited. In this case, time-triggered transmissions are necessarily cyclically scheduled and thus delays between processes in the application layer can be large, e.g. with plesiochronous processes operating on their own local clock and execution cycle, as is observed in systems using cyclic MIL-STD-1553B buses, up to twice the transmission interval due to released packets waiting for scheduled transmission at the source and for the receiving process to run at the destination.

Rate-constrained traffic

edit

Rate-constrained traffic is another periodic time-sensitive traffic class, and it shall be modeled to align with time-triggered traffic (and vice versa) in order to fulfill maximum latency and jitter requirements. However, even where the sum of the allocated bandwidths is less than the capacity provided at every point in the network, delivery is still not guaranteed due, e.g., to potential buffer overflows at switch queues, etc., which simple limitation of bandwidths does not guarantee are avoided.

Best effort traffic

edit

Best effort traffic will utilize network bandwidth not used by rate-constrained and time-triggered traffic.

In TTEthernet devices, this traffic class cannot interfere with deterministic traffic, as it resides in its own separate buffer memory. Moreover, it implements internal architecture which isolates best effort traffic on partitioned ports, from the traffic assigned to other ports. This mechanism can be associated with fine-grained IP traffic policing, to enable traffic control which is much more robust than VLANs with FIFO buffering.

History

edit

In 2008, it was announced Honeywell would apply the technology to applications in the aerospace and automation industry.[7] In 2010 a switch-based implementation was shown to perform better than shared bus systems such as FlexRay for use in automobiles.[8] Since then, Time-Triggered Ethernet has been implemented in different industrial, space and automotive programs and components.

See also

edit

Notes

edit
  1. ^ The quality of the synchronization determines the limit on the efficiency with which the physical link between a data source and a switch may be used for time-triggered transfers, and thus the overall efficiency of the network: The individual data frames must be transmitted so that they arrive within the time slot expected by the switch. Hence the maximum error in synchronization between the source and the switch must be included in the duration of the time slot that the switch must allow. Otherwise frames of the time-triggered transfer, which are correctly timed from the perspective of the source, will be dropped by the switch for being mistimed. Hence, the larger the errors in the synchronization, the fewer such frames can be transmitted in any given period. This is a particular problem in the use of standard IEEE 802.3 Ethernet network interfaces with software support for IEEE1588 for the transmission of time-triggered transfers, e.g. for provably reliable data transport. This is, partly, why the use of specific TTEthernet network interfaces with hardware support for synchronization, etc., is recommended in implementations of TTEthernet.

References

edit
  1. ^ "Time-Triggered Ethernet". www.tttech.com. Retrieved 13 July 2014.
  2. ^ "Time-Triggered Ethernet". European Space Agency. Retrieved 2020-04-10.
  3. ^ Loveless, Andrew (July 30, 2020). "On Time-Triggered Ethernet in NASA's Lunar Gateway" (PDF). NASA Technical Reports Server. Retrieved May 4, 2022.
  4. ^ "ECSS-E-ST-50-16C – Space engineering – Time-Triggered Ethernet (30 September 2021) | European Cooperation for Space Standardization". ecss.nl. Retrieved 2022-05-04.
  5. ^ "TTEthernet – A Powerful Network Solution for All Purposes" (PDF). Marketing whitepaper. TTTech Computertechnik AG. 2009. Archived from the original (PDF) on March 28, 2014. Retrieved March 28, 2014.
  6. ^ Wilfried Steiner and Bruno Dutertre, SMT-Based Formal Verification of a TTEthernet Synchronization Function, S. Kowalewski and M. Roveri (Eds.), FMICS 2010, LNCS 6371, pp. 148–163, 2010.
  7. ^ "New Products: Ethernet Platform". News release in Avionics magazine. April 1, 2008. Retrieved June 9, 2011.
  8. ^ T. Steinbach; F. Korf; T. C. Schmidt (May 18, 2010). "Comparing time-triggered Ethernet with FlexRay: An evaluation of competing approaches to real-time for in-vehicle networks". 2010 IEEE International Workshop on Factory Communication Systems Proceedings. pp. 199–202. doi:10.1109/WFCS.2010.5548606. ISBN 978-1-4244-5460-0. S2CID 16739946.
edit