Real-time and QoS -enabled middleware - RTCORBA, TAO, ZEN

1. Real-time and QoS-enabled middleware- RTCORBA, TAO, ZEN

2. Outline • DRE Systems • Real-time CORBA • TAO • ZEN

3. DRE  ----  Distributed, Real-time, Embedded Systems Characteristics of DRE systems • network  centric • stringent QoS demands      e.g., real-time performance requirements • resource constraints      e.g., embedded systems constraints in memory, power,processor etc. • mission critical control  Future DRE systems  • multi-QoS properties,such as predictable latency/jitter, throughput, scalability, dependability, security etc. much be satisfied simultaneously and often in real time. • different levels of services • trade-offs among the levels • The need for autonomous and time-critical apps rquire flexible system infrastructure components that can adapt robustly to dynamic changes in mission requirements and environmental conditions.  harder to develop, maintain, and evolve than mainstream desktop and enterprise software

4. Large-scale Switching Systems Total Ship Computing Environments IOM IOM BSE BSE BSE Examples of DRE Systems IOM IOM Total Ship C&C Center IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM IOM IOM BSE BSE BSE IOM IOM IOM IOM Avionics Industrial Process Control Theater Missile Defense

5. Motivation for QoS-enabled Middleware Trends • Hardware keeps getting smaller, faster, cheaper • Software keeps getting larger, slower, & more expensive Historical Challenges • Building distributed systems is hard • Building them on-time & under budget is even harder New Challenges • Many mission-critical distributed applications require real-time QoS support • e.g., combat systems, online trading, telecom • Building QoS-enabled applications manually is tedious, error-prone, & expensive • Conventional middleware does not support real-time QoS requirements effectively

6. problems with conventional approaches • Tedious and error-prone development - Accidental complexity proliferates, because DRE applications are often still developed using low-level languages, such as C and assembly language.  • Limited debugging tools - Although debugging tools are improving, real-time and embedded systems are still hard to debug, due to inherent complexities, such as concurrency, asynchrony, and remote debugging. • Validation and tuning complexities - It is hard to validate and tune key QoS properties, such as (1) pooling concurrency resources, (2) synchronizing concurrent operations, (3) enforcing sensor input and actuator output timing constraints, (4) allocating, scheduling, and assigning priorities to computing and communication resources end- to-end, and (5) managing memory. Middleware Solution

7. Overview of CORBA • Common Object Request Broker Architecture (CORBA) • A family of specifications • OMG is the standards body • Over 800 companies • CORBA defines interfaces, not implementations • It simplifies development of distributed applications by automating/encapsulating • Object location • Connection & memory mgmt. • Parameter (de)marshaling • Event & request demultiplexing • Error handling & fault tolerance • Object/server activation • Concurrency • Security • CORBA shields applications from heterogeneous platform dependencies • e.g., languages, operating systems, networking protocols, hardware

8. Early CORBA • Lack of QoS Specification • Lack of Real-time Features • Lack of Optimizations Not Suitable for DRE Systems

9. Real-time CORBA Features Management of • Processor resources • Communication resources • Memory resources

10. RT CORBA features • Explicit binding • Scheduling service • Thread pooling • End-to-end priority propagation • Portable priorities • Protocol properties

11. Explicit binding Deal with network resource issues • Control jitter due to connection setup • Minimize thread-level priority inversions • Avoid request-level (“head-of-line”) priority inversions

12. Controlling Network Resources • Connection pre-allocation • Eliminates a common source of operation jitter • Priority Banded Connection Policy • Invocation priority determines which connection is used • Private Connection Policy • Guarantees non-multiplexed connections Note the priority inversion below since the stop(), turn(), and query_state() requests all share the same connection

13. Scheduling service • Problem:How can Real-time CORBA give developers control over system resources while avoiding the following two deficiencies: • It can be tedious to configure all the CORBA client/server policies • Application developers must select the right priority values • Solution: Apply the Real-time CORBA Scheduling Service to simplify application scheduling • Developers just declare the current activity • i.e., a named chain of requests scheduled by the infrastructure • Properties of an activity are specified using an (unspecified) external tool

14. Client-side Scheduling • The client-side programming model is simple // Find the scheduling service RTCosScheduling::ClientScheduler_var scheduler = ...; // Schedule the ‘edge_alarm’ activity scheduler->schedule_activity (“edge_alarm”); controller->edge_alarm (); • Note the Scheduling Service is an optional part of Real-time CORBA 1.0

15. Server-side Scheduling • Servers can also be configured using the Scheduling Service // Obtain a reference to the scheduling service RTCosScheduling::ServerScheduler_var scheduler = ...; CORBA::PolicyList policies; // Set POA policies // The scheduling service configures the RT policies PortableServer::POA_var rt_poa = scheduler->create_POA (“ControllerPOA”, PortableServer::POAManager::_nil (), policies); // Activate the servant, and obtain a reference to it. rt_poa->activate_servant (my_controller); CORBA::Object_var controller = rt_poa->servant_to_reference (my_controller); // Configure the resources required for this object // e.g., setup interceptors to control priorities scheduler->schedule_object (controller, “CTRL_000”);

16. Thread pooling • Problem:How can we pre-allocate threading resources on the server portably & efficiently? • e.g., the Base_Stationmust have sufficient threads for all its priority levels • Solution:Use Real-time CORBA thread pooling

17. Real-time CORBA Thread Pools • Pre-allocation of threads • Partitioning of threads • Bounding of thread usage • Buffering of additional requests

18. Buffering requests Requests are buffered when all threads are busy Buffering can be specified in terms of: • Number of bytes • Number of requests When buffers are full: • A transient exception is thrown to client • Request is dropped by server • Request can be reissued later by client

