Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | branden-rodgers |
View: | 215 times |
Download: | 0 times |
Institute for Software Integrated SystemsVanderbilt University
Constraint-Based Embedded Program
CompositionPI: Ted Bapty
Sandeep Neema, Andy Gokhale, Jeff GrayInstitute for Software Integrated Systems
Vanderbilt Universityhttp://www.isis.vanderbilt.edu/projects/pces
Contract #: F33615-00-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 andPruning
• Customized Component Composition
• CDL Gen• Contract Simulation• Contract Validation
Domain-SpecificStrategies
SpecificationAspects
Models
ConstrainedModels
Strategies (C++)
XML
Parser
Aspect
Parser
B
c d e1
3
2
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)
SpecificationAspects
MatlabSimulink/StateflowSimulation
SMV/LPEModelChecking
BBNQuOCDL
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 ModelMatlab 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)
BBNQuoGen .CPP
.H
.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?
Counterexample
no
yes
reiterate
AnalogVideo
Receiver FrameGrabber
PPM video BBNDistribution
Controller
CDLContract
AQMEMIC Tool
“VanderBlimp” Demonstration Scenario
WithoutMIC & CDL
Client
Client
Client
Putting the ‘air’ in the UAV
OSHA Note:We use Helium
Control
CDLContract
CDLContract
CDLContract
CDLContract
future
future
Boeing BoldStroke OEP
Embedded Systems Modeling Language (ESML)DARPA MoBIES project
Specification
WeaponRelease
Sensor
LocDisplay
ComputePosition
Processor#1
Eager Eager Eager
Lazy
Processor#2
Design-SpaceExploration and
Pruning
Customized ComponentsUpdateMap
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
componentclass 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
componentclass 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 Language Jan 01, Jan 02 (v2)
• Meta Weaver Framework Aug 01, Apr 02
• Design Space Exploration & Synthesis– CDL Generation (rev 1) Oct 01, Apr 02– OBDD Representation Apr 02, Aug 02– Aspect Selection/Customization Aug 02
• Demonstrations– Bold Stroke Apr 02, Aug 02– BBN UAV Apr 02– SWR Aug 03
Technical Progress/Accomplishment
• Definition Implementation of Constraint & Strategy Language– Constraint/Strategy Language (v1) – Models-to-XML Translation – Constraint Weaver Synthesis 90%
• Definition of Domain Modeling Languages – Component Modeling 80%– State/Contract (New) 90%
• Synthesis– CDL 90%– QoS adaptation Simulation (New) 70%– QoS adaptation Verification (New) 10%– Bold Stroke Component Composition 20%
• Demonstrations– BBN 80%– Boeing 10%
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