CORBA in the Time-Triggered Architecture

Similar documents
OMG Smart Transducer Specification (I)

Chapter 39: Concepts of Time-Triggered Communication. Wenbo Qiao

TU Wien. Shortened by Hermann Härtig The Rationale for Time-Triggered (TT) Ethernet. H Kopetz TU Wien December H. Kopetz 12.

Diagnosis in the Time-Triggered Architecture

The Time-Triggered Architecture

An Encapsulated Communication System for Integrated Architectures

Real-Time Component Software. slide credits: H. Kopetz, P. Puschner

Real-Time System Modeling. slide credits: H. Kopetz, P. Puschner

Distributed Embedded Systems and realtime networks

TU Wien. Fault Isolation and Error Containment in the TT-SoC. H. Kopetz. TU Wien. July 2007

The Time-Triggered Ethernet (TTE) Design

TU Wien. Excerpt by Hermann Härtig The Rationale for Time-Triggered (TT) Ethernet. H Kopetz TU Wien December H. Kopetz 12.

Developing deterministic networking technology for railway applications using TTEthernet software-based end systems

Systems. Roland Kammerer. 10. November Institute of Computer Engineering Vienna University of Technology. Communication Protocols for Embedded

Applying CORBA to embedded time-triggered real-time systems. S. Aslam-Mir (Sam) Principal CORBA Architect Vertel USA

Real-Time Communication

A Look Ahead. Dependable Embedded Systems. Outline. H. Kopetz. July Encapsulated Execution Environments. Automotive Requirements

CS4514 Real-Time Systems and Modeling

A Comparison of TTP/C and FlexRay

16 Time Triggered Protocol

Adding Hard Real-Time Capabilities to CORBA

Virtual Networks in an Integrated Time-Triggered Architecture

Introduction to the Distributed Real-Time System

A Fault Management Protocol for TTP/C

Mixed-Criticality Systems based on a CAN Router with Support for Fault Isolation and Selective Fault-Tolerance

Amrita Vishwa Vidyapeetham. ES623 Networked Embedded Systems Answer Key

Compositional Design of RT Systems: A Conceptual Basis for Specification of Linking Interfaces

Real-Time Entities and Images

Page 1. Real-Time Communication. TU Wien. Outline. Example of the Networks onboar a Car. Requirements on RT Communication Protocols

Reliable UDP (RDP) Transport for CORBA

MicroQoSCORBA A QoS-Enabled, Reflective, and Configurable Middleware Framework for Embedded Systems

Field buses (part 2): time triggered protocols

Embedded Software Engineering

Deterministic Ethernet as Reliable Communication Infrastructure for Distributed Dependable Systems

Communication in Avionics

The Time-Triggered Model of Computation

Distributed IMA with TTEthernet

Integrated HW/SW Systems: Requirements

Real Time Operating Systems and Middleware

Component-Based Design of Large Distributed Real-Time Systems

Dependable Computer Systems

Today: Distributed Middleware. Middleware

Software Paradigms (Lesson 10) Selected Topics in Software Architecture

A Component Model and Software Architecture for CPS

Virtual Gateways in the DECOS Integrated Architecture

An Introduction to TTEthernet

Time-Triggered Ethernet

2. REAL-TIME CONTROL SYSTEM AND REAL-TIME NETWORKS

02 - Distributed Systems

Issues in Programming Language Design for Embedded RT Systems

Modeling and Verification of Distributed Real-Time Systems using Periodic Finite State Machines

The Timed Asynchronous Distributed System Model By Flaviu Cristian and Christof Fetzer

Integrated HW/SW Systems: Requirements

Syllabus Instructors:

System Models for Distributed Systems

Today: Distributed Objects. Distributed Objects

Model-Based Design of the Communication System in an Integrated Architecture

Introduction to Distributed Systems

Failure Tolerance. Distributed Systems Santa Clara University

A Multi-Modal Composability Framework for Cyber-Physical Systems

