520 likes | 656 Views
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
E N D
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 Oksana Tkachuk Robby Venkatesh Ranganath Jesse Greenwald Todd Wallentine 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
For the past decade … • We’ve been developing program analysis frameworks • Standard tensions • Scalable versus Precise • How semantic is the analysis? • Property-specific versus Language-based • How rich are the properties? • Push-button versus Configurable • How usable is the technology?
Analyzing Source Code • Worked on a broad range of case studies • SPIN, SMV, … • Extracting models by hand • Developed a series of tool frameworks for analyzing safety properties of concurrent programs • FLAVERS (Ada) • INCA Translators (Ada) • Bandera (Java)
Succesful? • Tools are widely used • For education • As a basis for further work by us and others • Tools have been used to find bugs in real systems • 1000-10000 LOC • <10 threads • Bugs that eluded significant testing efforts
Whole Program Analysis • will never scale to large code bases • even for highly abstract analyses (e.g., control flow) • even for simple properties (e.g., def-use) • Must perform modular analyses • Hard to do for truly global properties? • Hard to do in presence of concurrency? • What are the natural module boundaries? • How big can a module be?
A Solution … • Target the full range of software artifacts • Requirements models • Architectural descriptions • Designs (at various levels of refinement) • Code • Use semantic analyses • within artifacts (properties) • across different artifacts (conformance)
Features of our Vision • Early and varied semantic modeling • structural modeling is useful as well • Analysis driven feedback and refinement • Artifact generating analyses • Proofs, reachable modes, … • Synthesize code wherever possible • Aspects of an agile process • continuous delivery of working artifacts • Exploit "domain information" throughout • ultimately meta-tools may be useful
Development Flow User’s informal requirements Query checker, Visualization tools Requirements Model Consistency, Completeness, … checker Requirements Model Requirements Model Requirements Model
Development Flow Functional Model Functional Model Functional Model Functional Model Functional Model’ Performance Model Functional Model’ Functional Model’ Functional Model’ Performance Model Performance Model Performance Model User’s informal requirements Model-specific analysis Inter-model consistency, completeness, … checking
Development Flow Functional Model Functional Model’ Performance Model … Conformance checker(s) Design Model Design Model Design Model Design Model
Development Flow Functional Model Functional Model’ Performance Model … Multi-layer conformance checking Structural Design Model Synchronization Policy Spec Abstract Behavioral Model Quality of Service Spec …
Development Flow Functional Model Functional Model’ Performance Model … Structural Design Model Structural Design Model Structural Design Model Structural Design Model Synchronization Policy Spec
Development Flow Functional Model Functional Model’ Performance Model Structural Design Model Structural Design Model Structural Design Model Synchronization Policy Spec Synchronization Policy Spec Synchronization Policy Spec Abstract Behavioral Model Abstract Behavioral Model Abstract Behavioral Model Quality of Service Spec Quality of Service Spec Quality of Service Spec … … … … Structural Design Model Synchronization Policy Spec Abstract Behavioral Model Quality of Service Spec …
Development Flow Structural Design Model Synchronization Policy Spec Abstract Behavioral Model Quality of Service Spec … … Conformance checker(s) Code
Development Flow Structural Design Model Synchronization Policy Spec Abstract Behavioral Model Quality of Service Spec … … Domain-appropriate Implementation Framework Model/spec dependent synthesis procedures (proof generating)
Lessons • Adapt methods to developers • Ease of use, leverage domain abstractions • Use layered, incremental methods • Low entry barrier, early and focused feedback • Focus technology on the hard part • Synchronization, timing, global properties • Synthesize as much code as possible • Developer buyin, reduce code-level reasoning • Developers won’t write specs, so tell them they are writing code
Model Checking in Cadena • Steps toward our vision • Hard problems here are • not component coding (localized) • Inter-component coordination (sequencing, synchronization, timing, …) • Theme • exploit domain semantics • exploit implementation infra-structures
An Overview of … • Component modeling • Middle-ware modeling • Develop an abstract model that captures semantics of actual middle-ware • Environment modeling • Exploit environment information to reduce state space • Property specification • Structural reductions • Exploit structure of state space of periodic RT systems
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
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
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 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
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 event
Towards a Complete Model ? How should we model communication layer? We have transition semantics for intra-component behavior.
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 System Threads run call-backs associated with event consumer ports passive components dispatch queues for each rate group getData consumer refs … … … … publish Event channel with internal thread pool Thread Pool … 60Hz 20Hz 5Hz 1Hz … correlation & filtering proxy consumer holds list of consumer references
System Observations invoke[m,c] dispatch[e] eof[r] accept[e,s] getData consumer refs … … … … c.m == v publish publish[e,c] Event channel with internal thread pool Thread Pool … 60Hz 20Hz 5Hz 1Hz … correlation & filtering
Modeling of Components Structure follows component behavior spec and connection representation closely handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } 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; }
Modeling of Connections instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut Modeled very directly in BOGOR CAD.connectEvent(GPS, “dataCurrent", AirFrame,"inDataAvailable", 20, false);
Modeling Middleware (Threads) Thread Pool … 60Hz 20Hz 5Hz 1Hz 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; } Dispatch queue polling
Modeling Middleware (Queues) Extend model checker types Polymorphic extension … … … 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
Modeling Middleware (Scheduling) … … … • 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 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
Modeling of Environment System behavior is driven by periodic time-triggered events 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
Relative Timeout Counts R1, R2, R3 R1 R1, R2 R1 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 R1 R1, R2 • 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 Problem: Don’t know how long R2 work takes?
Relative Timeout Counts R1 Next R1 timeout could fall in the middle of R2 work R1, R2 • 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 Problem: Don’t know how long R2 work takes? 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 Components Handler duration overruns next frame boundary: • ihp += • choose prefix of handler to execute • assign residual duration to handler suffix Handler duration fits in before next frame boundary: • ihp += thandler • execute handler to completion 2 2 ihp ihp 1 1 thandler thandler- ihp thandler
Preliminary Results (Full Search) System ND Priority Lazily-Timed • Basic • 1 rate, 3 components, • 2 events per hyper-period • Multi-Rate • 2 rates, 6 components, • 6 events per hyper-period • Modal • 3 rates, 8 components, • 125 events per hyper-period • Medium • 2 rates, 50 components, • 820 events per hyper-period 20, .12s 12, .11s14, .11s 120k, 5m 100, .38s33, .19s 3M+, ? 9.1k, 8.6s900, 1.3s 13M+, ? 740k, 29m4k, 8.6s
Functional Properties Property I: System never reaches a state where TacticalSteering and NavSteering are both disabled Property II: If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame]
Event-based Specifications .*; publish[E, c2] + c1.mode == A; [- invoke[Fhandler, c3]]* No trace of form • 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
Exploiting System Structure • Symmetry reductions • Equivalence between states • Partial order reductions • Commutativity between transitions • Collapse compression • Sharing between state components • Can we exploit the time-triggered nature of real-time systems?
A Simple Transition System l1: y = 0; goto l2; l2: x = 0; goto l3; l3: true -> x = 2; goto l4; true -> x = 3; goto l4; l4: y = y + x; goto l5; l5: y>5 -> skip; goto end; y<=5 -> skip; goto l2; end:
Synopsis • A system is quasi-cyclic if • A subset of its state variables repeatedly reach certain fixed values (e.g., initial values) • The rest of the variables can vary freely • Decompose DFS of quasi-cyclic system • BFS of quasi-cyclic regions • DFS within regions • Memory bounded by region DFS • Time penalty due to redundant state visits
Parallel Quasi-cyclic Search • Region DFS are completely independent • Embarassingly parallel • Naïve implementation on 4 processors overcomes overhead • This summer • check realistic scenario • ~400 components, ~130 modal components