Model Checking Software Artifacts http://www.cis.ksu.edu/bogor 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 Oksana Tkachuk Robby Venkatesh Ranganath Jesse Greenwald Todd Wallentine http://www.cis.ksu.edu/bandera http://www.cis.ksu.edu/cadena
SAnToS Laboratory, Kansas State University, USA. Model Checking Software Artifacts. http://www.cis.ksu.edu/cadena. http://www.cis.ksu.edu/bandera. http://www.cis.ksu.edu/bogor. Principal Investigators. Students. Matt Dwyer John Hatcliff Gurdip Singh. William Deng Georg Jung - PowerPoint PPT Presentation
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
Model Checking Software Artifacts
http://www.cis.ksu.edu/bogor
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
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 Looked at implemented semantics of
existing ORBs and Event Services ACE/TAO, 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
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 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 isn’t very interested in real-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
R1
R2
R3
R1 R1R1, R2
R1, R2, R3
Assume that worst case execution time of Ri work can be performed in the period of Ri
There is a pattern to the number of timeout counts in a frame
• e.g., in frame of Ri there are two timeouts of Ri-1
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, …)
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
Functional Properties
Property II: If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame]
Property II: If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame]
Property I:System never reaches a state where TacticalSteering and NavSteering are both disabled
Property I:System never reaches a state where TacticalSteering and NavSteering are both disabled
Event-based Specifications
Many properties of interest in this domain are event oriented Some require access to state information
A state qualified event (written e + f) defines the occurrence of an observable event, e,
in a state that satisfies a given formula, f. For example,
If component c1 is in mode A when component c2 produces event E, them component c3 will consume event F.*;