Transcript No Slide Title

1
TU Wien
The Time-Triggered Architecture
for Real-Time Systems
H. Kopetz
TU Wien
© H. Kopetz 07/07/2015
Introduction
2
http://stf.rgai.hu
© H. Kopetz 07/07/2015
Introduction
3
Outline
 Introduction
 System Architecture
 Time-Triggered Protocols
 Composability--Temporal Firewalls
 Fault Tolerance
 Conclusion
© H. Kopetz 07/07/2015
Introduction
4
Our Goal
Our goal is to facilitate the systematic design of large dependable
control systems out of components. The interactions of the
components is realized by the exchange of messages across interfaces
to a real-time communication system.
The driving forces for the composition of a large System of Systems
(SOS) out of a set of components (component systems) are:
 Cognitive complexity reduction in order to reduce the design and
development effort
 Reuse of components: The components may be newly designed
according to a given architectural style or may be already existing
systems (legacy systems).
 Simplified diagnostics and repair.
© H. Kopetz 07/07/2015
Introduction
5
Report on US Air Traffic Control
In February 1997, the United States General Accounting
Office (GAO) published a report to the Secretary of
Transportation, Mr.F. Pena, about the design and
implementation of the new air traffic control system in
the US.
The author of the report was Dr. R. B. Stillman, Chief
Scientist for Computers and Telecommunications.
© H. Kopetz 07/07/2015
Introduction
6
ATC Plagued by Problems
“To illustrate, the long-time centerpiece of this modernization
program--the Advanced Automation System (AAS)--was
restructured in 1994 after estimated costs tripled from $2.5 billion
to 7.6 billion and delays in putting significantly less-thanpromised system capabilities into operation were expected to run 8
years or more.”
“For example, the per-unit cost estimate for the Voice Switching
and Control System increased 522 percent, and the first site
implementation was delayed 6 years from the original estimate.”
Source: GAO Report to the Secretary of Transportation, February 3, 1997, p.24
© H. Kopetz 07/07/2015
Introduction
7
Principal Findings of GAO Report
 An architecture is the centerpiece of sound system
development and maintenance.
 FAA is developing a logical architectural component for
ATC modernization and evolution.
 FAA lacks a technical architectural component to guide
and constrain ATC modernization and evolution.
 Without a technical ATC architecture, costly system
incompatibilities have resulted and will continue.
 FAA lacks an effective management structure for
developing and enforcing an ATC systems architecture.
© H. Kopetz 07/07/2015
Introduction
What is a Technical System Architecture?
A technical system architecture is a framework for the
construction of a system that constrains an implementation in
such a way that the ensuing system is understandable,
maintainable, extensible, and can be built cost-effectively.
© H. Kopetz 07/07/2015
Introduction
8
9
Technical System Architecture (II)
 Architectural style: An architecture must provide rules and
guidelines for the partitioning of a system into subsystems and for
the design of the interactions among the subsystems.
 Composability: An architecture must provide a framework for the
systematic construction of a system out of subsystems (components).
 Property Match: Components must comply with the architectural
style to avoid a property mismatch at the component interfaces.
 Elegance: An architecture must constrain an implementation in
such a way that the ensuing system is understandable, maintainable,
extensible, and can be built cost-effectively--in other words, it is
elegant.
Architecture Design is Interface Design
© H. Kopetz 07/07/2015
Introduction
10
Property Mismatches at Interfaces
Property
Physical, Electrical
Communication protocol
Syntactic
Flow control
Incoherence in naming
Data representation
Temporal
Dependability
Semantics
© H. Kopetz 07/07/2015
Example
Line interface, plugs,
CAN versus J1850
Endianness of data
Implicit or explicit,
Information push or pull
Same name for different entities
Different styles for data representation
Different formats for date
Different time bases
Inconsistent time-outs
Different failure mode assumptions
Differences in the meaning of the data
Introduction
Size versus Mental Effort to Understand
Mental Effort (Complexity)
Human Mental
Capability
If the mental effort
required to understand a
particular system
function grows with the
system size, there is an
inherent limitation to the
size of the systems we
can build.
Size
© H. Kopetz 07/07/2015
Introduction
11
12
Complexity and Size
 Large systems can only be built if the effort required to
understand the system operation, i.e, the complexity of the
system, remains under control as the system grows.
 The effort to understand any particular system function
should remain constant, and should be independent of the
system size.
 A large system contains many more different functions
than a small system.
 The effort needed to understand all functions of a large
