Model Driven Engineering for QoS Management in Distributed Real-time & Embedded Systems

1. Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee Model Driven Engineering for QoS Management in Distributed Real-time & Embedded Systems Dr. Aniruddha S. Gokhale a.gokhale@vanderbilt.edu Assistant Professor, EECS Presented at Avaya Labs April 14th, 2006

2. DOC Group Research • CoSMIC - Modeling Deployment & Configuration (D&C) crosscutting concerns • RACE – Resource and Control Engine • DAnCE – Deployment And Configuration Engine • CIAO – QoS-enabled component middleware www.dre.vanderbilt.edu

3. The Future • Distributed real-time & embedded (DRE) systems • Network-centric & larger-scale “systems of systems” • Composable from COTS components • QoS requirements a mix of enterprise & real-time • Dynamic operational modes and environment Notion of Enterprise Distributed Real-time & Embedded (DRE) Systems The Past • Real-time & embedded systems • Deeply embedded • Resource constrained • Fixed and often static operational modes and environments

4. … … … Container Container Middleware Bus Replication Security Persistence Notification A/V Streaming Scheduling Load Balancing Technology Enablers: Component Middleware “Write Code That Reuses Code” • Components encapsulate application “business” logic • Components interact via ports • Provided interfaces, e.g.,facets • Required connection points, e.g., receptacles • Event sinks & sources • Attributes • Containers provide execution environment for components with common operating requirements • Components/containers can also • Communicate via a middleware bus and • Reuse common middleware services …

5. Key challenges in the solution space • Enormous accidental & inherent complexities • Continuous evolution & change • Highly heterogeneous platform, language, & tool environments Mapping problem artifacts to solution artifacts is very problematic New Demands on DRE Systems • Key challenges in the problem space • Network-centric, dynamic, very large-scale “systems of systems” • Stringent simultaneous quality of service (QoS) demands • Highly diverse & complex problem domains

6. DRE Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks Promising Solution: Model Driven Engineering (MDE) • Develop, validate, & standardize generative software technologies that: • Model • Analyze • Synthesize & • Provision • multiple layers of middleware & application components that require simultaneous control of multiple quality of service properties end-to-end • Specialization is essential for inter-/intra-layer optimization & advanced product-line architectures <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware/application developers & users

7. Decorator Decorator Application Developers (Modelers) XML XML MDE Tool Developer (Metamodeler) … … DB #n DB #1 Storage Options Technology Enabler: Generic Modeling Environment (GME) “Write Code That Writes Code That Writes Code!” GME Architecture COM COM GME Editor ConstraintManager Browser Translator(s) COM Add-On(s) Metamodel GModel GMeta XML UML / OCL CORE Paradigm Definition XML ODBC Goal: Correct-by-construction DRE systems www.isis.vanderbilt.edu/Projects/gme/default.htm

8. DRE Lifecycle Stages Affecting QoS Specification & Implementation • Defining, partitioning, & implementing appln functionality as standalone components Assembly & Packaging • Bundling a suite of software binary modules & metadata representing app components Installation • Populating a repository with packages required by app Configuration • Configuring packages with appropriate parameters to satisfy functional & systemic requirements of an application without constraining to physical resources Planning • Making deployment decisions to identify nodes in target environment where packages will be deployed Preparation • Moving binaries to identified entities of target environment Launching • Triggering installed binaries & bringing appln to ready state QoS Assurance & Adaptation • Runtime (re)configuration & resource management to maintain end-to-end QoS • OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

9. Our MDE Solution: CoSMIC • CoSMIC tools e.g., PICML used to model application components • Captures the data model of the OMG D&C specification • Synthesis of static deployment plans for DRE applications • New capabilities being added for QoS provisioning (real-time, fault tolerance) CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic

