Introduction to Formal Methods

1. Introduction to Formal Methods; Preconditions, Postconditions, and Invariants Revisited; Z language Example (Pressman) Introduction to Formal Methods

2. -- VHDL description of flipflop entity DFF is port (D, clock, reset: in std_logic; Q1: out std_logic;) end DFF: architecture behavior of DFF is begin process (reset, clock) begin if reset = ‘1’ then Q1 <= 0; elseif (clock ‘event and clock=‘1’) then Q1 <= D; endif; end process; end behavior; “engineering” hardware vs “engineering” software: example—a simple flipflop D Q1 clock reset well-defined “part” with datasheet Just change one character…..

3. Software: ---is an abstract layer ---must be translated to hardware ---is very easily modified ---is often developed by a group ---often consists of multiple processes sharing resources What tools has “classical” software engineering developed to deal with the difficulties of producing robust software?

4. Some useful concepts: --“software life cycle” requirements  specifications  design  implement  test  maintain --well-defined development process matching project and resources --process maturity level: “CMM”—well-defined, improve each cycle --independence of testing, design for test, automated test --levels of development: system, unit (black box), code (glass box) --the object-oriented paradigm: promotes modularity, reuse, information hiding --design languages, e.g., Unified Modeling Language (UML) --”contracts”: preconditions, postconditions, invariants, “assert” precondition to divide: denominator is not zero postcondition to push onto stack: stack is not empty

5. But none of these “informal” tools or methods can guarantee fault-free software. For one thing, in most cases there is not enough time in the universe to test all possible states of a system and it may even be difficult to determine what “all possible states” are (“combinatorial explosion”: e.g., if there are n boolean inputs, there are 2n possible states). Therefore, to increase the quality of software, we need to resort to “formal” methods, which are based on mathematics and are expressed in formal languages having well-defined syntax and semantics. The two main mathematical areas we need are Set theory: A ∩ B, A ∪ B, a ∉ X, ∅ Logic: ∄ n ∈ ℕ such that 0 × n = 2 A B

6. Formal methods are mathematically based. They are an attempt to deal with contradictions, ambiguities, vagueness, incomplete statements, and mixed levels of abstraction. They are most valuable for systems which have: --safety concerns (e.g., airplane systems, medical devices) --security concerns What are formal methods?

7. Formal methods can be used to: --Mathematically PROVE correctness of a system --Reduce faults Formal methods can provide: --program specification: define program is supposed to do --program verification: PROVE program does what the specification says it will do Possible automated verification techniques: --automated theorem proving --model checking: exhaustively check all possible “states” of the model that has been developed When are formal methods useful?

8. Formal techniques: --use set theory, logic to specify systems --increase probability of complete, consistent, unambiguous specifications --require specialized training for developers --have high start-up costs; may require high overhead; some concepts (e.g., timing, reliability) difficult or impossible to capture in formal systems --may be difficult for the customer to understand --do not replace more traditional approaches --may be “heavyweight” or “lightweight” Formal techniques

9. Some examples*: --diagnosing subtle problems in a LAN recovery protocol --developing an aircraft collision avoidance system --developing process control systems --[hardware] verifying correct execution of Intel floating point hardware (formal methods adopted after the infamous Pentium division error incident) *G. Huling, Introduction to use of formal methods in software and hardware, WESCON/94, Sep 1994, pp. 48-52, DOI 10.1109/WESCON.1994.403628 (available from IEEE Xplore)  Potentially useful for systems in domains such as: --security --avionics --medical devices When are formal methods useful?

10. Example: Intel Pentium Processor • in 1994, Intel launched the first Pentium CPU, for use in personal computers • this processor was the first Intel processor to incorporate a math coprocessor for floating-point arithmetic, or FPU • before that programs had to tell processors how to divide floating point numbers via integer arithmetic • this was accomplished by providing instructions that were built into the FPU • much faster for numerical calculations

11. Example Continued • this also makes the CPU more complex and expensive • Intel produced these chips for almost a year before the error was caught and corrected • the problem was that the FPU would incorrectly divide certain pairs of numbers • famous example is Coe’s numbers: • 4195835 / 3145727 • The answer is 1.33382, while the Pentium returns 1.33374 (to 6 sig. figs)

12. Example Continued • the error was discovered by Professor Nicely of Lynchburg College • he got values back from his Pentium machine which did not match his theoretical values, but his theoretical values matched values computed on a 486 machine. • the probability of hitting input combinations to produce the error was tiny, but these inputs gave the wrong answer every time

13. Reason for the Error • the divider in the FPU uses a radix 4 SRT algorithm • can compute two binary digits for a quotient every step, rather than one like other FPU’s • this requires a stored division table, similar to a multiplication table • five values out of about a thousand were omitted from the table

14. Consequences • because the error was discussed in the academic community and the findings were posted on the web, this became a large story for the media • this subsequently caused bad publicity for Intel • IBM halted the manufacture and sale of personal computers using the Pentium processor • Intel was eventually forced to replace all bad Pentium chips for customers who wanted them replaced • this, along with having to perform changes to the hardware of the chip, cost Intel hundreds of millions of dollars (approx. $500 million)

