92
1 © H. Kopetz 03/27/22 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

Embed Size (px)

Citation preview

Page 1: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

1

© H. Kopetz 04/19/23 Introduction

TU Wien

The Time-Triggered Architecture for Real-Time Systems

H. KopetzTU Wien

Page 2: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

2

© H. Kopetz 04/19/23 Introduction

http://stf.rgai.hu

Page 3: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

3

© H. Kopetz 04/19/23 Introduction

Outline

Introduction System Architecture Time-Triggered Protocols Composability--Temporal Firewalls Fault Tolerance Conclusion

Page 4: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

4

© H. Kopetz 04/19/23 Introduction

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.

Page 5: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

5

© H. Kopetz 04/19/23 Introduction

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.

Page 6: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

6

© H. Kopetz 04/19/23 Introduction

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-than-promised 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

Page 7: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

7

© H. Kopetz 04/19/23 Introduction

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.

Page 8: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

8

© H. Kopetz 04/19/23 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.

Page 9: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

9

© H. Kopetz 04/19/23 Introduction

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

Page 10: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

10

© H. Kopetz 04/19/23 Introduction

Property Mismatches at Interfaces

Property ExamplePhysical, Electrical Line interface, plugs,Communication protocol CAN versus J1850Syntactic Endianness of dataFlow control Implicit or explicit,

Information push or pullIncoherence in naming Same name for different entitiesData representation Different styles for data representation

Different formats for dateTemporal Different time bases

Inconsistent time-outsDependability Different failure mode assumptionsSemantics Differences in the meaning of the data

Page 11: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

11

© H. Kopetz 04/19/23 Introduction

Human MentalCapability

Size versus Mental Effort to Understand

Mental Effort (Complexity)

Size

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.

Page 12: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

12

© H. Kopetz 04/19/23 Introduction

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.

Page 13: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

13

© H. Kopetz 04/19/23 Introduction

Summary: A Good Distributed Architecture

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 well-

defined and small interfaces. It thus builds structure by weak inter-component 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.

Page 14: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

14

© H. Kopetz 04/19/23 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

Page 15: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

15

© H. Kopetz 04/19/23 Introduction

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?

Page 16: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

16

© H. Kopetz 04/19/23 Introduction

Time-Triggered Architecture (TTA)

Safety without compromises No single point of failureFormal analysis of critical functions

Composability: Building systems out of prevalidated components--

Component reuseFully specified operational interfaces in the temporal domain

and value domainTwo level design methodology

FlexibilityFlexible reuse of existing components

.

Page 17: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

17

© H. Kopetz 04/19/23 Introduction

TTA Overview

Controlled Object

RT Communication System

H H H

TR TR

H HostTR Transducer Data Sharing Interface

Analog or Digitaldense time-base

Digital on asparse time-base

Page 18: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

18

© H. Kopetz 04/19/23 Introduction

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

Page 19: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

19

© H. Kopetz 04/19/23 Introduction

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.

Page 20: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

20

© H. Kopetz 04/19/23 Introduction

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∃ t j∈RHi : Value ( RT image at ti) = Value ( RT entity at t j )

Page 21: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

21

© H. Kopetz 04/19/23 Introduction

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”.

Page 22: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

22

© H. Kopetz 04/19/23 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 Entity

RT Image

Page 23: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

23

© H. Kopetz 04/19/23 Introduction

State versus Event Observations

Characteristic StateObservation

EventObservation

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

Page 24: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

24

© H. Kopetz 04/19/23 Introduction

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.

Page 25: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

25

© H. Kopetz 04/19/23 Introduction

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.

Page 26: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

26

© H. Kopetz 04/19/23 Introduction

Distributed System Interfaces

CommunicationSystem

Inter-face View

Inter-face View

Component A Component B

Messages

Page 27: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

27

© H. Kopetz 04/19/23 Introduction

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:

A BData

ControlElementary Interface:

