Real-Time CORBA Chenyang Lu CSE 520S
CORBA Common Object Request Broker Architecture Ø CORBA specifications q OMG is the standards body q Over 800 companies q CORBA defines interfaces , not implementations Ø Object Request Brokers (ORB) allow clients to invoke operations on distributed objects transparently of q object location q programming language q operating system q communication protocols and interconnect q hardware 2
CORBA Architecture Ø CORBA: Common Object Request Broker Architecture Ø Remote Procedure Call (RPC): Client invokes operations on objects. Ø An Object = q An interface specified by an Interface Definition Language (IDL) q Servant(s) that implements the IDL interface 3
The ACE ORB (TAO) • Open-source Real-Time CORBA >> 1M SLOC • 100+ person • years of effort Pioneered • R&D on DRE middleware design & optimization Source: D.C. Schmidt, http://www.dre.vanderbilt.edu/~schmidt/TAO.html 4
Application Example: Avionics •Apply COTS & open systems to mission-critical real-time avionics •Deterministic & statistical deadlines •~20 Hz •Low latency & jitter •~250 u s •Periodic & aperiodic processing •Complex dependencies •Continuous platform upgrades • T est flown at China Lake NAWS by Boeing OSAT II '98 • www.cs.wustl.edu/~schmidt/TAO-boeing.html • Also used on SOFIA project by Raytheon • sofia.arc.nasa.gov • First use of Real-time CORBA in avionics • Drove Real-time CORBA standardization 5
Application Example: Hot Rolling Mills • Goals: Control the processing of molten steel moving through a hot rolling mill in real-time • System Characteristics •Hard real-time process automation requirements • i.e., 250 ms real-time cycles •System acquires values representing plant’s current state, tracks material flow, calculates new settings for the rolls & devices, & submits new settings back to plant • www.siroll.de • Key Software Solution Characteristics • Affordable, flexible, & COTS • Product-line architecture • Windows NT/2000 • Design guided by patterns & frameworks • Real-time CORBA 6
Application Example: Image Processing • www.krones.com • Goals: Examine glass bottles for defects in real-time • System Characteristics • Process 20 bottles/sec • ~50 ms per bottle • Networked configuration • ~10 cameras • Key Software Solution Characteristics • Affordable, flexible, & COTS • Embedded Linux • Remote booted by DHCP/TFTP • Compact PCI bus + Celeron processors • Real-time CORBA 7
RPC in CORBA Ø CORBA: Common Object Request Broker Architecture Ø Remote Procedure Call (RPC): Client invokes operations on objects. Ø An Object = q An interface specified by an Interface Definition Language (IDL) q Servant(s) that implements the IDL interface 8
Limitations of CORBA Ø Lacks QoS specification interfaces to applications q Applications cannot specify rate, deadline or importance Ø Lacks QoS enforcement q Does not map task QoS specification to priorities of threads q Contains significant priority inversion Ø Lacks performance optimization q Poor worst-case and average latency 9
Latencies and Priority Inversions 10
The ACE ORB (TAO) • Open-source Real-Time CORBA >> 1M SLOC • 100+ person • years of effort Pioneered • R&D on DRE middleware design & optimization 11
TAO Overview • Based on ACE wrapper Component Client facades & frameworks Services in args (Servant) OBJ operation() • Available on Unix, Win32, REF out args + return MVS, QNX, VxWorks, LynxOS, VMS... IDL • Thousands of users around SKEL the world Container IDL ORB DII STUBS INTERFACE Object Adapter ORB CORE GIOP/IIOP/ESIOPS Commercially supported Objective: Simplify the development of distributed real-time & embedded http://www.dre.vanderbilt.edu/~schmidt/commer cial-support.html (DRE) systems Approach: Use standard techology, patterns, & frameworks 12
I/O Subsystem: Priority Inversions Ø Messages are processed in FIFO order regardless of priorities Ø Kernel has lower priority than real-time priorities q Processing of a high priority message in the kernel can be blocked by a lower priority task at the application level 13
I/O Subsystem: Solutions Ø Early demultiplexing Ø Prioritized kernel processing Ø Map task priority to kernel thread Ø Note: This needs kernel support 14
ORB Core: Priority Inversions Ø Communication of different tasks shares a same socket connection. Ø Incoming requests are demultiplexed to threads in FIFO order. 15
ORB Core Priority-based Concurrency Architecture Ø Server sets model: Each priority is processed by a separate thread. Ø A separate connection is maintained for each priority in the server ORB. q Use buffered connections to reduce run-time overhead. Ø Suitable for fixed priority scheduling. 16
Object Adapter: Problems Ø Layered demultiplexing is inefficient in term of q average latency q worst-case latency 17
Object Adapter: Solutions Ø Perfect hashing q Generate a hash function offline q Computational complexity O(1) Ø De-layered active demultiplexing q Clients obtain index to (servant, operation) ahead of time 18
Reduce Priority Inversion Conventional ORB TAO 19
Real-Time Event Service •20
Limitations of RPC Ø Tight coupling between clients and server Ø Lacks asynchronous message delivery Ø Lacks support for group communication 21
Motivating Applications Boeing Bold Stroke Middleware Infrastructure Platform •Operations well defined •Event-mediated middleware solution Domain Company Avionics mission computing Boeing, Raytheon Mass storage devices SUTMYN, StorTek Medical Information Systems Siemens, GE Satellite Control LMCO COMSAT Telecommunications Motorola, Lucent, Nortel, Cisco, Siemens Missile & Radar Systems LMCO Sanders, Raytheon Steel Manufacturing Siemens ATD Beverage Bottling Automation Krones AG
CORBA Event Service Ø Asynchronous event delivery Ø Decouples suppliers and consumers one to one Ø Support group communication many to one many to many one to many 23
Event Delivery Models Event Channel pulls from Suppliers push to Event Suppliers, Consumers pull Channel, Event Channel from Event Channel pushes to Consumers Suppliers push to Event Event Channel pulls from Channel, Consumers pull from Suppliers, Event Channel pushes Event Channel to Consumers 24
CORBA Event Service Limitations Ø Broadcasts any supplied event to all consumers Ø No filtering or correlation Ø No real-time event dispatching/scheduling X Ø No periodic event X X 25
TAO Real-Time Event Service Ø Suppliers specify types of events generated. Ø Consumers subscribe to interested event types, to events from specific suppliers, or both. event A:S1 event B:S2 event C:S3 event B:S4 26
Event Channel Architecture Ø Push-push model for real-time delivery Ø Modularity: features are implemented in pluggable modules 27
Suspend and Resume Ø Light-weight operations to suspend/resume event delivery Ø Useful for frequent changes in consumer sets q Mode change 28
Periodic Events Ø Consumers can register for timeout events provided by Event Service Ø Timeout events dispatched according to priority of consumer 29
Event Correlation Ø Provides event correlation q Conjunctive (“AND”) q Disjunctive (“OR”) Conjunctive correlation 30
Scheduling Service Ø Separates dispatching mechanism from scheduling policy Ø Dispatcher consults run-time scheduler for priorities Ø Flexibility for different scheduling policies (e.g., RMS, EDF, MUF) 31
Real-Time Event Dispatching High Priority Dispatching Thread Kokyu Dispatching Queue Dispatching Thread Kokyu Dispatching Queue Dispatching Thread Kokyu Dispatching Queue Low Priority 32
Critiques Ø Full compatibility with CORBA q T oo complex and heavy-weight for embedded systems? Ø Centralized event channel q Scalability for distributed systems à federated event channel q Single point of failure à fault tolerant event channel Ø Overhead of redirection Ø Support for multicore and multiprocessor platforms. 33
Federated Event Channel Ø Gateway forwards events to remote processors. EC EC EC Gateway Gateway T 13 T 11 T 12 Application Application Application Processor 1 Processor 2 Processor 3
Source Ø Slides partially based on Douglas Schmidt’s TAO tutorial and Joe Hoffert’s class presentation. 35
Recommend
More recommend
