Analyzing Component-based Designs: The Cadena Environment SAnToS Laboratory, Kansas State...
-
Upload
monica-singleton -
Category
Documents
-
view
219 -
download
0
Transcript of Analyzing Component-based Designs: The Cadena Environment SAnToS Laboratory, Kansas State...
Analyzing Component-based Designs:
The Cadena Environment
http://www.cis.ksu.edu/cadena
SAnToS Laboratory, Kansas State University, USA
Matt DwyerJohn HatcliffGurdip Singh
Principal Investigators
SupportUS National Science Foundation (NSF)US National Aeronautics and Space Agency (NASA)US Department of Defense Advanced Research Projects Agency (DARPA) US Army Research Office (ARO)
Rockwell-Collins ATCHoneywell Technology Center and NASA Langley Sun MicrosystemsIntel
Students
William DengGeorg JungAdam Childs
RobbyVenkatesh Ranganath
Distributed Components
Network
Distributed Components
Middleware (e.g. CORBA)
Java
C++
C++
C
Java
C
InterfaceDefinition Language (IDL) specifications for remote methods
Automatically generated proxies
Distributed Components
Middleware (e.g. CORBA)
Event Service Transaction Service
Naming Service Synchronization Service
Java
C++
C++
C
Java
C
ComponentInterface DefinitionLanguage(CCM IDL)
substantial portion of code auto-generated
Checking CCM Systems
Light-weight behavioral specifications
Leverage abstractions that programmers already write
Component IDL Scale static analysis
techniques to handle remote connections
Use emerging model-checking technology dedicated to OO structures and RT scheduling algorithms
Middleware (e.g. CORBA)
Event Service Transaction Service
Naming Service Synchronization Service
Java
C++
C++
C
Java
C
Modern Software Systems Our Themes
These systems are huge! What are appropriate
abstractions/specifications and how can we get programmers to write them?
Mission-control software for Boeing aircraft, e.g., F-18 E/F, Harrier, UCAV
Boeing’s Bold Stroke Avionics Middleware …built on top of ACE/TAO RT CORBA
Our focus: developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws
Analysis & Verification of
AvionicsMission Control
Systems
Analysis & Verification of
AvionicsMission Control
Systems
Boeing Bold Stroke Platform
Radar
Weapons
Nav Sensors
WeaponManagement
Data Links
Many Computers
Many Computers
Multiple BusesMultiple Buses
Constrained Tactical LinksConstrained
Tactical Links
O(106) Lines of Code
O(106) Lines of CodeHard & Soft
Real-TimeHard & Soft Real-Time
Periodic & Aperiodic
Periodic & Aperiodic
Multiple Safety Criticalities
Multiple Safety Criticalities
Information Security
Information Security
Focus Domain
MissionComputer
VehicleMgmt
COTSCOTS
Control-Push Data-Pull
Component A computes some data that is to be read by one or more components Bi
Typical situation
Run-time Actions
A
B1
Bk
A publishes a dataAvailable event
Bi call the getData() method of A to fetch the data
dataAvailable
dataAvailable
getData()
Control-Push Data-Pull Structure
1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device.2. Logical GPS publishes DATA_AVAILABLE event
3. Airframe component fetches GPS data by calling GPS GetData method4. Airframe updates its position data and publishes DATA_AVAILABLE event5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method6. NavDisplay updates the physical display
1
2
3
44
5
6
Input
Output
Larger Configuration
…moving up to 1000+ components
Development Process
Component Development
Component Development
Common Components
Platform-specificComponents
Component IntegrationComponent Integration
Connect components, assign priorities, locking schemes, distribute
Analysis & Functional Testing
Analysis & Functional Testing
Debuggers, call-graph analyzers, scheduling tools
Real Board Testing Real Board Testing
Test real-time aspects, frame-overruns, etc.
100+ developers
Research Context Provided with an Open Experimental Platform (OEP)
from Boeing a sanitized version of the real system 100,000+ lines of C++ code (including RT CORBA
middleware) Provided with 150+ page document that outline
development process and describe challenge problems
Must provide tool-based solutions that can be applied by Boeing research team to realistic systems
Must propose solutions that fit within current development process, code base, etc.
Must propose metrics for tool performance and ease of use
evaluation by Boeing research team
Next…
Short-comings in Bold Stroke
development that we will attempt to address
One could imagine doing a number of things. We first focused on items in
Boeing’s “wish list”.
Lack of Modeling
Informal natural language requirements
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
C++ component library
XML component connectioninformation
Process moves directly from informal textual requirements documents to C++ coding (!)
No use of component-level (CCM) IDL for code generation Still resistance by “legacy developers” to higher-level
descriptions (moving away from machine code has been difficult for some)
development bypasses modeling
Unleveraged Artifacts
Current design/model artifacts are used as informal documentation not connected to analysis/visualization tools not connected to “glue code” (deployment
code) generation
Lack of Model Analysis
1. Forward & backward data and event dependencies2. Dependency intersections
4. All components from a particular rate group
5. Cycle checks
…15-20 others related to dependencies
Boeing OEP Challenge Problems
3. Components with high data coupling
Lack of Model AnalysisBoeing OEP Challenge Problems
If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F
(Section 4.1.5.3.6)
A temporal property well-suited for model-checking!
A temporal property well-suited for model-checking!
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
No Unifying Mechanism
C++ Component Code
Bold Stroke XML Configurator Info
?High-level
Specification Language
Design Artifacts
Analysis and QoSAspect Synthesis
Integrated Development Environment
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
Cadena
Java/C++ Component Code
Bold Stroke XML Configurator Info
UML Design Artifacts
Analysis and QoSAspect Synthesis
Integrated Development Environment
CCM Interface Definition Language
RT Aspect SpecsState
TransitionsSystem
Configuration
Eclipse Plug-In
High-level Specification
Language
Cadena
Next…
Cadena functionality and capabilities…
Example System
Example SystemBasic components seen earlier
Basic components seen earlier
Example SystemNavigation Steering Subsystem
Navigation Steering Subsystem
Example System
Tactical Steering Subsystem
Tactical Steering Subsystem
Example System
Display Control
Display Control
on/off
on/off
Outline
2. Component Connections
2. Component Connections
3. Dependence Information
3. Dependence Information
4. Modal Behavior
4. Modal Behavior
1. Component Interface
1. Component Interface
CCM Component Interfaces
CCM Component Interfaces are based on a notion of ports Event ports – asynchronous event delivery
consumes port – input (event sink) publishes port – output (event source)
Interface ports – synchronous method calls provides port – provide interface to clients
(facet) uses port – use interface of other component
(receptacle)
Component PortsCORBA 3CCM IDL
input event portinput event port
eventtype TimeOut {}eventtype DataAvailable {}
interface ReadData { readonly attribute any data;}
component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut}
Component Ports
eventtype TimeOut {}eventtype DataAvailable {}
interface ReadData { readonly attribute any data;}
component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut}
CORBA 3CCM IDL
output event portoutput event port
Component Ports
eventtype TimeOut {}eventtype DataAvailable {}
interface ReadData {any get_data();}
component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut}
CORBA 3CCM IDL
provide interface to clients(facet)
provide interface to clients(facet)
Outline
2. Component Connections
2. Component Connections
Cadena Component Assemblysystem ModalSP {
locations l1,l2,l3; rates 1,5,20,60;
instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut }
instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …
create instance of LazyActive component
called AirFrame
create instance of LazyActive component
called AirFrame
Cadena Component Assemblysystem ModalSP {
locations l1,l2,l3; rates 1,5,20,60;
instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut
instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …
connect event INPUT port of current component
to event OUTPUT port of GPS component
connect event INPUT port of current component
to event OUTPUT port of GPS component
Cadena Component Assemblysystem ModalSP {
locations l1,l2,l3; rates 1,5,20,60;
instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut
instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …
connect data INPUT port of current component
to data OUTPUT port of GPS component
connect data INPUT port of current component
to data OUTPUT port of GPS component
Cadena Component Assembly
Cadena Visualization
Cadena User Interface
Outline
3. Dependence Information
3. Dependence Information
Dependency Specifications
Inter-component dependences are given by connection information (already seen)
We now give notation for specifying intra-component dependencies
Light-weight specification layer that provides significant benefit … In this case, component integrator leverages
this info in a variety of ways to specify aspects such as rates/priorities, distribution, scheduling, etc.
Used to visualize system behavior in different modes
outDataAvailable
port action
outDataAvailable
port action
triggers triggers call on set_data()
call on set_data()
dependencydefault == none;
dependencies { dataWriteOut.set_data() -> outDataAvailable; }
behavior { ... }
Light-weight Dependency Specs
triggers no other actions
triggers no other actions
Light-weight Dependency Specs
dependencydefault == all;
dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } }
behavior { ... }
in enabled mode, shows actions triggered by receipt of event on inDataAvailable port
in enabled mode, shows actions triggered by receipt of event on inDataAvailable port
Light-weight Dependency Specs
dependencydefault == all;
dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } }
behavior { ... }
in disabled mode, inDataAvailable triggers no
other port actions
in disabled mode, inDataAvailable triggers no
other port actions
Light-weight Dependency Specs
dependencydefault == all;
dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } }
behavior { ... }
Outline4. Modal Behavior
4. Modal Behavior
Transition System Semantics
Boeing engineers want to reason about system/component modes at design time
Ideal for model-checking because… component modes are finite mode-transitions are triggered by event/data-
port actions only tiny portion of system’s state space needs
to be exposed Mode-related requirements can be
naturally captured as safety properties e.g., frame-bounded response, invariants
Ultimate Modeling ViewCCM IDLModelLayer
Check mode behaviors, temporal properties, timing constraints
Code Layer
Check that implementations satisfy/refinement high-level specs – leverage the fact that code skeletons are automatically generated
Generate code, fill-in skeletons, check for refinement
We don’t do all of this yet!
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes {enabled,disabled}; Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
input portsinput ports
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
output portsoutput ports
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
mode declaration using CORBA IDL
mode declaration using CORBA IDL
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
behavior for events on dataInReady port
behavior for events on dataInReady port
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
behavior mode casesbehavior mode cases
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …
data flow specification
data flow specification
Component Behavior
component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange;
enum Modes (enabled,disabled); Modes m;
behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … publish eventpublish event
Towards a Complete Model
We have transition semantics for intra-component behavior.
How should we model communication layer?
?
Middleware/Service Semantics Weak CCM and Event Services Specs
(OMG) Informal : English and examples Intentionally under-specified to allow
implementor freedom Look at implemented semantics of
existing ORBs and Event Services ACE/TAO, FACET, OpenCCM, K-State
Developed a family of semantic models that captured their behavior
Outline of Real SystemEvent channel with internal thread pool
…Thread Pool
…
60Hz 20Hz 5Hz 1Hz
… … ……
passive componen
ts
passive componen
ts
proxy consumer holds list of consumer
references
proxy consumer holds list of consumer
references
dispatch queues for each rate
group
dispatch queues for each rate
group
publish
correlation & filtering
consumer refs
Threads run call-backs associated with event consumer ports
getData
Lots of details …
What events are users interested in reasoning about? publish, dispatch, timeouts, …
What state information? modes, dispatch queues, correlation
automata, … Minimize detail, but retain …
ability to express properties of interest correspondance with implementation
semantics
System ObservationsEvent channel with internal thread pool
…Thread Pool
…
60Hz 20Hz 5Hz 1Hz
… … ……
invoke[m,c]invoke[m,c]
publish[e,c]publish[e,c]
dispatch[e]dispatch[e]
publish
correlation & filtering
consumer refs
accept[e,s]accept[e,s]
eof[r]eof[r]
getData
c.m == vc.m == v
Modeling StrategyEvent channel with internal thread pool
…Thread Pool
…
60Hz 20Hz 5Hz 1Hz
… … ……
correlation & filtering
Modeling Strategy
Component Models Event ChannelModel
Component Models
EnvironmentModel
Connection Models
Model Checker Support Ability to define efficient building blocks
Sets, queues (with symmetry support) Flexible atomicity control Programmable scheduler Static data definition State compaction Flexibility in search strategies
Full-state space Bounded/heuristic search State-less search
BOGOR has all this and more …
Modeling of Components
function tacticalSteering_push_inDataAvailable(CAD.Event event){ Data d; loc loc0: live {} when tacticalSteeringMode do {} goto loc1; when !tacticalSteeringMode do {} return; loc loc1: live{d} when true do { d := CAD.getField<Data>(AirFrame, "ReadData.data"); } goto loc2; loc loc2: live{} when true do { CAD.setField<Data>(TacticalSteering, “dataOut.data", d); } goto loc3; loc loc3: live {} invoke pushOfProxy(TacticalSteering, “dataOutReady“) return;}
handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} }
handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} }
Structure follows component behavior spec and connection representation closely
Structure follows component behavior spec and connection representation closely
Modeling Middleware (Threads)
thread threadgroup5() { Pair.type<EventHandlerEnum, CAD.Event> pair; EventHandlerEnum handler; CAD.Event event;
loc loc0: live { handler, event } when Queue.size<Pair.type<EventHandlerEnum, CAD.Event>>(Q5) > 0 do invisible { pair := Queue. getFront<Pair.type<EventHandlerEnum, CAD.Event> >(Q5); Queue.dequeue<Pair.type<EventHandlerEnum, CAD.Event> >(Q5); handler := Pair. first<EventHandlerEnum, CAD.Event>(pair); event := Pair.second<EventHandlerEnum, CAD.Event>(pair); } goto loc1;
loc loc1: live {} invoke virtual f(handler, event) goto loc0;}
…Thread Pool
60Hz 20Hz 5Hz 1Hz Dispatch queue polling
Dispatch queue polling
Extend model checker types
Extend model checker types
Polymorphic extension
Polymorphic extension
Modeling Middleware (Queues)
extension Queue for edu.ksu.cis.cadena.bogor.ext.Queue { typedef type<'a>; expdef int size<'a>(Queue.type<'a>); expdef int capacity<'a>(Queue.type<'a>); expdef boolean isFull<'a>(Queue.type<'a>); expdef boolean isEmpty<'a>(Queue.type<'a>); expdef Queue.type<'a> create<'a>(int); actiondef enqueue<'a>(Queue.type<'a>, 'a); expdef 'a getFront<'a>(Queue.type<'a>); actiondef dequeue<'a>(Queue.type<'a>); expdef boolean
containsPair<'a>(Queue.type<'a>,'a);}
… … …
Data in state space, operations implemented as Java code
Data in state space, operations implemented as Java code
Modeling Middleware (Scheduling)
…Thread Pool
60Hz 20Hz 5Hz 1Hz
… … ……
Bold Stroke Systems are scheduled based on RMA
• run highest-priority (i.e., rate) enabled action
• many fewer schedules, contains all real schedules
BOGOR allows encoding specific schedules
• Java plugin filters enabled actions in state exploration algorithm
Typically model checkers use non-deterministic scheduling
• i.e., choose from set of enabled transitions in a state
• set of all such schedules contains all real schedules
Modeling of Environment
Model time directly expensive (state space becomes acyclic) hard to get accurate timing info (platform
specific) Boeing wasn’t very interested in time-properties
other than schedulability
Abstract time modeling strategies Timeouts can happen at any time Bound number of timeouts in hyper-period Bound relative number of timeouts in adjacent
rate groups Approximate passage of time
System behavior is driven by periodic time-triggered events
Relative Timeout Counts
Enforce only the relative # of timeouts for adjacent rates
Timeout for Ri is enabled after
• work for Ri is complete
• proper number of timeouts for Ri-1 are performed
R1
R2
R1R1, R2
Problem: Don’t know how long R2 work takes?
Relative Timeout Counts
Enforce only the relative # of timeouts for adjacent rates
Timeout for Ri is enabled after
• work for Ri is complete
• proper number of timeouts for Ri-1 are performed
R1
R2
R1, R2
Problem: Don’t know how long R2 work takes?
Next R1 timeout could fall in the middle of R2 work
R1
Must consider all interleavings of R1 timeout and actions performed in R2 work (or R3 work, …)
Relative Timeout Counts
R1
R2
R1, R2
R1
R1
R2
R1, R2
R1
R1
R2
R1, R2
R1
R1
R2
R1, R2 R1
Modeling of Environment
Previous model does not relate component execution with passage of time
Assume we have worst-case execution bounds for event handlers
• e.g., from schedulability analysis
Keep track of intra-hyper-period time (ihp) normalized by duration of shortest action
Increment ihp by duration bounds for handlers as they are executed
One tricky issue …
Lazily-Timed Componentsihp
1 2
thandler
ihp 2
thandler
Handler duration fits in before next frame boundary:
Handler duration fits in before next frame boundary:
1. ihp += thandler
2. execute handler to completion
1. ihp += thandler
2. execute handler to completion
ihp
1
thandler-
Handler duration overruns next frame boundary:
Handler duration overruns next frame boundary:1. ihp +=
2. choose prefix of handler to execute
3. assign residual duration to handler suffix
1. ihp += 2. choose prefix of
handler to execute3. assign residual
duration to handler suffix
Preliminary Results (Full Search)
Basic1 rate, 3 components,
2 events per hyper-period
Multi-Rate2 rates, 6 components,
6 events per hyper-period
Modal3 rates, 8 components,
125 events per hyper-period
Medium2 rates, 50 components,
820 events per hyper-period
System ND Priority Lazily-Timed
20, .12s 12, .11s14, .11s
120k, 5m 100, .38s33, .19s
3M+, ? 9.1k, 8.6s 900, 1.3s
13M+, ? 740k, 29m 4k, 8.6s
Conclusions Could imagine providing a variety of forms of
automated checking of lightweight specs for component-based systems
Cadena provides currently provides a few – as requested by Boeing engineers
Component IDL is a natural level for attaching lightweight specs
Spec forms are naturally incremental Cadena continues the line of work by Garlan et.
al. on model-checking pub/sub systems model-checkers that support OO structures directly
make it much easier to model such systems basing model-checker scheduling on scheduling policy
of actual system dramatically reduces state-space
Project Web Site
http://www.cis.ksu.edu/cadena