10. Bold Stroke Architecture Middleware Infrastructure Mission Computing Services Operating System Networking Interfaces Hardware (CPU, Memory, I/O) • Avionics mission computing product-line architecture for Boeing aircraft, e.g., F-18 E/F, 15E, Harrier, UCAV • DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++ code • Based on COTS hardware, networks, operating systems, & middleware • Used as Open Experimentation Platform (OEP) for DARPA IXO PCES, MoBIES, SEC, MICA programs DRE System Example: Boeing Bold Stroke Data Links Vehicle Mgmt Mission Computer Nav Sensors Radar Expendable Management Expendables

11. (I) The Packaging Aspect • Application components are bundled together into assemblies • Several different assemblies tailored towards delivering different end-to-end QoS and/or using different algorithms can be part of the package • e.g., large-scale DRE systems require 100s-1,000s of components • Packages describing the components & assemblies can be scripted via XML descriptors

12. RT Event Channel Packaging Aspect Problems (1/2) Ad hoc techniques for ensuring component syntactic & semantic compatibility Distribution & deployment done in ad hoc manner Ad hoc means to determine event notification support

13. Packaging Aspect Problems (2/2) Existing practices involve handcrafting XML descriptors <!– Associate components with impls --><componentfiles> <componentfile id=“RateGenerator"> <fileinarchive name=“HouseRateGen.csd"/> </componentfile> <componentfile id=“HiResGPS"> <fileinarchive name=“aGPS.csd"/> </componentfile> <componentfile id=“cockpitDisplay"> <fileinarchive name=“navDisplay-if.csd"/> </componentfile> </componentfiles> XML file in excess of 3,000 lines, even for medium sized scenarios Modifications to the assemblies requires modifying XML file

14. CoSMIC MDE Solution for Packaging Aspect • Platform-Independent Component Modeling Language (PICML) • Developed in Generic Modeling Environment (GME) • Core of Component Synthesis using Model-Integrated Computing (CoSMIC) toolchain • Capture elements & dependencies visually • Define “static semantics” using Object Constraint Language (OCL) • Define “dynamic semantics” via model interpreters • Also used for generating domain specific meta-data • “Correct-by-construction”

15. Example Metadata Generated by PICML • Component Interface Descriptor (.ccd) • Describes the interface, ports, properties of a single component • Implementation Artifact Descriptor (.iad) • Describes the implementation artifacts (e.g., DLLs, OS, etc.) of one component • Component Package Descriptor (.cpd) • Describes multiple alternative implementations of a single component • Package Configuration Descriptor (.pcd) • Describes a configuration of a component package • Top-level Package Descriptor (package.tpd) • Describes the top-level component package in a package (.cpk) • Component Implementation Descriptor (.cid) • Describes a specific implementation of a component interface • Implementation can be either monolithic- or assembly-based • Contains sub-component instantiations in case of assembly based implementations • Contains inter-connection information between components • Component Packages (.cpk) • A component package can contain a single component • A component package can also contain an assembly • Based on OMG (D&C) specification (ptc/03-06-03)

16. Example Output from PICML A Component Implementation Descriptor (*.cid) file <ComponentAssemblyDescription id="a_HUDDisplay"> ... <connection> <name>GPS-RateGen</name> <internalEndPoint> <portName>Refresh</portName> <instance>a_GPS</instance> </internalEndPoint> <internalEndPoint> <portName>Pulse</portName> <instance>a_RateGen</instance> </internalEndPoint> </connection> <connection> <name>NavDisplay-GPS</name> <internalEndPoint> <portName>Refresh</portName> <instance>a_NavDisplay</instance> </internalEndPoint> <internalEndPoint> <portName>Ready</portName> <instance>a_GPS</instance> </internalEndPoint> </connection> ... </ComponentAssemblyDescription> • Describes a specific implementation of a component interface • Contains inter-connection information between components <!–-Component Implementation Descriptor(.cid) associates components with impl. artifacts--> <Deployment:ComponentImplementationDescription> <label>GPS Implementation</label> <UUID>154cf3cd-1770-4e92-b19b-8c2c921fea38</UUID> <implements href="GPS.ccd"/> <monolithicImpl> <primaryArtifact> <name>GPS Implementation artifacts</name> <referencedArtifact href="GPS.iad"/> </primaryArtifact> </monolithicImpl> </Deployment:ComponentImplementationDescription>

