Wp2 hard real time protocols
Download
1 / 58

WP2: Hard Real-Time Protocols - PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on

WP2: Hard Real-Time Protocols. Thomas Losert, Miguel Segarra, Karl-Erik Årzén. Content. Introduction – Thomas Losert CORBA & OCI – Miguel Segarra Protocol Issues – Thomas Losert TTPIOP – Thomas Losert RTEIOP – Karl-Erik Årzén. Introduction.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' WP2: Hard Real-Time Protocols' - tieve


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Wp2 hard real time protocols

WP2: Hard Real-Time Protocols

Thomas Losert, Miguel Segarra, Karl-Erik Årzén


Content
Content

  • Introduction – Thomas Losert

  • CORBA & OCI – Miguel Segarra

  • Protocol Issues – Thomas Losert

    • TTPIOP – Thomas Losert

    • RTEIOP – Karl-Erik Årzén


Introduction
Introduction

  • Decision on Testbeds is based on D2.1 „Analysis of Protocols for Real-Time Control“

  • Chosen TTP/C and RT-Ethernet as Protocols for the Testbeds

  • 100% reliability usually is not necessary in Control Systems (thus no retransmissions)


Main activities and achievements
Main Activities and Achievements

  • D2.2 HRT Protocol Specification

  • D2.3 HRT Protocol

  • Extra Documents:TTP Transport DefinitionRTE Transport Definition

  • 2 Prototype Implementations based on OCI exploring different variants (e.g., connection-less and connection-oriented)


Recommendations from previous review regarding d2 2
Recommendations from Previous Review regarding D2.2

We have implemented the following:

  • The selected pluggable framework (OCI) has been moved to the annex

  • A clarification for synchronization has been added

  • We have issued a revised version of the document (e.g., added timestamps, (a)periodic/sporadic tasks, next transmission time)


Rt corba oci

RT-CORBA & OCI

Miguel Segarra


Contents
Contents

  • How does CORBA work?

  • Specifications vs Reality

  • Sources of nondeterminism

  • Real-Time CORBA Transport Selection

  • Transport Plugin Framework



How does corba work1

IDL

C

L

I

E

N

T

S

E

R

V

A

N

T

I

D

L

I

D

L

Object Request Broker

POA

How does CORBA work?

  • Client Side

  • Server Side


How does corba work2

C

L

I

E

N

T

S

E

R

V

A

N

T

I

D

L

I

D

L

Object Request Broker

POA

How does CORBA work?

Client.GetValue();

Servant.GetValue();


How does corba work3

C

L

I

E

N

T

C

L

I

E

N

T

S

E

R

V

A

N

T

S

E

R

V

A

N

T

I

D

L

I

D

L

I

D

L

I

D

L

Object Request Broker

Object Request Broker

POA

POA

How does CORBA work?

GIOP

Client.GetValue();

Servant.GetValue();



Specification vs reality1

CORBA

Real-Time CORBA

Specification vs Reality

But close to the process resources are very limited!

Time

Service

Minimum

CORBA

Messaging


Specification vs reality2

Real-Time CORBA

CORBA

Time

Service

Messaging

Dynamic part of CORBA

Specification vs Reality

In embedded/real-time systems a lot of decisions are made at design time!

Minimum

CORBA



Sources of non determinism1

Invoke priority

threadpriority

concurrency

ORB

connection

protocol

threadpriority

ORB

Sources of non-determinism

Provide predictability by controlling ORB behavior

Servant

Client

Skeleton

Stub

POA


Sources of non determinism2

request dispatching

marhalling

marhalling

ORB

Memory mgmt

buffering

Memory mgmt

buffering

delay

threaddispatching

ORB

Sources of non-determinism

Impact on ORB architecture of predictability issues

Servant

Client

Skeleton

Stub

POA



Real time corba transport selection1
Real-Time CORBA Transport Selection

  • A real-time CORBA broker


Real time corba transport selection2

ORB B

ORB A

TCP/IP

TTP

Other

Real-Time CORBA Transport Selection

Object Reference

Client