15. Why is this Important • just performing standard verification and testing of the system was not enough to catch this error • probability is very small and it is not possible to test all inputs to the chip • if formal methods had been used from the beginning this error would have been caught • formal specifications and proofs would have shown which values should not have been allowed to be set to zero • this would have saved Intel money and corrected the error before it could ever become in error

16. Intel Today • today Intel uses formal specification and formal verification in their hardware design process • write all specifications in a formal language and then prove these specifications using an automated proof checker called HOL Light • incorporate verification algorithms such as square root and reciprocal algorithms which weed out errors like the one found in the Pentium FPU • though this method is more tedious, it provides strict validation of the system, catching errors in the design before they become costly

17. Other Examples of Industrial Usage of Formal Methods • used by NASA to verify the software on the Deep Space 1 • spacecraft designed to test high risk technologies in deep space to lower costs and risks on future missions • formal methods verified the Remote Agent software • found 5 concurrency errors in LISP that would not have been found otherwise and would have been fatal to the spacecraft • an error occurred 24 hours after launch in software only tested using NASA’s test benchmark suite • used in the development of Mondex • an electronic purse stored on a smart card • stores financial data for use in making transactions wirelessly

18. “Heavyweight” formal methods vs “lightweight” formal methods (which use partial specification and focused application): “Many factors influence deciding when and where to use lightweight and heavyweight formal methods. For large complex projects, the application of a heavyweight formal method is virtually impossible thus the lightweight formal method is a good candidate. When we are dealing with safety-critical systems or even, perhaps, trusted systems (in the ISO 15408 sense), using the lightweight formal method is debatable. In these cases, it may be better to use a heavyweight formal specification and analysis if time and cost permit.” Application of Lightweight Formal Methods in Requirement Engineering1V. George ,and R. Vaughn, Crosstalk, The Journal of Defense Engineering http://www.stsc.hill.af.mil/crosstalk/2003/01/george.html accessed august 12, 2010 When are formal methods useful?

19. "Ten Commandments" of formal methods (Pressman, Software Engineering, A Practitioner's Approach): 1. Choose the appropriate notation 2. Formalize but don't overformalize 3. Estimate costs 4. Have a formal methods "guru" on call 5. Do not abandon traditional development methods 6. Document sufficiently 7. Don't compromise quality standards 8. Do not be dogmatic 9. Test, test, test, …. 10. Reuse

20. Earlier we looked at adding statements to ensure correct program behavior: precondition: logical condition that a caller of an operation guarantees before making the call postcondition: logical condition that an operation guarantees upon completion invariant: logical condition that is preserved by transformations These conditions are all expressed as logical statements --they can be quantified: --they can be used to support testing at different levels Preconditions, postconditions, invariants

21. We will also be concerned with how the STATE of a system or component changes: e.g., if the system or a component is in state S, it can be modified to a new state S’

22. A complete formal system We will use an example formal specification language: Z system described through a set of "schemas”, which have data invariant(s) state(s) S: represents change is state S; changed entity r is denoted by r’ operations-- with precondition(s) / postcondition(s) What is Z?

23. 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler” (note: this is just a simple example to demonstrate Z syntax, it is not meant to represent a “safety-critical system” which would be appropriate for strict formal specification) Used blocks Unused (free) blocks Blocks released to queue when files deleted Queued for entry into Unused

24. 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 Z specification: -------BlockHandler---------------------- used,free:  BLOCKS BlockQueue: seq P BLOCKS ----------------------------------------------- used  free =   used  free = AllBlocks   i: dom BlockQueue.BlockQueue i  used   i,j : dom BlockQueue . i  j  BlockQueue i  BlockQueue j =  Z example (2)

25. 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 Z specification: -------BlockHandler---------------------- used,free:  BLOCKS BlockQueue: seq P BLOCKS ----------------------------------------------- used  free =   used  free = AllBlocks   i: dom BlockQueue.BlockQueue i  used   i,j : dom BlockQueue . i  j  BlockQueue i  BlockQueue j =  set Some Z notation intersection union sequence contained in “then” and implies in empty set for all intersection

26. ---------RemoveBlock--------------------------  BlockHandler ----------------------------------------------------- #BlockQueue > 0, used’ = used \ head BlockQueue  free’ = free  head BlockQueue  BlockQueue’ = tail BlockQueue ------------------------------------------------------ ---------AddBlock-------------------------------  BlockHandler Ablocks? : BLOCKS ----------------------------------------------------- Ablocks?  used, used’ = used  free’ = free  BlockQueue’ = BlockQueue ^ (Ablocks?) ------------------------------------------------------ 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 Z example (3)

27. 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 1. What if BlockQueue is replaced by BlockStack? 2. What are postconditions for the operations? Modifications

28. Additional Z Notation

29. Z Sequence Notation

30. Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler” Used blocks Z example revisited (1) 1 3 4 6 9 Unused (free) blocks 2 5 7 8 10 11 12 Blocks released to queue when files deleted 2 5 8 11 7 Queued for entry into Unused

31. Examples: 1. Change BlockQueue to BlockStack: 2. Output size of BlockQueue in AddBlock or RemoveBlock 3. Make BlockQueue part of “free” instead of “used” Modifying the example

32. Modifying the example

33. Class exercise: --Describe a priority queue in Z notation --Are there operations you need which have not yet been defined in these slides on the Z notation? Formal methods in project (exercise)