17. (II) The Multilayer Configuration Aspect Configuration of components & assemblies • Component-based software must be configurable at many levels • e.g., application components & containers, component servers, & middleware services & infrastructure Configuration of component server Configuration of event notifiers Configuration of component containers Configuration of the middleware bus

18. Hook for marshaling strategy Hook for the request demuxing strategy Hook for the event demuxing strategy Hook for the connection management strategy Hook for the concurrency strategy Hook for the underlying transport strategy Challenge: The M/W Bus Configuration Component middleware is characterized by a large configuration space that maps known variations in the application requirements space to known variations in the middleware solution space

19. server object management middleware Challenge: Configuring Container Policies • Existing techniques for metadata configurations rely on ad hoc manual configurations e.g., CORBA server-side programming Determine various middleware policies for server objects e.g., security, lifetime, replication Determine thread pool sizes; how are they shared; number of lanes and their priorities; if borrowing is enabled Determine right buffer sizes Determine end-to-end priority propagation model to use Determine the server object management policies Ensure semantic compatibility among chosen configurations • This “glue code” is traditionally handcrafted

20. CoSMIC MDE Solutions for Configuration Aspect Approach: • Develop an Options Configuration Modeling Language (OCML) using GME • OCML is used by • Middleware developer to design the configuration model • Application developer to configure the middleware for a specific application • OCML metamodel is platform-independent • OCML models are platform-specific

21. Applying OCML to CIAO+TAO • Middleware developers specify • Configuration space • Constraints

22. Applying OCML to CIAO+TAO • Middleware developers specify • Configuration space • Constraints • Application developers provide a model of desired options & their values, e.g., • Middleware network resources • Concurrency & connection management strategies • Constraint checker flags incompatible options

23. Applying OCML to CIAO+TAO • Middleware developers specify • Configuration space • Constraints • Application developers provide a model of desired options & their values, e.g., • Middleware network resources • Concurrency & connection management strategies • Constraint checker flags incompatible options • Synthesizes XML descriptors for middleware configuration • Generates documentation for the middleware configuration • Validates the configurations

24. (III) Deployment Planning Aspect Component integrators must make appropriate deployment decisions, including identifying the entities (e.g., CPUs) of the target environment where the packages will be deployed Select the appropriate package to deploy on selected target Determine current resource allocations on target platforms Select appropriate target platform to deploy packages

25. Planning Aspect Problems How to ensure a particular deployment configuration maximizes QoS How do you correlate QoS requirements of packages to resource needs How do you determine current resource allocations? How do you ensure that the selected targets will deliver required QoS

26. Example: Fault Tolerance Planning • CoSMIC (PICML) enhancements to represent failover units and replication groups • capture requirements, such as replication degrees, heartbeat intervals, importance, replication style, state synchronization mechanisms FOU and requirements

27. Modeling Shared Risk for FT Planning • Model shared risk group elements in a system e.g., ship comprising regions, data centers, shelves, racks and blades • Generative programming to synthesize deployment plans for FOUs that minimize shared risk (e.g., co-failure probability) system wide risk hierarchy

28. (IV) Quality Assurance & QoS Validation Aspect Existing Quality Assurance Processes: • Auto-build scoreboard systems • e.g. Mozilla’s Tinderbox • Error reporting based on prepackaged installation tests • e.g. GNU GCC and ACE & TAO • Online crash reporting • e.g. Netscape’s QFA and Microsoft’s Watson • Shortcomings: inadequate, opaque, inefficient and inflexible QA processes • Scope: Generally restricted to functional testing and often incomplete • Documentation: No knowledge of what has or hasn’t undergone QA • Control: Developers have no control over the QA processes • Adaptation: Can’t learning from the earlier test results Persistent Challenges • Scale • Massive configuration & optimization space • Time to market pressure • Rapid updates, frequent releases • Heterogeneity • Scattered resources & distributed developers • Incomplete information • Unobservable usage context Emerging Opportunities • Leverage remote computing resources and network ubiquity for distributed, continuous QA