system grows with the system size.
The design effort must be guided by technical system
architecture.
© H. Kopetz 07/07/2015
Introduction
Summary: A Good Distributed Architecture
13
 provides a framework and guidelines for the composition of a system
out of nearly autonomous components (subsystems) without the
occurrence of property mismatches.
 defines an architectural style.
 specifies the type of interactions among the components across welldefined and small interfaces. It thus builds structure by weak intercomponent coupling and strong intra-component coupling.
 provides interfaces that are flexible enough to support the intended
functions, but rigid enough to act as error containment boundaries.
 is based on already familiar orthogonal concepts that are used
recursively.
 is scalable without limits.
© H. Kopetz 07/07/2015
Introduction
Technology Trend to Distributed Systems
 System on a Chip (SOC) is the components: A complete
computer system, including, CPU, Memory, I/O, Communication
Controller, Operating Systems, and Application Software can be
implemented on a single silicon die: e.g., Motorola “Golden
Oak”
 Smart Sensors: Sensing Element, signal processing, calibration,
diagnosis, communication control on a single die.
 On-Chip Oscillators for low-cost nodes: cheap, but imprecise
 COTS: Commercial off the shelf components comprising
hardware and software
 Integrated Fault Tolerance: to mask faults, e.g. SEU (single
event upsets)--New failure modes of SOCs
© H. Kopetz 07/07/2015
Introduction
14
15
Economics of Silicon
Silicon real-estate requirements (today, i.e. in the year 2002):
ARMcore 32 bit CPU: 1 mm2
Infineon 256 Mbit DRAM: < 100 mm2 :
320 kbyte of DRAM: 1 mm2
 Marginal Production Costs of 1 mm2 of silicon is in the order
of 10 US cent (Cost at silicon foundry TSMC)
 Cost of packaging, testing, pins, power-supply significant and
often dominant.
 Marginal production costs of 100 mm2 silicon chip order of 10
US $.
One men minute of work buys how many megabytes of RAM?
© H. Kopetz 07/07/2015
Introduction
16
Time-Triggered Architecture (TTA)
 Safety without compromises
 No single point of failure
 Formal analysis of critical functions
 Composability:
 Building systems out of prevalidated components--Component
reuse
 Fully specified operational interfaces in the temporal domain
and value domain
 Two level design methodology
 Flexibility
 Flexible reuse of existing components
.
© H. Kopetz 07/07/2015
Introduction
17
TTA Overview
H
H
H
RT Communication System
TR
Digital on a
sparse time-base
TR
Controlled Object
© H. Kopetz 07/07/2015
H Host
TR Transducer
Data Sharing
Interface
Analog or Digital
dense time-base
Introduction
18
Design Principles of the TTA
 Establishment of a Consistent Distributed Computing
Base
 Global Time at every Node
 Temporal Accuracy of of Real-time Data
 Distinction between State and Event Observations
 Interfaces specified in the domains of time and value
 Transparent Fault Tolerance
© H. Kopetz 07/07/2015
Introduction
19
Validity of Real-Time Data
How long is the observation:
“The traffic light is green”
temporally accurate ?
The validity of real-time data is time dependent.
© H. Kopetz 07/07/2015
Introduction
20
Definition: Temporal Accuracy
The temporal accuracy of a RT image is defined by referring
to the recent history of observations of the related RT entity.
A recent history RHi at time ti is an ordered set of time points
<ti,ti-1,ti-2,. . . . ti-k>, where the length of the recent history
dacc = ti - ti-k
is called the temporal accuracy. Assume that the RT entity has
been observed at every time point of the recent history. A RT
image is temporally accurate at the present time ti
if
 tj RHi : Value( RTim ageat ti )  Value( RTentity at tj )
© H. Kopetz 07/07/2015
Introduction
21
State and Event Observation
An observation is a state observation, if the value of the
observation contains the full or partial state of the RT-entity.
The time of a state observation denotes the point in time when
the RT-entity was sampled.
An observation is an event observation, if the value of the
observation contains the difference between the “old state”
(the last observed state) and the “new state”. The time of the
event information denotes the point in time of the L-event of
the “new state”.
© H. Kopetz 07/07/2015
Introduction
Example of State and Event Observation
State observation (blue):
<Name of RT entity, Time of observation, full value>
The flow is at 5 l/sec a 10:45 a.m.
Event Observation (red):
<Name of Event, Time of event occurrence, state difference>
The flow changed by 1 l/sec at 10:45 a.m.
RT Image
RT Entity
© H. Kopetz 07/07/2015
Introduction
22
23
State versus Event Observations
Characteristic
State
Observation
Event
Observation
Value
Full Value
Value Difference
Frequency
Periodic
Sporadic
Loss of Observ. Period lost
Loss of synchr.
Semantics
At-least-once
Exactly-once
Error Detection
At receiver
At sender only
© H. Kopetz 07/07/2015
Introduction
24
Message
A message is an atomic data structure that is formed for the
purpose of inter-component communication. The endpoints of
the communication are the component interfaces.
In the temporal domain, a message can be characterized by
 The message send instant, i.e. the instant when the first bit
