- Email: [email protected]
Complex systems proved and improved
MKXOFiOCESWlS
AND
MICROSYSTEMS ELSEVIER
Microprocessors
and Microsystems
20 (1997)
495-499
Complex systems proved and improved Graeme Parkin National
Physical
Laboratory,
Information
Systems
Engineering,
Building
10, Queens Road,
Teddington,
Middlesex,
TWl I OL W, UK
Abstract Formal methods, the application of mathematics to the development of systems, have been promoted as bringing dramatic improvements to the quality of developed products. In practice it has been found that, although systems can be described in mathematics, going on to prove properties is too difficult and expensive. Prover technology overcomes the problems of proof, by modelling systems in propositional logic using a unique patented algorithm to do automatic proofs quickly. This technique works because the algorithm is able to exploit the fact that people design systems which they can understand and do not require hard proofs. Prover technology is briefly described showing what it can do and how it does it. Descriptions of how it is being used in the avionics and railway industries will be given. Keywords:
Formal
Methods;
Formal
Verification;
Propositional
logic;
Railways;
Avionics
-
1. Introduction Extensive testing failed to find a bug in the satellite Clementine launched in the spring of 1994 by the USA’s Department
of Defense
and National
Aeronautics
and
Space Administration. The bug resulted in the satellite spinning wildly and missing its rendezvous with the asteroid Geographos. This example is one of many failures over the last decade that have highlighted the need for more scientific and efficient methods for the system development process.It is not credible in today’s environment to develop critical systemsbased on “trial and error” programming and saturation testing. Formal methods are the application of mathematics to systemsdevelopment. They allow the user to construct a mathematical model, a specification written in a mathematical notation, of the system to be developed. The mathematical model can then be used to develop the system rigorously and prove that the system has certain properties. The most generally accepted benefit of producing a mathematical model of a system is the early removal of errors, which would be much more costly to remove at the later stagesof the system development lifecycle [l]. The ability to do proofs is potentially a very big step forward as it allows the requirements of a system to be 0141-9331/97/$17.00 0 PZI s0141-9331(97)01115-5
1997 Published
by Elsevier
Science
B.V.
completely checked. This is as compared to testing or simulation which can never for any reasonable sized system be complete. For example a system with n inputs, with each input having two values, requires 2” tests which is not practical for any reasonable size of n. Proof would show properties of such a system for any value of n. It should be noted that proofs do not remove all the need for testing. For example you have proved that your implementation is functionally equivalent to your original mathematical model but are not using a provably correct compiler which could then introduce errors. What proof does do is narrow down areas where errors are most likely to be introduced. A survey [2] on the use of formal methods in industry found that, though it is accepted that systems can be described in mathematics, when proofs of properties are needed they are too difficult and expensive. The main reasons for this are that proofs require highly trained personnel, are labour intensive and there is lack of good tool support. In practice the take up of formal methods has been limited to safety-critical and security systems.
The following sections will describe briefly a mathematical modelling technique and proof algorithm which overcome the current problems with applying proofs. It will be explained where this mathematical modelling technique can be used and how it is being currently
496
G. Parkinlhficroprocessors
used. A simple example will be given to demonstrate use.
2. Automatic
and Microsystems
20 (1997)
495-499
its
‘iI’yJ-J;ht
proof?
Ideally you would like a tool which, given a mathematical model of a system, would automatically prove whether a requirement of that system is true (theorem) or produce a counter example. This cannot be done for mathematics in general (Goedel’s proof). The answer is to restrict the mathematics used to that which allows automatic proof. Propositional logic which consists of Boolean variables with connectives like AND (&), OR (#) or NOT (-) gives automatic proof. Unfortunately although you can determine whether a propositional formula is a theorem or not it is known to be very difficult to compute this quickly in the general case (in complexity theory terms it is known as a co-NP complete problem). However for a wide range of industrial systems a unique patented algorithm [3] has been developed which overcomes this problem on proofs, this will be called Stalmarck’s algorithm (after the inventor). The speed of Stilmarck’s algorithm depends on what is called the degree of hardness, which is the least number of simultaneous assumptions that are required to prove a theorem in propositional logic. So you can have a propositional formula with low degree of hardness, say 0 or 1, with over 1000 000 variables which can be proved very quickly. As will be shown later in the examples of the industrial use of Stalmarck’s algorithm people design systems with low degree of hardness (up to 2 hardness). A possible reason for this is that the designers need to understand what a system does. In fact it would be a useful criteria for some developed systems that they have a low degree of hardness e.g. safety critical systems.
3. Simple example
To illustrate how you might use propositional logic we will show a trivial example. This example will use a tool called Prover’ which implements Stblmarck’s algorithm. We shall take the simple electrical circuit shown in Fig. 1 and analyse it for sneak paths. To analyse this we need to represent the logic of this circuit in propositional logic. This we do by representing each item in the circuit by a Boolean variable: Battery, Ignition, Brake, Switch,Radio and Indicator-light. SotheBattery is on when the Boolean variable Battery is true ’ Prover is technically supported and marketed in the United Kingdom by the National Physical Laboratory, Queens Road, Teddington, Middlesex, TWll OLW for Formal Methods Sweden AB, Swedenborgsgatan 2, S-I 18 48, Stockholm, Sweden.
Fig. I, Simple
electrical
car circuit
(with
a sneak path).
and off when it is false. The mathematical model of this circuit represents all possible paths from the items Battery, Ignition, Brake and Switch to Radio and Indicator light. This can be input to the Prover tool either through a graphical user interface see Fig. 2, or with text input see Fig. 3, or the input could be done automatically via some other formal representation of the circuit e.g. system graph see Figs. 4 and 5. The requirement of this circuit you would like to show would be: (Radio-(Battery
& Ignition))
that is the Radio is on only if the Battery and Ignition are on. The Prover tool will attempt to prove this requirement based on the mathematical model constructed. In this case it would say it is not possible to prove and come up with the sneak circuit, that is the one via the Switch and the Brake. The ability to do automatic proof has another advantage: you do not mind doing it. The three different ways shown of modelling the electrical circuit were proved to be identical, see Fig. 6 for one way of doing this with Prover.
4. Modelling
The electrical circuit although very simple illustrates how you go about using propositional logic with Stllmarck’s algorithm: 1. develop way of modelling your system in propositional logic; 2. build translator from a design language used to describe a system into propositional logic; 3. write down your requirements in propositional logic; 4. prove these with respect to the constructed mathematical model produced by the translator. Translators are important because mathematical models in propositional logic will in general be very large as its not a very expressive language. Propositional logic has been used to model: switch and relay systems [4, 31; sequential software (loop free) [4, 31; and a hardware.
l l
G. ParkinlMicroprocessors
and Microsystems
20 (1997)
491
495-499
Battery
Ignition
Brake
Indtcator-light Switch Fig. 2. Simple electrical car circuit in Prover (GUI). #signature #boolean-inpin #boolean-inpin #boolean-inpin #boolean-inpin
“0.0.
#boolean-definition #boolean-definition #boolean-definition #boolean-definition #boolean-outpin #boolean-outpin
alpha. Battery; Ignition; Brake; Switch;
0” code
import
Ignition-on (Battery & Ignition) ; Switch-on (Battery & Switch) ; Brake-and-Switch-on (Switch-on k Brake); Brake-and-Ignition-on (Ignition-on & Brake); Radio (Ignition-on Indicator-light
# Brake-and-Switch-on); (Switch-on It Brake-and-Ignition-on);
Fig. 3. Simple electrical car circuit in Prover (Import Syntax).
More recent work has shown that it is feasible to model Programmable Logic Controller programs [5] and to generate fault trees from a propositional logic model [6]. 5. Industrial
examples
5.1. Railways ABB Signal in Sweden produce computer systems to control railway yards (interlocking systems). Such systems have to be safe. ABB Signal uses a declarative language called STERNOL for writing the interlocking
programs. These STERNOL programs have to have certain properties which correspond to safety properties in the railway yard. Before StAlmarck’s algorithm was applied they had no automatic way for checking for these properties. The resulting failures caused railway yards to shutdown safely but for no good reason. A customized tool was built around StQlmarck’s algorithm that translated the STERNOL programmes into propositional logic and then the properties were proved, if no proof was found a counter example was shown in terms of the original STERNOL programmes. This customized tool has been built into ABB Signal system development process and used since 199 1. This technique has resulted in the time spent on verification being reduced by greater #NAME; Car-circuit; #BATTERIES; Battery; #CONSUMERS; Radio, Indicator-light; #INPUTS ; Ignition, Brake, Svitch; #UNDIRECTED; Battery Ignition Radio ; Battery Switch Indicator-light; Radio Brake Indicator-light;
Fig. 4. Simple electrical car circuit in System Graph.
Fig. 5. Simple electrical car circuit in Prover (System Graph).
498
G. Parkin/Microprocessors
and Microsystems
20 (1997)
495-499
Car-Clrcuii-Diagram
lgnltlon
Brake
Switch
Fig. 6. Comparing electrical car circuits in Prover (Prover can be rm~ in a mode to look for a model to satisfy the above, in this caseit produces a contradiction, that is no model).
than 90%, overall time spent on development reduced by greater than 20% and increased quality of the delivered systems (no failures!). Note in particular that the engineers do not have to understand how to model their systems in propositional logic since they continue to program in STERNOL. Further work has been done to improve the system development process by being able to show that two STERNOL programmes are equivalent. This can also be used to show that STERNOL compilers produce the same results by reverse compiling the object code. 5.2. Avionics Saab Military Aircraft have used Stllmarck’s algorithm for some time and are currently implementing it into their system development process. A particular system they have analysed using propositional logic was the landing gear control logic of the multi-role aircraft Gripen. This control system consists of both software and hardware. Both the software and hardware were modelled as separate systems and then merged into one system model (this was done using a graphical user interface to propositional logic). The initial system model was first considered to consist of fault free components. A safety property that was explored was whether the emergency extracting sequence occurs if and only if the control sequence initiates it. Was
it possible that the emergency extracting sequence could occur in any unpredictable, unwanted situation? In propositional logic we have: Emergency-extract-signal -Emergency-extract-order
Having done this the system model was enhanced with possible component faults and the safety properties could then be rechecked to see when they would fail with a single fault, two faults, etc. This approach has enabled systematic fault analysis. Saab Military Aircraft will be using this technology as part of their system development from 1995.
6. Conclusion The ability of Sdlmarck’s algorithm to automatically prove properties of industrial systems makes it unique. It is now in use on some significant industrial scale problems. It is believed it has the potential to be used on a wide range of other similar type problems.
References [l] A. Hall, Seven myths of formal methods. IEEE Software, September (1990).
G. ParkinlMicroprocessors
and Microsystems
[2] S. Austin and G.I. Parkin, Formal Methods: A Survey. National Physical Laboratory, March 1993. [3] G. Stllmarck and M. Siflund, Modelling and verifying systemsand software in propositional logic. IFAC SAFECOMP’90, London, UK, 1990. [4] G. StHlmarck and 0. Akerlund, Forma1 verification of hardware and software systems using NP-circuit. In Y. Malmtn and V. Rouhiainen (eds.) Reliability and Safety of Processes
20 (1997)
495-499
499
and Manufacturing Systems, Elsevier Applied Science, Oxford, 1991. [S] A. Borllv and H. Agren, Formal verification of programmable logic control. Technical report, Logikkonsult NP AB, Swedenborgsgatan 2, S-1 18 28, Stockholm, Sweden, 1995. Draft. [6] J.A. Mertens, Integrating Formal Verification and Reliability Analysis. Technical report, Logikkonsult NP AB, Swedenborgsgatan 2, S-l 18 28, Stockholm, Sweden, 1995.
AND
MICROSYSTEMS ELSEVIER
Microprocessors
and Microsystems
20 (1997)
495-499
Complex systems proved and improved Graeme Parkin National
Physical
Laboratory,
Information
Systems
Engineering,
Building
10, Queens Road,
Teddington,
Middlesex,
TWl I OL W, UK
Abstract Formal methods, the application of mathematics to the development of systems, have been promoted as bringing dramatic improvements to the quality of developed products. In practice it has been found that, although systems can be described in mathematics, going on to prove properties is too difficult and expensive. Prover technology overcomes the problems of proof, by modelling systems in propositional logic using a unique patented algorithm to do automatic proofs quickly. This technique works because the algorithm is able to exploit the fact that people design systems which they can understand and do not require hard proofs. Prover technology is briefly described showing what it can do and how it does it. Descriptions of how it is being used in the avionics and railway industries will be given. Keywords:
Formal
Methods;
Formal
Verification;
Propositional
logic;
Railways;
Avionics
-
1. Introduction Extensive testing failed to find a bug in the satellite Clementine launched in the spring of 1994 by the USA’s Department
of Defense
and National
Aeronautics
and
Space Administration. The bug resulted in the satellite spinning wildly and missing its rendezvous with the asteroid Geographos. This example is one of many failures over the last decade that have highlighted the need for more scientific and efficient methods for the system development process.It is not credible in today’s environment to develop critical systemsbased on “trial and error” programming and saturation testing. Formal methods are the application of mathematics to systemsdevelopment. They allow the user to construct a mathematical model, a specification written in a mathematical notation, of the system to be developed. The mathematical model can then be used to develop the system rigorously and prove that the system has certain properties. The most generally accepted benefit of producing a mathematical model of a system is the early removal of errors, which would be much more costly to remove at the later stagesof the system development lifecycle [l]. The ability to do proofs is potentially a very big step forward as it allows the requirements of a system to be 0141-9331/97/$17.00 0 PZI s0141-9331(97)01115-5
1997 Published
by Elsevier
Science
B.V.
completely checked. This is as compared to testing or simulation which can never for any reasonable sized system be complete. For example a system with n inputs, with each input having two values, requires 2” tests which is not practical for any reasonable size of n. Proof would show properties of such a system for any value of n. It should be noted that proofs do not remove all the need for testing. For example you have proved that your implementation is functionally equivalent to your original mathematical model but are not using a provably correct compiler which could then introduce errors. What proof does do is narrow down areas where errors are most likely to be introduced. A survey [2] on the use of formal methods in industry found that, though it is accepted that systems can be described in mathematics, when proofs of properties are needed they are too difficult and expensive. The main reasons for this are that proofs require highly trained personnel, are labour intensive and there is lack of good tool support. In practice the take up of formal methods has been limited to safety-critical and security systems.
The following sections will describe briefly a mathematical modelling technique and proof algorithm which overcome the current problems with applying proofs. It will be explained where this mathematical modelling technique can be used and how it is being currently
496
G. Parkinlhficroprocessors
used. A simple example will be given to demonstrate use.
2. Automatic
and Microsystems
20 (1997)
495-499
its
‘iI’yJ-J;ht
proof?
Ideally you would like a tool which, given a mathematical model of a system, would automatically prove whether a requirement of that system is true (theorem) or produce a counter example. This cannot be done for mathematics in general (Goedel’s proof). The answer is to restrict the mathematics used to that which allows automatic proof. Propositional logic which consists of Boolean variables with connectives like AND (&), OR (#) or NOT (-) gives automatic proof. Unfortunately although you can determine whether a propositional formula is a theorem or not it is known to be very difficult to compute this quickly in the general case (in complexity theory terms it is known as a co-NP complete problem). However for a wide range of industrial systems a unique patented algorithm [3] has been developed which overcomes this problem on proofs, this will be called Stalmarck’s algorithm (after the inventor). The speed of Stilmarck’s algorithm depends on what is called the degree of hardness, which is the least number of simultaneous assumptions that are required to prove a theorem in propositional logic. So you can have a propositional formula with low degree of hardness, say 0 or 1, with over 1000 000 variables which can be proved very quickly. As will be shown later in the examples of the industrial use of Stalmarck’s algorithm people design systems with low degree of hardness (up to 2 hardness). A possible reason for this is that the designers need to understand what a system does. In fact it would be a useful criteria for some developed systems that they have a low degree of hardness e.g. safety critical systems.
3. Simple example
To illustrate how you might use propositional logic we will show a trivial example. This example will use a tool called Prover’ which implements Stblmarck’s algorithm. We shall take the simple electrical circuit shown in Fig. 1 and analyse it for sneak paths. To analyse this we need to represent the logic of this circuit in propositional logic. This we do by representing each item in the circuit by a Boolean variable: Battery, Ignition, Brake, Switch,Radio and Indicator-light. SotheBattery is on when the Boolean variable Battery is true ’ Prover is technically supported and marketed in the United Kingdom by the National Physical Laboratory, Queens Road, Teddington, Middlesex, TWll OLW for Formal Methods Sweden AB, Swedenborgsgatan 2, S-I 18 48, Stockholm, Sweden.
Fig. I, Simple
electrical
car circuit
(with
a sneak path).
and off when it is false. The mathematical model of this circuit represents all possible paths from the items Battery, Ignition, Brake and Switch to Radio and Indicator light. This can be input to the Prover tool either through a graphical user interface see Fig. 2, or with text input see Fig. 3, or the input could be done automatically via some other formal representation of the circuit e.g. system graph see Figs. 4 and 5. The requirement of this circuit you would like to show would be: (Radio-(Battery
& Ignition))
that is the Radio is on only if the Battery and Ignition are on. The Prover tool will attempt to prove this requirement based on the mathematical model constructed. In this case it would say it is not possible to prove and come up with the sneak circuit, that is the one via the Switch and the Brake. The ability to do automatic proof has another advantage: you do not mind doing it. The three different ways shown of modelling the electrical circuit were proved to be identical, see Fig. 6 for one way of doing this with Prover.
4. Modelling
The electrical circuit although very simple illustrates how you go about using propositional logic with Stllmarck’s algorithm: 1. develop way of modelling your system in propositional logic; 2. build translator from a design language used to describe a system into propositional logic; 3. write down your requirements in propositional logic; 4. prove these with respect to the constructed mathematical model produced by the translator. Translators are important because mathematical models in propositional logic will in general be very large as its not a very expressive language. Propositional logic has been used to model: switch and relay systems [4, 31; sequential software (loop free) [4, 31; and a hardware.
l l
G. ParkinlMicroprocessors
and Microsystems
20 (1997)
491
495-499
Battery
Ignition
Brake
Indtcator-light Switch Fig. 2. Simple electrical car circuit in Prover (GUI). #signature #boolean-inpin #boolean-inpin #boolean-inpin #boolean-inpin
“0.0.
#boolean-definition #boolean-definition #boolean-definition #boolean-definition #boolean-outpin #boolean-outpin
alpha. Battery; Ignition; Brake; Switch;
0” code
import
Ignition-on (Battery & Ignition) ; Switch-on (Battery & Switch) ; Brake-and-Switch-on (Switch-on k Brake); Brake-and-Ignition-on (Ignition-on & Brake); Radio (Ignition-on Indicator-light
# Brake-and-Switch-on); (Switch-on It Brake-and-Ignition-on);
Fig. 3. Simple electrical car circuit in Prover (Import Syntax).
More recent work has shown that it is feasible to model Programmable Logic Controller programs [5] and to generate fault trees from a propositional logic model [6]. 5. Industrial
examples
5.1. Railways ABB Signal in Sweden produce computer systems to control railway yards (interlocking systems). Such systems have to be safe. ABB Signal uses a declarative language called STERNOL for writing the interlocking
programs. These STERNOL programs have to have certain properties which correspond to safety properties in the railway yard. Before StAlmarck’s algorithm was applied they had no automatic way for checking for these properties. The resulting failures caused railway yards to shutdown safely but for no good reason. A customized tool was built around StQlmarck’s algorithm that translated the STERNOL programmes into propositional logic and then the properties were proved, if no proof was found a counter example was shown in terms of the original STERNOL programmes. This customized tool has been built into ABB Signal system development process and used since 199 1. This technique has resulted in the time spent on verification being reduced by greater #NAME; Car-circuit; #BATTERIES; Battery; #CONSUMERS; Radio, Indicator-light; #INPUTS ; Ignition, Brake, Svitch; #UNDIRECTED; Battery Ignition Radio ; Battery Switch Indicator-light; Radio Brake Indicator-light;
Fig. 4. Simple electrical car circuit in System Graph.
Fig. 5. Simple electrical car circuit in Prover (System Graph).
498
G. Parkin/Microprocessors
and Microsystems
20 (1997)
495-499
Car-Clrcuii-Diagram
lgnltlon
Brake
Switch
Fig. 6. Comparing electrical car circuits in Prover (Prover can be rm~ in a mode to look for a model to satisfy the above, in this caseit produces a contradiction, that is no model).
than 90%, overall time spent on development reduced by greater than 20% and increased quality of the delivered systems (no failures!). Note in particular that the engineers do not have to understand how to model their systems in propositional logic since they continue to program in STERNOL. Further work has been done to improve the system development process by being able to show that two STERNOL programmes are equivalent. This can also be used to show that STERNOL compilers produce the same results by reverse compiling the object code. 5.2. Avionics Saab Military Aircraft have used Stllmarck’s algorithm for some time and are currently implementing it into their system development process. A particular system they have analysed using propositional logic was the landing gear control logic of the multi-role aircraft Gripen. This control system consists of both software and hardware. Both the software and hardware were modelled as separate systems and then merged into one system model (this was done using a graphical user interface to propositional logic). The initial system model was first considered to consist of fault free components. A safety property that was explored was whether the emergency extracting sequence occurs if and only if the control sequence initiates it. Was
it possible that the emergency extracting sequence could occur in any unpredictable, unwanted situation? In propositional logic we have: Emergency-extract-signal -Emergency-extract-order
Having done this the system model was enhanced with possible component faults and the safety properties could then be rechecked to see when they would fail with a single fault, two faults, etc. This approach has enabled systematic fault analysis. Saab Military Aircraft will be using this technology as part of their system development from 1995.
6. Conclusion The ability of Sdlmarck’s algorithm to automatically prove properties of industrial systems makes it unique. It is now in use on some significant industrial scale problems. It is believed it has the potential to be used on a wide range of other similar type problems.
References [l] A. Hall, Seven myths of formal methods. IEEE Software, September (1990).
G. ParkinlMicroprocessors
and Microsystems
[2] S. Austin and G.I. Parkin, Formal Methods: A Survey. National Physical Laboratory, March 1993. [3] G. Stllmarck and M. Siflund, Modelling and verifying systemsand software in propositional logic. IFAC SAFECOMP’90, London, UK, 1990. [4] G. StHlmarck and 0. Akerlund, Forma1 verification of hardware and software systems using NP-circuit. In Y. Malmtn and V. Rouhiainen (eds.) Reliability and Safety of Processes
20 (1997)
495-499
499
and Manufacturing Systems, Elsevier Applied Science, Oxford, 1991. [S] A. Borllv and H. Agren, Formal verification of programmable logic control. Technical report, Logikkonsult NP AB, Swedenborgsgatan 2, S-1 18 28, Stockholm, Sweden, 1995. Draft. [6] J.A. Mertens, Integrating Formal Verification and Reliability Analysis. Technical report, Logikkonsult NP AB, Swedenborgsgatan 2, S-l 18 28, Stockholm, Sweden, 1995.