Servant

Skeleton

Stub

RTOS A

RTOS B

Invocation

TTP

TCP/IP



Transport plugin framework1
Transport Plugin Framework

Service handler

Acceptor

Pluggable transport

protocol

ORB

Pluggable protocol framework

threads

Pluggable message

support

POA

Connector


Oci open communications interface

OCI:Open Communications Interface


Open communications interface
Open Communications Interface

  • It is an interface (abstract) for a transport plugin framework

    • It supports connection-oriented, reliable “byte-stream” transports. That is,transports which allow the transmission of a continuous stream of bytes(octets) fromthe sender to the receiver.

    • Non-reliable or non-connection-oriented protocols can also be used if the transportplug-in itself takes care of reliability and connection management.


Open communications interface1
Open Communications Interface

CLIENT SIDE

SERVER SIDE

IMPLEMENTATION

TCP/IP

Conn. Fact.

TCP/IP

Connector

TCP/IP

Transport

TCP/IP

Acceptor

TCP/IP

Acc. Fact.

Transport

Acceptor

Conn. Fact.

Connector

Acc. Fact.

n

n

1

1

ABSTRACT

Conn. Fact. Reg.

Acc. Fact. Reg.

ORB

creates


Open communications interface2
Open Communications Interface

OCI

OCI+_RTE

OCI_TCPIP

OCI+_TTP

GIOP

GIOP

GIOP

RTEIOP

TTPIOP

IIOP


Open communications interface3
Open Communications Interface

  • Hardware and software used

    • Sun UltraSparc

    • Power PC for TTP nodes

    • Power PC for VME boards

    • Axis developer board

  • Operating systems

    • Sun Solaris 8.0

    • RTAI Linux


Open communications interface4
Open Communications Interface

  • We did not foresee to make a lot of modifications to the ORB core but at the end we needed to make modifications in order to have pure oneway requests and to provide special transport handles for RTEthernet


Protocol issues

Protocol Issues

Thomas Losert


General issues
General Issues

  • A Distributed Control System must be aware of the Progression of Time

  • The ORB must be aware of the Progression of Time


Adding time awareness
Adding Time Awareness

  • Proposed Extension of the Transport: protocol_time, next_transmission_time, delivery_time, and precision

  • Additional Interfaces in RTCORBA-module allow the Application to Read these Values via the RTObject which is an additional interface we have implemented

  • Time-Format should be Simple: Chosen Time Format from Smart Transducers Interface Specification (formal/2003-01-01)


Deadlines
Deadlines

  • In RTCORBA just Timeouts are supported(when set at client side)

  • Defined policies in the ORB but not implemented in the testbeds


Changes extensions
Changes/Extensions

  • An RTORB contains a policy that decides between 100 ns and 60 ns

  • Timestamping (not implemented)

  • Proposed extension of IDL allows classification of tasks: periodic (RT), sporadic (RT), and aperiodic (no RT)




Composability
Composability

  • We call an architecture composable with respect to a specified property, if the system integration will not invalidate this property provided it has been established at the subsystem level, e.g.:

    • Timeliness

    • Testability

  • System properties should follow from subsystem properties.

    Otherwise the system integrator is left with the challenging task to find out why the system does not work, although all subsystems work according to their specifications.


Tdma media access
TDMA Media Access

  • TT communication system

  • Periodic transmission of state messages

  • Two redundant channels with TDMA

    • Sending slots

    • TDMA rounds

Real Time


Flow of state and event information in ttpiop
Flow of State and Event Information in TTPIOP

Event Information

State Information


Rteiop

RTEIOP

Real-Time Communication over Switched Ethernet

ThrottleNet: The link layer in the RT Ethernet approach


Switched ethernet
Switched Ethernet

  • Isolated collision domains

  • Full duplex communication

  • Inexpensive hardware (COTS) and high performance

  • Traffic control (throttling) guarantees end-to-end latency

  • Buffer delay causes jitter

Switch


