Top Banner
© H. Kopetz 01/21/09 1 TU Wien The Rationale for Time-Triggered (TT) Ethernet H Kopetz TU Wien December 2008
52

TU Wien The Rationale for Time-Triggered (TT) Ethernetos.inf.tu-dresden.de/Studium/RTS/WS2011/10-KopetzFull.pdf · 2012. 1. 26. · defined by the international standard of time

Feb 15, 2021

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • © 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.