Programming Languages for Real-Time Systems. LS 12, TU Dortmund

Administrative Stuff. We are now in week 11 No class on Thursday About one month to go. Spend your time wisely Make any major decisions w/ Client

Subsystem Hazard Analysis (SSHA)

DISTRIBUTED REAL-TIME SYSTEMS

3. Quality of Service

02 - Distributed Systems

Interprocess Communication Tanenbaum, van Steen: Ch2 (Ch3) CoDoKi: Ch2, Ch3, Ch5

Flexible Fault Tolerance In Configurable Middleware For Embedded Systems

Communication. Overview

Today CSCI Remote Method Invocation (RMI) Distributed Objects

Real-Time Systems 1. Basic Concepts

Real-Time (Paradigms) (47)

Failure Models. Fault Tolerance. Failure Masking by Redundancy. Agreement in Faulty Systems

ARTIST-Relevant Research from Linköping

Introduction to Real-time Systems. Advanced Operating Systems (M) Lecture 2

Real-Time Operating Systems Design and Implementation. LS 12, TU Dortmund

Chapter 4 Communication

CSE 5306 Distributed Systems. Fault Tolerance

Communication. Distributed Systems Santa Clara University 2016

Evaluation of numerical bus systems used in rocket engine test facilities

Verteilte Systeme (Distributed Systems)

Time Triggered and Event Triggered; Off-line Scheduling

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

CORBA in Control Systems

Synthesis-driven Derivation of Process Graphs from Functional Blocks for Time-Triggered Embedded Systems. Ghennadii Sivatki

Time Handling in Programming Language

Multimedia Systems 2011/2012

Automotive and highly dependable Networks!

A Comparison of LIN and TTP/A

DTU IMM. MSc Thesis. Analysis and Optimization of TTEthernet-based Safety Critical Embedded Systems. Radoslav Hristov Todorov s080990

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 1. Introduction

Pattern-Based Analysis of an Embedded Real-Time System Architecture

Ensuring Schedulability of Spacecraft Flight Software

MODELS OF DISTRIBUTED SYSTEMS

Web Services - Concepts, Architecture and Applications Part 3: Asynchronous middleware

System types. Distributed systems

What is Multicasting? Multicasting Fundamentals. Unicast Transmission. Agenda. L70 - Multicasting Fundamentals. L70 - Multicasting Fundamentals

PROJECT FINAL REPORT

Investigation of System Timing Concerns in Embedded Systems: Tool-based Analysis of AADL Models

DISTRIBUTED COMPUTER SYSTEMS

Transcription:

1 CORBA in the Time-Triggered Architecture H. Kopetz TU Wien July 2003

Outline 2 Hard Real-Time Computing Event and State Messages The Time Triggered Architecture The Marriage of CORBA with the TTA Conclusion

What means Hard Real-Time Computing? 3 A real-time computer system must produce results before deadlines that are dictated by the enviroment. If the result has no utility after the deadline has passed, the deadline is called firm otherwise it is soft. If a catastrophe could result if a firm deadline is missed, the deadline is called hard. A real-time computer system that has to meet at least one hard deadline is called a hard real-time system. Hard- and soft real-time system design are fundamentally different. Examples for hard real time systems: Engine Control, X-by-Wire, Nuclear Power, Flight Control, Medical Systems

Hard Real Time versus Soft Real Time 4 Characteristic Hard Real Time Soft Real Time Response time hard soft Pacing environment computer Peak-Load Perform. predictable degraded Error Detection system user Safety critical non-critical Redundancy active standby Time Granularity millisecond second Data Files small/medium large Data Integrity short term long term

Example of a Hard Real-Time System 5 Communication Network Interface (CNI) within a node I/O Driver Interface Assistant System Gateway Body Body Electronics Network CC CC CC Communication System CC CC CC CC Brake Manager Engine Control Steering Manager Suspension I/O I/O I/O I/O CC: Communication Controller