Periodic real time channel
Periodic Real-Time Channel

  • One-way communication channel between sender and receiver

  • Parameters:

    • Frequency (maximum send rate)

    • Maximum transmit time (maximum message size)

    • Maximum allowed latency

  • Schedulability analysis decides if latency constraint holds


Non real time traffic
Non Real-Time Traffic

  • Bandwidth is allocated to non-real time traffic

  • TCP, UDP, ….


Throttling
Throttling

  • Traffic control through buffering

  • Ensure that sending nodes do not violate their periodicity

  • Bandwidth limitation

  • Applies to real-time traffic and non real- time traffic


Schedulability analysis
Schedulability Analysis

  • Worst-case based

  • Calculate the latencies for the worst-case buffering scenario

  • Take the buffer overflow into account

  • May result in considerable jitter

  • Implemented by a special node (the “GlobeThrottle”)

  • Dynamic admission of new channels


Globethrottle
GlobeThrottle

  • GlobeThrottle:

  • contains the global traffic information

  • schedules the RT traffic requests

  • updates the nodes when the schedule is changed

  • router for non-RT traffic

  • gateway to Internet

  • converts incoming broadcasts to scheduled unicasts

GlobeThrottle


Rt layer
RT-Layer

RT layer:

  • Traffic control for worst- case scheduling

  • Distinguish RT and non- RT traffic (RT header)

  • Fragmentation

    • Non RT traffic

    • RT traffic (may improve schedulability)


Related work
Related Work

  • K.G Shin et al (U of Michigan)

    • Throttled shared Ethernet

    • Statistical latency bounds

  • RTnet

    • Time-triggered Real-Time Ethernet

    • RTAI

    • Univ of Hannover



Throttlenet and corba
ThrottleNet and CORBA

  • ThrottleNet as the data link layer

  • Real-time CORBA requests on the same network as ordinary CORBA requests


Ordinary corba traffic
Ordinary CORBA traffic

  • IIOP messages tunneled over ThrottleNet

  • Fragmented and buffered to not disturb the real-time traffic

  • ThrottleNet transparent to IIOP

  • Buffering the only effect on IIOP


Real time traffic
Real-Time Traffic

  • GIOP requests from client to server mapped to ThrottleNet real-time channels

  • True one-way requests

    • Support for this added to the ICa ORB

  • GIOP messages tunneled over ThrottleNet


Real time traffic1
Real-Time Traffic

  • Explicit connection bindings -- validate_connection

    • avoid binding related overhead

    • the communication between the client and server in connection with the binding is from a scheduling point of view be considered as being part of the real-time channel communication


Throttlenet corba

CORBA client &server application code

RT-ORB

OCI+

RTE

IIOP

TCP

IP

RT

ThrottleNet

EthernetInterface

ThrottleNet CORBA

  • OCI with two parallel transport plug-ins

  • The application decides which transport to use


Throttlenet r t client
ThrottleNet R-T Client

  • Register the communication channel with the GlobeThrottle server.

  • If schedulability test in GlobeThrottle returns OK

    • Setup explicit connection

    • Communicate over the connection


Globethrottle1
GlobeThrottle

  • Could be implemented in different ways

    • As an ordinary CORBA object residing in one the nodes.

      • Communication using IIOP

    • As a new CORBA “real-time scheduling” service


Main characteristics
Main Characteristics

  • Close in spirit to ordinary CORBA

    • Unicast

    • Invocation-oriented event-triggered communication

  • RT traffic and CORBA IIOP traffic coexist on the network

  • One-way communication

  • Hard upper bounds on latency, but considerable jitter

  • Open Issues:

    • Is the GIOP message format efficient enough?


Possible future extension
Possible Future Extension

  • Global Clock

    • Improves schedulability and reduces jitter

    • Compare RTnet

  • Schedulability analysis for two-way invocations


Outlook
Outlook

  • Moving ORB from Usermode to Kernelmode is outside the scope of this project

  • Tool for offline-scheduling of IDL (for TTPIOP)

  • Clock Synchronisation (for RTEIOP)

  • Running the ORB in RTAI context or running the ORB in user context (e.g., with lxrt)


ad