Frequent Links
Formal methods
In computer science, specifically software engineering and hardware engineering, formal methods are a particular kind of mathematically based techniques for the specification, development and verification of software and hardware systems.^{[1]} The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analysis can contribute to the reliability and robustness of a design.^{[2]}
Formal methods are best described as the application of a fairly broad variety of theoretical computer science fundamentals, in particular logic calculi, formal languages, automata theory, and program semantics, but also type systems and algebraic data types to problems in software and hardware specification and verification.^{[3]}
Contents
Taxonomy
Formal methods can be used at a number of levels:
Level 0: Formal specification may be undertaken and then a program developed from this informally. This has been dubbed formal methods lite. This may be the most costeffective option in many cases.
Level 1: Formal development and formal verification may be used to produce a program in a more formal manner. For example, proofs of properties or refinement from the specification to a program may be undertaken. This may be most appropriate in highintegrity systems involving safety or security.
Level 2: Theorem provers may be used to undertake fully formal machinechecked proofs. This can be very expensive and is only practically worthwhile if the cost of mistakes is extremely high (e.g., in critical parts of microprocessor design).
Further information on this is expanded below.
As with programming language semantics, styles of formal methods may be roughly classified as follows:
 Denotational semantics, in which the meaning of a system is expressed in the mathematical theory of domains. Proponents of such methods rely on the wellunderstood nature of domains to give meaning to the system; critics point out that not every system may be intuitively or naturally viewed as a function.
 Operational semantics, in which the meaning of a system is expressed as a sequence of actions of a (presumably) simpler computational model. Proponents of such methods point to the simplicity of their models as a means to expressive clarity; critics counter that the problem of semantics has just been delayed (who defines the semantics of the simpler model?).
 Axiomatic semantics, in which the meaning of the system is expressed in terms of preconditions and postconditions which are true before and after the system performs a task, respectively. Proponents note the connection to classical logic; critics note that such semantics never really describe what a system does (merely what is true before and afterwards).
Lightweight formal methods
Some practitioners believe that the formal methods community has overemphasized full formalization of a specification or design.^{[4]}^{[5]} They contend that the expressiveness of the languages involved, as well as the complexity of the systems being modelled, make full formalization a difficult and expensive task. As an alternative, various lightweight formal methods, which emphasize partial specification and focused application, have been proposed. Examples of this lightweight approach to formal methods include the Alloy object modelling notation,^{[6]} Denney's synthesis of some aspects of the Z notation with use case driven development,^{[7]} and the CSK VDM Tools.^{[8]}
Uses
Formal methods can be applied at various points through the development process.
Specification
Formal methods may be used to give a description of the system to be developed, at whatever level(s) of detail desired. This formal description can be used to guide further development activities (see following sections); additionally, it can be used to verify that the requirements for the system being developed have been completely and accurately specified.
The need for formal specification systems has been noted for years. In the ALGOL 58 report,^{[9]} John Backus presented a formal notation for describing programming language syntax (later named Backus Normal Form then renamed BackusNaur Form (BNF)^{[10]}). Backus also wrote that a formal description of the meaning of syntactically valid ALGOL programs wasn't completed in time for inclusion in the report. "Therefore the formal treatment of the semantics of legal programs will be included in a subsequent paper." It never appeared.
Development
Once a formal specification has been produced, the specification may be used as a guide while the concrete system is developed during the design process (i.e., realized typically in software, but also potentially in hardware). For example:
 If the formal specification is in an operational semantics, the observed behavior of the concrete system can be compared with the behavior of the specification (which itself should be executable or simulateable). Additionally, the operational commands of the specification may be amenable to direct translation into executable code.
 If the formal specification is in an axiomatic semantics, the preconditions and postconditions of the specification may become assertions in the executable code.
