1 / 52

Model Checking Software Artifacts

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

karan
Télécharger la présentation

Model Checking Software Artifacts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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?

  3. 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)

  4. 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

  5. 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?

  6. 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)

  7. 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

  8. Development Flow User’s informal requirements Query checker, Visualization tools Requirements Model Consistency, Completeness, … checker Requirements Model Requirements Model Requirements Model

  9. 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

  10. Development Flow Functional Model Functional Model’ Performance Model … Conformance checker(s) Design Model Design Model Design Model Design Model

  11. 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 …

  12. Development Flow Functional Model Functional Model’ Performance Model … Structural Design Model Structural Design Model Structural Design Model Structural Design Model Synchronization Policy Spec

  13. 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 …

  14. Development Flow Structural Design Model Synchronization Policy Spec Abstract Behavioral Model Quality of Service Spec … … Conformance checker(s) Code

  15. 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)

  16. 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

  17. and now for Bogor …

  18. 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

  19. 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

  20. Modal SP

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. Towards a Complete Model ? How should we model communication layer? We have transition semantics for intra-component behavior.

  27. 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

  28. 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

  29. 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

  30. 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; }

  31. 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);

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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?

  38. 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, …)

  39. 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 …

  40. 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

  41. 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

  42. 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]

  43. 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

  44. 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?

  45. 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:

  46. System State Space

  47. State Space Decomposition

  48. 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

  49. Cadena models are quasi-cyclic

  50. 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

More Related