Formal modelling of software systems

1. Formal modelling of software systems

2. Presentation Plan • Where computers are used and why, • What happens if they do not work, • Software quality and the problem of correctness, • Software specification, • Formal software specification. • Formal Methods in the industry

3. Computer systems are used • In aircraft systems (navigation, stability, etc.), • For air traffic control, • For the control of railway signals and junctions, • In medical systems, • In nuclear power stations.

4. Why computer control is necessary • Enables usage of designs with better aerodynamic properties, but inherently unstable, • Less stable aircraft is more manoeuvrable, • Reduction of the workload on a pilot. EuroFighter Typhoon (EF2000) is unstable

5. Cockpit What it was What it is now (AirbusA340)

6. easy to make changes, such as add new functionality software can be installed easily, identical computers with different programs could perform completely differently – less hardware to maintain. Flexibility of software –advantages

7. Flexibility of software –disadvantages • Developers are tempted to constantly modify software, leading to quality problems, • Difficult to ensure compatibility across the spectrum of usage(Arianne 5 failure).

8. Near-accidents • A software bug on early versions of the F16 military jet caused it to flip when it crossed the equator. • In 1983, a Boeing 767 was approaching Denver airport on a computer-controlled descent. • The computer was programmed to conserve as much fuel as possible on landing, and it slowed the engines down to a minimum rate that would have been acceptable under normal weather conditions. • However the plane was flying through a storm, and the engines cooled down so much that ice formed on them. • This interfered with the flow of air, and the engines overheated, and therefore stopped. • It took four minutes before the engines could be restarted, during which the plane was on a powerless glide.

9. More accidents • The Times, Thursday October 3, 1996. Computer blamed as 70 are killed in Peru jet crash. • On October 14, 1989, at Dallas-Forth Worth, Texas, the air traffic control computer had more data to process than memory available. It crashed and remained out of service for more than 20 minutes. • The Docklands Light Railway always stopped on a portion of elevated track, remained there for a few minutes with the doors closed, and then moved on. • The original specification had included a stop there because of a large development, which was later cancelled. • However the railway stop was not cancelled. The software developers had already included it in the software, which having passed testing, they were unwilling or unable to modify.

10. Even more • Robots are used to perform surgery, e.g., prostate, hip and brain surgery. What happens if there is a failure in the software that controls a scalpel? • In Texas in 1986, two patients died from radiation therapy from a computer-controlled radiation therapy machine. The accident occurred because of a software bug that allowed events to occur in the wrong order. • In the 1970s, some nuclear power plants in the USA were declared able to withstand earthquakes. • A bug was discovered in the program that was used to calculated the stresses on the pipes of the cooling system. • In 1978, the US Nuclear Regulatory Commission shut down five nuclear power stations until it could be proved that they could all withstand an earthquake.

11. General Motors’ problem General Motors opened a factory in Detroit in 1985 with 50 automatic guided vehicles (AGVs) to transport parts and 260 robots to paint and weld. … Almost a year after it was opened, all this high technology was so unreliable that the plant was only producing about half the 60 cars per hour that it was supposed make … … The production lines ground to a halt for hours while technicians tried to debug software. When they did work, the robots started dismembering each other, smashing cars, spraying paint everywhere, or even fitting the wrong equipment … AGVs … sometimes simply refused to move. When GM’s robots ran amok, The Economist, August 10, 1991, p. 64-65.

12. About the future • Railways: high speed tilting trains. • Airplanes: an increasing number of operations on airplanes are controlled by software (fly-by-wire). • Cars: Mercedes Benz has developed a ‘hands-off ’ car. The driver sets the speed and distance from the vehicle in front, and the car steers using video cameras. If the driver wants to overtake, he turns on the indicator, and video cameras are used to determine if it is safe to perform the manoeuvre.

13. Software problems • Portability, for instance, the lifetime of an aircraft is more than 30 years, hardware – 5, • Avionics systems are very expensive to build, • Would like to use commercial off-the shelf components to reduce development costs

14. Software systems have to provide results • Correctly, all the time, • Not to display potentially misleading information, • Fast enough. Software must work correctly as soon as it is installed, particularly in safety-critical systems.

15. The problem of correctness • Consider the following program: • Read(ch) • WriteString(‘42’) • is this correct? • A program is meaningless without a specification • It is nearly useless without a formal specification.

16. Waterfall software development model

17. Software testing Correctness – whether the system behaves as it should. We need to: • Describe what a system should be doing, • Derive a number of inputs to check if the system built behaves as it should.

18. The use of a specification • Software designers and implementers - code development, • Technical writers - user manuals, • Quality assurance people - software testing, • A specification is particularly important in maintenance/porting of existing systems.

19. Spiral software development model

20. A specification • A step in the software lifecycle between determination of overall requirements stage and the design one. • A description of a system. • A mathematical model of a system. • A vehicle for defining the meaning of some system, thus making it possible to communicate and understand it.

21. Specification types • Informal • Structured - SSADM uses diagrams to describe data and event structures. • Object-Oriented • objects - data+behaviour+encapsulation -facilitates reuse of objects • diagrammatic structure of data objects and their behaviour • Formal - uses mathematical notations • Z - data transformations. • X-machines and finite-state machines - control flow • CSP - communication of concurrent systems

22. Why formal specification • Natural language is ambiguous • It is difficult to give a concise description “... the system has a single primary input. It requires ...”

