Your SlideShare is downloading. ×
Industrial use of formal methods
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

Industrial use of formal methods

3,078
views

Published on

Formal methods aim to apply mathematically-based techniques to the development of computer-based systems, especially at the specification level, but also down to the implementation level. This aids …

Formal methods aim to apply mathematically-based techniques to the development of computer-based systems, especially at the specification level, but also down to the implementation level. This aids early detection and avoidance of errors through increased understanding. It is also beneficial for more rigorous testing coverage. This talk presents the use of formal methods on a real project. The Z notation has been used to specify a large-scale high integrity system to aid in air traffic control. The system has been implemented directly from the Z specification using SPARK Ada, an annotated subset of the Ada programming language that includes assertions and tool support for proofs. The Z specification has been used to direct the testing of the software through additional test design documents using tables and fragments of Z. In addition, Mathematica has been used as a test oracle for algorithmic aspects of the system. In summary, formal methods can be used successfully in all phases of the lifecycle for a large software project with suitably trained engineers, despite limited tool support.

Published in: Education, Technology, Business

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,078
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
68
Comments
1
Likes
3
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. The Industrial Use of Formal Methods: Experiences of an Optimist Prof. Jonathan P. Bowen London South Bank University University of Westminster Museophile Limited www.jpbowen.com jonathan.bowen@lsbu.ac.uk
  • 2. Experiences of an Optimisthttp://en.wikipedia.org/wiki/John_Redcliffe-Maud
  • 3. Background: Safety and reliability
  • 4. Airbus A380 simulatorEmirates Aviation CollegeDubai, 3 February 2011
  • 5. Theory and Practice“It has long been my personal view that theseparation of practical and theoretical work isartificial and injurious. Much of the practical workdone in computing, both in software and in hardwaredesign, is unsound and clumsy because thepeople who do it have not any clear understandingof the fundamental design principles of their work.Most of the abstract mathematical and theoreticalwork is sterile because it has no point of contactwith real computing.” — Christopher Strachey (1916-1975)
  • 6. Formal Methods• Term established by late 1970s – Next stage from structured design – Mathematical basis• Formal specification and (optionally) proof: – Validation (correct specification) – Verification (correct implementation wrt spec)• But engineers calculate rather than prove• Please contribute to the Formal Methods Wiki: – http://formalmethods.wikia.com
  • 7. Z notation• Formal specification – predicate logic, set theory, and schema boxes – Courses (academia & industry) – Textbooks (reasonable choice) – Tools (type-checkers, provers, …)• Web resources – www.zuser.org• Google group – comp.specification.z• Z User Group (meetings) & Z standard
  • 8. Z Standard• ISO/IEC 13568 – Long process (1990s) – Inconsistencies found!• Final Committee Draft – accepted in 2001• Useful for tools and industrial application
  • 9. Levels of Complexity – Abstraction• 25 lines of informal requirements• 250 lines of specification (e.g., Z)• 2,500 lines of design description• 25,000 lines of high-level program code• 250,000 machine instructions of object code• 2,500,000 CMOS transistors in hardware!
  • 10. Technologytransferproblems
  • 11. Choosing a formal method – difficult
  • 12. Tools –difficultto use
  • 13. Applications of Formal Methods Examples: • Tektronix (Z) • STV algorithm (VDM) • IBM CICS (Z/B) • AAMP5 microproc. (PVS) • GEC Alsthom (B) • A300/340 (Z)
  • 14. Industrial-Strength Formal Methods in Practice Examples: • Motorola CAP DSP (ACL2) • Radiation Therapy Machine (Z) • ATC system (VDM) • Railways (Prover Technology) And more recently: Microsoft
  • 15. National Air Traffic Services• Handled 2.2 million flights (in 2009), covering the UK and eastern North Atlantic.• And carried more than 200 million passengers safely through some of the busiest and most complex airspace in the world.• Provides air traffic control from its centres at Swanwick, Hampshire and Prestwick, Ayrshire.• Also provides air traffic control services at 15 of the UKs major airports including Heathrow, Gatwick, Stansted, Birmingham, Manchester, Edinburgh, and Glasgow, together with air traffic services at Gibraltar Airport.
  • 16. National Air Traffic Services, UK Swanwick southern England www.nats.co.uk
  • 17. Flight strips on paper Last flight of Concorde
  • 18. European airspaceSource: WikipediaLondon:England& Wales
  • 19. National Air Traffic Services• Advertisement & leaflet at Heathrow Airport • Air Traffic Management (ATM)• Single European Sky ATM Research (SESAR)• SESAR Joint Undertaking• www.sesarju.eu• SESAR project (2004–20)
  • 20. Altran Praxis www.altran-praxis.com
  • 21. Open-DO Formal Methods in Air Traffic Control Slides by Neil White www.slideshare.net/AdaCore/white-open-do www.youtube.com/watch?v=IQMWVqQfm5ACopyright © Altran Praxis
  • 22. Agenda• A quick introduction – What is iFACTS?• Formal methods for Specification – Z, State machines.• Formal methods for Implementation – Implementation: SPARK.• Formal methods for Test – Verification: more Z, Mathematica.Copyright © Altran Praxis
  • 23. Context• NATS, the UK’s leading air traffic services provider, has pioneered research and development of advanced air traffic control tools for several years from its simulator and research centre. The iFACTS project will deliver a subset of these tools onto the system at the company’s main en-route Control Centre at Swanwick.• Further information is available at: www.computerweekly.com/Articles/2007/03/07/222258/Nats- claims-the-biggest-air-traffic-control-innovation-since.htmCopyright © Altran Praxis
  • 24. UK Air Traffic ControlCopyright © Altran Praxis limited 2010
  • 25. ATC team – The Notes of this slide and the previous slide give some guidance on style and usage. Planner Tactical Assistant (in/out) (controller) (flight strips)Copyright © Altran Praxis limited 2010
  • 26. Why iFACTS?• iFACTS – Interim Future Area Control Tools Support – will further improve safety and provide Controllers with a set of advanced support tools, which will enable them to increase the amount of traffic they can comfortably handle. In trials, the system has delivered significant capacity increases.Copyright © Altran Praxis
  • 27. What is iFACTS?• iFACTS provides tools to support the controllers – Electronic flight strips replace the paper flight strips. – Trajectory tools - including prediction, deviation alerts, and conflict detection – are added.• iFACTS is not an Air Traffic control system – Integrated with, but sits alongside, the existing system.Copyright © Altran Praxis
  • 28. Medium Term Conflict Detection:Separation Monitor Separation Monitor Separation (NM) Cancel Alert Green Lines Labels 15 BAW225 UAL3 UAL2 10 SAA321 BAW028 ANZ001 AZA292 BAL547 DLH4695 AMM1077 5 SAS123 BAW43BE 0 0 5 10 15 Time to Interaction (mins)Copyright © Altran Praxis limited 2010
  • 29. Agenda• A quick introduction – What is iFACTS?• Formal methods for Specification – Z, State machines.• Formal methods for Implementation – Implementation: SPARK.• Formal methods for Test – Verification: more Z, Mathematica.Copyright © Altran Praxis
  • 30. The complete iFACTS specification• The functional specification – Z• The algorithm specification – Maths• The HMI specification – State tables• The rest of the specification! – EnglishCopyright © Altran Praxis
  • 31. The Z specification
  • 32. Z training• Z reader training – 3 day course; fluency then comes after 1 week on the job. – We have trained 75 people to read Z. – Engineers, domain experts, ATCOs.• Z writer training – 3 day course, fluency then comes after 3 months on the job. – We have trained 11 people to write Z. – All engineers.Copyright © Altran Praxis
  • 33. Z tools• Z written in Microsoft Word – To get acceptance, you need to work with what people know. – Supported by Word Add-ins. • A Z character set. • A simple interface to the fuzz type checker. • A graphical representation tool.Copyright © Altran Praxis
  • 34. Z tools• Advantages – Easy to develop commentary and Z together. – Hyper linking of fuzz errors back to source. – Cross-referencing of Z names in final document.• Disadvantages – All the problems of large word documents. – Tools can be slow on 1000 page documents. – Merging branches is painful.• The Future – Open Office XML?Copyright © Altran Praxis
  • 35. The state machine specification Button 1 Checkbox 1State 1 State 2 N/AState 2 State 1 State 3State 3 State 1 State 2Transition Actions State 1 -> State 2 : De-select Checkbox 1Copyright © Altran Praxis
  • 36. State machine training & tools• Training – So trivial that we don’t train! – People “just get it”.• Tools – Err …. None.Copyright © Altran Praxis
  • 37. Agenda• A quick introduction – What is iFACTS?• Formal methods for Specification – Z, State machines.• Formal methods for Implementation – Implementation: SPARK.• Formal methods for Test – Verification: more Z, Mathematica.Copyright © Altran Praxis
  • 38. The SPARK Implementation• SPARK Ada – An annotated subset of Ada.• 150 KSLOC (Logical)• RTE (Run-Time Exception) Proof – Formal partial correctness proof against specification not considered cost-effective.Copyright © Altran Praxis
  • 39. Code
  • 40. SPARK Training• 57 people trained in SPARK – Mostly contractors and clients. – Diverse programming background. – All SPARK coders are also Z readers.• Effective as SPARK coders immediately• Picking up RTE proof takes longer. – About 2 months.• How long to pick up formal correctness proofs? – No data, but I suspect longer again.Copyright © Altran Praxis
  • 41. SPARK Tools• The SPARK toolset – Examiner. – Proof Simplifier. – Proof Checker.• See me later!Copyright © Altran Praxis
  • 42. Agenda• A quick introduction – What is iFACTS?• Formal methods for Specification – Z, State machines.• Formal methods for Implementation – Implementation: SPARK.• Formal methods for Test – Verification: more Z, Mathematica.Copyright © Altran Praxis
  • 43. Test Design
  • 44. The Challenge of Test Design How many potential tests for this fragment?
  • 45. The Challenge of Test Design• If you just turn the handle there are 1134 conditions to test.• But if you work at it hard enough you can cover the required subset in just 6 test scripts.• Formal methods are not a substitute for initiative.Copyright © Altran Praxis
  • 46. Test reference models• Algorithms are specified in pure mathematics. – Working out the expected answer for test cases is very difficult and error prone.• We generate test cases as usual.• We create a test reference implementation in Mathematica.• We do back-to-back testing of iFACTS against the reference. – Diverse tools and implementers reduce the possibility of a common failure.Copyright © Altran Praxis
  • 47. Mathematica tools & training• Small team – only 5 trained.• Reference model has similar defect density to SPARK implementation.• Limited conclusions to draw from such a small activity.Copyright © Altran Praxis
  • 48. Conclusions• Formal methods are applicable to all phases of the lifecycle.• Training engineers is not a barrier – It’s a one-off cost – Our data shows that training is easy and cheap.• Tool support is vital – The Achilles heel of formal methods •Except the SPARK Examiner!Copyright © Altran Praxis
  • 49. Altran PraxisAltran Praxis Limited20 Manvers StreetBath BA1 1PXUnited KingdomTelephone: +44 (0) 1225 466991Facsimile: +44 (0) 1225 469006Website: www.altran-praxis.comEmail: neil.white@altran-praxis.comCopyright © Altran Praxis
  • 50. Tracing• Completeness of coverage – e.g., testing all parts of a Z specification• DOORS tool – Integrate Systems Engineering• Link all specification components with test case(s) or argument for safety case• Flag unlinked components• Also visualization of schema structurewww.integrate.biz/casestudies/BusinessGoalAlignment.aspx
  • 51. Future• Traffic Load Prediction Device (TLPD)• Forecast air traffic load up to 4 hours ahead• Plan workloads for optimum traffic flowswww.altran-praxis.com/news/nats_control_system_21_Sep_10.aspxx
  • 52. Reflection Oui, louvre sort plus belle Dune forme au travail Rebelle, Vers, marbre, onyx, émail. [Yes, the work comes out more beautiful from a material that resists the process, verse, marble, onyx, or enamel.] — Théophile Gautier (1811–1872) LArt
  • 53. BewarePanaceas! Cf. Formal methods
  • 54. CaviatEmptor!Cf. Software
  • 55. The Industrial Use of Formal Methods: Experiences of an Optimist Prof. Jonathan P. Bowen London South Bank University University of Westminster Museophile Limited www.jpbowen.com jonathan.bowen@lsbu.ac.uk