Verification
Once a formal specification has been developed, the specification may be used as the basis for proving properties of the specification (and hopefully by inference the developed system).
Humandirected proof
Sometimes, the motivation for proving the correctness of a system is not the obvious need for reassurance of the correctness of the system, but a desire to understand the system better. Consequently, some proofs of correctness are produced in the style of mathematical proof: handwritten (or typeset) using natural language, using a level of informality common to such proofs. A "good" proof is one which is readable and understandable by other human readers.
Critics of such approaches point out that the ambiguity inherent in natural language allows errors to be undetected in such proofs; often, subtle errors can be present in the lowlevel details typically overlooked by such proofs. Additionally, the work involved in producing such a good proof requires a high level of mathematical sophistication and expertise.
Automated proof
In contrast, there is increasing interest in producing proofs of correctness of such systems by automated means. Automated techniques fall into two general categories:
 Automated theorem proving, in which a system attempts to produce a formal proof from scratch, given a description of the system, a set of logical axioms, and a set of inference rules.
 Model checking, in which a system verifies certain properties by means of an exhaustive search of all possible states that a system could enter during its execution.
Some automated theorem provers require guidance as to which properties are "interesting" enough to pursue, while others work without human intervention. Model checkers can quickly get bogged down in checking millions of uninteresting states if not given a sufficiently abstract model.
Proponents of such systems argue that the results have greater mathematical certainty than humanproduced proofs, since all the tedious details have been algorithmically verified. The training required to use such systems is also less than that required to produce good mathematical proofs by hand, making the techniques accessible to a wider variety of practitioners.
Critics note that some of those systems are like oracles: they make a pronouncement of truth, yet give no explanation of that truth. There is also the problem of "verifying the verifier"; if the program which aids in the verification is itself unproven, there may be reason to doubt the soundness of the produced results. Some modern model checking tools produce a "proof log" detailing each step in their proof, making it possible to perform, given suitable tools, independent verification.
Applications
Formal methods are applied in different areas of hardware and software, including routers, Ethernet switches, routing protocols, and security applications. There are several examples in which FMs have been used to verify the functionality of the hardware and software used in DCs. IBM used ACL2, a theorem prover, in AMD x86 processor development process. Intel uses FMs to verify its hardware and firmware (permanent software programmed into a readonly memory). There are several other projects of NASA in which FMs are applied, such as Next Generation Air Transportation System, Unmanned Aircraft System integration in National Airspace System,^{[11]} and Airborne Coordinated Conflict Resolution and Detection (ACCoRD).^{[12]}
BMethod with AtelierB,^{[13]} is used to develop safety automatisms for the various subways installed throughout the world by Alstom and Siemens, and also for Common Criteria certification and the development of system models by ATMEL and STMicroelectronics.
Formal verification has been frequently used in hardware by most of the wellknown hardware vendors, such as IBM, Intel, and AMD. There are many areas of hardware, where Intel have used FMs to verify the working of the products, such as parameterized verification of cache coherent protocol,^{[14]} Intel Core i7 processor execution engine validation ^{[15]} (using theorem proving, BDD’s, and symbolic evaluation), optimization for Intel IA64 architecture using HOL light theorem prover,^{[16]} and verification of high performance dualport gigabit Ethernet controller with a support for PCI express protocol and Intel advance management technology using Cadence.^{[17]} Similarly, IBM has used formal methods in the verification of power gates,^{[18]} registers,^{[19]} and functional verification of the IBM Power7 microprocessor.^{[20]}
Formal methods and notations
This section is in a list format that may be better presented using prose. (August 2009) 
There are a variety of formal methods and notations available.
 Specification languages
 Abstract State Machines (ASMs)
 A Computational Logic for Applicative Common Lisp (ACL2)
 ANSI/ISO C Specification Language (ACSL)
 Alloy
 Autonomic System Specification Language (ASSL)
 BMethod
 CADP
 Common Algebraic Specification Language (CASL)
 Java Modeling Language (JML)
 Knowledge Based Software Assistant (KBSA)
 Process calculi
 Actor model
 Esterel
 Lustre
 mCRL2
 Perfect Developer
 Petri nets
 Predicative programming
 RAISE
 SPARK Ada
 Spec sharp (Spec#)
 Specification and Description Language
 TLA+
 USL
 VDM
 VDMSL
 VDM++
 Z notation
 Rebeca Modeling Language
 Model checkers
 SPIN
 PAT is a powerful free model checker, simulator and refinement checker for concurrent systems and CSP extensions (e.g. shared variables, arrays, fairness).
 MALPAS Software Static Analysis Toolset is an industrial strength model checker used for Formal Proof of safety critical systems
 UPPAAL
See also
 Automated theorem proving
 Design by contract
 Formal methods people
 Formal specification
 Formal verification
 Formal system
 Model checking
 Software engineering
 Specification language
References
 ^ R. W. Butler (20010806). "What is Formal Methods?". Retrieved 20061116.
 ^ C. Michael Holloway. "Why Engineers Should Consider Formal Methods" (PDF). 16th Digital Avionics Systems Conference (27–30 October 1997). Retrieved 20061116.
 ^ Monin, pp.34
 ^ Daniel Jackson and Jeannette Wing, "Lightweight Formal Methods", IEEE Computer, April 1996
 ^ Vinu George and Rayford Vaughn, "Application of Lightweight Formal Methods in Requirement Engineering", Crosstalk: The Journal of Defense Software Engineering, January 2003
 ^ Daniel Jackson, "Alloy: A Lightweight Object Modelling Notation", ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 11, Issue 2 (April 2002), pp. 256290
 ^ Richard Denney, Succeeding with Use Cases: Working Smart to Deliver Quality, AddisonWesley Professional Publishing, 2005, ISBN 0321316436.
 ^ Sten Agerholm and Peter G. Larsen, "A Lightweight Approach to Formal Methods", In Proceedings of the International Workshop on Current Trends in Applied Formal Methods, Boppard, Germany, SpringerVerlag, October 1998
 ^ Backus, J.W. (1959). "The Syntax and Semantics of the Proposed International Algebraic Language of Zürich ACMGAMM Conference". Proceedings of the International Conference on Information Processing. UNESCO.
 ^ Knuth, Donald E. (1964), Backus Normal Form vs Backus Naur Form. Communications of the ACM, 7(12):735–736.
 ^ Gheorghe, A. V., & Ancel, E. (2008, November). Unmanned aerial systems integration to National Airspace System. In Infrastructure Systems and Services: Building Networks for a Brighter Future (INFRA), 2008 First International Conference on (pp. 15). IEEE.
 ^ Airborne Coordinated Conflict Resolution and Detection, http://shemesh.larc.nasa.gov/people/cam/ACCoRD/
 ^ website : http://www.atelierb.eu/en/
 ^ C. T. Chou, P. K. Mannava, S. Park, “A simple method for parameterized verification of cache coherence protocols,” Formal Methods in ComputerAided Design, pp. 382398, 2004.
 ^ Formal Verification in Intel® Core™ i7 Processor Execution Engine Validation, http://cpsvo.org/node/1371, accessed at Sep. 13, 2013.
 ^ J. Grundy, “Verified optimizations for the Intel IA64 architecture,” In Theorem Proving in Higher Order Logics, Springer Berlin Heidelberg, 2004, pp. 215232.
 ^ E. Seligman, I. Yarom, “Best known methods for using Cadence Conformal LEC,” at Intel.
 ^ C. Eisner, A. Nahir, K. Yorav, “Functional verification of power gated designs by compositional reasoning,” Computer Aided Verification Springer Berlin Heidelberg, pp. 433445.
 ^ P. C. Attie, H. Chockler, “Automatic verification of faulttolerant register emulations,” Electronic Notes in Theoretical Computer Science, vol. 149, no. 1, pp. 4960.
 ^ K. D. Schubert, W. Roesner, J. M. Ludden, J. Jackson, J. Buchert, V. Paruthi, B. Brock, “Functional verification of the IBM POWER7 microprocessor and POWER7 multiprocessor systems,” IBM Journal of Research and Development, vol. 55, no 3.
This article is based on material taken from the Free Online Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
Further reading
 Jean François Monin and Michael G. Hinchey, Understanding formal methods, Springer, 2003, ISBN 1852332476.
 Jonathan P. Bowen and Michael G. Hinchey, Formal Methods. In Allen B. Tucker, Jr. (ed.), Computer Science Handbook, 2nd edition, Section XI, Software Engineering,Chapter 106, pages 1061 – 10625, Chapman & Hall / CRC Press, Association for Computing Machinery, 2004.
 Michael G. Hinchey, Jonathan P. Bowen, and Emil Vassev, Formal Methods. In Philip A. Laplante (ed.), Encyclopedia of Software Engineering, Taylor & Francis, 2010, pages 308–320.
External links
 Formal Methods Europe (FME)
 Formal method keyword on Microsoft Academic Search
 Foldoc:formal methods
 Evidence on Formal Methods uses and impact on Industry Supported by the DEPLOY project (EU FP7)
