Transcript TU Wien - Action M

1
TU Wien
Component-Based Design of
Industrial Control System
H. Kopetz
TU Wien
September 2006
© H. Kopetz 7/7/2015
The Message
Today, in 2006,
computer technology is in the middle of a major
paradigm shift, similar to the transition from the
Mainframe to the Personal Computer
twenty-five years ago.
© H. Kopetz 7/7/2015
2
3
Outline
 Introduction
 Technology Developments
 What is a Component?
 Composition Framework
 Example: Time-Triggered Architecture
 Future Developments
 Conclusion
© H. Kopetz 7/7/2015
Technology Developments
 Hardware
 Communication
 Software
 User Expectations
© H. Kopetz 7/7/2015
4
Estimated Parameters of an SoC around 2015
2004
Feature Size (nm)
90
DRAM Mbits/mm2
10
SRAM Mbits/mm2
0.2
Million transistors/mm2
1
Chip size mm2
200
Frequency in GHz
2
Cost/ mm2 (in cents)
10
Cost per transistor (cents)
10
Number of CPUs/mm2
5
Cost (c) per CPU ARM 7 (200k)
2
MTTF/chip permanent (years)
1000
MTTF/chip transient (years)
1
© H. Kopetz 7/7/2015
2007
65
40
.8
4
200
8
10
2.5
20
0.5
1000
.8
2015
20
100
8
40
200
50
10
0.25
200
0.05
100
<0.01
5
The Technology Landscape--Hardware
 The limits of Moore’s law are becoming visible: power
dissipation, physical feature size, reliability.
 The performance increase of a single processor from one
generation to the next is proportional only to the square root
of the increase in silicon area (Pollack’s rule).
 The transient failure rate of sub-micron devices is increasing
[both single-event upset (SEU) and single-event transient
(SET)].
 Multi-computer chips (SoC) area appearing. The
development cost of such a chip can pass the 100 Mio $ wall-mass markets are needed to justify this level of investment.
It is getting more and more difficult to mobilize and finance the
engineering resources required to design a billion transistor SoC.
© H. Kopetz 7/7/2015
6
From the International Roadmap of Semiconductors
Architectural means to mitigate the consequences of
component failures might become a necessity when using the
upcoming submicron devices, as stipulated in the latest 2005
International Roadmap of Semiconductors p.6:
Relaxing the requirement of 100% correctness for devices and
interconnects may dramatically reduce the costs of
manufacturing, verification and test. Such a paradigm shift is
likely forced in any case by technology scaling, which leads
to more transient and permanent failures of signals, logic
values, devices and interconnects.
© H. Kopetz 7/7/2015
7
The Technology Landscape--Communication
 The widespread availability of a wireless communication
infrastructure enables the ad-hoc detection and integration of
services without any physical action--the coming of situation
aware systems--wireless sensors and actuators.
 Seamless integration of Radio Frequency Identification (RFID)
technology with embedded devices (e.g., cell phones).
 Flexible transmission technologies (e.g., spread spectrum, ultra
wide band, frequency hopping) and waveform-agile transmission
methodologies (cognitive radio) allow multiple users to share a
given frequency band with minimal interference and reduce the
power required per bit transmitted.
It must be possible to integrate heterogeneous communication
subsystems with minimal effect on the overall architecture of a large
control system.
© H. Kopetz 7/7/2015
8
The Technology Landscape--Embedded Software
 Uncontrolled system complexity: The costs of design, verification,
integration and maintenance of large systems are getting prohibitive.
 The investment in software is more long-lasting than the investment
in hardware.
 Security becomes a key issue-- as embedded devices are integrated
into the Internet, particular in wireless systems.
 The clear distinction between software and hardware is disappearing,