of the message leaves the sender.
 The message receive instant, i.e., the instant when the last
bit of the message arrives at the receiver.
© H. Kopetz 07/07/2015
Introduction
25
Interface
The interface between two subsystems (cluster, component,
etc.) is characterized by
 Its data properties, i.e., the structure and semantics of the
data items crossing the interface
 Its temporal properties, i.e., the temporal conditions that
have to be satisfied by the interface: control and temporal
data validity.
 The functional intent, i.e., the assumptions about the
functions of the interfacing partner
In a non-real-time computer system, there is little concern
about the temporal properties.
© H. Kopetz 07/07/2015
Introduction
26
Distributed System Interfaces
Component A
Interface
View
© H. Kopetz 07/07/2015
Communication
System
Messages
Component B
Interface
View
Introduction
27
Elementary vs. Composite Interface
Consider a unidirectional data flow between two subsystems
(e.g., data flow from sensor node to processing node).
We distinguish between:
Elementary
Interface:
Composite
Interface:
Control
A
Data
B
Example:
state message
in a DPRAM
B
Queue of
event messages
Control
A
Data
Elementary interfaces are inherently simpler than composite interfaces
© H. Kopetz 07/07/2015
Introduction
Information Push vs. Information Pull
Information Push Interface: Information producer pushes
information on information consumer (e.g., telephone, interrupt)
Information Pull Interfaces: Information consumer requests
information when required (e.g, email).
What is better in real-time systems?--For whom?
© H. Kopetz 07/07/2015
Introduction
28
State Message versus Event Message
29
 State Message: A periodic message that contains state observations
(synchronous).
Message handling: update in place and non-consuming read.
Periodic state messages can be implemented as an elementary interface
(no dependence of sender on receivers) with error detection at the
receiver.
 Event Message: A message that contains event observations
(asynchronous).
Message handling: exactly-once semantics, realized by message
queues. Requires a composite interface (dependence of sender on
receivers) for error detection at the sender.
(Compare “sampled message” and “queued message” in ARINC)
© H. Kopetz 07/07/2015
Introduction
Time Triggered (TT) vs. Event Triggered (ET)
A Real-Time system is Time Triggered (TT) if the control
signals, such as
 sending and receiving of messages
 recognition of an external state change
are derived from the progression of a (global) time.
A Real-Time system is Event Triggered (ET) if the control
signals are derived from the occurrence of events, e.g.,
 termination of a task
 reception of a message
 an external interrupt
© H. Kopetz 07/07/2015
Introduction
30
31
Basic Elements of the TTA
Assumes existence of a sparse global time and contains the following
four basic elements:
 Interface: a data-sharing boundary between two communicating
subsystems that contains temporally accurate state observations.
 Communication subsystem: transports real-time data in the
from of state messages from an output interface to an input
interface within a given time.
 Host computer: Reads input data from an input interface
(information pull), performs a data transformation and writes
output data into an output interface (information push) within a
given a priori known duration.
 Transducer: Transforms output data from an interface into a form
required by the system environment and transforms data from the
environment into the form required by an input interface.
© H. Kopetz 07/07/2015
Introduction
A Time-Triggered Architecture (TTA) Node
Control signals and data items to and
from the controlled object
Interface to Transducerss
Communication Network Interface (CNI)
Host computer including
application software
Host Computer
Communication Network Interface (CNI)
Interface to Other Nodes
Messages to and from the
real-time communication system
© H. Kopetz 07/07/2015
Introduction
32
33
TTP - Principle of Operation
 TTP generates a global time-base
 Media access is controlled by TDMA, based on this time
 Acknowledgement implicit by membership
 Error detection is at the receiver, based on the a priori
known receive time of messages
 State agreement between sender and receiver is enforced
by extended CRC calculation
 Every message header contains 3 mode change bits that