23. More reasons • Likely to be inconsistent • Likely to be incomplete “... The voicemail system will let a caller leave a message if a phone owner cannot take the call ...” what will happen if a phone owner was having a conversation but finished it shortly after someone tried to call him and has not yet hang up ?

24. A useful specification language • Has a clearly defined syntax. • Can be interpreted in only one way. • Can be reasoned with, to demonstrate • consistency, • completeness, • satisfaction of properties, • correctness of implementation. Z is discrete maths (set theory + logic) + supplementary text.

25. Demystifying formal methods • Formal methods do not guarantee infallibility • user need might be captured erroneously, • a model of a system cannot cover everything, • a need to track reasons behind decisions. • Formal methods allow • to prove properties about a system, • perform correct transformations, such as from a specification to a design, • generate a test set, accounting for all possible faults.

26. more on demystifying 1 • Formal methods are helpful in non-safety-critical software development • Training is required, but not very costly - it is more difficult to start thinking about specifying a system rather than implementing it • Formal methods can reduce costs • By finding errors earlier, • One of the IBM’s systems’ development time was reduced by 9% through usage of formal methods.

27. more on demystifying 2 • Incomprehensible • a formal specification is rather easier to understand than pseudocode which is often provided, because a specification can be abstract and pseudocode is normally rather low-level, • using a language + diagrams, • demonstrating consequences, • animation - including prototyping.

28. more on demystifying 3 • FM make it rather easier to find faults: • Inspections, • Use of simple checking tools, • Proving properties (e.g. that a system will not lose a message, that it will always deliver one).

29. Common pitfalls • It is difficult to estimate costs for usage of formal methods, including training time. • Formal methods do not replace conventional software development processes, instead • complement them, • provide better opportunities to accommodate change. • One should not introduce formal methods in a “big bang” way, a gradual introduction works best. • If an error is found in a specification at the implementation stage, we should correct both the specification and the code.

30. 10 commandments of formal methods • Choose an appropriate notation, • Formalise, but do not overformalise, • Estimate costs, • Have a formal methods guru on call, • Do not abandon your traditional methods, • Document sufficiently, • Do not compromise your quality standards, • Do not be dogmatic, • Test, test and test again, • Reuse.

31. Usage of tools • There is a number of tools supporting formal methods; usage of formal methods without tools can be difficult. • Types of tools available: • type-checking, • theorem-proving, • model checking.

32. It is very important to remember that: • Every formal notation is good for a specific task it was designed for and can lead to a disaster when used outside its domain. • Abstractions - • too abstract a specification does not allow to find out what the system is doing, • too detailed one is essentially an implementation rather than a specification.

33. Formal Methods in the Industry • Hardware design, synthesis and verification (Verilog, U.S. – Bell Labs) • FM toolsets, e.g. Type Checkers, Provers and Animators (B-Core UK Ltd. – ORA Canada, …) • System Analysis, Design and Development Consultants (Praxis UK) • Corporations (IBM, BT, Daimler-Benz )

34. Industrial Projects Conducted Using FM • High level Formal Specification of a Bus (Volvo Sweden) • Formal Spec. of a Secure Gateway (Thomson Telecoms, France) • Formal Specification and Design of CICS (IBM UK) • Formalisation of Requirements for Railway Interlocking Systems (Danish Railways)

35. High level Formal Spec. of a Bus • Organization: Volvo Bus Corporation (Sweden) and Logikkonsult AB (Sweden) • Method: Propositional logic • Formal systems analysis and development of a general high-level formal specification of a bus. Formalisation and validation (using NP-tools) of safety requirements, functional requirements. • Size: 100 page specification document, about 1500 propositional variables, about 1000 propositional formulas.

36. Developing a Secure Gateway • The security policy was formally modeled by B abstract machines and proven consistent with the SA-RT semi-formal functional specifications by means of an interactive theorem prover. • Size: Approximately 5000 lines of specification. Approximately 500 proof obligations verified • Period: September 1994 - March 1995 • Conclusions: The most time-consuming part of the work has been elaborating a security model rather than writing or proving the formal specification.

37. CICS • Organisation: IBM UK • B-Method was applied to development of a new component of a future release of CICS • Conclusions: The possibility of automating mechanical aspects of the coding process - Tools such as type-checkers and code generators reduced coding errors. • Size: (Approximate figures:) Specification: 750 lines AMN, implementation: 2500 lines AMN. 10,000 Lines of generated code. 2 Man-years. • Period: March 1993 - December 199

38. Railway Interlocking System • Danish State Railways • Requirement specifications for systems that control points and signals such that no train collisions and no derailing occur. • Size: 30 pages including comments on the specification • Period: The VDM spec. took less than a year, including the time which it took to get acquainted with the application domain • Conclusions: Formal methods helped in clarifying the safety requirements

39. Lessons Learnt • Tools are central to the use of any formal technique • The amount of man-hour overhead of using FM is not only very well justified but also fairly minor. • Formal Methods can be and are being used in areas much broader than software development

40. Books and articles • An Introduction to Formal Specification and Z, B. Potter, J. Sinclair & D. Till, Prentice-Hall, 2nd edition, 1996 • The Z Notation: A Reference Manual, J.M. Spivey, Prentice Hall, 2nd edition, 1992. • Software Engineering, a practitioner's approach,R. Pressman, London, McGraw-Hill, 1994. • 7 Myths of formal methods, IEEE Software, 7(5) September 1990, 11-19.

41. Final Thoughts The world is turning to C,though at best it is taught awkwardly.But we don’t have to mope,there’s a glimmer of hope,in the method of formality.David Gries(1995, ZUM95)