TTE_Node

Interfaces and Buses / TimeTriggeredEthernet / TTE_Node

Block Name: TTE_Node

Code location: VisualSim/actor/lib/networking/tte/TTE_Node

Table Of Content

Description
Data Flow
Synchronization
Block Dependencies
Examples
Tutorial
Parameters
Ports

Description:

TTEthernet implements time-triggered communication mechanisms to provide a deterministic communication service over Ethernet. These time-triggered mechanisms establish and maintain a global time, which is realized by the synchronization of the local clocks of all TTEthernet devices. The global time is used as basis for implementing temporal partitioning, precise diagnosis, efficient resource utilization, or composability. The global time service of TTEthernet can be compared with the IEEE 1588 Precision Time Protocol, but uses multiple active “grandmaster clocks” to form a fault tolerant synchronization group with no need for reelection in case of an active grandmaster clock failure.
This block connects TTE_Node to the network. This block manages triple redundancy, multicast, MAC and Phy layers. Time-Triggered Ethernet functionality is implemented based on the SAE AS6802 specification of the Layer 2 Quality-of-Service (QoS) enhancement for Ethernet networks. The library provides capability for deterministic, synchronous, and congestion-free communication, unaffected by any asynchronous Ethernet traffic load. The block supports the isolation of the synchronous time-critical dataflows from other asynchronous Ethernet dataflows. This implementation of the standard enables designers to test, define the topology and validate their architecture for performance latency, throughput, jitters and other intrusions such as large, high priority packets, rate-controlled data streams and virtual LANs. This means that distributed applications with mixed time-criticality requirements (e.g., real-time command and control, audio, video, voice, data) can be integrated and coexist on one Ethernet network.

Name of either source or Destination node must start with Node_ followed by a number.

Data Flow

In order to support integration of applications with different real-time and safety requirements in a single network, TTEthernet supports three different traffic classes:

• Time-Triggered (TT) traffic – is sent in a time-triggered way, i.e. each TTEthernet sender node has a transmit schedule, and each TTE-Switch has a receive and forward schedule. This traffic is sent over the network with constant communication latency and small and bounded jitter.
• Rate-Constrained (RC) traffic – is sent with a bounded latency and jitter ensuring lossless communication. Each TTEthernet sender node gets a reserved bandwidth for transmitting messages with the RC traffic. No clock synchronization is required for RC message exchange.
• Best-Effort (BE) traffic – traffic with no timing guarantees. BE traffic class compatible with the IEEE 802.3 standard Ethernet traffic.

The TTEthernet frame format is compatible with the standard Ethernet (IEEE 802.3) frame format. TTEthernet operates at the OSI model Layer 2, and allows the usage of existing layer 3 and upper layer protocols on top of TTEthernet.

TT messages are used for deterministic communication. All TT messages are sent over the network at predefined times and take precedence over all other traffic types. TT messages are optimally suited for communication in distributed real-time systems, specifically for safety related by-wire systems that require running of tight control loops over the network. TT messages allow designing of strictly deterministic distributed systems, where the timing properties of data flows are known in advance. Switches in TTEthernet have the central role of handling of communication data. TT messages are handled in the switch according to a predefined schedule. Precise planning at the time of system design precludes resource conflicts at runtime. Due to the predefined transmission time of a message, it is possible to reserve the medium and avoid even minimal delays of transmission if this is required for a specific TT message.

RC messages are used for applications with less stringent determinism and real-time requirements. RC messages limit the usage of bandwidth for each application (sender), and thus allow to determine upper bounds for message delays and jitter. RC messages can be used for critical applications that depend on highly reliable communication and have moderate communication latency and jitter requirements. Typically, RC messages are also used for audio/video (streaming) applications. In contrast to TT messages, RC messages are not sent with respect to a system-wide synchronized time base. Hence, different communication controllers may send RC messages at the same point in time to the same receiver. As a consequence, the RC messages may queue up in the network switches, leading to increased transmission jitter. As the transmission rate of the RC messages is bound a priori and controlled in the network switches, an upper bound on the transmission jitter can be calculated off-line and message loss due to buffer overflowor message timeouts is prevented. If TT messages are to be transmitted via the same outgoing port of a
switch at the same time, the TT messages take priority over the RC messages. TT messages can delay RC messages. RC messages are transmitted when no planned transmission of TT messages is pending and the sender observes the minimal transmission distance. The switch is responsible for arranging RC messages queued at an outgoing port.

BE messages follow a method that is well-known in classical Ethernet networks. The network handles the messages in the best-effort manner, and therefore there is no guarantee whether and when these messages will be transmitted. BE messages use the remaining bandwidth of the network and have less priority than TT and RC messages. All legacy Ethernet traffic (e.g. internet protocols) can be mapped to this service class. RC and TT messages take precedence over BE messages at the same outgoing port of a switch. The switch uses the remaining bandwidth for BE messages if no TT or RC messages are to be transmitted. BE messages are transmitted after all pending RC messages, thus the remaining bandwidth is exploited in an optimal way. Tools are used to design and verify a TTEthernet system in advance. This ensures that the bandwidth for TT and RC messages is always sufficient according to the requirements of the application and interrupts are reduced to a minimum. Later incremental changes of the system configuration are possible.

Synchronization

Clock synchronization among all participants is crucial for the transmission of TT messages. TTEthernet components always transmit clock synchronization messages to keep the clocks of the end systems and switches in synchronization. For this purpose TTEthernet relies on a redundant hierarchical master-slave method that has a distributed fault-tolerant majority of master nodes and master switches to provide the time in the system. This method is unique for TTEthernet and can be combined with other mechanisms such IEEE 1588. TTEthernet takes a two-step approach to synchronization. In the first step, the synchronization masters send protocol control frames to the compression masters. The compression masters then calculate an averaging value from the relative arrival times of these protocol control frames and send out a new protocol control frame in a second step. This new protocol control frame is then also sent to synchronization clients. TTE_Node block acts as the synchronization master and TTE_Bridge block acts as compression master block in the network.

Block Dependencies:

TTE_Node block requires a number of mandatory data structure fields including Task_Source, Task_Destination, Task_Hop, Task_Trace, Task_Size, Type, Network_Message, Network_Message_Type and Task_Layer. Hence, it is recommended to use TTE_Traffic block to generate transactions for configured TTEthernet network. Other blocks that are required along with TT_Node block are as follows; TTE_Bridge, TTE_Config, TTE_Config and TTE_Stats.

Examples:

1. TTE Example System with three Sources and One Destination with Single Bridge
2. TTE Example System with Multi-Bridge
3. TTE Example System with two Redundant Connections

Tutorial

A detailed tutorial of TTEthernet networke System exploration is available in this document.

Parameters

Ports