• 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

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

• 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

What it was
What it is now
(AirbusA340)

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

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

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

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

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

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.

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

• 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

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

Consider the following program:
Read(ch)
WriteString(‘42’) is this correct?
It is nearly useless without a formal specification.

elicitation of overall system's requirements are we builing the right program?
requirements specification software design implementation
(coding) are we builing the program right?
testing maintenance

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.

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

requirements specification testing software design implementation
(coding)

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

• 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

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

• 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 ?

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

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

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

• 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 lowlevel,
– using a language + diagrams,
– demonstrating consequences,
– animation - including prototyping.

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

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

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

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

• 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
• 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
• 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
• 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
• 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
• Organisation: IBM UK
• B-Method was applied to development of a new component of a future release of CICS
•
Conclusions: T he 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
• 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: T he 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
• 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

• 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
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)