What is a Component? 6 In our context, a component is complete computer system that is time aware and forms an independent Fault Containment Region (FCR). 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. What is a software component? Does it have state? Does it form an FCR?

Model of a Component Messages 7 h-state Input Start computation End Output Messages must be correct, both in the domains of time and value.

The 10-9 Challenge in Hard Real-Time Systems 8 The system as a whole must be more reliable than any one of its components: e.g., System Dependability 1 FIT--Component dependability 1000 FIT (1 FIT: 1 failure in 10 9 hours) Architecture must support fault-tolerance to mask component failures System as a whole is not testable to the required level of dependability. The safety argument is based on a combination of experimental evidence about the expected failure modes and failures rates of fault-containment regions (FCR) and a formal dependability model that depicts the system structure from the point of view of dependability.

Make Certain that Components Fail Independently 9 A component forms a Fault-Containment Region (FCR). Any dependence of FCR failures must be reflected in the dependability model--a challenging task! Independence is a system property. Independence of FCRs can be compromised by Shared physical resources (hardware, power supply, timebase, etc.) External faults (EMI, heat, shock, spatial proximity) Design Flow of erroneous messages Composite Interfaces

Some Important Concepts in Relation to Time 10 We assume a (dense) Newtonian time in the environment. Instant: cut of the timeline Duration: interval on the timeline Event: occurrence at an instant--has no duration Real Time Omniscient Observer: has a reference clock that is in perfect Synchrony with Atomic Time Absolute Timestamp: Timestamp generated by the reference clock

RT Entities, RT Images and RT Objects 11 Operator Distributed Computer Control Object B R T L A N C A C RT Entity RT Image RT Object A: Measured Value of Flow B: Setpoint for Flow C: Intended Valve Position

Real Time (RT) Entity 12 A Real-Time (RT) Entity is a state variable of interest for the given purpose that changes its state as a function of real-time. We distinguish between: Continuous RT Entities Discrete RT Entities Examples of RT Entities: Flow in a Pipe (Continuous) Position of a Switch (Discrete) Setpoint selected by an Operator Intended Position of an Actuator

Observation 13 Information about the state of a RT-entity at a particular point in time is captured in an observation. An observation is an atomic triple Observation = <Name, Time, Value> consisting of: The name of the RT-entity The point in real-time when the observation has been made The values of the RT-entity Observations are transported in messages.

State and Event Observation 14 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 Left-event of the new state. Old state New state Observation Real Time

Example of State and Event Observation 15 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

RT Image 16 A RT-Image is a picture of a RT Entity. A RT image is accurate at a given point in time, if it is an accurate representation, both in the domains of value and time, of the corresponding RT Entity. How long is the observation: The traffic light is green temporally accurate? Temporal parameters are associated with real-time data.

Temporal Accuracy of an RT Image 17 Value Accuracy Interval RT Entity RT Image Real-Time If a RT-image is updated by observations, then there will always be a delay between the state of the RT entity and that of the RT image

Jitter is Bad in Control Systems: 18 Observation of the Controlled Object Jitter: Variability of the Delay Delay Output Real-Time The consequences of a significant jitter: Measurement error increases Probability of Orphans Action Delay increases Clock Synchronization difficult Sporadic Failures in time-critical szenarios

Probability of Long Jitter in PAR Protocols 19 Probability Density Application specific critical jitter value System operates correctly System Failure d min d max Most of the time, the system will operate correctly. Length of Jitter

Elementary vs. Composite Interface 20 Consider a unidirectional data flow between two subsystems (e.g., data flow from sensor node to processing node). We distinguish between: Elementary Interface: Sender Control Receiver Example: state message in a DPRAM Composite Interface: Sender Receiver Queue of event messages A composite Interface introduces a control dependency between the Sender and Receiver and thus compromises their independence.