allow the specification of up to seven successor modes
© H. Kopetz 07/07/2015
Introduction
How well can we synchronize clocks?
© H. Kopetz 07/07/2015
Introduction
34
35
Sparse Time Base
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
© H. Kopetz 07/07/2015
Introduction
36
Uniform Time Format--OMG Standard
Time horizon
Time granularity
determined by
precision of GPS
Elapsed seconds since January 6, 1980 at
00:00(GPS base).
240 seconds
1 sec
2-24 sec
external time format (8 bytes)
Start of epoch: January 6, 1980 at 0:00:00 UTC
Granularity about 60 nanosecond
© H. Kopetz 07/07/2015
Introduction
37
Time and State
In abstract system theory (Mesarovic, p.45), the notion of
state is introduced in order to separate the past from the
future:
“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.”
A precise concept of time is a prerequisite for a
precise concept of state.
© H. Kopetz 07/07/2015
Introduction
Global Interactions versus Local Processing
Host
Computer
Host
Computer
Host
Computer
C
N
I
C
N
I
C
N
I
CC+MEDL
CC+MEDL
CC+MEDL
© H. Kopetz 07/07/2015
CC+MEDL
CC+MEDL
C
N
I
C
N
I
Host
Computer
Host
Computer
I/O
I/O
38
In the TTA,
the locus of
temporal
control
is in the
communication system.
In ET systems, the locus
of temporal control is in
host computers.
Introduction
39
TTP-Controller
TTP-Time
Interrupt
Host CPU
CNI in DPRAM
TTP
Controller
TTP Control
Data in MEDL
Protocol
Engine
Replicated TTP Bus
© H. Kopetz 07/07/2015
Introduction
40
Use of Apriori Knowledge
The a priori knowledge about the behavior is used to improve
the Error Detection: It is known a priori when a node has to
send a message (Life sign for membership).
 Message Identification: The point in time of message
transmission identifies a message (Reduction of message
size)
 Flow control: It is known a priori how many messages will
arrive in a peak-load scenario (Resource planning).
For event-triggered asynchronous architectures, there exists
an impossibility result: ‘It is impossible to distinguish a slow
node from a failed node!’ This makes the solution to the
membership problem very difficult.
© H. Kopetz 07/07/2015
Introduction
41
Continuous State Agreement
The internal state of a TTP controller (C-state) is formed by
the
 Time
 Operational Mode, and
 Membership
The Protocol will only work properly, if sender and receiver
contain the same state.
Therefore TTP contains mechanisms to guarantee continuous
state agreement (extended CRC checksum) and to avoid
clique formation (counts of positive and negative CRC
checks).
© H. Kopetz 07/07/2015
Introduction
42
TTP-A Objectives
 Composability and Testability
 Latency Guarantee for State Estimation
 Good Error Detection for fail safe operations
 Use of Standard UARTS (8 data bits with parity)
 High Data Efficiency (>50 %) and small latency
 Single wire (10 kbits) or twisted pair operation
 Clock Synchronization better than 1 msec
© H. Kopetz 07/07/2015
Introduction
43
Fault-Tolerant Sensor Connection
Fault Tolerant Unit
TTP/A Bus
A
Sensors
A
TTP/A
A
Host
TTP/C
Controlled Object
A
FTU
A
TTP/C
A
Host
TTP/A
TTP/A
TTP/C
A
© H. Kopetz 07/07/2015
TTP/A master controller
TTP/C controller
TTP/A slave node interfacing
to sensors and actuators
TTP/C Bus
Introduction
44
TTA and the CORBA Architecture
Time-Triggered
Architecture
TTA CNI
Object A
ORB at A
Corba Facilities:
Time
Internationalization
Domain Specific, e.g,
Banking
Health Care
Object B
ORB at B
Object Request Broker (ORB)--GIOP communication
Corba Services:
Naming
Transaction
Security
Persistent State
Event Notification, and more
© H. Kopetz 07/07/2015
Introduction
Integration of TT and ET Services--the Options
(i)
Parallel: Time Axes is divided into two parallel windows,
where one window is used for TT, the other for ET, Two media
access protocols needed, one TT, the other ET
Loss of
Temporal
Composability
TT
ET
TT
ET
Time
(ii)
Layered: ET service is implemented on top of a TT protocol
Single time triggered access media access protocol.
Loss of Global
Bandwidth
Sharing
Time
What are the consequences for global time and state?
© H. Kopetz 07/07/2015
Introduction
45
Architecture Design is Interface Design
A good interface within a distributed real-time system
 is precisely specified in the value domain and in the
temporal domain,
 provides the relevant abstractions of the interfacing
subsystems and hides the irrelevant details,
 leads to minimal coupling between the interfacing
subsystems,
 limits error propagation across the interface,
 Conforms to the established architectural style
