Exploiting CCM Lifecycle Stages for BoldStroke Component Configuration with CIAO

1. Exploiting CCM Lifecycle Stages for BoldStroke Component Configuration with CIAO Christopher Gill and Nanbor Wang Department of Computer Science and Engineering Washington University, St. Louis {cdgill,nanbor}@cse.wustl.edu Work supported by DARPA contract F33615-00-C-3048 (WU PCES subcontract from Boeing) CCM Workshop, Kansas State University, Manhattan, Kansas Monday May 19, 2003

2. Component Configuration Lifecycle • Two distinct “planes” of a system • Functional aspects • Interfaces are implemented • Syntactic match for call/interface • Extra-functional QoS aspects • Caller/called available rates match • Total resource allocation is feasible • Utilization is tuned • Three system config phases • Component packaging • Application assembly • Application deployment • Analysis needed at each stage • Functional/extra-functional aspects • Some info added/changed at each • May leave some decisions for later Instance Creation Port Connections Component Package Component Package Assembly/ PackagingTool Component Package Assembly Archive .aar (ZIP) Properties DeploymentTool

3. Component Packaging Component Reference • Check Functional Aspects • Are all offered ports implemented by executor? • Check QoS Aspects • Are modes specified? • Are intra-component port dependencies specified? • Are available rates specified for each port in each mode? • Might allow to specify { } (empty) • Are calibrated execution times specified for each mode? • (e.g., WCET<400MHz>) Receptacles Facets Component Executor Offered Ports Required Ports Event Sinks Event Sources Attributes

4. Application Assembly • Check Functional Aspects • Are inter-component port dependencies specified? • Do signatures match between required and offered ports along each dependency? • Check QoS Aspects • Can sets of available rates be derived for each port in each mode? • Using simple rate propagation to fill in empty sets • Do sets of rates match? • Narrow to rate set intersection RateGenerator HiResGPS CockpitDisplay Component Server

5. Application Deployment • Check Functional Aspects • Are OS/middleware services bound and available? • Check QoS Aspects • Is CPU speed known? • Recalibrate WCET values • Is there a feasible resource allocation (at some rates?) • Can we optimize feasible configurations of rates? • E.g., FAIR, CB-FAIR (WSOA) • E.g., feedback control U=.90 RateGenerator HiResGPS CockpitDisplay WayFastTM Processor 

6. BoldStroke Configuration Example: Packaging Most General Constraints Info from that component only

7. BoldStroke Configuration Example: Assembly Composite info (still partially specified) Intersections of constraints from individual components

8. BoldStroke Configuration Example: Deployment Fully specified Info Bound constraints (constants)

9. BoldStroke Configuration Example: Tuning Feasible for 200MHz CPU Tuned for 400MHz CPU

10. Summary • CIAO makes the QoS aspects of BoldStroke components first-class elements in the CCM programming model • Just as functional aspects are first-class in “plain-old” CCM • Ensures QoS correctness across applications & platforms • Supports composition of QoS (as well as functional) aspects • Allows custom optimization for performance and control • Several configuration phases in the system lifecycle • Each with more information and more constraints • When a value is bound is crucial, parameterization matters • If several alternatives are acceptable, need tuning metrics • Successive constraint composition/resolution • Resulting set of alternatives may have > 1 element: “conflict set” • Use additional optimizations/control/tuning to choose one

11. Looking Ahead • Next steps: Cadena on CIAO, PI meeting June 4-6 • What CIAO features are missing, or need revision? • Partial evaluation and refinement are fundamental • CIAO can provide hooks at each configuration stage • Modeling tools may insert QoS constraints & variables to be refined • E.g., calibrated execution times based on CPU speed • Static role of modeling tools in this example is clear • Specify variables, range bounds, initial values • Load and check CIAO XML specification at each stage • Update and store CIAO XML specification for next stage • Overall run-time architecture is less clear • Do modeling tools provide run-time checkers? • How do they interface with schedulers, other services? • With epochs of adaptation, is configuration lifecycle a spiral?