e.g., power-dissipation is becoming also a software issue, not only in
battery-operated devices.
Component-based design elevates the design process to a higher level of
abstraction--but many key issues are still open, e.g., the precise
specification of component interfaces, the identification of faultcontainment units.
© H. Kopetz 7/7/2015
9
New Software Implementation Choices
Algorithm
Complexity
Ease of
Programming
CPU
Software
FPGA
(Software)
10
Greater
DataVolumes
Higher Execution
Speed
(speedup 100X)
From: R. Chamberlain, Embedding
Applications within a Storage
Aplliance Proc. HPEC 2005, p. 2
Example: Look for keywords in a set of documents:
(A and B) or (C and D)
Search for the occurrence of A,B,C,D in FPGA, connect the results in software
© H. Kopetz 7/7/2015
User Expectations
 In a large embedded control system that consists of a vast
assembly of networked components that must operate 24 hours per
day for 365 days per year the occurrence of transient and
permanent failures of components and interconnects must be
considered the norm, not the exception. Future system must thus
include strategies and mechanisms that assure that the reliability of
the user-perceived system services remains at an acceptable level
despite the occurrence of these failures.
 In an ambient intelligence scenario, where a multitude of diverse
embedded devices is fielded in a home, it cannot be expected that
the end-user is willing to spend her/his time and effort to
troubleshoot a misbehaving distributed embedded system. A
system must thus be capable to diagnose its own faults and guide
an untrained user to repair the system with minimal effort.
© H. Kopetz 7/7/2015
11
12
Integrity-Level of Application Domains
System
MTTF w.r.t.
permanent
fa ilures
(in years)
System
MTTF w.r.t
transient
fa ilures
(in years)
Dataintegrity
requirement
Market
volume
LowIntegrity
> 10
>1
low
huge
Consumer
Electronics
ModerateIntegrity
> 100
> 10
moderate
large
P resent-day
automotive
HighIntegrity
> 1000
> 100
very high
moderate
Controlise
Enterpr
Systems
server
SafetyCritical
> 100 000
> 100 000
very high
small
Flight
control
Application
© H. Kopetz 7/7/2015
Examples
The 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 control systems.
© H. Kopetz 7/7/2015
13
Summary: Need for a Higher-Level Design Process
 The difference between software design and hardware
design is disappearing--we need a design process that
captures both domains.
 The hardware-base is becoming less reliable, but the
system’s services must be more reliable. Fault-tolerance
will become the norm, not the exception. It must be
supported at the architecture level anad by the design
process.
 Physical parameters of the execution environment (e.g., the
generated heat) must be considered in algorithm design.
The design process must be elevated to a higher level of
abstraction to substantially increase designer productivity and
enhance the design choices of the implementations
© H. Kopetz 7/7/2015
14
Component-Based Design: What is a Component?
Agreement at an abstract level:
A component is a building block in the construction of large
systems.
Is this building block
 A software unit of independent deployment (Szyperski-software component) or
 a hardware-software unit that has behavior and state
(system component)?
We need a clear concept of a component and a
composition framework that supports the
interactions among components.
© H. Kopetz 7/7/2015
15
System Component: Software plus Container
Application
Software
Module
16
Application
Software
Module
API
Operating System and Middleware
Hardware
Communication Network Interface
API
I
O
Only the Software plus Container exhibits temporal properties
© H. Kopetz 7/7/2015
System Component Characteristics
A (system) component--(sometimes called host, processing
element(PE) or IP core or a tile)-- has the following characteristics:
 It performs a computation controlled by software or a hardware
state machine.
 It is aware of the progression of real-time.
 It supports one or more message-based interfaces and contains
state.
 Every interface must contain one and can contain more ports for
sending and receiving messages.
 At any instant, only one message can be sent/received at a port.
