Home >Documents >Middleware for Distributed Real-time & Embedded Systems

Middleware for Distributed Real-time & Embedded Systems

Date post:15-Jan-2016
View:40 times
Download:0 times
Share this document with a friend
Middleware for Distributed Real-time & Embedded Systems. Dr. Douglas C. Schmidt [email protected] www.dre.vanderbilt.edu/TAO/. Professor of EECS Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee. Hardware keeps getting smaller, faster, & cheaper. - PowerPoint PPT Presentation
  • Middleware for Distributed Real-time & Embedded Systems Dr. Douglas C. [email protected]/TAO/Professor of EECSInstitute for Software Integrated Systems Vanderbilt University Nashville, Tennessee

  • Motivation for QoS-enabled MiddlewareTrendsMany mission-critical distributed applications require real-time QoS supporte.g., combat systems, online trading, telecomBuilding QoS-enabled applications manually is tedious, error-prone, & expensiveConventional middleware does not support real-time QoS requirements effectivelyBuilding distributed systems is hardBuilding them on-time & under budget is even harder

  • Motivating Mission-Critical ApplicationsLarge-scale Switching SystemsIndustrial Process ControlTheater Missile Defense

  • Problems with Current Approaches

  • Middleware: A More Effective ApproachDevelop & apply the new generation of distributed object computing (DOC) middleware technologies to Simultaneously control multiple QoS properties & Improve software development quality, productivity, adaptability, & assurability

  • Why We are SucceedingThe past decade has yielded significant progress in QoS-enabled middleware, stemming in large part from the following trends:

  • Overview of CORBA CORBA shields applications from heterogeneous platform dependenciese.g., languages, operating systems, networking protocols, hardwareCommon Object Request Broker Architecture (CORBA)A family of specificationsOMG is the standards bodyOver 800 companiesCORBA defines interfaces, not implementationsIt simplifies development of distributed applications by automating/encapsulatingObject locationConnection & memory mgmt.Parameter (de)marshalingEvent & request demultiplexingError handling & fault toleranceObject/server activationConcurrencySecurity

  • Caveat: Requirements & Historical Limitations of CORBA for Real-time SystemsRequirementsLocation transparencyPerformance transparencyPredictability transparencyReliability transparencyHistorical LimitationsLack of QoS specificationsLack of QoS enforcementLack of real-time programming featuresLack of performance optimizations

  • Real-Time CORBA OverviewRT CORBA adds QoS control to regular CORBA to improve application predictability, e.g.,Bounding priority inversions & Managing resources end-to-end

    Policies & mechanisms for resource configuration/control in RT-CORBA include:Processor ResourcesThread poolsPriority modelsPortable prioritiesCommunication ResourcesProtocol policiesExplicit bindingMemory ResourcesRequest buffering

    These capabilities address some (but by no means all) important real-time application development challengesReal-time CORBA leverages the CORBA Messaging QoS Policy framework

  • Overview of the CORBA QoS Policy FrameworkCORBA defines a QoS framework that includes policy management for request priority, queueing, message delivery quality, timeouts, connection management, etc. QoS is managed through interfaces derived from CORBA::PolicyEach QoS Policy can be queried with its PolicyTypeClient-side policies can be specified at 3 overriding levelsORB-level via PolicyManagerThread-level via PolicyCurrentObject-level via overrides in an object referenceClient-side policies are validated via Object::_validate_connection()Server-side policies can be specified at 3 overriding levelsORB-level through PolicyManagerPOA-level passed as arguments to POA::create_POA() Some policies can be set at the Object-level through the RTPOAServer-side policies can be stored in the tagged components of the IOR

  • Applying RT CORBA to Real-time AvionicsKey System CharacteristicsDeterministic & statistical deadlines~20 HzLow latency & jitter ~250 usecsPeriodic & aperiodic processingComplex dependenciesContinuous platform upgradesTest flown at China Lake NAWS by Boeing OSAT II 98, funded by OS-JTFwww.cs.wustl.edu/~schmidt/TAO-boeing.htmlAlso used on SOFIA project by Raytheonsofia.arc.nasa.govFirst use of RT CORBA in mission computingDrove Real-time CORBA standardizationKey ResultsGoalsApply COTS & open systems to mission-critical real-time avionics

  • Applying RT CORBA to Time-Critical Targets

  • Applying RT CORBA to Hot Rolling MillsGoalsControl the processing of molten steel moving through a hot rolling mill in real-timeSystem CharacteristicsHard real-time process automation requirements i.e., 250 ms real-time cyclesSystem acquires values representing plants current state, tracks material flow, calculates new settings for the rolls & devices, & submits new settings back to plant

  • Applying RT CORBA to Image ProcessingGoalsExamine glass bottles for defects in real-timeSystem CharacteristicsProcess 20 bottles per seci.e., ~50 msec per bottleNetworked configuration~10 cameras


  • An Example DRE ApplicationConsider an application where cooperating drones explore a surface & report its properties periodicallye.g., color, texture, etc.Drones arent very smart,e.g., they can fall off the edge of the surface if not stoppedThus, a controller is used to coordinate their actionse.g., it can order them to a new position

  • Designing the DRE ApplicationEnd-users talk to a Base_Station objecte.g., they define high-level exploration goals for the dronesThe Base_Station provides set-points for the controllersThe Controller object controls the drones remotely using Drone objectsDrone objects are proxies for the underlying drone vehiclese.g., they expose operations for controlling & monitoring individual drone behavior Each drone sends information obtained from its sensors back to the Base_Station via a Controller object

  • Defining Application Interfaces with CORBA IDLEach Drone talks to a Controllere.g., Drones send hi-priority edge_alarm()messages when they detect an edgeThe Controller should take corrective action if a Drone detects its about to fall off an edge!The Base_Station interface is a Controller factoryDrones use this interface to create their Controllers during power upEnd-users use this interface to set high-level mobility targetsThis API is a simplification of various semi-autonomous vehicle use-casesinterface Drone { void turn (in float degrees); void speed (in short mph); void reset_odometer (); short odometer (); // };interface Controller { void edge_alarm (); void battery_low (); //};interface Base_Station { Controller new_controller(in string name) raises (Lack_Resources); void set_new_target(in float x, in float y, in float w, in float h); //};exception Lack_Resources {};

  • QoS-related Application Design ChallengesOur example application contains the following QoS-related design challengesObtaining portable ORB end-system prioritiesPreserving priorities end-to-endEnforcing certain priorities at the serverChanging CORBA prioritiesSupporting thread pools effectivelyBuffering client requestsSynchronizing objects correctlyConfiguring custom protocolsControlling network & end-system resources to minimize priority inversionAvoiding dynamic connectionsSimplifying application schedulingControlling request timeouts


  • Portable End-to-End PrioritiesProblem: How can we map global priorities onto heterogeneous native OS host thread priorities consistently end-to-end? Solution: Use Standard RT CORBA priority mapping interfaces

  • Obtaining Portable ORB End-system Priorities

    OS-independent design supports heterogeneous real-time platformsCORBA priorities are globally unique values that range from 0 to 32767Users can map CORBA priorities onto native OS priorities in custom waysNo silver bullet, but rather an ``enabling technique'i.e., cant magically turn a general-purpose OS into a real-time OS!











    Native Priority

    Native Priority


  • Priority Mapping ExampleDefine a class to map CORBA priorities to native OS priorities & vice versaclass My_Priority_Mapping : public RTCORBA::PriorityMapping { CORBA::Boolean to_native (RTCORBA::Priority corba_prio, RTCORBA::NativePriority &native_prio) { // Only use native priorities in the range [128-255), e.g. // this is the top half of LynxOS thread priorities. native_prio = 128 + (corba_prio / 256); return true; }

    CORBA::Boolean to_corba (RTCORBA::NativePriority native_prio, RTCORBA::Priority &corba_prio) { if (native_prio < 128) return false; corba_prio = (native_prio - 128) * 256; return true; }};

  • Setting Custom Priority MappingProblem: How do we configure the PriorityMapping that the ORB should use?Solution: Use TAOs PriorityMappingManager!

  • TAOs PriorityMappingManagerTAO provides an extension that uses a locality constrained object to configure the priority mapping:CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); // The ORB

    // Get the PriorityMappingManagerCORBA::Object_var obj = orb->resolve_initial_references (PriorityMappingManager);TAO::PriorityMappingManager_var manager = TAO::PriorityMappingManager::_narrow (obj);

    // Create an instance of your mappingRTCORBA::PriorityMapping *my_mapping = new My_Priority_Mapping;

    // Install the new mappingmanager->mapping (my_mapping);It would be nice if this feature were standardized in RT CORBAThe current specification doesnt standardize this in order to maximize ORB implementer options, e.g., link-time vs. run-time bindings

  • Preserving Priorities End-to-EndProblem: How can we ensure requests dont run at the wrong priority on the server?e.g.,

Popular Tags:

Click here to load reader

Embed Size (px)