© H. Kopetz 01/21/09 1 TU Wien The Rationale for Time-Triggered (TT) Ethernet H Kopetz TU Wien December 2008
© H. Kopetz 01/21/09
1TU Wien
The Rationale for
Time-Triggered (TT) Ethernet
H Kopetz
TU Wien
December 2008
© H. Kopetz 01/21/09
2Outline
! Introduction
! Basic Concepts
! Innate Design Conflicts
! Standard TT Ethernet
! Safety-Critical TT Ethernet
! Conclusion
© H. Kopetz 01/21/09
3Importance of Real-Time Communication
For the following reasons, distributed systems are the dominant architectural choice for many real-time applications:
! Composability: the construction of new applications out of existing pre-validated components
! Intelligent Instrumentation--integration of sensor/actuator, local processing and communication on a single die
! Reduction of wiring harness
! Avoidance of a single point of failure in safety critical applications.
In any distributed real-time system, a proper real-time communication service is of central importance
© H. Kopetz 01/21/09
4History of Real-Time Protocols
Over the past decades, many domain-specific real-time protocols have appeared on the market, such as:
! CAN
! Profibus
! AFDX
! TTP
! FlexRay
! Real-Time Ethernet
! etc.
None of these protocols has penetrated the market in manner that is comparable to standard Ethernet in the non-real-time world.
© H. Kopetz 01/21/09
5A Protocol Consolidation is Expected
Technological and economic developments will enforce a protocol consolidation in the near future:
! According to the highly respected IRTS 2007, the cost of production per million bits of DRAM will fall from 0.96 cent in 2007 to 0.06 cent in 2015. The cost of design and mask generation of an SoC is more 10 Million Dollars that must be amortized over each hardware protocol implementation.
! Interoperability requirements require protocol compatibility.
! Every unique protocol requires a unique set of software modules and development tools that must be developed and maintained.
! Substantial human resources must be deployed to learn about and gain experience with a new protocol.
© H. Kopetz 01/21/09
6Properties of a Successful Protocol
A successful real-time protocol must have the following properties:
! Sound theoretical foundations w.r.t. time, determinism, security, and composability.
! Support for all types of real-time applications, from multimedia to safety-critical control systems.
! Support error containment of failing nodes
! Economically competitive--a hardware SoC protocol controller should cost less than 1 !.
! Compatibility with the Ethernet standard that is widely used in the non-real-time world will reduce the software and human effort.
© H. Kopetz 01/21/09
7Basic Concepts
! Time--sparse time base ! Cycle! RT-Cluster! Component! Message! Real-Time Data! Behavior and Service! Open vs. Closed Communication! State ! Determinism
We need clearly defined basic concepts, such that we all
can agree on the precise meaning of the terms:
© H. Kopetz 01/21/09
8Time
Whenever we use the term time we mean physical time as defined by the international standard of time TAI.
If the occurrence of events is restricted to some active intervals on the timeline with duration " with an interval of silence of duration # between any two active intervals, then we call the time base "/#-sparse, or sparse for short, and events that occur during the active intervals sparse events.
0 1 2 3 4 5 6 7 8 9
Time
Events are only allowed to occur at subintervals of the timeline
! "! ""
© H. Kopetz 01/21/09
9Cyclic Representation of the Sparse Time
Real-Time
Silence
Occurrence of
Sparse Events
© H. Kopetz 01/21/09
10Component
A component is a hardware/software unit that accepts input messages, provides a useful service, maintains internal state, and produces after some elapsed time output messages containing the results. A component is thus an identifiable functional unit of data transformation and comprehension and forms an abstract high-level concept in the mental model of system behavior.
Application
Software
Module
API
Hardware
Operating System and Middleware
Communication Network InterfaceI O
Custom
Hardware
Application
Software
Module
API
Hardware
Operating System and Middleware
Communication Network InterfaceI O
Application
Software
Module
API
Hardware
Operating System and Middleware
Communication Network InterfaceI O
FPGA
Block
© H. Kopetz 01/21/09
11Real-Time Data
The bit-vector that is contained in the data-field of a message represents real-time data, if the meaning (semantics) of this data depends on the instant of observation of the entity of relevance.
For example, if we measure the position of a piston in an automotive engine this measurement—we call it an observation—is only meaningful if we consider an observation as an atomic triple formed by the instant of observation, the observed value and the name of the entity that is observed.
© H. Kopetz 01/21/09
12State of a Component
The concept of state is introduced in a model of a system in order to separate past behavior from future behavior. We follow the definition of Mesarovic :
The state enables the determination of a future output solely on the basis of the future input and the state the system is in. In other word, the state enables a decoupling of the past from the present and future. The state embodies all past history of a system. Knowing the state supplants knowledge of the past. . . . Apparently, for this role to be meaningful, the notion of past and future must be relevant for the system considered.
The sparse time model introduced above makes it possible to establish the consistent system-wide separation of the past from the future. Without a proper model of time, the notion of state of a distributed system is an ill-defined concept.
© H. Kopetz 01/21/09
13Sparse Time and State
Real-Time
Silence, when
State is defined
Occurrence of
Sparse Events
© H. Kopetz 01/21/09
14Determinism I (dense time base)
Our first definition of determinism: A model behaves deterministically if and only if, given a full set of initial conditions (the initial state) at time to, and a sequence of
future timed inputs, the outputs at any future instant t are entailed.
This definition of determinism is intuitive, but it neglects the fact that in a real (physical) distributed system clocks cannot be precisely synchronized and therefore a system-wide consistent representation of time (and consequently initial state) cannot be established if events are allowed to occur on a dense time-base.
© H. Kopetz 01/21/09
15Determinism II (sparse time base)
We therefore need a revised, more pragmatic, definition of determinism in a distributed real-time computer system that takes account of the finite synchronization of clocks and the digital nature of the time base:
A model of a distributed computer system (hardware, software, communication) is said to behave deterministically if and only if, given a sparse time-base with an infinite sequence of active intervals tj, the state of the system $(t0) at
t0 (now), and a set of future sparse Input Messages IM1(ti1),
IM2(ti2), . . . , IMn(tin), then the set of future Output
Messages OM1(to1), OM2(to2), . ., OMn(ton) and the state of
System $(tx) at all future tx is entailed.
© H. Kopetz 01/21/09
16Communication Requirements
! Predictable Communication Service for the transmission of real-time data --deterministic multicast unidirectional message
•DeterminismTimelinessComplexity ReductionTestingActive Redundancy (e.g., TMR)Certification
•Multicast --independent non-intrusive observation, TMR
•Uni-directionality --separate communication from computation
! Flexible best-effort Communication Service for the transmission of non-real-time data coming from an open environment
! Support for Streaming Data
! Dependability
© H. Kopetz 01/21/09
17Mitigation at the Architecture Level: TMR
Triple Modular Redundancy (TMR) is the generally accepted technique for the mitigation of component failures at the system level:
A B
© H. Kopetz 01/21/09
18Fault-Handling at the Architectural Level: TMR
Triple Modular Redundancy (TMR) is the generally accepted technique for the mitigation of component failures at the system level:
VOTER
A/1
AVOTER
A/2
VOTER
A/3
B
VOTER
B/1
VOTER
B/2
VOTER
B/3
© H. Kopetz 01/21/09
19Innate Conflicts in Real-Time Protocol Design
!Temporal Guarantees
!Synchronization Domain
!Error Containment
!Consistent Ordering of Events
!Determinism
© H. Kopetz 01/21/09
20Temporal Guarantees (I)
It is impossible to provide tight temporal guarantees in an open communication scenario.
If every sending component in an open communication scenario is autonomous and is allowed to start sending a message at any instant, then it can happen that all sending components send a message to the same receiver at the same instant (the critical instant), thus overloading the channel to the receiver. In fielded communication systems, we find three strategies to handle such a scenario:
• The communication system stores messages intermediately
•The communication system exerts back-pressure on the sender.
•The communication system discards some messages.
None of these strategies is acceptable for real-time data.
© H. Kopetz 01/21/09
21Temporal Guarantees (II)
Tight temporal guarantees can only be given, if the senders cooperate and coordinate their sending actions such that there is no channel conflict among the senders of real-time messages.
Such a coordination can be achieved by establishing a conflict free schedule for sending real-time data, based on the reference to a common time-base.
© H. Kopetz 01/21/09
22Single Synchronization Domain
It is impossible to support more than a single synchronization domain for the temporal coordination of components within a RT-cluster.
The synchronization within a cluster can be established either by reference to a single global time or by reference to a single leading data source.
Example: A dynamic scenario that is observed by a set of smart cameras.
© H. Kopetz 01/21/09
23Error Containment
Host Host Host Host
Host Host Host Host
Communication
System
© H. Kopetz 01/21/09
24Error Containment
Host Host Host Host
Host Host Host Host
Communication
System
© H. Kopetz 01/21/09
25Error Containment
Host Host Host Host
Host Host Host Host
Communication
System
© H. Kopetz 01/21/09
26Error Containment
Host Host Host Host
Host Host Host Host
Communication
System
© H. Kopetz 01/21/09
27Error Containment
It is impossible to maintain the communication among the correct components of a RT-cluster if the temporal errors caused by a faulty component are not contained.
Error containment of an arbitrary node failure requires that the Communication System has temporal information about the allowed behavior of the nodes--it must contain application-specific state.
Host Host Host Host
Host Host Host Host
Error Containment
Communication
System
Temporal ErrorContainment
Boundary
© H. Kopetz 01/21/09
28Consistent Ordering of Events
It is impossible to establish, on the basis of their digital timestamps, a consistent view of the temporal order of events in a distributed system, if the events can be generated at any instant of a dense time-line.
Because of the accumulation of the synchronization error and the digitalization error, it is not possible to reconstruct the temporal order of two events from the knowledge that the global timestamps differ by one.
0 1 2 3 4 5 6 7 8 9
17
42
clock j
clock k68
69event 17 : 2 by j
event 42 : 3 by k
event 68: 7 by j
event 69: 6 by k
Respective macroticks
of clocks j and k are con-
nected by dotted lines
© H. Kopetz 01/21/09
29Determinism
It is impossible to build a deterministic distributed real-time system without the establishment of some sort of a sparse global time base for the consistent time-stamping of the sparse events.
Without a sparse global time base and sparse events, simultaneity cannot be resolved consistently in a distributed system, possibly resulting in an inconsistent temporal order of the messages that report about these simultaneous events. Inconsistent ordering results in the loss of replica determinism.
The assignment of events to a sparse global time-base can be established at the the system level by the generation of sparse events or at the application level by the execution of agreement protocols which assign consistently dense events to sparse intervals.
© H. Kopetz 01/21/09
30Purpose of TT Ethernet
The purpose of TT Ethernet is to provide a uniform communication system for all types of distributed non-real-time and real-time applications, from very simple uncritical data acquisition tasks, to multimedia systems and up to safety-critical control applications, such as fly-by-wire or drive-by wire.
It should be possible to upgrade an application from standard TT- Ethernet to a safety-critical configuration with minimal changes to the application software.
© H. Kopetz 01/21/09
31Certification as a Design Driver
Certification is only possible if a system has been designed for certification:
! Independence of Fault-Containment Units (FCU)
! Elimination of temporal error propagation from one FCU to the network and in consequence to the other FCUs.
! Deterministic Operation
! Formal Analysis of Critical Algorithms
! Modular Composition of Correctness Argument
© H. Kopetz 01/21/09
32Legacy Integration
TT-Ethernet is required to be fully compatible with existing Ethernet systems in hardware and software:
! Message format in full conformance with Ethernet standard
! Standard Ethernet traffic must be supported in all configurations
! Existing Ethernet controller hardware must support TT Ethernet traffic.
! IEEE 1588 standard for global time representation is supported
© H. Kopetz 01/21/09
33The Key Decision- Two Message Categories
Competition vs. Cooperation
Host Host Host Host
Host Host Host Host
Host Host Host Host
Host Host Host Host
Internet Model
Standard (ET) Ethernet
Embedded System Model
TT Ethernet
© H. Kopetz 01/21/09
34Distinguish between two Categories of Messages
ET-Messages:
! Standard Ethernet Messages
! Open World Assumption
! No Guarantee of Timeliness and No Determinism
TT-Messages:
! Scheduled Time-Triggered Messages
! Closed World Assumption
! Guaranteed a priori known latency
! Determinism
© H. Kopetz 01/21/09
35TT and ET Ethernet Message Formats are Alike
Preamble (7 bytes)
Start Frame Delimiter (1 byte)
Destination MAC Address ( 6 bytes)
Source MAC Address (6 bytes)
Client Data (0 to n bytes)
PAD (0 to 64 bytes)
Frame Check Sequence (4 bytes)
Tag Type Field (88d7 if TT)
Standard
Ethernet
Message
Header
© H. Kopetz 01/21/09
36Conflict Resolution in TT Ethernet
! TT versus ET: TT message wins, ET message is interrupted (preempted). The switch will retransmit the preempted ET message autonomously
! TT versus TT: Failure, since TT messages assumed to be properly scheduled (closed world system)
! ET versus ET: One has to wait until the other is finished (standard Ethernet policy).
There is no guarantee of timeliness and determinism for ET messages!
© H. Kopetz 01/21/09
37Global Time
! TT Messages are used to build a global time base
! TT Ethernet time format is a sparse binary time format. Fractions of a second are represented as 24 negative powers of two (down to about 60 nanoseconds), and full seconds are presented in 40 positive powers of two (up to about 30 000 years) of the physical second.
! This binary time-format has been standardized by the OMG and IEEE 1588.
! TT Ethernet gives the user the option to make a tradeoff between dependability and cost of the global time.
© H. Kopetz 01/21/09
38TT Ethernet Periods
! The TT Ethernet recommends to restrict the period durations to the positive and negative powers of two of the second, i.e. a period can be either 1 second, 2 seconds, 4 seconds, and so forth, or 1/2 second, 1/4 second, 1/8 second and so forth.
! The duration of each period can then be characterized by the corresponding bit (period bit) in the binary time format.
! The phase of a period, i.e. the offset to the start instant of the selected duration in the global time format, is designated by the specification of a pattern of twelve bits (the phase bits) to the right of the period bit.
We then can represent a cycle with two Bytes (four period bits i.e. 16 periods, and twelve phase bits).
© H. Kopetz 01/21/09
39TT Ethernet Periods--Example
2-24 sec1 sec bit 24239 seconds
Phase of the PeriodPeriod bit5 Bytes
Specification of a period of 1/24 (i.e 1/16) second with a phase
(i.e. the offset from the periodic 1/16 second instant) of
1/26+1/211 = 16113 µseconds.
© H. Kopetz 01/21/09
40TT Ethernet Protocol Family
TT Ethernet forms of an upward compatible family of protocols, starting with low-cost low-function controllers and going up to safety critical configurations with fault-tolerant time base, supported by certification:
! Low-level TT Ethernet system which is not time-aware and provides no or minimal error containment.
! Professional TT Ethernet system which is time-aware and contains configuration state to perform error containment of failing nodes.
! Advanced TT Ethernet system with multiple switches that supports fault-tolerant clock synchronization and triple modular redundancy.
© H. Kopetz 01/21/09
41Integrity-Level of Application Domains
Application
System
MTTF w.r.t.
permanent
failures
(in years)
System
MTTF w.r.t
transient
failures
(in years)
Data-
integrity
requirement
Market
volume
Examples
Low-
Integrity
> 10 > 1 low huge Consumer
Electronics
Moderate-
Integrity
> 100 > 10 moderate large Present-day
automotive
High-
Integrity
> 1000 > 100 very high moderate Enterprise
server
Safety-
Critical
> 100 000 > 100 000 very high small Flight
control
© H. Kopetz 01/21/09
42The Dilemma
! The consumer electronics (CE) domain has the size to support the large development costs needed to build powerful SoCs.
! Since in the near future there is no need to harden CE chips to mitigate the consequences of ambient cosmic radiation, the CE industry will not pay extra for hardening their chips.
! Architectural mitigation strategies have to be developed such that replicated mass-market chips can be used to build high-integrity embedded systems. TMR (triple modular redundancy) is an example for such a high-level strategy.
© H. Kopetz 01/21/09
43What is Needed to Implement TMR?
What architectural services are needed to implement Triple Modular Redundancy (TMR) at the architecture level?
! Provision of an Independent Fault-Containment Region for each one of the Replicas
! Synchronization Infrastructure
! Predictable Multicast Communication
! Replicated Communication Channels
! Support for Voting
! Deterministic (which includes timely) Operation
Advanced TT-Ethernet provides all services needed to implement TMR.
© H. Kopetz 01/21/09
44Fault Hypothesis in the TT-Ethernet
i. A Node Computer forms a single FCR that can fail in an
arbitrary failure mode.
ii. A communication channel including the central guardian in
the TT Ethernet switch forms a single FCR that can fail to distribute messages
iii. The central guardian within an appropriate Ethernet switch transforms non-fail-silent failures to fail-silent failures.
iv. Error detection can be performed by a membership and clique avoidance algorithms in advanced TT Ethernet systems.
v. The system can recover from a single failure within two TDMA rounds.
© H. Kopetz 01/21/09
45Approach to Safety: The Swiss-Cheese Model
Subsystem
Failure
Catastrophic
System EventMultiple
Layers of
Defenses
From Reason, J
Managing the Risk of
Organizational Accidents
1997
NGU Strategy
On-Chip TMR
Off-Chip TMR
Normal Operation
© H. Kopetz 01/21/09
46On-Chip Mitigation of Soft Errors by TMR
Trusted
Network
Authority
(TNA)
TISS
HOST
Local I/O
TISS
Local I/O
HOST
TISS
HOST
Local I/O
TISS
Local I/O
HOST
TISS
HOST
Local I/O
TISS
Local I/O
HOST
TISS
HOST
Local I/O
TISS
Time-Triggered Network-on-Chip
Replica
A
Voter
Voter
Replica
B
Voter
Replica
C
Assumptions:
•Jobs are replica deterministic
•Single event impacts only a single
fault-containment region
•Data Structures in the core area
(red) protected by Error-Correcting
Codes
•Estimated Reliability
Improvement by a Factor of 1000
Example of an MPSoC with a TTNoC
© H. Kopetz 01/21/09
47Three Levels of Fault Mitigation
(i) Normal Operation
(ii) On-Chip TMR: to handle transient faults within a chip
(iii) Off-Chip TMR: to handle a transient and permanent fault of a chip
(iv) NGU (Never-Give-Up) Strategy: to handle multiple correlated transient faults
© H. Kopetz 01/21/09
48Configuration with off-Chip TMR
Switch
Blue
Switch
Brown
Voting Actuator Voting Actuator
Standard Ethernet
TT EthernetTT Ethernet
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Green DASRed DAS
© H. Kopetz 01/21/09
49Example: TMR Configuration
Switch
Blue
Switch
Red
Voting Actuator Voting Actuator
Standard Ethernet
TT EthernetTT Ethernet
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
© H. Kopetz 01/21/09
50Example: TMR Configuration
Switch
Blue
Switch
Red
Voting Actuator Voting Actuator
Standard Ethernet
TT EthernetTT Ethernet
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
© H. Kopetz 01/21/09
51Example: Streaming Multimedia System
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
TT-Ethernet
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
TT-Ethernet
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
TT-Ethernet
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Multimedia
AmplifierBeamer
Videostream
Audio/Video Stream (TT Ethernet)
Micro
Component
Micro
Component
FPGAMicro
Cromponent
Processingnear
Memory
OCNI OCNI
OCNI OCNI OCNI
TNA(TrustedNetwork
Authority)
Micro
Cromponent
OCNI
OCNI
Micro
Component
TT-Ethernet
OCNI
10-100 Gigabyte Time-triggered Interconnect
Large External Memory
Memory
Bus
Loudspeakers
7 channel Audiostream
DVD Player Satellite Receiver
© H. Kopetz 01/21/09
52Conclusions
TT Ethernet
! provides a uniform communication infrastructure for all types of real-time and non real-time applications--from simple data acquisition systems, to multimedia systems up to safety-critical control applications.
! is based on sound theoretical concepts concerning time and determinism
! is fully compatible with the existing Ethernet standard.
! can be introduced in a modular fashion, integrating existing Ethernet hardware and software with modules that support the new services.