© H. Kopetz 7/7/2015
17
Different Types of System Components
Local Interfaces--Open Components
Application
Software
Module
API
Operating System and Middleware
Hardware
Communication Network Interface
I
O
The Communication Network Interfaces (CNI) of all three
different types of system components should have the same
syntax, timing and semantics. For a user, it should not be
discernible which type of system component is behind the CNI.
© H. Kopetz 7/7/2015
18
Model Driven Design: From the PIM to the PSM
Domain Specific Application Model
(e.g. expressed in UML)
Platform Independent Model (PIM)
expressed in a High-Level Language
Platform
Independent
Model
Platform
Specific
Model
© H. Kopetz 7/7/2015
19
Model Driven Design: From the PIM to the PSM
Domain Specific Application Model
(e.g. expressed in UML)
Platform Independent Model (PIM)
expressed in a High-Level Language
Platform
Independent
Model
Platform
Specific
Model
© H. Kopetz 7/7/2015
20
The Key Issue: Interfaces of a System Component
Diagnostic and Management Interface
(Boundary Scan in Hardware Design)
Local
Interfaces
to
Environment
Component
Configuration Planning Interface
© H. Kopetz 7/7/2015
Linking
Interface (LIF)
Offers the services of a
component.
Relevant for
Composability
21
The LIF Specification Hides the Implementation
Component
Hardware
Operating System
Middleware
Programming Language
WCET
Scheduling
Memory Management
Etc.
© H. Kopetz 7/7/2015
Linking
Interface
Specification
(In Messages,
Out Messages,
Temporal,
Coordiation,
Interface State,
Meaning-Interface
Model)
22
Linking Interface (LIF) Specification
Operational Specification of the Messages:
 Operational Input Interface Specification
 Syntactic Specification (e.g. by IDL)
 Temporal Specification (receive instant)
 Input Assertions
 Operational Output Interface Specification
 Syntactic Specification (e.g. by IDL)
 Temporal Specification (send instant)
 Output Assertions
 Coordination Patterns
Semantic Specification:
 Meaning of the data elements: Means-and-ends interface model
that explains the data transformation of the component
 Interface State of the Interface Model
© H. Kopetz 7/7/2015
23
Semantic Specification: Interface Model
Specifying the concepts that are behind the
names of the data structures
 Interface model specifies the relationship between the input
messages, the output messages, the interface state and time.
 Interface model must be expressed with concepts that are familiar
to the conceptual world of the intended users.
 Interface model of an open component must include the context of
use, i.e. a (constrained) model of the environment.
 The brittleness of natural language cannot be avoided in open
components.
 Meta-level specification remain often informal -- Formalization
increases the precision, but at the same time increases the distance
to reality (Chargaff)
 Beware of pseudo-formalism.
© H. Kopetz 7/7/2015
24
25
The Composition Framework
Host
Host
Host
Host
Host
Host
?
Host
© H. Kopetz 7/7/2015
Host
Services of the Composition Framework
The composition framework that links the LIFs of the
components is realized by a real-time communication network
which must have the following properties:
 Timely transport of messages from any output port to any
input port
 High performance with minimal power consumption
 Determinism to enable fault-masking by TMR
 Protection of the network and the correct nodes from a
failing node (hardware or software error)
 Integrated diagnostics to detect component misbehavior
© H. Kopetz 7/7/2015
26
27
The Key Decision concerning the Network
Competition
Cooperation
vs.
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
© H. Kopetz 7/7/2015
Conflict Resolution in the Network
28
Only a single message can be received at a receive port at an instant:
 Competition--Arbitration or Message Store Needed:
 Network access control protocol ensures that only one sender
