A Method Providing Identity Privacy to Mobile Users During Authentication ? Didier Samfat Refik Molva EURECOM Institute 2229 Route des Cr ^ etes BP 193 - Sophia Antipolis - France fsamfat , molvag@eurecom.fr August 12 , 1994 Abstract The increasing development of mobile networks raises new security requirements and concerns . In addition to the basic need of authentication , confidentiality and key distribution services , a new problem involving privacy is the unauthorized tracking of users ' migration . In other words , accessing any information related to the mobile user 's location data without his consent , is a serious violation of his privacy . Moreover , if no care is taken , the disclosure of the mobile user real identity may appear during the authentication process . The basic solution to this problem is the use of aliases which insure nontraceability by hiding the user 's real identity and also his relationship with domain authorities . In this paper we provide a classification of the different degrees of non-traceability and present a new efficient method for the computation of aliases . This technique can be used during authentication of mobile users and thus avoids the drawbacks of existing solutions such as GSM and CDPD . 1 Introduction The advent of mobile networks has prompted new security requirements in contrast to the traditional fixed networks . In addition to protect the mobile network from eavesdropping and illegal access , a new problem involving mobility is the privacy of the user 's identity . In fact , a typical situation arises when a mobile user registered in one domain -LRB- home domain -RRB- appears in a different foreign domain ; in order to obtain services in the visited domain , the user must be authenticated and his \ solvency '' must be confirmed to the visiting domain by his home authority . Usually , during this process the user has to provide a non-ambiguous identity to his home domain and has to prove it . If no care is taken , this identity can be tapped by an eavesdropper -LRB- on the air interface in a cellular environment or through the signalling protocols exchanged on the wired network registered -RRB- and thus give additional information to an unauthorized party . This paper is organized as follows . We begin in section 2 by summarizing the drawbacks of existing solutions . In Section 3 we make a classification of different level of identity privacy which potential solutions should take into account . Section 4 presents a method for protecting identification which can be used during authentication of mobile users . Section 5 concludes with a summary of the paper . 2 Review of Existing Approaches Providing anonymity to users is not a new feature . Some mechanisms exist for banking environments -LSB- 9 , 10 -RSB- . The main problem with this approach , is even if the payment is untraceable , the identity of the customer is revealed during authentication . However , another mecanism allows the computation of untraceable credentials but the pseudonyms are known to a single `` clearinghouse '' . The Global System for Mobile -LRB- GSM -RRB- -LSB- 1 -RSB- is the first digital cellular network to provide anonymity to his subscribers . In GSM , non-traceability is provided by using a Temporary Mobile Subscriber Identifier ? A pattent application has been submitted for the work described herein . All rights reserved to Eurecom Institute . -LRB- TMSI -RRB- . But the main concern with GSM is when a user first switches on his portable phone his International Mobile Subscriber Identifier -LRB- IMSI -RRB- is transmited in clear through the radio path -LRB- the TMSI is allocated only after this step -RRB- . In the Cellular Digital Packet Data -LRB- CDPD -RRB- -LSB- 7 -RSB- , before the authentication procedure takes place , the mobile unit engages a Diffie-Hellman key exchange protocol with the visited authority in order to obtain a shared-secret key . Next , the mobile unit 's identity is enciphered with this key . The drawback of this approach remains the nature of the Diffie-Hellman protocol which allows an intruder to masquerade as the visiting authority and to discover the mobile unit real identity . Even if these approaches are reasonable in their context , the same can not be guaranteed if perfect privacy is required . In fact what is needed , is a single efficient mechanism allowing a user to access the service of the mobile network while keeping his identity secret as well as the access control mechanism from unauthorized -LRB- and authorized -RRB- parties . Such mechanisms should take into account different degrees of privacy as described in the next section . 3 Classification of Untraceability Requirements Hiding the user 's identity is not always sufficient to fulfill the non-traceability requirement . An additional requirement is to hide various relationships between the user and the administrative authorities . Therefore , we have defined five classes of user 's identity privacy depending on the expected level of security . 1 . C1 : Hiding User Identity from Eavesdroppers . Most of the existing solutions address this requirement . However , the basic requirement is that analysis of successive aliases should not lead to the disclosure of the real user 's identity . 2 . C2 : Hiding User Identity from Foreign Authorities . There is no need for a foreign authority to know the real identity of the user . What it needs is only a proof of the solvecy of the entity accessing the service and enough information to bill the user 's home authority . 3 . C3 : Hiding Relationship Between the User and Authorities . In a higher level of privacy , it is important to protect the existing relationship between the mobile user and his home authority from an unauthorized third-party . 4 . C4 : Hiding the Identity of the Home Authority from Foreign Authorities . When the mobile user needs to be authenticated in a visited domain , the foreign authority needs to contact the user 's home authority in order to have a confirmation of the good standing of the user . Therefore , even if the real identity of the user is hidden , his relationship with his home is known by the foreign authority . 5 . C5 : Hiding User Behaviour from Home Authority . In some cases it might be important for a mobile user to hide his migration from his home authority . This requirement is specially important if perfect secrecy of user behaviour should be guaranteed by the system , that is , if no one other than the user should know about the user 's location . 4 Authentication and Untraceability In this section we present an authentication protocol for mobile users which protects the different identities of the involved parties . We assume that a user has one home which is the administrative domain where he is registered on a long-term basis . When accessing the network in the home domain , the mobile user is authenticated with a traditional server-based authentication mechanism such as Kerberos -LSB- 2 -RSB- or KryptoKnight -LSB- 3 -RSB- . Users of every network domain are registered with that domain 's Authentication Server -LRB- AS -RRB- . The AS of a domain can be replicated or partitioned within the domain but the set of all partitioned and duplicated ASs represent a single domain-level authority . Moreover , the user has a personal device which can store information , and a universal identification -LRB- for example home user identification -RRB- to which only the home domain can linked the different aliases . A B EKab -LRB- A LEKab -LRB- TaLEKab -LRB- Na -RRB- -RRB- -RRB- ; Na ; Ta > Figure 1 : One-Way Authentication Protocol 4.1 Authentication Protocol Building Blocks We base our design on the one-way authentication protocol -LRB- see figure 1 -RRB- borrowed from KryptoKnight an authentication and key distribution service developed at IBM Research -LSB- 3 -RSB- . The expression in figure 1 is computed as a result of applying a strong encryption function E , e.g. , DES -LSB- 6 -RSB- , with Kab as the encryption key , over three inputs : one nonce -LRB- Na -RRB- , a timestamp -LRB- Ta -RRB- and the name of the message originator . In the rest of the paper AUTHab will denote the one-way authentication of an initiator A to a responder B. 4.2 Alias Computation KryptoKnight does not provide identity privacy as the initiator A sends his identity in clear to the responder B. Therefore , if we want to protect an identity A from an unauthorized party , we need to compute an alias which the responder B can understand . The basic idea of this solution relies on the fact that using shared-secret keys always requires an identity to be provided in contrast to public-key where the identity is implicit . Therefore , an alias for the principal A can be computed as follow : Pb -LRB- Na ; Na LA -RRB- Pb -LRB- -RRB- denotes the result of the encryption with the responder 's public-key over two inputs : one nonce and the identity of the initiator . L represents the exclusive-or operation . Upon receiving the alias , B deciphers Na then Na LA with his secret-key Sb then obtains A by doing Na LNaLA . The advantages of this alias computation are the following : ffl One-time-use alias . Long-term use of a single static alias is not a good solution , as it may be cracked or correlated to yield the user 's real identity . This solution provides different aliases at each security process . ffl No direct relationship between aliases . Each alias is computed using a nonce and it is therefore impossible to make a correlation between aliases as they are only random numbers . ffl Domain separation . Assuming the conspiracy of all visited domains -LRB- except the home domain -RRB- it is impossible to discover the real identity of the user . Only the responder -LRB- B , in our case -RRB- can decipher the alias of the originator -LRB- A -RRB- . 4.3 Basic Protocol We present here an authentication protocol that takes into account only the first three classes of identity privacy as described in section 3 . In doing so , we avoid the drawbacks of GSM and CDPD and provide an appropriate solution for untraceability of mobile users . The basic untraceable authentication protocol is depicted in figure 2 . The main idea is to generate and use at each security transaction a random alias . In addition to the notation defined in sections 4.1 and 4.2 , the following notation is used in this protocol : ffl Uid -LCB- Universal identification of the end-user U in his home domain . ffl ASh , ASr -LCB- Respectively Authentication Server of the home domain and the remote domain . ffl Nx -LCB- Nonce issued by entity X. ffl Px , Sx -LCB- Public-key , Secret-key pair of entity X. ffl Kxy -LCB- Secret key shared by entity X and entity Y . ffl T ICKKx -LRB- Ks -RRB- -LCB- A ticket computed with the key Kx and containing a belongssession key Ks . U ASr ASh ASh ; Ph -LRB- Nu ; Nu LUid -RRB- ; AUTHuh > Ph -LRB- Nu ; Nu LUid -RRB- ; Ph -LRB- Nr ; Nr LASr -RRB- ; AUTHrh > Pr -LRB- Nr -RRB- ; T ICKKrh -LRB- Kur -RRB- < T ICKKur -LRB- Pr -RRB- < Figure 2 : Basic Untraceable Authentication Protocol This protocol provides class C1 and C2 of identity privacy as neither the user nor the ASr identity are disclosed during the authentication process . The basic requirement is that the user 's device has to store on a long-term basis his home domain public key Ph. We now turn to the details of the protocol : 1 . The user begins by generating a nonce Nu and stores it in his device . Next , he computes both his alias Ph -LRB- Nu ; Nu LUid -RRB- -RRB- , and his one-way authentication message using his home key Ku . Then , he sends these messages to the local ASr along with ASh identity . 1 . 2 . Upon receipt of the initial message , ASr issues a nonce Nr , saves Pr -LRB- Nr -RRB- in its database and generates its own alias Ph -LRB- Nr ; Nr LASr -RRB- . Next , ASr computes its authentication message containing AUTHuh with Krh -LRB- secret key shared with ASh -RRB- using a token chaining technique 2 . 3 . When ASh receives the message in flow 2 , it proceeds as follows : -LRB- a -RRB- It deciphers Nu and the user 's alias with Sh . Then Uid is obtained by applying once again the XOR operation . -LRB- b -RRB- ASh recovers ASr identity in the same way -LRB- c -RRB- Having Uid and ASr , ASh is able to look for the corresponding shared secret keys in his database and recomputes AUTHrh -LRB- d -RRB- A match in this last step authenticates both the user and ASr without revealing neither Uid nor ASr identification to a third-party . -LRB- e -RRB- Upon a sucessful result , ASh sends Pr -LRB- Nr -RRB- along with a ticket containing the location dependent key Kur which is going to be used for the authentication of U in the remote domain . In fact , Pr -LRB- Nr -RRB- can be seen as a secret transaction number which identifies the authentication process involving both the user and ASh . In other words , this transaction number allows ASr to know who is sending the ticket and to whom Kur belongs while insuring anonymity to the home AS as well as to the user . 4 . This flow is purely optional as it allows ASr to give the user his public key Pr . This key will be used by the user during future single-sign-on with ASr for the computation of new aliases . Once the user has established a residency in the remote domain with the identification Uidr , e.g. Ph -LRB- Nu ; Nu LUid -RRB- , he may protect this identity on the next single-sign-on using the same alias computation technique as in section 4.1 . The user issues a new nonce N1 and provides Pr -LRB- N1 ; N1 LUidr -RRB- along with his authentication message . Upon receiving this message , ASr is able to recover Uidr . This technique allows the user to vary his identity in the remote domain during each authentication process . 4.4 Enhancing the Level of Anonymity The basic protocol lacks secrecy in the relationship between the user and his home AS because ASh identity is revealed in flow 1 . In order to provide an additional degree of privacy of class C3 as described in section 1solution for the protection of ASh identity is described in section 4.4 2Further details on this kind of authentication technique are described in -LSB- 4 -RSB- 3 , the user must compute an alias for ASh and thus need Pr . One solution is that before the authentication protocol takes place , the user receives a public-key certificate containing Pr . This may be obtained by contacting a trusted Certification Authority 3 . 5 Conclusion In conclusion , the need to provide identity privacy to mobile users is an important requirement . Existing approaches such as GSM presented some weakness in providing users good anonymity . After classifying different levels of user 's identity privacy , we proposed a generic solution for the computation of aliases which can be used during authentication of mobile users . The proposed method is flexible enough to protect the real identity of the user from both unauthorised -LRB- i.e eavesdroppers -RRB- and authorised parties -LRB- visited authorities -RRB- . References -LSB- 1 -RSB- M. Rahnema , Overview of the GSM System and Protocol Architecture , IEEE Communications Magazine , April 1993 . -LSB- 2 -RSB- J. Steiner , C. Neuman , J. Schiller , Kerberos : An Authentication Service for Open Network Systems , Proceedings of USENIX Winter Conference , February 1988 . -LSB- 3 -RSB- R. Molva , G. Tsudik , E. Van Herreweghen , S. Zatti , KryptoKnight Authentication and Key Distribution Systems , Proceedings of ESORICS ' 92 , November 1992 . -LSB- 4 -RSB- R. Molva , D. Samfat , G. Tsudik , Authentication of Mobile Users , IEEE Network Magazine , Special Issue on Mobile Communications , March/April 1994 . -LSB- 5 -RSB- W. Diffie and M. Hellman , New Directions in Cryptography , IEEE Transactions on Information Theory , November 1976 . -LSB- 6 -RSB- National Bureau of Standards , Federal Information Processing Standards , National Bureau of Standards , Publication 46 , 1977 . -LSB- 7 -RSB- Cellular Digital Packet Data -LRB- CDPD -RRB- System Specification , Release 1.0 , July 19 , 1993 . -LSB- 8 -RSB- European Telecommunications Standards Institute , Universal Personal Telecommunications , ETSI NA7 WP1 , November 1992 . -LSB- 9 -RSB- D. Chaum , A. Fiat and M. Naor , Untraceable Electronic Cash , Proceedings of Crypto ' 88 , August 1988 . -LSB- 10 -RSB- D. Chaum , Security Without Identification : Transactions Systems to Make Big Brother Obsolete , CACM Vol . 28 , No. 10 , October 1985 . -LSB- 11 -RSB- RSA Data Security Inc. , The RC4 Encryption Algorithm , Document No. 003-013005-100-000-000 , March 12 , 1992 . 3or if available may retrieve the certificate from a special database