29. CoSMIC MDE Solution for QA Aspect Approach: • Develop an Benchmark Generation Modeling Language (BGML) w/GME • BGML provides a model-based toolsuite to empirically evaluate & refine deployment configurations to maximize application QoS • Use in conjunction with OCML BGML Workflow • End-user composes the scenario in the BGML modeling paradigm • Associate QoS properties with this scenario, such as latency, jitter, or thruput • Synthesize the appropriate test code to run the experiment & measure the QoS • Feedback metrics into models to verify if system meets appropriate QoS at design time

30. Resolving Planning Challenges with BGML (1/2) Example Scenario • Navigation Display – displays GPS position updates • GPS Component – generates periodic position updates • Airframe Component – processes input from the GPS component and feeds to Navigation display • Trigger Component – generates periodic refresh rates Goal • Determine the configuration settings for the individual components to achieve the QoS required for this scenario Step1: Model component Interaction using BGML Step2: Configure each component, associating the appropriate IDL interfaces

31. Resolving Planning Challenges with BGML (2/2) Step4: Associate QoS metrics to measure in the scenario Step3: Associate operations with the component ports void start_time_probe () { if (!timer_count) test_start = ACE_OS::gethrtime (); start_timer_probe = ACE_OS::gethrtime (); } void stop_time_probe () { finish_timer_probe = ACE_OS::gethrtime (); history.sample (finish_timer_probe - start_timer_probe); if (++ timer_count == niterations) { test_end = ACE_OS::gethrtime (); ACE_DEBUG ((LM_DEBUG, "test finished\n")); ACE_Throughput_Stats::dump_throughput ("Total", gsf, test_end - test_start, stats.samples_count ()); } } • BGML tool allows actual composition of the target interaction scenario, auto-generates benchmarking code • Each configuration option can then be tested to identify the configuration that maximizes the QoS for the scenario • These empirically refined configurations can be reused across applications that have similar/same application domains • These configurations can be viewed as Configuration & Customization (C&C) patterns

32. Appln Server Appln Server Static configuration (V) Adaptation & Resource Management Aspect CONTEXT Made feasible using adaptive & reflective middleware Need to provide runtime QoS adaptation along functional path Global, dynamic resource management

33. RACE Control Architecture Static Inputs • Resource (CPU) utilization set-point <arms:CPUset-point> 0.8 </arms:CPUset-point> • End-to-end deadlines <arms:deadline units="ms">800 </arms:deadline> Dynamic Inputs • Current CPU utilization • End-to-end execution time

34. RACE Control Architecture Processing • RACE Controller • Reallocates resources to meet control objectives • RACE Control Agent • Maps resource reallocation to OS/string specific parameters • Uses OS & string control agents to modify OS/string parameters

35. CUTS Environment for Emulating DRE Systems • Component Workload Emulator (CoWorkEr) Utilization Test Suite (CUTS) consists of a test network of CoWorkEr nodes • Outside the test network is a Benchmark Data Collector (BDC) for collecting test metrics • Makeup & functionality of a CoWorkEr • CCM assembly constructed from CCM monolithic components • Can perform CPU operations, database operations & memory allocations & deallocations • Can perform background workloads • Can send/receive events to/from other CoWorkErs to form application strings

36. CoWorkEr Behavioral Modeling in CUTS • I/O Automata used to model behavior using state transitions and actions • WML integrates into I/O automata at the action level • Extends semantics of binding between worker and its actions

37. Measuring the Performance of Components Critical paths can be selected & evaluated to determine if end-to-end QoS deadlines are meet All data is collected by the Benchmark Data Collector (BDC) & stored in a database for offline evaluation Time to transmit an event is measured Time to process an event is measured

38. CUTS BMW Utility • Dynamic updates of test runs • Enables viewing of collected data and metrics

39. CUTS BMW: Observable Metrics • Test selection based on critical path • Metrics include best, average, worst case timings