and thus introduces structure into a system.
© H. Kopetz 07/07/2015
Introduction
46
47
Composability
Compose: “to make or form by combining things, parts, or elements”
Composition: “the act of combining parts or elements to form a whole”
Webster
Encyclopedic Dictionary, 1989, p. 302
Composability: “The ease of forming a whole by combining parts”
Parts: The component systems or the components
Whole: A system of systems (SOS).
A composition brings into existence new emerging services of the SOS that are more
than the sum of the prior services of the components.
These emerging services are the result of the integration of the component systems.
© H. Kopetz 07/07/2015
Introduction
48
What is a “Component”?
In our context, a component is complete computer system that
is time aware. It consists of
 The hardware
 The system and application software
 The internal state
The component interacts with its environment by the
exchange of messages via interfaces.
© H. Kopetz 07/07/2015
Introduction
Closed Component vs. Open Component
 Closed Component: Contains no local interface to the
real world, but can contain local interfaces to other closed
components.
Semi-closed if it is time-aware.
 Open Component: Contains an interface to the real
world.
Semi-open if no control signals are accepted from the realworld (e.g., a sampling system).
The real world has an unbounded number of properties.
© H. Kopetz 07/07/2015
Introduction
49
50
Interfaces of a Component
Diagnostic and Management Interface
(Boundary Scan in Hardware Design)
Local
Interfaces
Application
Software
Linking
Interface (LIF)
Relevant for Composability
Configuration Planning Interface
© H. Kopetz 07/07/2015
Introduction
51
Interfaces of a Component (ii)
Realtime Service (RS) Interface--the linking interface LIF:
 In control applications periodic
 Contains RT observations
 Time sensitive
Diagnostic and Maintenance (DM) Interface:
 Sporadic access
 Requires knowledge about internals of a node
 Not time sensitive
Configuration Planning (CP) Interface:
 Sporadic access
 Used to install a node into a new configuration
 Not time sensitive
Local Interface(s):
 To other nodes or the environment
 Not visible to the user of the component
© H. Kopetz 07/07/2015
Introduction
How is the “Integration” achieved?
 The component systems are integrated by the exchange of
messages across linking interfaces (LIF).
 Our focus is on what are the contents of a message (data)
and when a message is sent and received (time).
 We abstract from the low-level (physical, coding) aspects
of communication.
 We assume that all property mismatches of the interacting
systems have been resolved by a connection system.
© H. Kopetz 07/07/2015
Introduction
52
Only RS Interface Important for Composability
An RS interface to a RT service module (e.g., a control algorithm)
must specify:
 At what point in time the input information is delivered to a
module (temporal pre-conditions)
 At what point in time the output information must be produced by
the module (temporal post-conditions).
 The properties of the intended information transformation
provided by the module (a proper model)
The RS interface contains RT images of the relevant RT entities.
© H. Kopetz 07/07/2015
Introduction
53
54
Interface Specification
Operational Specification:
 Operational Input Interface Specification
 Syntactic Specification
 Temporal Specification
 Input Assertion
 Operational Output Interface Specification
 Syntactic Specification
 Temporal Specification
 Output Assertion
 Interface State
Meta-level Specification:
 Meaning of the data elements: Means-and-ends model
© H. Kopetz 07/07/2015
Introduction
Views of a System: Four Universe Model
User Level
Meaning of Data Types
Informational Level
Data Types
Meta-level Specification
Interpretation by the User
Operational Interface Specification
Value and Temporal
Logical Level
Bits
Physical Level
Analog Signals
Avizienis, FTCS 12, 1982
© H. Kopetz 07/07/2015
Introduction
55
Operational Input Interface Specification
 Syntactic Message Specification: Forms information
chunks out of the bit-stream of a message using a interface
definition language (e.g., IDL of the OMG): e.g.,
numbers, operations, text (see: Four Universe Model)
 Temporal Message Specification: Specifies when a
message is expected: instant, phase, frequency
 Operational Input Assertion: Specifies an executable
predicate on the incoming message (and the interface
state) of a component to determine whether the message is
permitted at the given instant.
Many specifications do not contain a precise temporal
specification and the operational input assertions.
© H. Kopetz 07/07/2015
Introduction
56
Operational Output Interface Specification
 Syntactic Message Specification: Specifies the structure
of an outgoing message: e.g., numbers, operations, text
(see: Four Universe Model)
 Temporal Message Specification: Specifies when a
message must be sent: instant, phase, frequency
 Operational Output Assertion: Specifies a predicate on