O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

network security
non-traceability
roaming


Composition of Reactive System Components K. Lano , J. Bicarregui , T. Maibaum Dept. of Computing , Imperial College , 180 Queens Gate , London SW7 2BZ kcl@doc.ic.ac.uk J. Fiadeiro Dept. of Informatics , University of Lisbon , Campo Grande , 1700 Lisbon July 11 , 1997 Abstract This paper will present the case for using a formal component-based specification technique for reactive systems , such as the Object Calculus of Fiadeiro and Maibaum . The Object Calculus provides a modular , highly declarative and abstract specification language , suitable for refinement using model-based design notations such as B or VDM . In the Object Calculus , pre/post style specifications of the effect of actions can be given , together with temporal logic specifications of expected histories of behaviour of the system . Workshop Goals : Investigate application of formal specification in component-based systems , particularly reactive systems . 1 Background Temporal logic is an established technique for the specification of reactive systems : it has the advantage of being declarative and supporting reasoning , and it is sufficiently expressive for many practical cases . The Object Calculus adds a strong concept of encapsulation and theory composition to a basic temporal logic formalism -LSB- 8 -RSB- , which allows reactive system components to be separately specified , instantiated and combined using category-theoretic operations , in particular , the co-limit construction : \ given a category of widgets , the operation of putting a system of widgets together to form some super-widget corresponds to taking the co-limit of the diagram of widgets that shows how to interconnect them '' -LSB- 10 -RSB- Using this integration of category-theoretic structuring and temporal or modal logics , the development of the Object Calculus has been carried out by research groups at Imperial College and the University of Lisbon over the last 10 years . It has been taken up by other research groups and applied to systems of significant complexity , such as the steam boiler system described here . In this paper we will use examples from a case study of an established benchmark for formal methods , the steam boiler system , to illustrate the techniques of abstract and compositional specification using the Object Calculus . A description of the steam boiler system can be found in -LSB- 2 -RSB- , together with different approaches to formal specification of it . The purpose of the system is to produce a flow of steam from the boiler water tank , without letting the tank boil dry or overflow . Failures in the measuring devices involved -LRB- flow monitors on the water feed lines , steam level sensor and water level sensor -RRB- and the water pumps must be handled by an appropriate change of mode of the controller -LCB- in emergency situations this may involve a shutdown of the control system . Figure 1 shows the main components of the system . Valve Steam Measure M2 N2 N1 M1 Water Measure Pump -LRB- * 4 -RRB- Pump Controller -LRB- * 4 -RRB- Figure 1 : Steam Boiler Components A specification in the object calculus -LSB- 8 -RSB- is constructed as a set of linked theories in a temporal logic . Formally , it is a diagram of objects in a category of theories and theorem-preserving morphisms . A theory consists of collections of type and constant symbols , attribute symbols -LRB- denoting time-varying data -RRB- , action symbols -LRB- denoting atomic operations -RRB- and a set of axioms describing the types of the attributes and the effects , permission constraints and other dynamic properties of the actions . The axioms are specified using linear temporal logic operators : -LRB- in the next state -RRB- , U -LRB- weak until -RRB- , 2 -LRB- always in the future -RRB- and ? -LRB- sometime in the future -RRB- . There is assumed to be a first moment . The predicate BEG is true exactly at this time point . is also an expression constructor . If e is an expression , e denotes the value of e at the beginning of the next time interval . e itself denotes its value at the beginning of the current interval . Several actions may execute in a given interval : the formula ff where ff is an action , denotes that ff occurs in the current interval . We express the effects of actions via axioms of the form : Pre ^ ff -RRB- Post where Pre is a precondition , a predicate over the current state , and Post describes the properties of the state that results from execution of ff in a state satisfying Pre . It may use both att and att for attributes att of the theory . A wide variety of properties can be expressed using such a logic . In particular it seems appropriate for the specification of the steam boiler problem as the requirements of this system are expressed in terms of reaction cycles -LRB- intervals -RRB- where a collection of events -LRB- actions -RRB- occur , including inputs to the system , its internal reactions , and outputs from the system to the physical devices . Constraints between the events in a given cycle include that multiple level messages in a given interval should give rise to a transmission error : : 91 lev : Z ? level -LRB- lev -RRB- -RRB- transmission failure 91 x is the \ exists a unique x '' quantifier . Constraints between events in successive cycles include that three successive stop messages give rise to a termination -LRB- in the same cycle as the third stop -RRB- : stop ^ stop ^ stop -RRB- terminate and the protocol for failure detection and acknowledgement : water measure failed -RRB- -LRB- level failure detection U level failure acknowledgement -RRB- \ If the water measure fails in the current cycle , the message level failure detection is repeated until a level failure acknowledgement message is received . '' The use of weak until means that there is no obligation for an acknowledgement message to ever be received1 . In order to support reasoning about the attributes which may change over a given interval , we associate to each action the set of attributes which it may change : its write frame . For each attribute att we then have a locality axiom of the form att = att _ ff1 _ : : : _ ffn where the ffi are all those actions with att in their write frame . Theories are connected by means of theory morphisms oe which map each attribute symbol att of the source theory S to an attribute symbol oe -LRB- att -RRB- of the target theory T , each action ff of S to an action oe -LRB- ff -RRB- of T , and so forth . Each theorem of S must become a theorem of T under this translation : ` S ' implies ` T oe -LRB- ' -RRB- Preservation of the locality axioms means that no new actions -LRB- not in the image of oe -RRB- can be introduced in T which directly write attributes att of S. Any action with oe -LRB- att -RRB- in its write frame 1Technically , this means that this property is a safety rather than a liveness property . must be -LRB- or must always co-execute with -RRB- the interpretation of some action ff of S where att is in the write frame of ff in S . This form of encapsulation is close to that of B -LSB- 1 -RSB- : only operations declared in a given B module -LRB- machine -RRB- may directly write to variables declared in that module . 2 Position We believe that the Object Calculus formalism provides a suitable framework for the description of reactive system components . Such components are often of a generic nature , consisting of variations or enhancements of fundamental physical devices such as valves , tanks , pumps , etc. . Particular systems are built from a combination of these components . Thus the Object Calculus seems an appropriate formalism for their specification since it allows convenient extension , adaption and composition of component specifications . Moreover , the key properties of such components concern their dynamic and reactive behaviour , for which temporal logic is ideally suited . In the following sections we illustrate the use of the object calculus in specifying the steam boiler control system . 2.1 Abstract Specification At the most abstract level , all actions of a system can be assumed to occur in intervals without overlap . An interval at this level of abstraction represents a cycle of the concrete system . A theory SData gives definitions of the types and constants used in the system , and will be included in each of the other theories : Types PState = frunning ; offg PCState = fflow ; noflowg Condition = ffailed ; operatingg @Pump = fp1 ; p2 ; p3 ; p4g Constants M1 : N / * Minimum water level * / M2 : N / * Maximum water level * / N1 : N / * Minimum normal water level * / N2 : N / * Maximum normal water level * / W : N1 / * Maximum steam production * / C : N1 / * Capacity of boiler * / P : N1 / * Capacity of pump * / U1 : N / * Max rate of steam increase * / U2 : N / * Min rate of steam increase * / o : N1 / * Sampling interval * / Axioms M1 < N1 ^ N1 < N2 ^ N2 < M2 Each physical component has an associated monitor which provides an interface between it and the controller . This monitor is responsible for managing the protocol of communications between the controller and the components , and for detecting errors in data and communications . The axioms of the monitor theory for the water measure formalise the requirements given in -LSB- 2 , pages 500 -LCB- 509 -RSB- . Attributes water measure condition : Condition water quantity : Z Actions -LRB- With write frames presented as sets of attributes :-RRB- level -LRB- lev : Z -RRB- fwater quantityg water measure failed fwater measure conditiong transmission failure ? level failure detection ? level failure acknowledgement ? level repaired fwater measure conditiong level repaired acknowledgement ? Axioms Initially the water quantity is and the measure is operating : BEG -RRB- water quantity = ^ water measure condition = operating A water measure failure event occurs if we receive a level -LRB- lev -RRB- message with lev < or lev > C : 9 lev : Z ? level -LRB- lev -RRB- ^ -LRB- lev < _ lev > C -RRB- -RRB- water measure failed A transmission failure occurs if we do not receive a unique level message in the current cycle : : 91 lev : Z ? level -LRB- lev -RRB- -RRB- transmission failure Notice that this includes the case where no level message is received . If a level measure failure occurs , the system must react by recording the failure : water measure failed -RRB- water measure condition = failed The signal level failure detection must then be repeated until level failure acknowledgement is received : water measure failed -RRB- -LRB- level failure detection U level failure acknowledgement -RRB- A level repaired signal resets the water measure condition attribute : : water measure failed ^ level repaired -RRB- water measure condition = operating and leads to the generation of a level repaired acknowledgement : level repaired -RRB- level repaired acknowledgement A valid water level event sets the value of water quantity : : water measure failed ^ : transmission failure -RRB- -LRB- level -LRB- lev -RRB- -RRB- water quantity = lev -RRB- The theory of the steam measure monitor is identical in structure to the water measure monitor . Formally it is an isomorphic image under the morphism which maps C to W , water measure condition to steam measure condition , etc. . A similar structure can be given for the theory of the pump , pump monitor and the pump controller and its monitor . Indeed we can recognise a number of commonalities between the monitor theories -LRB- only the criteria for detecting sensor failures , and for recording the current state , are different -RRB- . There are common subtheories FailureManager of the form Attributes condition : Condition Actions component failed fconditiong component repaired fconditiong failure detection ? failure acknowledgement ? repaired acknowledgement ? Axioms BEG -RRB- condition = operating component failed -RRB- condition = failed component failed -RRB- -LRB- failure detection U failure acknowledgement -RRB- : component failed ^ component repaired -RRB- condition = operating component repaired -RRB- repaired acknowledgement These in their turn could be subdivided into parts dealing with the communication protocol -LRB- axioms 3 and 5 -RRB- and parts dealing with the recording of failure status -LRB- axioms 1 , 2 and 4 -RRB- . A theory Transmission has the form Actions component state -LRB- val : Z -RRB- ? transmission failure ? Axioms : 91 lev : Z ? component state -LRB- lev -RRB- -RRB- transmission failure where we regard the PState and PCState types as isomorphic to f0 ; 1g as in -LSB- 2 -RSB- . Therefore the Water Measure Monitor theory can be re-expressed in terms of Transmission , via the morphism m7 of Figure 2 : component state -LRB- s -RRB- 7 ! level -LRB- s -RRB- transmission failure 7 ! transmission failure and FailureManager , via the morphism m1 condition 7 ! water measure condition component failed 7 ! water measure failed component repaired 7 ! level repaired failure detection 7 ! level failure detection failure acknowledgement 7 ! level failure acknowledgement repaired acknowledgement 7 ! level repaired acknowledgement The attribute water quantity and axioms to initialise and set this quantity are defined locally in Water Measure Monitor , and the axiom 9 lev : Z ? level -LRB- lev -RRB- ^ -LRB- lev < _ lev > C -RRB- -RRB- water measure failed determining when a component failure occurs is also defined in this theory . Similar constructions work for the pump and pump controller -LRB- flow monitor -RRB- components . Figure 2 shows the structure of this part of the system . Separate copies of the FailureManager and Transmission theories are included in each of the component theories , but we identify all the different transmission failure actions so that a transmission failure in any component generates the same system error event . SData is also included into each of the theories shown in this diagram . Water Measure Monitor Steam Measure Monitor Pump Monitor Pump Control Monitor PD Pump / Monitor Failure Manager Failure Manager Failure Manager Failure Manager Control Transmission m1 m2 m3 m4 m6 m9 m10 m11 m12 m7 m8 m5 Figure 2 : Construction of Component Theories The theory of the controller then extends the co-limit of the monitor theories with the following attributes and actions : Types CState = finitialisation ; normal ; degraded ; rescue ; emergency stopg Constants hazard level -LRB- Z -RRB- : bool min level estimate -LRB- Z ; Z -RRB- : Z max level estimate -LRB- Z ; Z -RRB- : Z Attributes cstate : CState Actions react fcstateg terminate fcstateg stop ? steam boiler waiting ? physical units ready fcstateg program ready ? Axioms Some example axioms of the controller are : terminate -RRB- cstate = emergency stop and hazard level -LRB- water quantity -RRB- ^ cstate 2 fnormal ; degraded ; rescueg -RRB- terminate A terminate event occurs if there have been three successive stop events , or if there has been a transmission error : stop ^ stop ^ stop -RRB- terminate transmission failure -RRB- terminate Given the new mode and water level , take appropriate action : cstate = normal _ cstate = degraded _ cstate = initialisation -RRB- -LRB- water quantity < N1 -RRB- increase flow -RRB- ^ -LRB- water quantity > N2 -RRB- decrease flow -RRB- cstate = rescue -RRB- -LRB- min level estimate -LRB- water quantity ; steam quantity -RRB- < N1 -RRB- increase flow -RRB- ^ -LRB- max level estimate -LRB- water quantity ; steam quantity -RRB- > N2 -RRB- decrease flow -RRB- The specification can be validated via animation -LSB- 11 -RSB- . The actions increase flow and decrease flow are general operations which will be interpreted as opening and closing certain pumps in the actual physical system : we have defined a layered architecture in which the implementation details of such abstract actions are hidden from the high-level controller . 2.2 Design and Implementation B -LSB- 1 -RSB- specifications of steam boiler components were defined from the above theories . Standard techniques were used to code up temporal logic constraints . For example the temporal constraint ff -RRB- -LRB- U -RRB- can be formalised by a boolean flag gamma until beta , initialised to FALSE , and preconditions gamma until beta = FALSE on every controller action except and and method definitions : ff = pre gamma until beta = FALSE ^ : : : then gamma until beta : = TRUE jj ... end ; = : : : gamma until beta : = FALSE A C executable of 3098 lines of code was produced from the B implementations . A number of test scenarios were input to this executable , following the format defined in -LSB- 2 -RSB- . 3 Comparison We have shown that the Object Calculus can be used to provide a highly abstract and declarative specification of the behaviour of the steam boiler . We have formalised most aspects of the system . An executable controller has been produced and tested against the FZI simulator . Approximately 1 person week was used in writing the abstract specification , and 2 person weeks in developing the B design and implementation , including verification activities . B has been shown to be effective for industrial specification and to be comprehensible by ` average programmers ' . We believe that the Object Calculus is also quite easy to relate to reactive system concepts and to notations such as statecharts , which it generalises . The papers -LSB- 4 , 5 -RSB- describe how statecharts can be mapped to the Object Calculus . Some specifications of -LSB- 2 -RSB- address issues which we do not consider , such as the calculation of optimal control points or the probabilistic behaviour of device failures . Our abstract specification adopts the approach of -LSB- 7 -RSB- in working at the macro step level in order to simplify the description . The B design is at the micro step level . The Object Calculus description is also related to the rule-based approaches used in -LSB- 3 -RSB- and -LSB- 9 -RSB- , and suffers a similar problem of consistency obligations between rules . Our controller design model , like that of -LSB- 6 -RSB- , adopts a purely reactive system approach , whereby events are assumed to happen one at a time and are reacted to in the order of their arrival . An alternative structuring approach would be to use a time-based partitioning of modules , whereby the actions relevant to the initialisation phase of the steam boiler operation are placed in a theory separate from the actions and attributes of the running phase . The mapping from Object Calculus to B is systematic -LRB- theories correspond to machines -RRB- but is not entirely automatic , since a design process is involved . Future work will classify different design choices for this translation , and relate B structuring formally to the Object Calculus . The Object Calculus has also been related to the UNITY approach for reactive system specification -LSB- 12 -RSB- . References -LSB- 1 -RSB- J R Abrial , The B Book : Assigning Programs to Meanings , Cambridge University Press , 1996 . -LSB- 2 -RSB- J R Abrial , E Borger , H Langmaack -LRB- Eds . -RRB- , Formal Methods for Industrial Applications : Specifying and Programming the Steam Boiler Control , LNCS 1165 , Springer-Verlag , 1997 . -LSB- 3 -RSB- C Beierle et al , Refining Abstract Machine Specifications of the Steam Boiler Control to Well Documented Executable Code . Pages 52 -LCB- 78 of -LSB- 2 -RSB- . -LSB- 4 -RSB- J.C. Bicarregui , K.C. Lano , T.S.E. Maibaum , Objects , Associations and Subsystems : a hierarchical approach to encapsulation , ECOOP 97 , LNCS , 1997 . -LSB- 5 -RSB- Towards a Compositional Interpretation of Object Diagrams . J.C. Bicarregui , K.C. Lano and T.S.E. Maibaum . To appear : Proc . of IFIP TC2 Working Conference on Algorithmic Languages and Calculi , Strasbourg , February , 1997 . -LSB- 6 -RSB- R B?ussow , M Weber , A Steam-Boiler Control Specification with Statecharts and Z. Pages 109 -LCB- 128 of -LSB- 2 -RSB- . -LSB- 7 -RSB- J Cuellar , I Wildgruber , The Steam-Boiler Problem -LCB- A TLT Solution . Pages 164 -LCB- 183 of -LSB- 2 -RSB- . -LSB- 8 -RSB- J. Fiadeiro and T. Maibaum Describing , Structuring and Implementing Objects , in de Bakker et al. , Foundations of Object Oriented languages , LNCS 489 , Springer-Verlag , 1991 . -LSB- 9 -RSB- M-C Gaudel et al , A Formal Specification of the Steam-Boiler Control Problem by Algebraic Specifications with Implicit State . Pages 233 -LCB- 264 of -LSB- 2 -RSB- . -LSB- 10 -RSB- J Goguen and S Ginali , A Categorical Approach to General Systems Theory , in G. Klir -LRB- Ed . -RRB- , Applied General Systems Research , Plenum 1978 , pp 257 -LCB- 270 . -LSB- 11 -RSB- K Lano , Specification of Steam Boiler Controller in RAL/VDM + + and B , ROOS Project Document GR/K68783 -15 , 1997 . -LSB- 12 -RSB- K Lano , J Bicarregui , J Fiadeiro , A Lopes , Specification of Required Non-determinism , FME 97 , to appear in LNCS , 1997 . 4 Biography Juan Bicarregui has worked on tool support for formal methods , in particular the Mural proof assistant , and on their theoretical foundations . Jose Luiz Fiadeiro works in the area of formalisation of specification and program design paradigms using modal logics -LRB- temporal and dynamic -RRB- and of their underlying modularisation principles using category theory . Kevin Lano is a Research Fellow at the Department of Computing at Imperial College . He has previously worked in industry in the areas of formal methods and software assessment . His current research is focussed on the use of formal techniques to provide semantics for object-oriented and reactive systems . Tom Maibaum is Professor of Foundations of Software Engineering at the Department of Computing at Imperial College . He has worked on the development of compositional techniques for specification and design of software systems since 1974 and has published papers and books in the area .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

object calculus
reactive systems
temporal logic

program specification
specification languages