may send at an instant to a receiver and excercises back pressure
on the sender (based on priority (e.g., CAN) or on random
process (e.g., Ethernet bus) in case of conflict
 Conflicting messages are stored in the network (e.g., switched
Ethernet) and sent at a later time, when the line to the sender is
free
 Cooperation--no Arbitration and no Message Store Needed:
 Senders cooperate among each other to establish transmission
slots that are free of conflict at the receiver (e.g., TTP).
© H. Kopetz 7/7/2015
An Epistemological Issue
Accesses to common resources by multiple clients requires
arbitration or a priori coordination. Coordination can be achieved by
reference to a global time-base.
 Establishing temporal order is much more expensive than
maintaining temporal order.
 Once a proper global time has been established, it can be used to
to order events consistently in the temporal domain.
 In a system with global time, the difficult ordering problem has
to be solved only once, at system startup, to achieve the initial
synchronization of the clocks. Maintaining the clock
synchronization is relatively easy.
 In a system without global time, the difficult problem has to be
solved every time temporal order is required (arbitration).
© H. Kopetz 7/7/2015
29
Performance and Power
According to Richardson et. al (2006):
 Arbitration consumes time. Example AMBA Bus from
ARM: Since AMBA arbitrations consume three cycles
from request to address transmission and four from request
to data transmission, the induced latency overhead may
become significant.
 There is no need for arbitration, back-pressure or
intermediate storage of data packets in a synchronous
network. The power consumption is thus reduced over
comparable asynchronous networks.
Richardson, R.D. et. al. A Hybrid SoC Interconnect with Dynamic TDMA-Based Transaction
Less Buses and On-Chip Networks, Proc. Of the 19th International Conference on VLSI
Design, 2006, IEEE Press
© H. Kopetz 7/7/2015
30
Example for Determinism: Airplane on Takeoff
Consider an airplane with a three channel flight control
system taking off from a runway:
Channel 1
Channel 2
© H. Kopetz 7/7/2015
Take off
Abort
Accelerate Engine
Stop Engine
31
Example for Determinism: Airplane on Takeoff
Consider an airplane with a three channel flight control
system taking off from a runway:
Channel 1
Channel 2
Channel 3
Take off
Abort
Take off
Accelerate Engine
Stop Engine
Stop Engine (Fault)
Majority
Take off
Stop Engine
© H. Kopetz 7/7/2015
32
Determinism of a Communication Channel
A communication channel is called deterministic if (as seen
from an omniscient external observer):
 The receive order of the messages is the same as the send
order. The send order among all messages is established
by the temporal order of the send instants of the messages
as observed by an omniscient observer.
 If the send instants of n (n>1) messages are the same,
then an order of the n messages will be established in an a
priori known manner.
Two correctly operating independent deterministic
communication channels will deliver messages always in the
same order.
© H. Kopetz 7/7/2015
33
Determinism--Temporal Order is Obvious
A
B
A
B
Real
Time
Blue Channel
© H. Kopetz 7/7/2015
Red Channel
34
35
Determinism: Simultaneity--Who Wins?
A
B
A
B
Determinism:
If A wins on the
blue channel
Real
Time
then A must also
win on the
red channel
Blue Channel
© H. Kopetz 7/7/2015
Red Channel
Simultaneity: A Fundamental Problem
The ordering of simultaneous events is a fundamental
problem of computer science:
•Hardware level: metastability
•Node level: semaphor operation
•Distributed system: ordering of messages
There are two solutions within a distributed system to solve
the simultaneity problem:
• Distributed consensus--takes real-time and requires
bandwidth (atomic broadcast)
• Sparse time
© H. Kopetz 7/7/2015
36
The Time-Triggered Architecture
The Time-triggered Architecture (TTA) provides an execution
environment for real-time applications. It is
 a distributed architecture that provides a fault-tolerant sparse global
time-base of high precision at every node.
 a deterministic architecture that supports fault tolerance by
replication, where a node can be a single-chip computer (SoC).
 an integrated architecture, where different application subsystems
(DAS) up to the highest criticality class can be integrated into a
single framework.
 a generic architecture, which can be deployed in different
application domains (e.g., automotive, aerospace, train signaling,
process control, multimedia).
Kopetz, H, Bauer, G. , The Time-Triggered Architecture, Proc. of the IEEE, Jan 2003, Vol 91
p. 112-126
© H. Kopetz 7/7/2015
37
Fault Tolerant Sparse Time Base in the TTA
38
If the occurrence of events is restricted to some active intervals
with duration  with an interval of silence of duration  between
any two active intervals, then we call the timebase /-sparse, or
sparse for short.










Time

Eve nts




ar e only allowe d to oc cur at subinte rvals of the time line
In a sparse time base, instants can be represented by integers.
© H. Kopetz 7/7/2015
TTA Eight-Byte Time Format: OMG Standard
5 Bytes
239 seconds
1 sec bit 24
Horizon about
30 000 years
Epoch starts on January 8, 1980
(Origin of GPS Time)
© H. Kopetz 7/7/2015
2-24 sec
Precision about
60 nanosecond
39
Triple-Modular Redundancy (TMR) in the TTA
Triple Modular Redundancy (TMR) is the generally accepted
technique for the mitigation of component failures at the system
level:
V
O
T
E
R
A
B
V
O
T
E
R
V
O
T
E
R
© H. Kopetz 7/7/2015
A/1
V
O
T
E
R
B/1
A/2
V
O
T
E
R
B/2
A/3
V
O
T
E
R
B/3
40
41
Triple Modular Redundancy is Supported by the TTA
The following architectural services that are needed to implement
Triple Modular Redundancy (TMR) are supported by the TTA:
 Provision of an Independent Fault-Containment Region for each
one of the replicas
 Timely and Deterministic Operation
 Synchronization Infrastructure
 Multicast communication
 Replicated Communication Channels
 Support for Voting
© H. Kopetz 7/7/2015
Systems of Systems do not have a Single Top
The services of a large RT control system (e.g., the computer
system onboard a car or an airplane) can be partitioned into a
set of nearly autonomous subsystems, we call them
Distributed Application Subsystems (DAS). DASes
communnicate via gateways.
Examples of a DAS onboard a car are
 The body electronics DAS (doors, lights, clima control
etc.)
 The power train control DAS
 The multi-media DAS
.
© H. Kopetz 7/7/2015
42
Example of DASes onboard a Car
DAS-Distributed Application Subsystem
© H. Kopetz 7/7/2015
43
Integrated Architecture
A number of technical and economic advantages could be realized if the
different DASes were integrated into a single architecture
 Cost savings by the reduction of the number of ECUs, sensors and
wiring points (results also in an increase in hardware reliability).
 Better integration of functions--more flexibility
 Implementation of fault tolerance simplified
But
 Independence of individual DAS compromised--increased potential
of error propagation from one DAS to another DAS
 Integration increases complexity and diagnostics
 Allocation of responsibility more difficult.
© H. Kopetz 7/7/2015
44
The TTA is an Integrated Platform Architecture
DAS A
DAS B DAS C
DAS D
45
Distributed
Application
Systems (DAS)
DECOS
Platform Interface
Platform Interface Layer:
Core Services (done for TTP)
Layer (PIL)
•Encapsulation Services
•Timely and Deterministic Transmisson
•Event-Triggered Communication
Core
•Fault-Tolerant Clock Synchronization
•Virtual Channels
Services
•Fault Isolation
•Hidden Gateways
(Done)
•Determinism to support TMR
•Provision of Legacy Interfaces
•FCR-Diagnosis (Membership)
•Application Diagnosis Support
Different
Implementation
Every DAS has has its
Choices
own encapsulated
e.g., TTP, TT Ethernet
execution environment
(may be its own processor
and memory and I/O).
Technology invariant interface
© H. Kopetz 7/7/2015
Different Time-Triggered Communication Protocols
The TTA is not bound to a single communication protocol,
provided the core services are provided:
 The Time-Triggered Protocol (TTP) is the most mature
protocol that has been formally analyzed and is used in the
aerospace domain.
 The automotive industry has defined its own version of a
time-triggered protocol FlexRay.
 For high-bandwidth application a standard compatible
extension to Ethernet, TT Ethernet has been developed.
© H. Kopetz 7/7/2015
46
Why TT Ethernet?
 At present, the communication system of the TimeTriggered Architecture (TTA) is controlled by the TTP/C
protocol that provides the core services.
 The scope of the TTA would be substantially widened, if
Ethernet could be deployed as the communication system
within the TTA.
 Is it possible to augment Ethernet in such a way that
COTS Ethernet users (we call them ET Ethernet users) and
TT Ethernet users can operate in parallel?
© H. Kopetz 7/7/2015
47
Purpose of TT Ethernet
The purpose of TT Ethernet is to provide a uniform
communication system for all types of distributed nonreal-time and real-time applications, from very simple
uncritical data acquisition tasks, to multimedia systems
and up to safety-critical control applications, such as flyby-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 7/7/2015
48
Legacy 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 can coexist with TT
Ethernet controllers within the same cluster
 Special TT controllers are required if the additional
services (e.g., clock sync, membership) of TT Ethernet are
used.
© H. Kopetz 7/7/2015
49
Principles of Operation of TT Ethernet
50
 Distinction between two Messsage Categories:
Event Messages (Standard (ET) Ethernet Messages) originating in the
open world and State Messages (Time-Triggered (TT) Ethernet
Messages) originating in a closed world.
 TT messages are scheduled and the schedules are assumed to be free
of conflicts
 TT messages are sent at a predetermined instant on a sparse timebase
and arrive within an a priori known delay with minimal jitter .
 Conflict resolution: Preemption of ET Messages by the Switch in
case it is in the way of a TT message.
 Automatic Retransmission of a preempted ET messages by the
Switch
© H. Kopetz 7/7/2015
51
TT-Ethernet Message Format
Preamble (7 bytes)
Start Frame Delimiter (1 byte)
Destination MAC Address ( 6 bytes)
Source MAC Address (6 bytes)
Tag Type Field (88d7 if TT)
TT-Control Byte
Message Lenght Byte (in units of 8 bytes)
Parameters (0-10 bytes)
MAC Client Data (0 to n bytes)
PAD (0 to 64 bytes)
Frame Check Sequence (4 bytes)
© H. Kopetz 7/7/2015
Standard
Ethernet
Message
Header
TT Ethernet
Message
Header
State of Development of TT-Ethernet
TT Ethernet Hardware for 100 Mbit/sec:
 TT Ethernet switch with 8 ports available since mid 2005,
delay about 4 sec jitter for TT messages < 1 sec
 TT Ethernet controller in software available since mid 2005
 Prototype of a TT Ethernet controller (FPGA based) available
in PCMCIA Format since mid 2006. Achieved Clock
synchronization precision < 1 sec.
 Gigabit TT Ethernet implementations under investigation
 Safety-critical TT Ethernet implementations under
investigation.
© H. Kopetz 7/7/2015
52
Future Developments: DECOS European IP
53
Towards the Design of TTA System on a Chip (SoC)
Single PCB Board
with heterogeneous
COTS Micro-computers
connected by a
Network-on-Chip (NoC)
in a single FPGA.
Standard Interface
between Host and
TISS (Trusted
Interface Subsystem)
© H. Kopetz 7/7/2015
Prototype of a DECOS TTA Node at TU Vienna
A set of application computers (host) and a communication
network (TTP or TT Ethernet) are forming a single node.
© H. Kopetz 7/7/2015
54
End-to-End Layered Communication
Application
Software
Application
Program
Interface
API
Application
Software
Middleware
Layers
CNI
Core NoC
In a single processor system, the
analysis of the temporal properties
is nearly impossible.
© H. Kopetz 7/7/2015
Middleware Layers can be
implemented either in Software
or in Hardware.
Examples:
 Protocol Transformation (e.g.,
CAN to Ethernet)
 Dependability Enhancement
(e.g. Error Correction Code)
 Fault-Tolerant Unit (FTU)
Layer
 Security Layer
 File Transfer by DMA (Direct
Memory Access)
55
Modularization of the Middleware: In Hardware?
56
Application service
with dedicated
processor.
Modularized
Middleware
Services
(e.g, security,
Core Communication Services
dependability enhancement
protocol translation,
FTU Layer, etc.)
Middleware Module with dedicated hardware support and
with standardized recursive interfaces.
© H. Kopetz 7/7/2015
57
Example: TMR Configuration with the DECOS SoC
Red DAS
TNA
Voting Actuator Green DAS
Voting Actuator
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
10-100 Gigabyte Time-triggered Interconnect
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Large External Memory
Memory
Bus
Memory
Bus
Large External Memory
Large External Memory
TT Ethernet
Large External Memory
TT Ethernet
Switch
Blue
Switch
Brown
Standard Ethernet
© H. Kopetz 7/7/2015
Memory
Bus
58
Example: TMR Configuration
Voting Actuator
TNA
Voting Actuator
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
10-100 Gigabyte Time-triggered Interconnect
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Large External Memory
Memory
Bus
Memory
Bus
Large External Memory
TT Ethernet
Switch
Blue
Large External Memory
Switch
Red
Standard Ethernet
© H. Kopetz 7/7/2015
Memory
Bus
Large External Memory
TT Ethernet
59
Example: TMR Configuration
Voting Actuator
TNA
Voting Actuator
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
TNA
(Trusted
Network
Authority)
Micro
Component
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Micro
Component
Micro
Component
OCNI
OCNI
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
10-100 Gigabyte Time-triggered Interconnect
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Large External Memory
Memory
Bus
Memory
Bus
Large External Memory
TT Ethernet
Switch
Blue
Large External Memory
Switch
Red
Standard Ethernet
© H. Kopetz 7/7/2015
Memory
Bus
Large External Memory
TT Ethernet
60
Example: Streaming Multimedia System
Satellite Receiver
DVD Player
TT-Ethernet
TT-Ethernet
TNA
TNA
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
10-100 Gigabyte Time-triggered Interconnect
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Large External Memory
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Audio/Video Stream (TT Ethernet)
Large External Memory
TT-Ethernet
Multimedia
Amplifier
TNA
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Beamer
Memory
Bus
Large External Memory
7 channel Audiostream
Videostream
TT-Ethernet
TNA
(Trusted
Network
Authority)
Micro
Component
Micro
Component
Micro
Component
OCNI
OCNI
OCNI
OCNI
10-100 Gigabyte Time-triggered Interconnect
Loudspeakers
© H. Kopetz 7/7/2015
OCNI
OCNI
OCNI
OCNI
FPGA
Micro
Cromponent
Micro
Cromponent
Processing
near
Memory
Memory
Bus
Large External Memory
Conclusion
 Component-based design requires a precise component
definition and an appropriate composition framework
 The TTA provides such a composition framework. It has solid
conceptual foundations that support the certification of highdependability control system.The TTA is being industrialized
by the spin-off company TTTech. The TTA is being deployed
in high-dependability control systems, e.g., onboard the Airbus
A 380 and the Boeing 787.
 By the judicious application of partitioning and layering and
the strict separation of communication from computation the
the composition of large systems out of components can be
achieved.
© H. Kopetz 7/7/2015
61
62
Fault Hypothesis in the TTA
Normal
Failures
Correct
States
Rare Events
FT
Mechanisms
Fault-Hypothesis I
Fault Hypothesis II
© H. Kopetz 7/7/2015
NGU
Strategy
Approach to Safety: The Swiss-Cheese Model
Subsystem
Failure
From Reason, J
Managing the Risk of
Organizational Accidents
1997
Multiple
Layers of
Defenses
© H. Kopetz 7/7/2015
Normal State
63
Fault Tolerance part
of the Architecture
Never Give
Up Strategy
Catastrophic
System Event
Independence of Layers of
Error Detection are important
Control Cycle: Cyclic Model of Time
1
A
2
Real Time
B
3
1
C
4
5
6
1
D
E
B
6
E
5
C
D
4
Real
Time
2
A
Voting on
Replicated State
(a)
© H. Kopetz 7/7/2015
(b)
64
1 Start of Cycle
A Observation of Sensor Input
2 Start of Transmission of Sensor Data
B Transmission of Input Data
3 Start of Processing of Control Algorithm
C Processing of Control Algorithm
3
4 Termination of Processing
D Transmission of Output Data
5 Start of Output to Actuators
E Output Operation at the Actuator
6 Termination of Output Operation
1
Start of Cycle