the outgoing message of a component to be able to
determine whether the message is well-formed.
© H. Kopetz 07/07/2015
Introduction
57
58
Interface State
The state of a component as seen from the point-of-view of
the interface:
 Only a (small) subset of the full state of the component
 Simplified if a sparse time model is supported
 Methods to access the interface state should be provided at
the interface
© H. Kopetz 07/07/2015
Introduction
59
Meta-Level Specification
The meta-level specification provides an interface model in
order that the meaning of the information chunks that cross
the interface can be established:
 Hierarchical Model according to means-and-end
relationship
 Understandable to the user of the interface
 Limits to formalization if components are open
© H. Kopetz 07/07/2015
Introduction
Reasoning about the Emerging Services
The specification of the LIF message interfaces that are involved in a
composition must be sufficient to reason about the properties of the
emerging services:
 LIFs must be precisely specified in the time and value domain
Interface model behind a LIF.
 LIFs should refer only to those aspects of a component systems that
are required for the composition.
 Dependence of the subsystem operation on the correct functioning
of a LIF partner should be minimized (Otherwise, violation of the
principle of the stability of prior services).
Only if the LIF specification is easier to comprehend than the full
subsystem specification, a complexity reduction is achieved.
© H. Kopetz 07/07/2015
Introduction
60
(Cognitive) Interface Complexity
An interface provides a view into a system.
The cognitive complexity of this view depends on
 Interface model
 Number and interaction of elements visible at the interface
 Representation (Documentation) of the interface
 Experience of the observer
......
The time it takes for an “average” user to understand an interface
documentation is a possible quantitative measure of cognitive
interface complexity.
© H. Kopetz 07/07/2015
Introduction
61
Complexity Reduction by Partitioning
Complexity Reduction:
(LIF Service Interface Complexity)/(Component Complexity)
A good decomposition will lead to a significant complexity
reduction for the understanding of the emerging functions at
the system level.
The easier it is, to understand
a LIF interface, the better
the decomposition from
the point of view of
complexity management.
© H. Kopetz 07/07/2015
Introduction
62
Complexity Reduction by Partitioning
Complexity Reduction:
(LIF Service Interface Complexity)/(Component Complexity)
A good decomposition will lead to a significant complexity
reduction for the understanding of the emerging functions at
the system level.
The easier it is, to understand
a LIF interface, the better
the decomposition from
the point of view of
complexity management.
© H. Kopetz 07/07/2015
Introduction
63
A Composition Involving three LIFs
Linking Interfaces (LIFs)
© H. Kopetz 07/07/2015
Introduction
64
The Five Principles of Composability (LIF)
65
(1) Independent Development of the Components (Architecture)
(2)
(3)
(4)
(5)
The message interfaces of the components must be precisely specified in the value
domain and in the temporal domain in order that the component systems can be
developed in isolation.
Stability of Prior Services (Component Implementation)
The prior services of the components must be maintained after the integration and
should not fail if a partner fails.
Performability of the Communication System (Comm. System)
The communication system transporting the messages must meet the given temporal
requirements under all specified operating conditions.
Replica Determinism (Architecture)
Replica Determinism is required for the transparent implementation of fault tolerance
Diagnosability (Architecture)
It must be possible to diagnose a faulty component
© H. Kopetz 07/07/2015
Introduction
66
Common Composability Violations
 Missing temporal specification of interfaces concerning
message rates and message receive instants (1).
 Prior services are impaired by excessive load across an
information push interface (e.g., interrupts) (2).
 At the critical instant, the communication system does
not meet the temporal requirements of the applications (3).
 Missing replica determinism destroys the fault-tolerance
strategy (4).
 Error propagation: The prior services of a component
become dependent on a fault of a LIF partner (2).
 Diagnosis: Impossibility to determine the sender of an
incorrect message (e.g., CAN) (5)
© H. Kopetz 07/07/2015
Introduction
Temporal Firewall Interface in the TTA
A temporal firewall interface
 is a unidirectional elementary data flow interface for the
exchange of state information.
 is located in a dual ported RAM of a communication
controller--update-in-place semantics
 the instants when data is fetched (delivered) from (to) the
communication system are a priori common knowledge to all
communicating partners (error detection!)
 eliminates control error propagation since no control signal
