Your SlideShare is downloading. ×
0
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Uppaal
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Uppaal

198

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
198
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Model Checking with UPPAAL Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BestPractice Consulting — Thursday 31st May, 2012
  • 2. Background Ulrik Hørlyk Hjort Safety Critical and High Integrity system development since 1997 Defence industry from 1997 Space industry from 2003 Medical industry from 2006 Formal software development since 2003 VDM, Z, B-Method and UPPAAL Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 3. Overview Use of Model Checking to add value to traditional testing. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 4. Traditional Testing Testing involves running a program with a set of inputs and comparing the actual outputs from the program against the expected outputs (as defined in the specification). There are several limitations to using testing as the sole approach to software error detection: Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 5. Testing Limitations Testing cannot take place until some implementation is available. Correcting errors uncovered by testing could involve retracing many steps and undoing work previously done. If testing is the only approach to error detection then errors in the specification involve the greatest amount of work to rectify. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 6. Testing Limitations Testing can only help to uncover errors it cannot guarantee the absence of them. Since, for any application, it is impossible to test every set of input values, residual errors will always have to be accepted. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 7. Testing Limitations Testing is always carried out with respect to requirements as laid down in the specification. If the specification document is in any way ambiguous it is open to interpretation, and hence misinterpretation, making testing a rather inexact science. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 8. Ambiguous Specification Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 9. Testing Problems Clearly the specification plays a vital role in the reliability of the software produced. The design, and subsequent implementation, is based upon the information in the specification. The testing process relies upon the developers understanding of the specification to determine whether or not the software is behaving correctly. Misunderstandings in the specification can lead to the delivery of final applications that do not match user requirements. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 10. Formal Methods A formal method provides a formal language in which to express the initial specification and all future design steps towards the final program in a unambiguous way. More than just a specification language —it also includes a proof system for demonstrating that each design step preserves the formal meaning captured in the previous step. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 11. Formal Methods advantages The discipline required in producing a formal specification of user requirements and the ability to analyse a specification (which only arises if the specification language has a well-defined semantics) allows for feedback on system specifications at early development stages, increasing confidence that the specification accurately captures the real system requirements. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 12. Formal Methods advantages Important properties (such as internal consistency) of the initial specification can be checked mathematically and incorporated as run-time checks in the final program. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 13. Formal Methods advantages Proofs can help uncover design errors as soon as they are made, rather than having to wait for testing of the final implementation. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 14. Formal Methods advantages A proof of program correctness can be constructed that is a much more robust method of achieving program correctness than is testing alone. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 15. Formal Methods advantages Formal specifications can help considerably in generating suitable test cases. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 16. Model Checking In a model-based approach an abstract mathematical model is built of the data, using abstract mathematical types such as sets and abstract state machines. The behaviour of the operations is then specified directly with respect to this model. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 17. The UPPAAL System Integrated tool environment for: System Modelling Simulation of the model Verification of the model Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 18. The System Editor The system editor is used to create and edit the system model to be analyzed A system model describe a network of a finite number of non-deterministic finite state automata Edges between states may be labeled with: Guards Synchronizations Assignment statements Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 19. UPPAAL Model Items Initial Location Location Edge Synchronization Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 20. UPPAAL Model Items class _Factorial { int result; public void Factorial() { for (int i = result-1; i > 1; i--) { result *= i; } } public _Factorial() { result = 5; } public voidShowResult() { System.out.println("Result:" + result); } public static void main(String args[]) { _Factorial fac = new _Factorial(); fac.Factorial(); fac.ShowResult(); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 21. UPPAAL Model Items Subprogram Synchronization class Hello { private void Put_Line() { System.out.println("Hello World!n"); } public Hello() { Put_Line(); } public static void main(String args[]) { Hello hello = new Hello(); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 22. UPPAAL Model Items Ada Tasks task body TaskA is begin TaskB.WriteTaskName; end TaskA; task body TaskB is begin accept WriteTaskName do Put_Line("Task B"); end WriteTaskName; end TaskB; Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 23. UPPAAL Model Items Parametrised Synchronization class Factorial { int result; public int Factorial(int N) { int result = 1; for (int i = N; i > 1; i--) { result *= i; } return result; } public static void main(String args[]) { Factorial fac = new Factorial(); int result = fac.Factorial(5); System.out.println(result); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 24. The Model Checker (Verifier) The main purpose of a model checker is to verify the model with respect to a requirement specification. Like the model, the requirement specification must be expressed in a formally well-defined and machine readable language. The model checker support three path formulae expressed by temporal logic quantifiers: Reachability : Is the state formular ϕ satisfied from any reachable state ? Safety : ϕ is invariantly true in all reachable states Liveness : ϕ is eventually sastified Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 25. Quantifiers E : There exists a path A : For all paths G (♦ in UPPAAL) : All states in a path F ( in UPPAAL) : Some states in a path The following combinations are supported: A , A♦, E♦, and E Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 26. Reachability Properties: E ϕ “ϕ Reachable” E ϕ: It is possible from the initial state to reach a state in which ϕ is satisfied ϕ is true in at least one reachable state Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 27. Safety Properties: A ϕ “Invariantly ϕ” A ϕ: ϕ holds invariantly ϕ is true in all reachable states Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 28. Liveness Properties: A ♦ ϕ “Inevitable ϕ” A ♦ ϕ: ϕ will inevitable become true The automaton is guaranteed to eventually reach a state in which ϕ is true ϕ is true in some states of all paths Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 29. E ϕ “Potentially always ϕ” E ϕ: ϕ is potentially always true There exists a path in which ϕ is true in all states Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 30. The Simulator The simulator can be used in three ways: Running the system manually and manually choose the transitions to take Going through a trace generated by the verifier Running the system at is own in random mode Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 31. ATM System E X A M P L E Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 32. Actors: Customer, Bank System: ATM Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 33. Customer Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 34. ATM Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 35. Bank Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 36. ATM System Requirements: 1 Transaction is only valid with a bank balance greater than 10 euro 2 Customer gets cash when transaction is done 3 System may not be able to enter a deadlock state Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 37. Requirement 1 Transaction is only valid with a bank balance greater than 10 euro A (Customer.READY and Bank.TRANSACTION OK) imply Bank.balance >10 Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 38. Requirement 2 Customer gets cash when transaction is done E ♦ Customer.GET CASH and Bank.TRANSACTION DONE Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 39. Requirement 3 System may not be able to enter a deadlock state A not deadlock Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 40. System Automatic test of requirements and MMI flow of insulin pump Javascript with user actions commands and verification of expected result of these First manually written from UML diagrams, MMI flows and requirements Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 41. System UPPAAL model made from UML diagrams, MMI flows and requirements UPPAAL system locations was annotated with test script actions Full coverages paths of the model found by verifier A full coverage package of test Javascript generated from the model Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 42. System Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  • 43. Test script example expect_mainScreen() { expect(Label(Welcome); expect(Label(BatteryIndicator); } expect_callScreen() { expect(Label(Calling ...); } // Main Script: expect_mainScreen(); insert_card() expect_enter_pincode_screen(); key(5); expect(5); key(1); expect(1); expect_trasactionscreen(); . . . Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking

×