NEW RESULTS AND TRENDS IN FORMAL TECHNIQUES & TOOLS FOR THE DEVELOPMENT OF SOFTWARE FOR TRANSPORTATION SYSTEMS — A REVIEW1 Dines Bjørner Computer Science and Engineering, Informatics and Mathematical Modelling Technical University of Denmark, DK–2800 Kgs.Lyngby, Denmark E–Mail: [email protected], URL: www.imm.dtu.dk/˜db Abstract: We characterise what is meant by a metod in the context of software devel- opment. Then what is meant by a formal technique. We refute the possibility of formal methods, but express the desirability of formal techniques. Some such techniques are briefly surveyed. We will outline what has been done recently and what is currently being done using formal techniques in the area predominantly of railway systems. Problems are out- lined, as are avenues for future research. Being an invited survey, the paper features an extensive, albeit far from complete, literature reference list of almost 180 entries, taking up half the paper size ! There are no examples of formal techniques being actually shown in this paper — but there should be at least three papers (Pˇeniˇcka et al., 2003; Strupchanska et al., 2003; Haxthausen and Peleska, 2003b) in these proceedings which illustrate such techniques as are the subject of the current review. Keywords: Formal Method, Domain Description, Requirements Prescription, Software Design, Provable Correctness, Safety Criticality, Real–time, Embedded Systems, Interlock- ing 1. INTRODUCTION 1.2 Sub–System Interfaces Transportation systems pose extraordinary challenge when it comes to their monitor- Thus the challenge is compounded by the ing and control by combinations of classical possibility, when using computers, of com- automatic control systems and digital com- bining many diverse “sub-systems”, sub– puters. systems that, in the days of only combina- tions of classical automatic control system and human monitoring and control, were quite “separate”: Where information from one sub–system was basically only handed 1.1 Infra–Structure on to another sub–system via human inter- vention. Such human intervention often en- This is in particular the case for rail and air tailed data vetting: Is the information to be systems due to their hard real–time charac- passed–on relevant and valid ? teristics combined with the need for very high dependability. In these kinds of infra- With automated interfaces, even within –structure systems we see a need to inte- purely digital computer, ie., software, grate many diverse management planning, controlled sub–systems, the problem of and operational execution, monitoring and “switching domains” is staggering, but en- control facets. ticing. 1The writing of this paper, as well as the papers (Pˇeniˇcka et al., 2003; Pˇeniˇcka et al., 2003), also contained in these proceedings, and their presentation at Budapest, is sponsored by the EU IST Research Training Network AMORE: Algorithmic Models for Optimising Railways in Europe: www.inf.uni-konstanz.de/algo/amore/. Contract no. HPRN-CT-1999-00104, Proposal no. RTN1-1999-00446 1.3 Hybrid Systems what to choose. Such principles can not be automated. Problems under investiga- Perhaps, from a scientific and engineering tion are usually too complex and “never point of view, the most obviously interest- the same”. So the choice has to be done ing area of study is that of hybrid systems: by the developers. Hence cannot be for- These are not just combinations of contin- malised. Unfortunately the term ‘Formal uous and discrete systems, but are such in Method’ has stuck. which there is not just one, but several con- trollers — to use a standard terminology in automatic control theory. The software 2.3 Desirability of Formal Tech- controls the decisions when to exchange one niques & Tools controller for another. Such hybrid systems have been studied at UNU/IIST, the UN But many techniques can be formalised, University’s Intl. Inst. for Software Tech- and tools can be provided for the support of nology, Macau, nr. Hong Kong: (Wang such formal techniques. These techniques et al., 1994; Chen et al., 1994b; Chen et al., apply to oftentimes very large scale engi- 1994a; Yu, 1994a; Hung and Wang, 1994; neering documents, formally specified, and Widjaja et al., 1994; Wang and He, 1995; far too large to be analysed by humans. It is Zhou et al., 1995). An interesting concept therefore desirable to use such formal tech- in this connection is ‘Hybrid Automata’ niques and tools — since they may help en- (Henzinger, 1996). Hybrid automata com- sure, amongst others, correctness of soft- bine discrete transition graphs with contin- ware with respect to likewise formally pre- uous dynamical systems. They are mathe- scribed requirements. matical models for digital systems that in- teract with analog environments. Hybrid automata can be viewed as infinite-state 2.4 Examples of Techniques & Tools transition systems, and this view gives in- sights into the structure of hybrid state We take specification languages, and cor- spaces. rectness (of software or hardware) veri- fiers and model checkers to be tools. By techniques we then mean the specific way 1.4 Structure of paper in which the developer performs ‘calcula- The topic of this invited paper was sug- tions’ (ie., development steps), including gested by the Programme Chair. In effect applying these tools. Verifiers are soft- they chose the title ! It therefore behooves ware packages that either assist the devel- me to explain some of the terms of the title oper in conducting proofs of correctness or such as they are understood in computing which perform such proofs more or less au- science and software engineering. We there- tomatically. Model checkers are also soft- fore first explain — to an audience usu- ware packages which symbolically — al- ally associated with the field of automatic most “exhaustively” — tests the software control — what is meant by a method, its (hardware), while subject to usual com- principles and techniques; when such tech- puter interpretation, enters only desirable niques can be based on mathematics, and states. Certain kinds of compilers from do- in particular on discrete mathematics, in- main specific language scripts are tools that cluding notably mathematical logic. transform specifications into semantically consistent executable systems. 2. ON TECHNIQUES & TOOLS 2.5 Why Formal Techniques ? 2.1 What is a Method ? There are several, and in the mind of the By a (software development) method we current author, fully equivalent, good rea- shall understand a set of principles for se- sons for why one should apply formal cal- lecting a number of techniques and tools for culi (ie., techniques) in the pursuit of com- the study and solution of problems — in puting systems development: Usually one the form of the construction of an artifact is mentioned as being the most important (here: Software). one: Correctness of software — with re- spect to requirements (ie., that “the soft- 2.2 Impossibility of Formal Meth- ware is right”). To this we add that “it ods ! is the right software”, ie., that it affine to users expectations. Finally: “it is fun, it The method principles amount to criteria is professionally satisfying” to use formal for selection and application: When and techniques. 2.6 Convincing the Skeptics and developed at the IBM Vienna (Austria) Laboratory in the early 1970s and can be The subject of so–called Formal Methods, said to be have offered first comprehensive is, strangely, to the curent author — who formal techniques for general software de- is one of the “pioneers” of the field (within velopment. VDM-SL is now an ISO standard software) — still somewhat “controversial”. (Larsen et al., 1996). So a number of popularising papers have VDM basically offers model oriented, ie., been and are being offered: (Wood, 1990; discrete mathematics means of specifying Wing, 1990; Thomas, 1992; Bowen and and reasoning about software. Major texts Stavridou, 1992; Bowen and Stavridou, are (Bjørner and Jones, 1978; Bjørner and 1993; Bowen, 1993; Rushby, 1993; Bowen Jones, 1982; Fitzgerald and Larsen, 1997). and Hinchey, 1994; Butler et al., 1995; Cle- The autor of this paper was one of the land and MacKenzie, 1995; Hinchey and co–designers of VDM. Bowen, 1995; Kelly, 1995; Liu et al., 1995; Rushby, 1995; Caldwell, 1996; Kelly, 1996). These papers explain why developers 3.3 CSP might very well wish to use formal methods CSP stands for ‘Communicating Sequential in the development of software. (Rushby, Processes’. Put forward by Tony Hoare in 1993; Kelly, 1995; Rushby, 1995; Kelly, 1978 (Hoare, 1978) CSP has become one 1996) explain very well NASAs position on of the leading means for specifying, suc- the need for formal verification of safety cinctly and elegantly, the interaction be- critical on–board software. tween parallel processes. Leading books (Bowen and Hinchey, 1995b; Bowen on CSP are: (Hoare, 1985; Roscoe, 1997; and Hinchey, 1995a; Hall, 1990) provides Schneider, 2000) (entertaining) capsule advice to “skeptics”. 3.4 Z 3. SOME TECHNIQUES & TOOLS Z derives from the Z in Zermelo, who, as In this section we overview, ever so briefly, a mathematician, together with Frankel, some of the formal techniques that have established the Zermelo–Frankel axiomatic shown effectiveness in solving problems — basis for a set theory. also in the domain of railway operations Proposed around 1980 by Jean– and management. Raymond Abrial, Z has become one of the The possible distinction between a leading model oriented, ie., discrete math- method, like ASM, B, RAISE or VDM, a speci- ematics means of specifying and reasoning fication language, like CSP, RSL, VDM-SL or about software. The Z literature is abun- Z, or a technique cum tool, like SPIN — for dant, but we refer only to the delightful all of these see below — has here been de- text book: (Woodcock and Davies, 1996). liberately blurred. The next section will then comment on 3.5 Statecharts specific uses of these formal techniques.