cross the temporal firewall interface
Input Firewall: Assumptions
Output Firewall: Guarantees
© H. Kopetz 07/07/2015
Introduction
67
68
Temporal Firewall Information Flow
Clock
Sender
Information Push
Ideal for Sender
CNI
Memory
CNI
Memory
Time-Triggered
Communication System
Receiver
Information Pull
Ideal for Receiver
Information flow
Control flow
© H. Kopetz 07/07/2015
Introduction
69
Temporal Firewall Characteristics
Fully specified in the domains of time and value and of low
cognitive complexity:
 Information Content: State Message versus Event Message
 Role: Linking Interface (LIF) versus Local Interface
 Dependency: Elementary versus Composite
 Control: Information Push at Sender and Information Pull
at Receiver
 Error Detection: Sender versus Receiver
The Temporal Firewall Interface is the simplest interface
we were able to come up with.
© H. Kopetz 07/07/2015
Introduction
A Temporal Firewall is a Natural Concept
 A temporal firewall is a high-level abstract concept.
 It is a small and stable unidirectional interface that
provides understandable abstractions of the relevant
properties of the interfacing subsystems.
 Timeliness is an integral part of the temporal firewall
concept.
 Conceptually, the RT images in the temporal firewall are
closely related to the image presented by a sensor of an
analog RT entity in the environment.
 Temporal firewalls are thus based on an accustomed
view of the world.
© H. Kopetz 07/07/2015
Introduction
70
71
Localized View of Global System
Cluster 1
Cluster 2
A
X
D
© H. Kopetz 07/07/2015
B
Y
C
Z
Introduction
Stable Properties of Temporal Firewalls
The following stable properties of temporal firewalls are known a
priori to all interfacing partners:
 The addresses (names) and the syntactic structure of the data items
in the temporal firewall.
 A (abstract) model explaining the meaning of the data items
contained in the temporal firewall.
 The points on the global time base when the data items in the
temporal firewall are accessed by the TT communication system.
This information enables the avoidance of race conditions between
the producer and the consumer.
 The temporal accuracy of the data items in the temporal firewall.
This knowledge is important to guide the information consumer
about the minimum rate of sampling of the temporal firewall.
© H. Kopetz 07/07/2015
Introduction
72
73
Temporal Firewalls and Validation
Assume a host that is encapsulated between two temporal
firewalls, and input firewall and an output firewall. These two
firewalls form the only interfaces of this host to its environment.
 The stable properties of the input firewall form important
preconditions for the validation of the component under
consideration. Many assumptions about the environment are
contained in the specification of this input firewall.
 The stable properties of the output firewall form important
postconditions of the validation.
 In the validation process it must be demonstrated that the
postconditions, given in the output firewall specification, are
always TRUE, provided the preconditions associated with the
input firewall hold.
© H. Kopetz 07/07/2015
Introduction
74
Example: A Five Cluster System
H
H
H
H
Collision
Avoidance
H
ECluster
H
H
H
H
H
T
H
Transponder
H
© H. Kopetz 07/07/2015
T
Radar
H
RT Image in Temporal
Accuracy Relationship
to RT entity
ECluster
H
T
Controlled
Object
(State
Variables
T are called
RT-Entities)
T
Introduction
Temporal Firewalls and Composability
A composable architecture must support the
(1) Independent development of components--relates to the
architecture
(2) Stability of prior services--relates to the components
(3) Performability of the Communication System--relates to the
communication system.
(4) Replica determinism--to support transparent implementation of
fault tolerance.
(5) Diagnostics--It mus be possible to identify the sending FCU
(Fault Containment Unit) of every message.
The temporal firewall concept supports these principles of
composability.
© H. Kopetz 07/07/2015
Introduction
75
Top-Down Design Process in the TTA
Level 1:
Decompose the design problem into clusters and components
Allocate functions to components
Investigate the data flow among the components
Specify the temporal firewalls in value and time
Estimate the failure rates and specify the fault-hypothesis
Specify the NGU Strategy
Level 2:
Implement the components, taking the temporal firewall
specifications as constraints.
© H. Kopetz 07/07/2015
Introduction
76
Composability and Reuse of Components
Composability and the effortless reuse of available components
are highly intertwined:
 The precisely defined component interfaces of a composable
architecture specify clearly what a user has to supply and
what a user can expect from an existing component.
 The “stability of prior service” principle ensures that the
functions of the existing component are not disturbed by the
integration.
 The “constructive integration” principle ensures that the
component integration is linear and not circular.
© H. Kopetz 07/07/2015
Introduction
77
Bottom-up Design--Reuse of Components
The bottom up design takes advantage of the existing COTS
components:
 The input firewall parameters determine what a user is
expected to supply
 The output firewall parameters determine what a user can
