Analyzing Component-based Designs: The Cadena Environment http://www.cis.ksu.edu/cadena SAnToS Laboratory, Kansas State University, USA Matt Dwyer John Hatcliff Gurdip Singh Principal Investigators Support US 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 ATC Honeywell Technology Center and NASA Langley Sun Microsystems Intel Students William Deng Georg Jung Adam Childs Robby Venkatesh Ranganath
74
Embed
Analyzing Component-based Designs: The Cadena Environment SAnToS Laboratory, Kansas State University, USA Matt Dwyer John.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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!
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
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