40. Observing RACE Control Behavior • Demonstrates increased load due to “hog string” • Web enabled application of RACE to control QoS

41. F/A 18 product variant A/V 8-B product variant UCAV product variant F-15 product variant Domain-specific Services Common Middleware Services Product-line architecture Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) (VI) Optimizations for Product-line Architectures Air Frame FLIR AP HUD GPS Nav IFF • PLAs define a framework of components that adhere to a common architectural style with a clean separation of commonalities and appropriate provisions for incorporating variations • Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility Standards middleware is a key technology candidate for supporting and sustaining vision of software product-lines

42. Technology Gaps in Middleware for PLAs • PLAs have very “focused but crosscutting” requirements of underlying middleware infrastructure • Optimized for the platform • Lean footprint • Efficient configuration & deployment • Support run-time adaptations & reconfigurations • Standards middleware development & optimizations philosophy catered to maintaining “generality, wide applicability, portability & reusability” • OS, compiler and hardware independent • e.g., CORBA, J2EE. .NET • These technology gaps are hindering PLA progress => adverse economic and societal consequences • e.g. shortcomings of pre-postulated middleware [Jacobsen 04] Need to tailor and optimize standards middleware for PLAs while continuing to provide standards compliance, portability and flexibility

43. Middleware Specialization Catalog • Specification-imposed specializations • Layer-folding • Constant propagation • Memoization • Domain-specific language (DSL) tools & process for automating the specializations • Framework specializations • Aspect Weaving techniques • Bridge Reactor • Template method  Protocol • Strategy Messaging, Wait, Demultiplexing • Development of reusable specialization patterns • Deployment platform specializations • Unroll copy loops • Use emulated exceptions • Leverage zero-copy data transfer buffers • Identifying specialization points in middleware where patterns are applicable

44. Challenge: Lack of Application Context • Missed middleware optimization opportunities • Without application context • Every invocation performs check for locality • Middleware glue code for both code paths present in all use cases • Impossible for middleware (alone) to predict application usage Cannot be solved by operating solely at middleware level!

45. Approach: Supply Application Context w/Models • Build a global assembly optimizer framework • Use models to capture & derive application context • Explicit, e.g., radar & sensor are collocated (user-specified) • Implicit, e.g., radar & sensor are deployed onto the same node • Example • Detect components internal to an assembly • Eliminate overhead of • Multiple Homes

46. Communications Applications Modeling Environment Domain Specific Workflow Model Workflow MetaModel Workflow Model Interpreter Inputs to Graph Meta Model Inputs to Graph Execution Engine Graph Transformation Tool • Hierarchical • Enterprise communications applications analysis • Supports generative programming. Partial views may be useful and can be directly used for for interactive dialog generation tools • Static Analysis/Constraint checking. • Validation of a communications application for a specific domain/end user devices Output Modeling Framework Meta Model DSMs

47. Research Impact & Future Work Advanced MDE Current progress stems from years of iteration, refinement, & successful use CoSMIC Model driven middleware Shape the standards e.g., OMG’s Model Driven Architecture (MDA) for DRE systems RT/CCM ACE+TAO CORBA Component Model (CCM) Component Models (EJB) • Long-term Research Directions • High confidence, geographically distributed DRE systems • Grid applications • Large enterprise systems • Greater focus on platform-independent models • Heterogeneous systems Real-time (RT) CORBA CORBA & DCOM DCE Micro-kernels RPC Internet 1970 2000 2005 2010 Year

48. Concluding Remarks • Model-Driven Engineering (MDE) is an important emerging generative technology paradigm that addresses key lifecycle challenges of DRE middleware & applications • OMG PSIG on Model Integrated Computing www.omg.org/news/meetings/tc/ agendas/mic.htm Many hard R&D problems with model-driven engineering remain unresolved!! • CoSMIC MDE tools are based on the Generic Modeling Environment (GME) • CoSMIC is available from www.dre.vanderbilt.edu/cosmic • GME is available from www.isis.vanderbilt.edu/Projects/gme/default.htm

49. EXTRA SLIDES