Time-Triggered Ethernet (TTEthernet, TTE)

The TTEthernet protocol was developed to enable time-triggered communication over Ethernet. Its services include a clock synchronization service, a startup service, and clique detection and recovery services. TTEthernet is a transparent synchronization protocol, which means that it is able to co-exist with other traffic, potential legacy traffic, on the same physical communication network. It defines basic building blocks that allow to transparently integrate the time-triggered services on top of message-based communication infrastructures such as standard Ethernet. In addition, it is designed to operate for a multitude of cross-industry applications. As such, TTEthernet comprises demanding fault-tolerant capabilities.

TTEthernet specifies services that enable time-triggered communication on top of Ethernet, the TT Services. Messages from higher layer protocols, like IP or UDP, can easily be "made" time-triggered without modifications of the messages' contents itself. This is, because the TTEthernet protocol overhead is transmitted in dedicated messages, called Protocol Control Frames, which are used to establish system-wide clock synchronization. In short, TTEthernet is only concerned with "when" a data message is sent, rather than with specific contents within a data message.

For details about the protocol, please refer to the TTEthernet specification, available from TTTech (ttethernet@tttech.com).

History

Protocol dependencies

Any protocol that can be on top of standard Ethernet can also be on top of TTE.

Usually, UDP/IP is used (see the AFDX standard).

PCF: The "data payload" of such frames is entirely used by TTEthernet. PCF contain no real payload.

Example traffic

Wireshark

The recognition of TTE traffic is based on the MAC Destination Constant Field. The TTE dissector actually consists of two dissectors, one for TTE Data Frames (TTE, based on ARINC664 AFDX Frame), and one for TTE Protocol Control Frames (TTE-PCF). The former dissects the destination MAC address and displays the "Constant Field" and the "Critical Traffic Identifier (CT ID)". The latter dissects the contents of a PCF frame, as shown in the above example.

Both dissectors are fully functional and are active by default. They can be disabled independently, using the 'Analyze.Enabled protocols...' menu entry.