Elementary vs. Composite Interface 21 Consider a unidirectional data flow between two subsystems (e.g., data flow from sensor node to processing node). We distinguish between: Elementary Interface: Sender Control Receiver Example: state message in a DPRAM Composite Interface: Sender Receiver Queue of event messages A composite Interface introduces a control dependency between the Sender and Receiver and thus compromises their independence.

State Message versus Event Message 22 State Message: A periodic time-triggered 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: An event-triggered 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)

Examples of ET and TT Messages 23 ET Message: Client Server Request Interrupt Alarm Message Diagnostic Message TT Message: Data Sampling Control Loop Periodic Display Refresh Multimedia Flexibility, Openness. Best Effort Performance Temporal Predictability, Minimal Jitter

Unidirectional Information Transfer 24 Event-Message- Event Triggered: Sender Task CNI Queue Information Push CNI Queue Receiving Task Information Push State Messsage- Time Triggered: Sender Task CNI DPRAM Clock CNI DPRAM Receiving Task Information Push Control Data Information Pull

Comparison Event and State Message 25 Information Type Temporal Pattern Semantics Sender Access Receiver Access Synchronization Min. Temp. Distance Flow Control Error Detection Loss of Message Control Pattern Multicast Topology Jitter Event Messsage: Event Information Sporadic Exactly Once Queue--Add Mess. Dequeue--Consume Tight Unknown Explicit (PAR Prot.) At Sender Loss of State Synchr. Bidirectional (Queue) Difficult, Composite Significant State Messsage: State Information Periodic At least Once Read from DPRAM Overwrite DPRAM Loose Constant Implicit At Receiver Loss of Period Unidirectional Easy, Elementary Minimal

What Simplifies Open Interconnect? 26 Information Type Temporal Pattern Semantics Sender Access Receiver Access Synchronization Min. Temp. Distance Flow Control Error Detection Loss of Message Control Pattern Multicast Topology Jitter Event Messsage: Event Information Sporadic Exactly Once Queue--Add Mess. Dequeue--Consume Tight Unknown Explicit (PAR Prot.) At Sender Loss of State Synchr. Bidirectional (Queue) Difficult Significant State Messsage: State Information Periodic At least Once Read from DPRAM Overwrite DPRAM Loose Constant Implicit At Receiver Loss of Period Unidirectional Easy Minimal

What Simplifies Fault Tolerance (TMR)? 27 Information Type Temporal Pattern Semantics Sender Access Receiver Access Synchronization Min. Temp. Distance Flow Control Error Detection Loss of Message Control Pattern Multicast Topology Jitter Event Messsage: Event Information Sporadic Exactly Once Queue--Add Mess. Dequeue--Consume Tight Unknown Explicit (PAR Prot.) At Sender Loss of State Synchr. Bidirectional (Queue) Difficult Significant State Messsage: State Information Periodic At least Once Read from DPRAM Overwrite DPRAM Loose Constant Implicit At Receiver Loss of Period Unidirectional Easy Minimal

Preliminary Conclusion 28 In hard real-time systems, we need both services Event Message Transport State Message Transport Time-critical information should be transported in State Messages Event Messages provide open and flexible mechanisms for the transport of non-time critical information The Architecture must support analytical reasoning about its safety, since ultradependability is not testable.

The TTA is Waist-line Architecture 29 Higher-level Higher-level services: services: Application ET TT Transport Diagnosis Virtual Diagnosis Networks ET Gateway Transport FTU Etc. Layer Gateway Application Software using basic and higher level services New high-level services to ease application development Basic Services: TT Transport Clock Sync Fault Isolation Diagnosis Formally analyzed and validated basic services are available and stable Implementation of basic services is hidden from the application Extend the range of Implementation choices

Basic Services versus High-Level Services 30 The TTA distinguishes between four basis services and an openended set of high-level services. The basic services are: (1) Time Triggered Transport of Messages (2) Fault-Tolerant clock synchronization (3) Strong Fault-Isolation Services (4) Diagnostic service The high level services depend on the basic services, while the basic services do not depend on the high-level services!

