Institute for Software Integrated Systems Vanderbilt University Constraint-Based Embedded Program Composition PI: Ted Bapty Sandeep Neema, Andy Gokhale, Jeff Gray Institute for Software Integrated Systems Vanderbilt University Contract #: F C-1695

Problem Description Composition of Embedded Systems –Close Coupling of Environment, Architecture & Requirements –All Requirements (Functional, Temporal, Interface, Resources) MUST be satisfied. –How do we represent & maintain these requirements? Requirements Map to Constraints on System Implementation –Many Constraints Crosscutting the Design –Complex mapping from high-level requirements to constraints –How do we perform the mapping, distributing requirements? Need for flexibility to rapidly deploy designs to families of applications –How can we use constraints to adapt a core design to specific application instances? –How can we provide better scalability? –OMG MDA

Project Objectives Create domain-specific, graphical languages that capture the functional design of real-time embedded systems –BBN UAV –Boeing Bold Stroke/CCM A weaving process that maps high-level invariant properties and system requirements to design constraints affecting specific model regions, A generation process that: –design space nav. -> customized component composition –generate CDL; simulate/verify effects of contracts

Design-Space Exploration and Pruning Customized Component Composition CDL Gen Contract Simulation Contract Validation Domain-Specific Strategies Specification Aspects Models Constrained Models Strategies (C++) XML Parser Aspect Parser B c d e B c d e strategy ApplyConstraint(constraintName : string, expression : string) { addAtom("OCLConstraint", "Constraint", constraintName).addAttribute("Expression", expression); } strategy RemoveConstraint(constraintName : string) { findAtom(constraintName).removeChild(); } strategy ReplaceConstraint(constraintName : string, expression : string) { RemoveConstraint(constraintName); ApplyConstraint(constraintName, expression); } constraint FOOB2 { // apply a specific constraint to “B2” only in Structural models("ProcessingCompound")-> select(p | p.name() == "B2")->PowerStrategy(1, 100); } constraint FOOBStar { // apply a specific constraint to all nodes beginning with “B” - use wildcard in Structural models("ProcessingCompound")-> select(p | p.name() == "B*")->PowerStrategy(1, 100); } Meta-weaver A B Meta-Model

BBN UAV OEP Adaptive Quality Modeling Environment (AQME) Specification Aspects Matlab Simulink/ Stateflow Simulation SMV/LPE Model Checking BBN QuO CDL

Adaptive Quality Modeling Environment QoS Specification and Adaptation modeling –Hierarchical, parallel, finite state machine representation –States capture system-wide QoS configurations –Transitions represent cause and effect of change in operating conditions –Data/Event variables represent the interface to the operating environment

Adaptive Quality Modeling Environment Software modeling –Hierarchical dataflow representation Compounds, primitives –Parameters for component instrumentation and customization Middleware modeling –Services and system condition objects –Parameters for middleware instrumentation and customization

Simulation of QoS adaptation Matlab® Simulink®/Stateflow® used as the simulation engine Model interpreters generate Matlab M-code to construct Simulink/Stateflow representation User provides a network simulation model, that can simulate various load conditions in the network UAV Model Matlab M-file I Network model Simulation results Adaptation model I  Interpreter

QuO Contract Generation AQME models translated to QuO contracts represented in Contract Definition Language (CDL) Hierarchical concurrent state machine models translated to flat state machine representation Transition guards and actions expressions over data/event variables translated to calls over Middleware (syscond) objects UAV Model I QuO Contract (CDL) BBN QuoGen.CPP.H Target Appl./MW

Verification of QoS adaptation Cornell LPE/SMV planned to be used as the model checking engine AQME models translated to LPE/SMV input specifications Can verify properties like reachability, liveness, fairness, etc. of the QoS adaptation specifications UAV Model I SMV/LPE specification SMV/ LPE CTL specs Valid? Counter example no yes reiterate

Analog Video Receiver Frame Grabber PPM video BBN Distribution Controller CDL Contract AQME MIC Tool “VanderBlimp” Demonstration Scenario Without MIC & CDL Client Putting the ‘air’ in the UAV OSHA Note:We use Helium Control CDL Contract CDL Contract CDL Contract CDL Contract future

Boeing BoldStroke OEP Embedded Systems Modeling Language (ESML) DARPA MoBIES project Specification Weapon Release Sensor LocDisplay Compute Position Processor #1 Eager Lazy Processor #2 Design-Space Exploration and Pruning Customized Components UpdateMap Lazy

Embedded Systems Modeling Language (MoBIES) BoldStroke/CCM Components interaction modeling –Publish-subscribe event communication mechanism –Facets-Receptacles for data-communication Component internal interaction modeling –Event/data dependency within the components internal data variables and methods –Used to synthesize eager vs. lazy computation

A generalized component class ComputePosition { public: void call_back() = 0; int get_data() = 0; … protected: void notify(); void data_retrieve(); void compute_phase1(); void compute_phase2(); … int _data; }

Customization of ComputePosition as a Lazy component class LazyComputePosition : public ComputePosition { public: void call_back() { notify(); } int get_data() { data_retreive(); compute_phase1(); computer_phase2(); return _data; } protected: … };

Customization of ComputePosition as an Eager component class EagerComputePosition : public ComputePosition { public: void call_back() { data_retreive(); compute_phase1(); computer_phase2(); notify(); } int get_data() { return _data; } protected: … };

Contribution To PCES “analysis and transformation tools that achieve and preserve required properties” –The mapping of requirements to constraints will contribute to the achievement of system properties in the implementation. –OBDD-based constraint management “composition techniques that can be used cooperatively to support real-time programming” –Modeling component composition from requirements “programming reusable and portable aspect code” –Reusable libraries of weavers/aspects  composing advice based on system and application requirements to customize product family design “engineering approaches that can greatly reduce effort to program embedded systems” –Strategies for creating contracts & CDL generation

Contribution to Relevant Military Applications BBN UAV –Generation and management of complex behaviors (e.g., contracts) Systems are more adaptive to changing conditions Systems make better use of resources to accomplish mission –Evaluation/simulation of system behavior System behavior known before deployment More reliable systems, less chance of failure in ‘odd’ circumstances Bold Stroke: –Domain-specific application composition Rapid customization of military systems –Tuning implementations to system requirements, constraints Re-use of components  one component fits all via customization (through aspects) Others (original project plan) –Software Radio Single platform design  multiple waveform support Efficient generation of HW/SW –AMCOM Missile ATR Rapid design-space tradeoff for architecture studies, Coupled with SW/HW generation

Project Tasks/Schedule Definition Implementation of Constraint & Strategy Language –Constraint/Strategy LanguageJan 01,Jan 02 (v2) Meta Weaver Framework Aug 01, Apr 02 Design Space Exploration & Synthesis –CDL Generation (rev 1)Oct 01, Apr 02 –OBDD RepresentationApr 02, Aug 02 –Aspect Selection/CustomizationAug 02 Demonstrations –Bold StrokeApr 02, Aug 02 –BBN UAVApr 02 –SWRAug 03

Technical Progress/Accomplishment Definition Implementation of Constraint & Strategy Language –Constraint/Strategy Language (v1) –Models-to-XML Translation –Constraint Weaver Synthesis90% Definition of Domain Modeling Languages –Component Modeling80% –State/Contract (New) 90% Synthesis –CDL90% –QoS adaptation Simulation (New)70% –QoS adaptation Verification (New)10% –Bold Stroke Component Composition 20% Demonstrations –BBN80% –Boeing10%

Next Milestones Complete remaining portion of weaver framework BBN UAV –Complete CDL generator –Complete Contract Simulation –Complete Contract Verification (SMV/LPE) –New strategy polices for state adaptation –Demonstration Boeing Bold Stroke –Complete Bold Stroke Modeling –Adapt Design Space Exploration for Aspect Selection –Generate Bold Stroke Component Composition –Demonstration

Collaborations OEP Interaction: –BBN Contract Modeling and Simulation/CDL Generation UAV Demo –Boeing Bold Stroke Applications Modeling/Implementation Other PCES participants: –UVA/Boeing Modeling Collaboration, Tool Integration (GME/ESML) –Cornell Mapping our AQME models to XML for verification/analysis –GA Tech Collaborating on demo platform (using PPM image transport protocol) –PARC/UBC (planned) Component Behavior Composition Other DARPA projects: MoBIES –Extending Bold Stroke Modeling to support component composition with aspects

Tech Transfer Boeing –Modeling Tools (GME/ESML) –Customized components BBN –Modeling Tools (GME/AQME) –Simulation/CDL AFRL/IFGC (Rome AFB), Wayne Bonser (IFGC), Rodger Dziegel (IFTD) –Tools for Waveform Definition Language-to-Software Radio Implementation USARMY/AMCOM; Richard Sims ( AMSAM-RD-MG-IP) –Missile Embedded Systems, HW/SW Codesign Other ISIS Collaborators: –GM/Saturn, USAF/AEDC, Ford, NASA/MSFC, IBM, DuPont, Sandia, BAE/Sanders, Boeing, USMC, USAF/JSF, JPL, SWRI, Infineon,

Tech Transfer (continued) Workshop organization: –OOPSLA 2002 Workshop on Domain-Specific Visual Languages –AOSD Workshop on “Early Aspects” Publications/Interactions –AOSD Demonstration –Dissertation (Jeff Gray) –GCSE/SAIG 02 (submitted) –OOPSLA 02 (submitted) –HICSS 03 (4 papers submitted) –Real-Time OMG Workshop

Go/No Go Metrics [Bool] – Can we generate ‘real-world’ CDL contracts for xxxx complexity systems [int] – How many states can we design, simulate, analyze, and synthesize vs. hand-designed [float] – Turnaround time for a system behavior update vs. by-hand. [long?] Errors found/eliminated. [long?] Lines of code generated/avoided vs. hand- coded. [?] How high can the blimp fly ;)

Program Issues None