For many decades, formal methods are considered to be the way forward to help the software industry to make more reliable and trustworthy software. However, despite this strong belief and many individual success stories, no real change in industrial software development seems to be occurring. In fact, the software industry itself is moving forward rapidly, and the gap between what formal methods can achieve and the daily software-development practice does not appear to be getting smaller (and might even be growing). In the past, many recommendations have already been made on how to develop formal-methods research in order to close this gap. This paper investigates why the gap nevertheless still exists and provides its own recommendations on what can be done by the formal-methods-research community to bridge it. Our recommendations do not focus on open research questions. In fact, formal-methods tools and techniques are already of high quality and can address many non-trivial problems; we do give some technical recommendations on how tools and techniques can be made more accessible. To a greater extent, we focus on the human aspect: how to achieve impact, how to change the way of thinking of the various stakeholders about this issue, and in particular, as a research community, how to alter our behaviour, and instead of competing, collaborate to address this issue.
Nowadays, software has become an integral part of our daily lives. We can no longer imagine what life would be like if we were not continuously supported by software (and the underlying hardware, of course). As a consequence, there has been an enormous growth in the software industry worldwide, and it is expected that it will continue to increase in the coming years [34,93]. Moreover, also many other industries such as the service industry (banking, finance [47]) and the automotive industry [83] depend more and more on their software development; they are typically called software-intensive industries and face the same challenges as the software industry.
However, this enormous growth has also made it evident that the software industry is struggling to ensure the reliability of its software [33,76]. Software failures can have serious economic or societal consequences. For example, recently in Belgium, the ATMs were not usable for a full day after a software update [98], and in the Netherlands, the electronic payment system was intermittently unusable [4,79]. As a result, banks received damage claims from shop owner organisations, who claimed having a substantial income loss due to software issues. Many other similar examples are available [59,102], and estimates of the costs of software failures exceed € 250,000,000,000 annually worldwide [18,41,82]. Moreover, other scientific disciplines also depend increasingly on the reliability of software. For example, a software error recently detected in fMRI software has risked invalidating around 15 to 25 years of brain research including 3500 papers on the subject [29,30,71,72].
For decades, academic researchers have claimed that rigorous use of formal analysis tools can help to increase the quality and reliability of software [22,104]. A wide range of techniques, with corresponding tool support, have been developed [17]. These techniques differ in the guarantees they provide and in the ease of applicability. There is usually a trade-off: the stronger the guarantees provided by a technique, the more work is typically needed to obtain these guarantees. Despite this variety, all these techniques share a common foundation based on precise mathematical notations (e.g. formal program semantics and program logics), describing the program behaviour and properties [101].
Formal analysis techniques have been steadily improving over the last years due to the development of powerful automatic solvers and smart combinations of existing technologies, e.g. in SLAM/SLAM2/SDV [7,57], Astrée [26,64], or Frama-C [55]. Multiple examples illustrate that the application of formal methods on industrially-relevant examples is becoming possible. We list some interesting examples here, without striving to be exhaustive.
In the aviation industry the use of formal methods has been integrated in the development standards and accepted as a part of the (mandatory) certification procedure [80,81]. Tools such as Astrée and Frama-C were successfully employed to formally analyse portions of the code for several aircraft models including the currently largest passenger aircraft A380 [66,86,96]. Besides avionics, the Astrée verifier has been routinely applied to the docking software of a cargo space ship, in automotive control, nuclear plant technology, and ventilation [69]. Similarly, in the automotive field formal methods are also gaining increasing attention. Though not strictly enforced by the corresponding automotive standard ISO 26262, some suppliers internally design, check, or verify parts of their software using formal methods [53,70]; the degree of rigour required by the standard grows along the chain A-B-C-D, from the most relaxed Automotive Safety Integrity Level (ASIL) A to the strictest level D, while formal verification is recommended for C and D [48]. Social networks have no safetycritical software, but they also use formal methods: Facebook internally runs the INFER tool to verify selected properties, such as memory safety errors and other common bugs of their mobile apps, used by over a billion people [21]. The driving force in this case is the huge economic cost of failures. Moreover, in 2011, the AWS division of Amazon started to use TLA+ to meet the requirements stated in their contractual obligations, checking both their present designs and aggressively optimised ones [68]. Amazon believes that formal methods ‘accelerate both time-to-market and quality of [their] projects’, and since then, have expanded their efforts, recently also using OpenJML for the analysis of some of their components [25]. Moreover, formal methods have also been successfully used in quite a large number of other areas, for example, to raise the quality of operating system kernels [7,56], in compilation [60,65], in telecommunication services [39,87] to prove or refute properties of cryptography protocols [63], in railway signalling [6,31], for subway transportation [10,16], in control systems of the Ma
This content is AI-processed based on open access ArXiv data.