A BData

ControlComposite Interface:

Elementary interfaces are inherently simpler than composite interfaces

Example:state messagein a DPRAM

Queue ofevent messages

Page 28: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

28

© H. Kopetz 04/19/23 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?

Page 29: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

29

© H. Kopetz 04/19/23 Introduction

State Message versus Event Message

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)

Page 30: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

30

© H. Kopetz 04/19/23 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

Page 31: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

31

© H. Kopetz 04/19/23 Introduction

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.

Page 32: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

32

© H. Kopetz 04/19/23 Introduction

A Time-Triggered Architecture (TTA) Node

Interface to Transducerss

Host computer includingapplication software

Communication Network Interface (CNI)

Interface to Other Nodes

Communication Network Interface (CNI)

Control signals and data items to and from the controlled object

Messages to and from the real-time communication system

Host Computer

Page 33: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

33

© H. Kopetz 04/19/23 Introduction

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

Page 34: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

34

© H. Kopetz 04/19/23 Introduction

How well can we synchronize clocks?

Page 35: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

35

© H. Kopetz 04/19/23 Introduction

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. 0123456789TimeEvents are only allowed to occur at subintervals of the timelineΔπΔππ

Page 36: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

36

© H. Kopetz 04/19/23 Introduction

Uniform Time Format--OMG Standard

external time format (8 bytes)

Elapsed seconds since January 6, 1980 at 00:00(GPS base).

2-24 sec1 sec

Time horizon Time granularitydetermined by

precision of GPS

240 seconds

Start of epoch: January 6, 1980 at 0:00:00 UTCGranularity about 60 nanosecond

Page 37: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

37

© H. Kopetz 04/19/23 Introduction

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.

Page 38: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

38

© H. Kopetz 04/19/23 Introduction

Global Interactions versus Local Processing

HostComputer

C NI

CC+MEDL

HostComputer

CC+MEDL

HostComputer

CC+MEDL

HostComputer

CC+MEDL

HostComputer

CC+MEDL

C NI

C NI

C NI

C NI

I/O I/O

In the TTA, the locus of temporal control

is in the communic- ation system.

In ET systems, the locus of temporal control is inhost computers.

Page 39: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

39

© H. Kopetz 04/19/23 Introduction

TTP-Controller

ProtocolEngine

CNI in DPRAM

Host CPU

TTP ControlData in MEDL

TTP-Time Interrupt

Replicated TTP Bus

TTP

Controller

Page 40: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

40

© H. Kopetz 04/19/23 Introduction

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.

Page 41: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

41

© H. Kopetz 04/19/23 Introduction

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).

Page 42: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

42

© H. Kopetz 04/19/23 Introduction

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

Page 43: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

43

© H. Kopetz 04/19/23 Introduction

Fault-Tolerant Sensor Connection

TTP/A

TTP/C

TTP/C

TTP/A

A A A

A A A

Controlled Object

Sensors

TTP/A Bus

Host

Host

FTU

TTP/A TTP/A master controllerTTP/C TTP/C controllerA TTP/A slave node interfacing to sensors and actuators

Fault Tolerant Unit

TTP/C Bus

Page 44: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

44

© H. Kopetz 04/19/23 Introduction

TTA and the CORBA Architecture

Object Request Broker (ORB)--GIOP communication

ORB at A ORB at B

Object A Object B

Corba Facilities:TimeInternationalizationDomain Specific, e.g,

BankingHealth Care

Corba Services:NamingTransactionSecurityPersistent StateEvent Notification, and more

Time-TriggeredArchitecture

TTA CNI

Page 45: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

45

© H. Kopetz 04/19/23 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

TT ET TT ET Time

(ii) Layered: ET service is implemented on top of a TT protocol Single time triggered access media access protocol.

Time

Loss ofTemporal

Composability

Loss of GlobalBandwidth

Sharing

What are the consequences for global time and state?

