1 / 58

WP2: Hard Real-Time Protocols

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.

tieve
Download Presentation

WP2: Hard Real-Time Protocols

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WP2: Hard Real-Time Protocols Thomas Losert, Miguel Segarra, Karl-Erik Årzén

  2. Content • Introduction – Thomas Losert • CORBA & OCI – Miguel Segarra • Protocol Issues – Thomas Losert • TTPIOP – Thomas Losert • RTEIOP – Karl-Erik Årzén

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

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

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

  6. RT-CORBA & OCI Miguel Segarra

  7. Contents • How does CORBA work? • Specifications vs Reality • Sources of nondeterminism • Real-Time CORBA Transport Selection • Transport Plugin Framework

  8. How does CORBA work?

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

  10. 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();

  11. 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();

  12. Specification vs Reality

  13. CORBA Real-Time CORBA Specification vs Reality But close to the process resources are very limited! Time Service Minimum CORBA Messaging

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

  15. Sources of non-determinism

  16. Invoke priority threadpriority concurrency ORB connection protocol threadpriority ORB Sources of non-determinism Provide predictability by controlling ORB behavior Servant Client Skeleton Stub POA

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

  18. Real-Time CORBA Transport Selection

  19. Real-Time CORBA Transport Selection • A real-time CORBA broker

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

  21. Transport Plugin Framework

  22. Transport Plugin Framework Service handler Acceptor Pluggable transport protocol ORB Pluggable protocol framework threads Pluggable message support POA Connector

  23. OCI:Open Communications Interface

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

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

  26. Open Communications Interface OCI OCI+_RTE OCI_TCPIP OCI+_TTP GIOP GIOP GIOP RTEIOP TTPIOP IIOP

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

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

  29. Protocol Issues Thomas Losert

  30. General Issues • A Distributed Control System must be aware of the Progression of Time • The ORB must be aware of the Progression of Time

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

  32. Deadlines • In RTCORBA just Timeouts are supported(when set at client side) • Defined policies in the ORB but not implemented in the testbeds

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

  34. State vs. Event Values

  35. TTPIOP

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

  37. TDMA Media Access • TT communication system • Periodic transmission of state messages • Two redundant channels with TDMA • Sending slots • TDMA rounds Real Time

  38. Flow of State and Event Information in TTPIOP Event Information State Information

  39. RTEIOP Real-Time Communication over Switched Ethernet ThrottleNet: The link layer in the RT Ethernet approach

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

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

  42. Non Real-Time Traffic • Bandwidth is allocated to non-real time traffic • TCP, UDP, ….

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

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

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

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

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

  48. RTEIOP: ThrottleNet CORBA

  49. ThrottleNet and CORBA • ThrottleNet as the data link layer • Real-time CORBA requests on the same network as ordinary CORBA requests

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

More Related