rely upon
The architecture design must proceed taking these component
characteristics as constraints.
The temporal firewalls of the new components can be
designed according to the top-down process.
© H. Kopetz 07/07/2015
Introduction
78
79
Legacy Systems
In many application legacy systems have to be integrated in a
new design:
 Identify the “Linking Interface” of the legacy system.
 Provide a gateway component that hides the idiosyncracies
of the legacy system and provides a standard interface
(wrapper technology) to the new architecture.
 Provide back-pressure flow control in the gateway
component.
© H. Kopetz 07/07/2015
Introduction
80
Localized View of Global System
Cluster 1
Cluster 2
A
X
D
© H. Kopetz 07/07/2015
B
Y
C
Z
Introduction
81
System States of a FT System
States outside
States covered by
Normal Failures
Rare Events
Correct
States
FT
Mechanisms
Fault-Hypothesis
Fault Hypothesis
© H. Kopetz 07/07/2015
NGU
Strategy
Introduction
Systems on a Chip (SOC) Failure Modes
In the future, new failure modes are expected to occur due to
the high integration density:
 Multi-bit failures caused by SEUs
 Intermittent failures due to proximity effects
In safety-critical applications, an SOC must be considered to
form a single fault-containment region with no restricting
assumptions about its possible failure modes.
© H. Kopetz 07/07/2015
Introduction
82
Slightly off Specification (SOS) Failure
Special type of Byzantine failure:
A component produces an output signal (in the value domain
or in the temporal domain) that is slightly outside the specified
operating interval.
Some receivers interpret the result correctly, some others
cannot interpret the result.
Voltage
SOS Sender
Receive Window
A
© H. Kopetz 07/07/2015
B
C
D
Correct Sender
E
Introduction
83
84
Example: Brake by Wire System
ABS
ABS
Master
ABS
ABS
A master with an SOS failure can cause inconsistencies.
© H. Kopetz 07/07/2015
Introduction
85
Physical Interconnection Structure
Fail-silent
faults
G
G
G
G
G
G
G
G
TTP-Bus
Arbitrary Faults
TTP-Star
© H. Kopetz 07/07/2015
Guardian
Guardian
Introduction
G
G
TTA Fault Containment and Error Detection
T iming Error Containment
Region 1
Guardian
on Chan. 1
Receiving
Node A
Guardian
on Chan. 2
Receiving
Node B
Sending
Node
T iming Error
Containment Region 2
© H. Kopetz 07/07/2015
Introduction
86
Order of Magnitude of Failure Rates
The following table gives an order of magnitude estimate of
possible failure rates in an automotive environment:
Message t ransmission t ime
0.36 msec
10-7 hours
2 T DMA rounds
3.6 msec
10-6 hours
Cluster recovery
36 msec
10-5 hours
Independent message loss
every six minutes
10-1 hours
ECU failure t ransient
102 hours
ECU failure permanent
107 hours
© H. Kopetz 07/07/2015
Introduction
87
88
Fault-Tolerant Unit (FTU)
A fault-tolerant unit (FTU) is a set of actively redundant
components that provide a fault tolerant service to its
environment:
 FTUs have to receive identical input messages in the same
order
 FTUs have to operate in replica determinism
 The output messages of FTUs should be idempotent
 As long as a defined subset of the components of the FTU
is operational, the FTU is considered operational
FTUs provide the continuous service by fault masking.
© H. Kopetz 07/07/2015
Introduction
89
Active Redundancy: TMR
© H. Kopetz 07/07/2015
Voter
Voter
Voter
Voter
Voter
Voter
Introduction
90
Design (Software) Faults
The application of fault-tolerance techniques to tolerate
software faults by design diversity is still an open research
area:
 If a disciplined software development process is followed
most remaining failures are due to incorrect specification
 Even independent programming teams tend to make
similar errors
 Replica Determinism can get lost if different algorithms
are used
However, an independent check of safety assertions makes
sense.
© H. Kopetz 07/07/2015
Introduction
91
Multilevel Architecture
High Level Cluster
Real-Time
Buses
Lower Level Cluster with limited
functionality, implemented on diverse
hardware and diverse software.
Field Bus
Sensors and
Actuators
© H. Kopetz 07/07/2015
Controlled Object
Introduction
92
Conclusions
 The Time-Triggered Architecture provides a framework
for the constructive design of dependable distributed realtime systems.
 Essential system functions (clock synchronization,
membership) are implemented in hardware to simplify the
application development.
 Major industries (aerospace, automotive, railway) are
supporting the paradigm shift towards the time-triggered
technology.
© H. Kopetz 07/07/2015
Introduction