Basic Service 1: Message Transport by TTP/C 31 TTP (Time-Triggered Protocol) generates a fault-tolerant global time-base. Media access is controlled by TDMA, based on this time. ET messages are piggy-packed on the basic TT messages. Information identified by the common knowledge of the send/receive times. Two independent intelligent star couplers provide fault isolation in the temporal domain. Membership service to detect crash/omission (CO) failures. Also used to detect violations of the fault hypothesis.

Basic Service 2: Fault-Tolerant Sparse Time Base 32 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. 0 1 2 3 4 5 6 7 8 9 Time π π π Events are only allowed to occur at subintervals of the timeline

Basic Service 3: Fault Isolation 33 In the Time-Triggered Architecture Fault-Containment Regions (FCRs) communicate by the exchange of messages: In a properly configured system, any FCR (node) can fail in an without disrupting the operation of the nodes that have not been directly affected by the fault. Error Detection in the Time Domain is in the responsibility of the architecture. It is performed by independent replicated guardians which are part of the architecture. Error Detection in the Value Domain is in the responsibility of the fault-tolerance layer or of the application (e.g., by TMR), supported by post condition checks at the guardians. TTP/C contains also a clique avoidance service, based on a membership service to detect a violation from the fault hypothesis.

Basic Service 4: Diagnosis 34 The TTP/C membership service checks continuously, which node is alive and which node has failed. It monitors the correctness of the distributed computing base. The periodic TT message of each node is interpreted as a life sign of the sender. In order to distinguish between a sender fault and a receiver fault, the view of a third node is considered to be the judge (single fault assumption) Delay of the membership service < 2 TDMA rounds.

HL Service: ET Transport 35 Layered: ET service is implemented on top of a TT protocol Single time triggered access media access protocol. Maintains Temporal Composability Time The CAN Protocol and the TCP/IP Protocol have been implemented on top of basic TTP/C in order to be able to use legacy software and to support the integration of CORBA.

HL Service: CORBA Integration 36 TTA CNI Time-Triggered Architecture 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

Constraints on a Proposed Solution in CORBA 37 Interoperability with traditional ORBs Provide Hard Real-Time capabilities by supporting State Message Transport in addtion to Event Message Transport Provide Composability Support of Fault Tolerance Support Analytical Reasoning about Dependability at the level of the base Architecture Should be viable on embedded systems (small footprint)

Proposed Solution 38!No changes required at ORB!Application dependent Extensible Transport Plugin (could be generated by a tool)!additional Overhead in the Extensible Transport Plugin (can be neglected if CPU power is significantly greater than network performance)!for a prototype we use the Open Communication Interface (OCI) as Extensible Transport

Proposed Mechanisms 39 Communication Infrastructure provides both ET Message Channel and TT Message Channel IIOP works over ET Message Channel without any modification. Extensible Transport Plugin on Client s Side decides if information is available locally or must be requested from the remote CORBA object.

Flow of State and Event Information in CORBA 40 Client ORB OCI TTP GIOP RT Data GIOP Event Information State Information Servant ORB OCI GIOP TTP GIOP RT Data CORBA RT Data Node n-1 Node n Node n+1

Delay and Jitter of a TT Message 41 At present TT implementations up to 25 Mbit/second are available: This implementations achieves: TDMA round (8 nodes) about 1 msec Transport delay about 125 µsec Jitter about 1 µsec Delay and Jitter at the application level depend on the internal structure of the node local operating system and middleware.

Conclusion 42 The proposed integration of CORBA in the TTA (timetriggered architecture) as developed within the HRTC project provides: An architecture which meets the safety requirements of ultradependable hard real-time application. The seamless integration of this architecture into the open information infrastructure by providing full compatibility with exisiting CORBA standards. A new mechanism for the transport of time-critical information within dedicated CORBA subsystems,