Page 46: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

46

© H. Kopetz 04/19/23 Introduction

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.

Page 47: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

47

© H. Kopetz 04/19/23 Introduction

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.

Page 48: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

48

© H. Kopetz 04/19/23 Introduction

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.

Page 49: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

49

© H. Kopetz 04/19/23 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 real-world (e.g., a sampling system).

The real world has an unbounded number of properties.

Page 50: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

50

© H. Kopetz 04/19/23 Introduction

Interfaces of a Component

ApplicationSoftware

Linking Interface (LIF)Relevant for Composability

Diagnostic and Management Interface(Boundary Scan in Hardware Design)

Configuration Planning Interface

LocalInterfaces

Page 51: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

51

© H. Kopetz 04/19/23 Introduction

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

Page 52: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

52

© H. Kopetz 04/19/23 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.

Page 53: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

53

© H. Kopetz 04/19/23 Introduction

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.

Page 54: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

54

© H. Kopetz 04/19/23 Introduction

Interface Specification

Operational Specification: Operational Input Interface Specification

Syntactic SpecificationTemporal Specification Input Assertion

Operational Output Interface SpecificationSyntactic SpecificationTemporal SpecificationOutput Assertion

Interface StateMeta-level Specification: Meaning of the data elements: Means-and-ends model

Page 55: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

55

© H. Kopetz 04/19/23 Introduction

Views of a System: Four Universe Model

Physical LevelAnalog Signals

Logical LevelBits

Informational LevelData Types

User LevelMeaning of Data Types

Operational Interface SpecificationValue and Temporal

Meta-level SpecificationInterpretation by the User

Avizienis, FTCS 12, 1982

Page 56: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

56

© H. Kopetz 04/19/23 Introduction

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.

Page 57: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

57

© H. Kopetz 04/19/23 Introduction

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.

Page 58: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

58

© H. Kopetz 04/19/23 Introduction

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

Page 59: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

59

© H. Kopetz 04/19/23 Introduction

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

Page 60: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

60

© H. Kopetz 04/19/23 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.

Page 61: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

61

© H. Kopetz 04/19/23 Introduction

(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.

Page 62: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

62

© H. Kopetz 04/19/23 Introduction

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 understanda LIF interface, the better the decomposition from the point of view of complexity management.

Page 63: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

63

© H. Kopetz 04/19/23 Introduction

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 understanda LIF interface, the better the decomposition from the point of view of complexity management.

Page 64: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

64

© H. Kopetz 04/19/23 Introduction

A Composition Involving three LIFs

Linking Interfaces (LIFs)

Page 65: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

65

© H. Kopetz 04/19/23 Introduction

The Five Principles of Composability (LIF)

(1) Independent Development of the Components (Architecture)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.

(2) 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.

(3) Performability of the Communication System (Comm. System)The communication system transporting the messages must meet the given temporal requirements under all specified operating conditions.

(4) Replica Determinism (Architecture)Replica Determinism is required for the transparent implementation of fault tolerance

(5) Diagnosability (Architecture)It must be possible to diagnose a faulty component

Page 66: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

66

© H. Kopetz 04/19/23 Introduction

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)

Page 67: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

67

© H. Kopetz 04/19/23 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: AssumptionsOutput Firewall: Guarantees

Page 68: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

68

© H. Kopetz 04/19/23 Introduction

Temporal Firewall Information Flow

SenderCNIMemoryCNIMemoryReceiverInformation PushIdeal for Sender Information PullIdeal for ReceiverTime-TriggeredCommunication System

Clock

Information flow

Control flow

Page 69: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

69

© H. Kopetz 04/19/23 Introduction

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.

Page 70: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

70

© H. Kopetz 04/19/23 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.

Page 71: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

71

© H. Kopetz 04/19/23 Introduction

Localized View of Global System

A

B

C

D

Y

Z

X

Cluster 1 Cluster 2

Page 72: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