19. Creating & Destroying Thread Pools interface RTCORBA::RTORB { typedef unsigned long ThreadpoolId; ThreadpoolIdcreate_threadpool (in unsigned long stacksize, in unsigned long static_threads, in unsigned long dynamic_threads, in Priority default_priority, in booleanallow_request_buffering, in unsigned long max_buffered_requests, in unsigned long max_request_buffer_size); void destroy_threadpool (in ThreadpoolIdthreadpool) raises (InvalidThreadpool); }; These are factory methods for controlling the life-cycle of Real-time CORBA thread pools

20. Thread Pool PRIORITY 20 POA A POA B S3 S4 S1 S2 20 20 CLIENT_PROPAGATED SERVER_DECLARED Installing Thread Pools on an RT-POA RTCORBA::ThreadpoolId pool_id = // From previous page // Create Thread Pool Policy RTCORBA::ThreadpoolPolicy_var tp_policy = rt_orb->create_threadpool_policy (pool_id); // Create policy lists for RT-POAs CORBA::PolicyList RTPOA_policies_a (2); RTPOA_policies_a.length (2); RTPOA_policies_a[0] = tp_policy; RTPOA_policies_a[1] = // Set CLIENT_PROPAGATED policy... CORBA::PolicyList RTPOA_policies_b (2); RTPOA_policies_b.length (2); RTPOA_policies_b[0] = tp_policy; RTPOA_policies_b[1] = // Set SERVER_DECLARED policy... // Create the RT-POAs PortableServer::POA_var rt_poa_a = root_poa->create_POA (“POA A”, PortableServer::POAManager::_nil (), RTPOA_policies_a); PortableServer::POA_var rt_poa_b = root_poa->create_POA (“POA B”, PortableServer::POAManager::_nil (), RTPOA_policies_b);

21. Extended RT POA Interface • module RTPortableServer { • local interface POA : PortableServer::POA { • PortableServer::ObjectId • activate_object_with_priority • (in PortableServer::Servant servant_ptr, • in RTCORBA::Priority priority) • raises (ServantAlreadyActive, • WrongPolicy); • // ... • }; • Real-time CORBA extends the POA interface via inheritance • Methods in this interface can override default SERVER_DECLARED priorities • // Activate object with default priority of RTPOA • My_Base_Station *station = new My_Base_Station; • base_station_poa->activate_object (station); • // Activate another object with a specific priority • RTPortableServer::POA_varrt_poa = • RTPortableServer::POA::_narrow (base_station_poa); • rt_poa->activate_object_with_priority (another_servant, • ANOTHER_PRIORITY);

22. Priority type system • CORBA priorities: 032767 • Native Priorities: platform dependent • ORB provides mapping between CORBA priorities and native priorities. users can provide custom mapping

23. Architecture of TAO

24. enhancements • Real-time IDL Stubs and Skeletons • Real-time Object Adapter • ORB Run-time Scheduler • Real-time ORB Core • Real-time I/O subsystem • High-speed network interface

25. Real-time IDL • Real-time applications that use TAO must specify their scheduled resource requirements to real-time scheduling service •  RT_Operations using the attributes of the RT_Info IDL

26. Real-time Object Adapter

27. ORB Run-time Scheduler • Off-line feasibility scheduling analysis  • Thread priority assignment  • Coordinate mode changes

28. Real-time ORB Core Real-time ORB core

29. Real-time I/O subsystem • TAO's real-time I/O subsystem minimizes priority inversion and hidden scheduling problems that arise during protocol processing. • Strategy is to have a pool of kernel threads dedicated to protocol processing and to associate these threads with application threads. The kernel threads run at the same priority as the application threads, which prevents various real-time scheduling hazards such as priority inversion and hidden scheduling.

30. High-speed network interface • At the heart of our I/O subsystem is a daisy-chained interconnect comprising one or more ATM Port Interconnect Controller (APIC) chips. • APIC can be used both as a endsystem/network interface, as well as an I/O interface chip. • It sustains an aggregate bi-directional data rate of 2.4 Gbps. • In addition, TAO is designed with a layered architecture that can run on conventional embedded platforms linked via QoS-enabled networks (such as IPv6 with RSVP) and real-time interconnects (such as VME backplanes and multi-processor shared memory environments).

31. Application to the CORBA Audio/Video Streaming Service • QoS parameters: • Application class (interactive or not) • Media types (audio, video…) • Adaptation policies (coeff. of compression) • CORBA A/V streaming service: • Flexible and portable  CORBA • Efficient low-level transport

32. The TAO A/V Streaming Service QoS Framework • QoS Mapping: • translation between network-level and application-level • QoS Monitoring: • application adaptation to resources at run-time • QoS-Based transport API: • Guarantees required bandwidth

33. ZEN • New project that’s implementing Real-time CORBA on top of RT-Java • http://www.zen.uci.edu/ • Key goals of ZEN • Flexible configuration • Small footprint • Load classes only as needed • On-demand or during initialization • Easily extensible • Code & compile new alternatives • Dynamically “plug” them in/out of the ORB • e.g., new protocols, Object Adapters, IOR formats, etc. • Real-time performance • Bounded jitter for ORB/POA operations • Eliminate sources of priority inversion • Access to RT-Java features in ORB by applications • Low startup latency

34. Overview of the Adaptive QuO-Middleware • QuO = Quality Objects • Allows specifying • QoS requirements • Control and monitoring information • Behavior for dealing with run-time problems • RPC  contract + QoS guarantees • Middleware in charge of QoS respect