72

© H. Kopetz 04/19/23 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.

Page 73: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

73

© H. Kopetz 04/19/23 Introduction

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.

Page 74: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

74

© H. Kopetz 04/19/23 Introduction

Example: A Five Cluster System

TransponderH

H

HH

CollisionAvoidance

H

Radar

H H

H

H

H H

H

H

ECluster

ControlledObject

(State Variablesare called

RT-Entities)

H

RT Image in Temporal Accuracy Relationship to RT entityECluster

T

T

T

T

T

Page 75: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

75

© H. Kopetz 04/19/23 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.

Page 76: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

76

© H. Kopetz 04/19/23 Introduction

Top-Down Design Process in the TTA

Level 1:Decompose the design problem into clusters and componentsAllocate functions to componentsInvestigate the data flow among the componentsSpecify the temporal firewalls in value and timeEstimate the failure rates and specify the fault-hypothesisSpecify the NGU StrategyLevel 2:Implement the components, taking the temporal firewall specifications as constraints.

Page 77: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

77

© H. Kopetz 04/19/23 Introduction

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.

Page 78: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

78

© H. Kopetz 04/19/23 Introduction

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.

Page 79: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

79

© H. Kopetz 04/19/23 Introduction

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.

Page 80: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

80

© H. Kopetz 04/19/23 Introduction

Localized View of Global System

A

B

C

D

Y

Z

X

Cluster 1 Cluster 2

Page 81: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

81

© H. Kopetz 04/19/23 Introduction

States outside

Fault Hypothesis

States covered by

Fault-Hypothesis

System States of a FT System

CorrectStates

FTMechanisms

NGUStrategy

Normal Failures

Rare Events

Page 82: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

82

© H. Kopetz 04/19/23 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.

Page 83: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

83

© H. Kopetz 04/19/23 Introduction

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

Receive WindowSOS Sender

A B C D E

Correct Sender

Page 84: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

84

© H. Kopetz 04/19/23 Introduction

Example: Brake by Wire System

ABS ABS

ABS ABS

Master

A master with an SOS failure can cause inconsistencies.

Page 85: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

85

© H. Kopetz 04/19/23 Introduction

Physical Interconnection Structure

G G G G G G G G G G

Guardian Guardian

TTP-Bus

TTP-Star

Arbitrary Faults

Fail-silentfaults

Page 86: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

86

© H. Kopetz 04/19/23 Introduction

TTA Fault Containment and Error Detection

SendingNodeGuardianon Chan. 1Guardianon Chan. 2

ReceivingNode AReceiving Node B

Timing Error ContainmentRegion 1

Timing Error Containment Region 2

Page 87: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

87

© H. Kopetz 04/19/23 Introduction

Order of Magnitude of Failure Rates

Message transmission time 0.36 msec 10-7 hours

2 TDMA 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 transient 102 hours

ECU failure permanent 107 hours

The following table gives an order of magnitude estimate of possible failure rates in an automotive environment:

Page 88: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

88

© H. Kopetz 04/19/23 Introduction

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.

Page 89: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

89

© H. Kopetz 04/19/23 Introduction

Active Redundancy: TMR

VoterVoter Voter

VoterVoterVoter

Page 90: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

90

© H. Kopetz 04/19/23 Introduction

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.

Page 91: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

91

© H. Kopetz 04/19/23 Introduction

Controlled Object

Sensors andActuators

Field Bus

High Level Cluster Lower Level Cluster with limitedfunctionality, implemented on diverse hardware and diverse software. Real-Time

Buses

Multilevel Architecture

Page 92: 1 © H. Kopetz 11/09/2015 Introduction TU Wien The Time-Triggered Architecture for Real-Time Systems H. Kopetz TU Wien

92

© H. Kopetz 04/19/23 Introduction

Conclusions

The Time-Triggered Architecture provides a framework for the constructive design of dependable distributed real-time 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.