ABSTRACT ÅBO AKADEMI UNIVERSITY. Faculty of Mathematics and Natural Sciences. Department of Computer Science. Leonidas Tsiopoulos

Transcription

1 ABSTRACT ÅBO AKADEMI UNIVERSITY Faculty of Mathematics and Natural Sciences Department of Computer Science Author: Title: Leonidas Tsiopoulos UML Modeling of Control Systems Master of Science Thesis, 65 pages Supervisor: Assistant Professor Marina Waldén March 2003 The Unified Modeling Language (UML) has become the de facto standard for modeling software and hardware systems. It is a graphical language for specifying, visualizing, developing and documenting complex systems. Moreover, UML has been used successfully by the industry in order to ease the development process of large systems. The aim of this thesis is to present how the Unified Modeling Language (UML) can be used for modeling industrial strength control systems, from initial specification to implementation through refinement steps. Use cases, component, class and statechart diagrams have been used to model the system, and the U2B (UML to B) tool, developed at Southampton University, is used to translate the class and statechart diagrams to B code in order to be able to verify them. As a case study, a part of a liquid handling workstation for health care clinicians and researchers has been developed. Moreover, because this workstation is a safety critical system, safety analysis is incorporated into the system in order to develop it. I

2 FOREWORD The work described in this Master of Science Thesis was done in cooperation with PerkinElmer Life Sciences in Turku, Finland. I would like to thank Lasse Laine, Peter Nylund and Nils Kullberg for their guidance and comments during this work. Also, I would like to thank Colin Snook from Southampton University for offering his UML to B Method translation tool to be used for this work. Special thanks to my thesis supervisor Assistant Professor Marina Waldén. Without her support and advices this thesis would not have been written. I would like also to thank the people working at the department of Computer Science and the Turku Centre for Computer Science (TUCS) for the excellent working conditions and inspiring atmosphere. I am thankful for the love and support from my family, relatives, friends and my Mervi. II

3 TABLE OF CONTENTS ABSTRACT...I FOREWORD... II TABLE OF CONTENTS...III TABLE OF FIGURES... VI Appendices...VII 1 Introduction Background Structure of This Work The Unified Modeling Language Use Cases Actors Flow of Events Scenarios Component Diagrams Class Diagrams Collaboration Diagrams Statechart Diagrams The Action Systems Formalism Actions Enabledness of actions Action Systems The B Method Abstract Machine Specification Machine Refinement and Implementation Structuring Mechanisms in B B-action Systems Procedures in B-action systems Refinement of B-action Systems Tool support Rational Rose Enterprise Edition Tool U2B Tool Tools supporting the B Method...24 III

4 7 Modeling Control Systems Determining the controller and the plant Determining sensors and actuators Presentation of the Wallac case study The requirements of the case study The integrated development process proposed for the case study Safety aspects of the development Presence of failures UML-development incorporating safety aspects Use cases incorporating the possible failures Component-oriented development Class diagram of the specification Collaboration diagram of the Stackers Statechart Diagrams of the specification The Rotary Table The Stacker U2B translation to B-action systems and formal specification of the system Formal specifications and safety analysis Refining the system Class diagrams of the first refinement of the system The Rotary Table The Stacker unit Statechart Diagrams of the first refinement The Rotary Table The Stacker unit U2B translation to B-action systems and first refinement of the system Safety issues for the first refinement Class diagram of the second refinement step of the Rotary Table Statechart diagram of the second refinement for the Rotary Table Control System development Decomposition of the Rotary Table Determining controller and plant Class diagram of the controller and plant specifications Statechart diagram of the Rotary Table plant U2B translation to B-action systems Determining sensors and actuators Class diagram of the final control system Statechart diagram of the plant & the B-action system of the final control System...61 IV

5 12 Conclusions References V

6 Table of Figures Figure 1. A use case diagram...4 Figure 2. A component diagram...6 Figure 3. Class Diagram...7 Figure 4. Collaboration Diagram...7 Figure 5. Statechart diagram...8 Figure 6. The structure of an abstract machine specification...12 Figure 7. The structure of a machine refinement...14 Figure 8. M2 includes M1 [Schneider01]...15 Figure 9. M2 sees M1 [Schneider01]...16 Figure 10. An action system A and its embedding to a B machine [WS98]...17 Figure 11. Declaration of a global variable z in B [WS98]...18 Figure 12. Procedures in B-action systems...18 Figure 13. The refined B-action system [WS98, PTWBEJ01]...19 Figure 14. Rational Rose Window...22 Figure 15. U2B Translation for the class STATION of Figure Figure 16. Feedback Control [SG96]...25 Figure 17. The structure of the control system specification...25 Figure 18. General decomposition schema [Sekerinski99]...27 Figure 19. The Fillwell workstation [Fillwell02]...28 Figure 20. Top view of the Rotary Table...29 Figure 21. Safety analysis and stepwise system development [PTWBEJ01]...31 Figure 22. Use case diagram for the Stacker...33 Figure 23. Use case diagram for the Rotary Table...34 Figure 24. A component diagram for the Rotary Table and a Stacker...37 Figure 25. Specification Class Diagram for Rotary Table and Stacker...38 Figure 26. Collaboration Diagram for the Stackers...38 Figure 27. Specification Statechart Diagram for the Rotary Table...39 Figure 28. Specification Statechart Diagram of a Stacker for the stack service...40 Figure 29. Class Diagram of the Stacker...42 Figure 30. Position of plate holders after a two steps rotation...46 Figure 31. A part of the 1 st refinement statechart diagram for rotate service...49 Figure 32. A part of the 1 st refinement statechart diagram for stack service...51 Figure 33. Specification for role A of the association end...53 Figure 34. Proof Obligations generated by Atelier B for the first refinement of the Rotary Table...54 Figure 35. Proof Obligations generated by Atelier B for the first refinement of the Stacker unit...54 Figure 36. Proof Obligations generated by Atelier B for the second refinement of the Rotary Table...57 Figure 37. Proof Obligations generated by Atelier B for the Rotary Table Control System...61 VI

7 Appendices A Statechart diagram of Stacker for the destack service 66 B The specification of the Rotary Table and the Stacker unit as B-action Systems 67 B.1 The specification of the Rotary Table 67 B.2 The specification of the Stacker unit 70 B.3 The sets of commands for the Rotary Table and the Stacker unit 80 C The first refinement of the system - Diagrams 81 C.1 The class diagram 81 C.2 The statechart diagram of the 1 st refinement for the rotate service of the Rotary Table 82 C.3 The class diagram of the 1 st refinement for the Stacker unit 83 C.4 The statechart diagram of the 1 st refinement of a Stacker for the destack Service 84 C.5 The statechart diagram of the 1 st refinement of a Stacker for the stack service 85 D The first refinement step of the Rotary Table and the Stacker unit 86 D.1 The refined Rotary Table 86 D.2 The procedure class machine PLATEHOLDER of the Rotary Table refinement 90 D.3 The first refinement of the Stacker unit 94 D.4 The procedure class machine of the Stacker unit 108 D.5 The procedure machine of the XYZ driver for the Dispensing Head 109 D.6 The Z driver class of the Dispensing Head s XYZ driver 110 D.7 The sets and constants of the Rotary Table & the Stacker unit 112 E The second refinement of the Rotary Table Diagrams 114 E.1 The class diagram 114 E.2 The statechart diagram 115 F The second refinement step of the Rotary Table 116 F.1 The second refinement machine 116 F.2 The updated procedure class of the Rotary Table 120 F.3 The procedure class PLATE of the Rotary Table 125 F.4 The updated DEF2 class 126 G The control system decomposition of the Rotary Table Diagrams 128 G.1 The class diagram of the plant & controller decomposition of the Rotary Table 128 G.2 The statechart diagram of the plant of the Rotary Table 129 H The decomposition of the control system of the Rotary Table 130 H.1 The plant of the Rotary Table 130 VII

8 H.2 The controller of the Rotary Table 134 H.3 The updated DEF2 class 137 I The decomposition of the sensors & actuators of the Rotary Table Diagrams 139 I.1 The class diagram of the sensor & actuator decomposition of the Rotary Table 139 J The decomposition of sensors & actuators 140 J.1 The Rotary Table plant refinement 140 J.2 The refined controller of the Rotary Table 143 J.3 The updated procedure class PLATEHOLDER2 of the Rotary Table 146 J.4 The sensor Z_SENSOR of the Dispensing Head driver 150 J.5 The actuator of the Rotary Table 151 VIII

9 1 Introduction The purpose of this Master of Science thesis is to present how the Unified Modeling Language (UML) can be used for modeling industrial strength control systems, from initial specification to implementation through some refinement steps. Usually such a development method is not obvious, nor straightforward to obtain for a complex final system, given only the initial requirements. Using UML for the whole development process provides the developer(s) with good documentation, which is required in order to enable smoother evolution and reuse of the produced system. The work presented in this thesis has been done within the MATISSE 1 project. 1.1 Background The Unified Modeling Language (UML) [BRJ99, UML1.4] is the accepted standard for the development of object oriented software. It combines very important software engineering techniques, such as use cases, classes as well as statecharts. These techniques consist of a number of diagrams that help the programmer to specify, develop, maintain and reuse software. UML has been used successfully by the industry for the modeling of complex systems. A drawback of UML is that it does not have specific semantics, so the use of (UML specific) tools is inevitable, which are important in order to be able to verify the various kinds of UML diagrams. Such tools are Rational Rose [Rational03], which is used in this Thesis, and Rhapsody [Rhapsody03]. Another tool [SB03], which translates UML class diagrams to B Method code, is used so that these kinds of diagrams can be formally proved correct. The purpose of a control system is to maintain specified properties of the outputs of the process at given reference values called the set points [SG96]. Properties such as temperature, pressure, height and flow rates are monitored, and their values are used to control the process. Control systems consist of a number of entities embodying specific functions and properties that interact with each other to obtain the desired functionality and cooperation [BSS96].These entities are the sensors, the actuators, the controllers and the plants. Having these interactive entities, it is helpful to incorporate an object-oriented development process, which is offered by UML. A slightly different approach on decomposing a control system is presented in [Brooks85] where the decomposition is based on task achieving behaviour. In this approach the different behaviours of the control system s controller are decided after analyzing the computational requirements of the system. Then the information from the sensors is passed to the controller to perform various computations and finally the processed data is passed to the actuators. The control system developed in the case study of this Thesis is part of a safety-critical healthcare system. When developing safety-critical systems, it is important to fulfill not only functional requirements specifying the services to be performed by the system, but also safety requirements specifying the characteristics the system should take into account in order to ensure safety. Moreover, reliability is an issue of such a system. Reliability means the correct functioning of the system under given operating conditions 1 MATISSE: Methodologies and Technologies for Industrial Strength Systems Engineering. IST

10 and it should ensure an extremely high precision and quality of the experiments to be performed. By applying formal methods, enhancement of the safety and reliability of the system can be achieved. Formal methods mathematically prove the functional, as well as the safety and reliability requirements of the system in every development step. Furthermore, the application of formal methods allows early error discovery and correction, resulting in a faster development process. One way to develop complex control systems is by stepwise adding details to the system, starting from a high-level specification proceeding to a final control system via correctness preserving refinement steps. The B-action systems [WS98] used is a formalism which supports this kind of development of control systems. Each refinement step is accompanied by proofs. The B Method [Abrial96] and its associated tool provide a good mechanized support for refinement based development. Moreover, the B Method has been successfully used in industrial projects. Modeling the plant and the controller initially as a single B-action system allows the developer to abstract away from the communication mechanisms between them. Only in later refinement steps, an explicit mechanism for passing the values of sensors from the plant to the controller is introduced. 1.2 Structure of This Work This thesis approaches its topic with the classical top-down method starting from an abstract level describing the theory and the tools used, and gradually introducing the details. Chapter 2 describes the UML diagrams being used for the development of the control system. These are use case diagrams, component diagrams, class diagrams, collaboration diagrams, as well as statechart diagrams. Chapter 3 presents briefly the Action Systems formalism because it is the base, together with the B Method, for the B-action Systems formalism used in order to be able to verify the translated UML diagrams. What an action can be, when an action is enabled, as well as what an action system is, is explained. Chapter 4 gives a brief introduction to the B Method. What can be in an Abstract Machine Specification, as well as in a Machine Refinement and Implementation, is explained. Also, the structuring mechanisms of the B Method used in this Thesis are present. Chapter 5 describes the B-action Systems formalism. Specifically, procedure calls in B- action systems are described, as well as refinement of B-action Systems. Chapter 6 presents the tools used in the case study for the development process. The Atelier B support tool for the B Method is described, a brief presentation of the UML development tool, Rational Rose, is given, and a short description of the UML to B 2

11 (U2B) tool, which translates class and statechart diagrams, if they are attached to a class, is given, too. Chapter 7 explains how a control system is modeled after all the details have been introduced to the system. The process of determining the plant and the controller, as well as the sensors and the actuators of the control system is explained. Chapter 8 presents the case study, the requirements of it and the integrated development process proposed for the case study. Moreover, in this chapter a description is given of how the safety aspects of the development are fulfilled. Chapter 9 tells how the UML development incorporates the safety aspects. The technical report [PTWBEJ01] was used as the basis to perform the safety analysis of the system in this case study, because it consists of the safety analysis and safety requirements of an other part of the same system being developed within the MATISSE project. Moreover, the component-oriented development is given, together with the class and statechart diagrams of the specification. An abstract collaboration diagram of part of the system is given, too. Furthermore, the translated B-action systems of the formal initial specification of the system are described, as well as what was required by U2B in order to translate the diagrams correctly. Chapter 10 presents the refinement steps of the development of the system. The system developed as a case study consists of two parts. One part was developed until the first refinement, while the other was developed completely. The safety issues concerning the refinements are presented, too, as well as the features required by U2B for the translation. Chapter 11 covers the control system development. The class and the statechart diagrams of the control system are described together with the translated B-action systems. This control system development consists of two steps. First, the controller and the plant are determined and then the sensors and the actuators of the system are also determined. Chapter 12 consists of concluding remarks. 3

12 2 The Unified Modeling Language The Unified Modeling Language (UML) [BRJ99, UML1.4] has become the de facto standard notation for describing analysis and design models of software systems, as well as for documenting them. UML consists of a number of diagrams focusing on different aspects of the system independently. These diagrams can be separated into two groups depending on whether they are intended to describe structural or behavioural aspects. Major features of UML include use cases and scenarios, behavioral modeling with statecharts, packaging of various kinds of entities, object model, representation of tasking and task synchronization, models of physical topology, as well as support for objectoriented patterns. This thesis focuses on the UML diagrams that are most relevant for modeling control systems. In the case study an example of their use is shown. Comprehensive studying of UML can be obtained elsewhere [BRJ99, Douglass99, SP00]. 2.1 Use Cases Use cases specify desired behaviour of the system, without showing how that behaviour will be carried out and they let us focus on the issues of highest risk. A use case represents a functional requirement of the system as a whole. A use case is a set of actions, including variations, which a system performs to yield an observable result of value to an actor. A set of actions represents the interaction of its actors outside the system (its actors) with the system itself. These actions are in effect system level functions that are used to visualize, specify, construct and document the intended behaviour of the system during requirements capture and analysis. Furthermore, every use case must have a name that distinguishes it from other use cases. Figure 1 below illustrates a case with three use cases, service 1, service 2 and service 3, as well as an actor. Actor Service 1 Service 2 Service 3 Figure 1. A use case diagram. 4

13 2.1.1 Actors A use case can have an actor, which might be a human, a hardware device, or even another system. An association relationship between an actor and a use case indicates that the actor and the use case communicate with one another. Figure 1 above consists of three use cases Service 1, Service 2, and Service 3, as well as an actor interacting with them Flow of Events The flow of events can specify the behaviour of a use case. In the description of the flow of events, the start and the end of the use case should be included, as well as the interactions between the actors and the use case. Moreover, which objects are exchanged, the basic flow and alternative flows of the behaviour should be included in that flow of events Scenarios In a complex system, like the one described in the case study of this thesis, it is often desirable to separate main versus exceptional flows of events. This is due to the fact that a use case describes a set of sequences and it would be impossible to express all the details of a complex use case in just one sequence. As an example of scenarios, two sequences of a loan system are shown below [SP00]. Book borrower X borrows the library s second copy of book z, when she has no other book on loan. The system is updated accordingly. Book borrower Y tries to borrow the library s first copy of book w, but is refused because he already has 5 books out on loan, which is the maximum allowance. From the above example, each book borrower can be related to the actor of the Figure 1 and each book loan service to the services of the same diagram. A sequence from the set of sequences represents one possible flow of events through all these variations. Each sequence is called a scenario. 2.2 Component Diagrams The use case diagrams show only the specified services and their relationships, while the component diagram distributes the services among a set of components that will implement them. The component diagram is deduced from the use case diagram and the component interactions are deduced from the use case relationships. Each use case can be mapped to a component service. A component is an abstraction over the space of services of a system, which are captured by the use case diagram. The components interact with each other via the provided services. Figure 2 below shows a simple component diagram where component Comp_A interacts with component Comp_B via the service Service 1 offered from Comp_A. The service Service 2 is local to the component Comp_A. A specification language will be used to specify the components in a precise manner. 5

14 Comp_A Service1 Comp_B Service2 Figure 2. A component diagram. 2.3 Class Diagrams A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics [BRJ99]. The class can be a description of only one object depending on the requirements of the system. Class diagrams are the most common diagrams for modeling object-oriented systems. These diagrams are used to model the static design view of a system and they are the foundation for component diagrams, because they consist of operations, which are actually the services of a component. A class diagram consists of classes and relationships such as dependency, generalization, association and realization relationships. In this Thesis we concentrate on association, dependency and realization relationships, because U2B requires them in order to translate correctly the diagrams to B code. An association relationship between two classes specifies that the objects of one class are connected to the objects of the other class and vice versa [BRJ99]. A dependency relation between two classes A and B means that class A depends on class B, if a change to class B may force a change to class A [SP00]. A realization relationship is a semantic relationship between two classes in which one class specifies a contract that the other class guarantees to carry out [SP00]. A class consists of a name, a set of attributes and a set of operations that may have parameters. Every class c may either define a set of objects called the instances of c, or a single object, depending on its multiplicity. A class diagram [SB02] with a class STATION and a class PLATFORM with an association relationship between them can be seen in Figure 3 below. A station can have several platforms. When a train arrives it is sent to any of the available platforms. If no platform is available it is queued until a platform is freed by a train departing. A platform is available when it has no trains and occupied when it has one train. If a second train arrives at a platform or if a train arrives at a closed platform, there is a crash. A platform can be closed if it has no trains at it and then opened again. 6

15 S TATI ON q u e u e : s e q ( TRAI N ) = < > PLATFORM t r a in s : POW ( TRAI N ) = { } t r a i n _ a r r iv e s ( t t : TRAI N ) : o u t c o m e t r a i n _ d e p a r t s ( p p : PLATFORM) n e x t _ t r a in ( ) + p la t f o r m s 0.. n a r r iv a l( t t : TRAI N ) d e p a r t u r e ( ) c lo s e p la t f o r m ( ) a d d _ p la t f o r m ( p p : PLATFORM) o p e n p la t f o r m ( ) Figure 3. Class Diagram. When crashed, opening the platform will clear any trains from that platform and make it available if it had two trains at it, or make it closed if it had more than two trains. 2.4 Collaboration Diagrams While a class is a description of a set of objects that share the same attributes, operations, relationships, and semantics, collaboration diagrams contain objects and links between them. A collaboration diagram corresponds to a class diagram if the objects are instances of the classes, the links can be mapped to the associations, and the multiplicity requirements of the class diagram are satisfied. These diagrams are useful to represent the cooperation between objects and the state of a system at a special moment of time. A collaboration diagram associated with the class diagram, given in Figure 1 : p latfor m 1 s tation 4 : 3 : p latfor m 2 2 : tr ain a tr ain b Figure 4. Collaboration Diagram. 3, can be seen in Figure 4 [SB02]. In the diagram in Figure 4 there are five objects. The station, platform 1, platform 2, train a, and train b. The links and the messages sent between the objects can be seen, in conformance to the class diagram. The numbers in the diagram show in which sequence the messages are sent. 7

16 2.5 Statechart Diagrams In class diagrams the static behaviour of a system is modeled. The dynamic behaviour of a system can be modeled with statechart diagrams. A statechart diagram shows a state machine, emphasizing the flow of control from state to state. Generally, they can be associated with classes in order to describe the dynamic behaviour of the objects of the classes. Moreover, they can be related to use cases to model a scenario. Statechart diagrams consist of simple states and composite states and transitions, including events and actions. A state is an object state, which reflects a situation in the life of an object during which this object satisfies some condition, performs some action, or waits for some event. The transitions specify state changes and more specifically, they are viewed in UML as relationships between two states indicating that an object in the first state will enter the second state and perform given actions when an event occurs, provided certain conditions, i.e. guards, are satisfied. A simple statechart diagram [SB02] associated with the class PLATFORM in Figure 3 is given below in Figure 5. The operations of the class PLATFORM are given as transitions in the statechart diagram. Furthermore, one operation may correspond to several transitions in the statechart diagram. Initial c lo s e p latf o r m av ailab le c lo s e d o p e np latf o r m d e p ar tu r e o p e np latf o r m [ c ar d ( tr ains ) > 2 ] / tr ains : = { } o p e np latf o r m [ c ar d ( tr ains ) = 2 ] / tr ains : = { } ar r iv al ar r iv al o c c u p ie d ar r iv al c r as h e d arrival Figure 5. Statechart diagram. Let us consider the transition from state crashed to state available. In order for the transition openplatform to occur certain conditions have to hold, i.e., the number of trains to be equal to two, or bigger than two. Then the resulting state after the transition is either available or closed, respectively. In both cases the performed actions are the same, i.e. the value of the empty set is assigned to the variable trains. 8

17 3 The Action Systems Formalism In order to understand the B-action systems formalism, which is used in this Thesis to verify the development steps of the case study, a basic understanding of the action systems formalism is required. This formalism together with the B Method, described later, is the base of the B-action systems formalism. The action systems formalism is based on an extended version of Dijkstra s language of guarded commands [Dijkstra75]. This language consists of assignment, conditional choice, sequential composition, as well as iteration, and is defined using weakest precondition predicate transformers. A complete study on the action systems formalism can be found elsewhere [BaKu83, BS94]. 3.1 Actions An action A can be of the following form A : abort (abortion) skip (empty statement) v := e (deterministic assignment) v : v.( v R ) (nondeterministic assignment) {P} (assert statement) [P] (assumption) A 1 [] A 2 (nondeterministic choice) A 1 A 2 (sequential composition) where P and R are predicates and v is a variable or a list of variables [WS98, PS99]. A 1 and A 2 are actions. The weakest precondition for predicate transformers is applied in order to define the actions. The operators are defined below [WS98]. wp( abort, Q ) false wp( skip, Q ) Q wp( v : e, Q ) Q[v : e] wp(v : v.( v R ), Q) ( v R) ( v. v R. Q[v : v ]) wp( {P}, Q) P Q wp( [P], Q) P Q wp((a 1 [] A 2 ), Q) wp(a 1, Q) wp(a 2, Q) wp((a 1 A 2 ), Q) wp(a 1, wp(a 2, Q)) Actions are considered to be atomic, which means that only their input-output behaviour is of interest. Furthermore, it means that whenever an action is selected for execution it will be completed without interference. 3.2 Enabledness of actions The guard gda of an action A describes those states for which the action is enabled and is defined by [PS99] 9

18 gda = wp(a, false). The action A is enabled in a state, where the guard is true. Actions are in general guarded commands, i.e., statements of the form A = g S, where g is a boolean condition and S is a program statement. The guarded command g S is defined as follows using assumption: g S = [g]s Thus, the guard of A is g wp(s, false). Hence, a guarded command g S is only enabled when S is enabled and g holds. Furthermore, the nondeterministic choice A 1 [] A 2 is enabled when either A 1 or A 2 is enabled [WS98]: gd(a 1 [] A 2 ) = gd(a 1 ) gd(a 2 ) The body bd(a) of A is defined by bd(a) = gd(a) A [] gd(a) abort 3.3 Action Systems An action system is a set of actions operating on local and global variables and has the form: A = [ var z*, x z, x := z0, x0 do A 1 [] [] A n od ] : u The action system A contains the local variables x, the exported global variables z, marked with *, and the imported global variables u. The local variables x are visible only within A, in contrast to the exported global variables z which are visible to other action systems as well. The imported global variables, u, are referenced in the actions A 1,, A n, but they are not declared in A. The local and global variables are assumed to be distinct, meaning that no redeclaration of variables is permitted. The actions A i are allowed to refer to all the state variables of the action system A. If the action system A does not have any global variables, it is said to be a closed action system, otherwise, it is open. Moreover, each action can have local variables of its own. Also, an action is called local to an action system, if it only refers to local variables of that action system. 10

19 4 The B Method After the brief description of the action systems formalism, an overview of the B Method is given here. The B Method [Abrial96] is a formal approach to the specification and development of computer software systems. B takes into consideration advances in formal methods appeared during the last thirty years, including the Z notation, pre and post conditions, guarded commands [Dijkstra75], stepwise refinement, the refinement calculus [BaWright98], and data refinement [Schneider01]. A program development in the B Method consists of a specification, probably a number of refinements and an implementation. The specification is very abstract and involves a lot of non-determinism. The refinements transform stepwise the specification into an implementation. The implementation represents the final refinement and it is not allowed to contain any non-determinism. Within the B Method the specification, the refinements and the implementation have the form of abstract machines, which consist of global constraints and of operations on the state variables. The Abstract Machine Notation (AMN) is identical with the guarded command notation extended with precondition and unbounded choice. Every statement in AMN is a form of substitution [WS98]. It can be for example a skip-substitution, a simple substitution (x := e), a preconditioned substitution ( P S ), or a guarded substitution (SELECT P S ), where x is a variable, e is an expression, P is a predicate and S is a substitution. Every substitution S is defined as a predicate transformer, which transforms a postcondition Q into the weakest precondition for S to establish Q, wp(s, Q). The substitutions above are defined as follows: wp(skip, Q) = Q, wp(x:= e, Q) = Q[x := e], wp( P S, Q) = P wp(s, Q), and wp(select P S, Q) = P wp(s, Q). At this point the similarity between the B Method and the Action Systems formalism, described above, can be seen, i.e. the weakest preconditions are the same. The structure of the specification, the refinement and the implementation are described below. 4.1 Abstract Machine Specification The basic building block of a specification is the abstract machine. A specification describes what the component can do. The abstract machine contains information that describes various aspects of the specification, listing them under appropriate headings. The operations of a specification describe the functions/services that can be carried out by the component. The collection of operations is the interface by which the machine interacts with its environment. Moreover, it is important to note that a machine is a description of an object in the object-oriented sense. It has a name, some internal state, and a set of operations. The MACHINE clause provides the name of the machine, which is useful in order for other machines to be able to reference that machine. It is necessary that all machines in a 11

20 development have different names. A machine can have some parameters f for giving dimensional characteristics of the specification. These parameters are of type natural numbers or sets. The set of constraints F on the parameters f are given in the CONSTRAINTS clause. Moreover, constants c can be introduced in the CONSTANTS clause and the PROPERTIES clause gives the definition C of these constants c. An abstract machine has variables by which some local state information can be maintained. A variable may be of type NAT, which is the set of natural numbers, of type BOOL, as well as of type deferred set. All the variables are listed in the VARIABLES clause. Their types, as well as any other constraints, are given in the INVARIANT clause. The INVARIANT clause provides all the information about the variables of the machine. It has to give types of all the variables, and it can additionally give other restrictions on their possible values, and their relationships to each other. Furthermore, relationships among the variables and other parts of the system can be described in the invariant. The state of the variables can be changed by the machine, but the invariant describes properties of the variables, which must always hold. The INITIALISATION clause is used to describe the initial state of all the variables of the machine. All variables listed in the VARIABLES clause must be assigned some value. The possible initial states must be correct with respect to the invariant, in order for the INITIALISATION clause to be a consistent part of the specification. MACHINE Machine_name(f) CONSTRAINTS F CONSTANTS c PROPERTIES C VARIABLES x INVARIANT I INITIALISATION T OPERATIONS Operation_name = P S... Figure 6. The structure of an abstract machine specification. The OPERATIONS clause of the machine description consists of a list of operation definitions. A B description of an operation contains the information in a form which is 12

21 suited to structuring. The name, as well as input and output parameters of an operation are given by an operation header. outputs name(inputs) Where name is the name of the operation, outputs is a list of output parameters, and inputs is a list of input parameters. The variables are all formal parameters and they must be different. The structure of an abstract machine specification is shown in Figure 6 above. In order to prove that the machine Machine_name from the Figure 6 is consistent with its specification, a number of proof obligations are generated [WS98]: (C1) ( f. F) (C2) F ( c. C) (C3) (F C) ( x. I) (C4) (F C) wp(t, I) (C5) (F C I P) wp(s, I) The first three proof obligations are concerned with the consistency of the formal parameters, the constants and the variables. The obligation (C4) checks that the invariant is initially established and the condition (C5) checks that each operation preserves the invariant. 4.2 Machine Refinement and Implementation The B Method supports the notion of stepwise refinement, in which the design of the system implementation may be developed gradually. Specifically, a high level specification of a program may be transformed by a sequence of correctness preserving transformations into an executable program that satisfies the original specification [BS89]. A refinement in the B Method may either be a data refinement or an algorithmic refinement. The data refinement is achieved by changing the variables and the operations on them, while the algorithmic refinement permits the operations to change in order to make them more concrete without changing the state space. The structure of a machine refinement Refinement_name is shown in Figure 7 given below. It can be seen that a machine refinement and a machine specification have the same clauses, except that a machine refinement states in the REFINES clause which machine it refines. Also, the invariant R of the refinement gives the relation between the variables of the two machines in the data refinement. Hence, the invariant R in Figure 7 gives the relation between the abstract variables x in the machine specification Machine_name in Figure 6 and the concrete variables x in the machine refinement Refinement_name. Furthermore, the operations of the machine refinement refer only to the concrete variables x. The operation signatures in the abstract machine Machine_name and its refinement Refinement_name have to be identical, which means that the corresponding operations in Machine_name and Refinement_name must have the same names. If the operations have 13

22 parameters, these must be the same, too. Furthermore, all the operations that exist in the final refinement must exist in the specification with their body given as skip. REFINEMENT Refinement_name REFINES Machine_name VARIABLES x INVARIANT R INITIALISATION T OPERATIONS Operation_name = P S... Figure 7. The structure of a machine refinement. In order to prove that the machine refinement Refinement_name in Figure 7 is a refinement of the machine specification Machine_name in Figure 6, within the B Method, a number of proof obligations must be satisfied: (B1) (B2) (B3) (B4) ( (x, x ). I R), wp(t, wp(t, R)), ( (x, x ). (I R P) P ), and ( (x, x ). (I R P) wp(s, wp(s, R))). The proof obligation (B1) states that the invariant R of the refinement does not contradict the invariant I of the specification. Moreover, the proof obligation (B2) checks that the new initialization T establishes a situation where the previous initialization T cannot fail to establish the invariant R. Furthermore, the last two proof obligations ensure the correctness of each operation. The precondition P of the substitution S implies the precondition P of the substitution S when the invariants hold, i.e., the precondition is weakened in the refinement, (B3). Finally, a substitution S in the refined operation establishes a situation where the substitution S in the abstract operation cannot fail to maintain R, (B4). An implementation machine is the final refinement in a development within the B Method. The most important feature of an implementation is that the operations must not contain any nondeterministic substitutions. The notion of refinement between the machine implementation and another machine is the same as of refinement between the machine refinement and another machine, i.e., the proof obligations (B1) (B4). 14

23 4.3 Structuring Mechanisms in B It is valuable to structure large specifications in order to control complexity. The B Method provides structuring mechanisms [Schneider01], which enables machines to be expressed as combinations of simpler machines and allow distinct parts to be described and understood separately. Furthermore, the internal consistency conditions can be verified independently. Also, good structuring of a specification can reduce the proof effort by factoring the proof obligations into the appropriate components. Moreover, the machine state can be separated into different machines, which will be responsible for the operations on their own part of the state. The mechanisms that B provides are the INCLUDES, EXTS, USES, and SEES. The relationship between two machines, where M2 INCLUDES M1 is illustrated in Figure 8. MACHINE M2 SETS CONSTANTS VARIABLES PROPERTIES INVARIANT MACHINE M1 SETS CONSTANTS VARIABLES INVARIANT PROPERTIES read access promoted operation operation update access call access Figure 8. M2 includes M1 [Schneider01]. The machine M1 is considered to be part of the description of M2 and its state is part of the M2 state. The sets, constants and variables of M1 are visible to M2, and the invariant of M1 is implicitly included in the M2 invariant. Additionally, M1 s variables can be updated only via M1 s operations hence, M1 is responsible for preserving its own invariant. The M2 initialization initializes all its included machines and executes its own initialization. The machine M1 is not allowed to reference sets, constants, variables, and operations of M2, so it should be defined independently of the machine M2. The bodies of the M2 operations can contain calls to any operation of M1, and the syntax of an operation call is 15

24 x 1, x 2, op(e1, e2, ) where e1, e2, are value expressions, and x 1, x 2, are distinct variables standing for actual result parameters. A machine can call several operations of included machines in one step, as long as those operations are from different machines. Moreover, inclusion is transitive, but access to operations is not transitive. If all the operations of the included machine M1 are to be promoted to operations of M2, then M2 EXTS M1. Promoted operations change only the state of the included machine. The SEES and USES structuring mechanisms allow read-only access between machines. In this Thesis only the SEES mechanism of these two is used. A machine can be accessed by a number of other machines. In this case, it is useful when part of the state is expressed as a separate machine and other machines require knowledge of that part of the state. The SEES relationship of M2 sees M1 is illustrated in Figure 9. The machine M2 is provided read access to machine M1, which means that sets, constants, and variables of M1 are visible in M2. Furthermore, the invariant of M2 can refer to sets and constants of M1 but not to M1 variables. Because M1 is not under control of M2, M1 variables can be changed independently of M2. Only query operations can be called from M2, and this because query operations do not make any changes to the state of M1. The SEES relation, unlike INCLUDES, is not transitive. Moreover, if M2 sees M1, it also sees any machines that M1 includes. MACHINE M2 SETS CONSTANTS VARIABLES PROPERTIES INVARIANT MACHINE M1 query SETS CONSTANTS VARIABLES read access call access PROPERTIES INVARIANT Figure 9. M2 sees M1 [Schneider01]. 16

25 5 B-action Systems In order to be able to reason about distributed systems within the B Method, the B- action systems formalism is used. The B-action systems formalism has been used in this Thesis in order to verify the UML diagrams in each development step. In this formalism, a state-based view of action systems has been considered. Comprehensive study of this formalism can be found elsewhere [WS98]. In Figure 10 an action system is written as an abstract machine specification. Parallel and distributed systems can be modeled with the B-action systems formalism, where the operations are selected for execution in a nondeterministic manner. The form of the operations is Oper = SELECT P S, where P is a predicate on the variables (guard) and S is a substitution statement. When P holds the operation Oper is enabled. Only enabled operations are considered for execution and when there are no enabled operations the system terminates. The translation of the local variables x in the action system A to a variable of the machine specification ActionSystem is straightforward as can be seen in Figure 10. Moreover, each action in A is translated to an operation in the machine specification ActionSystem. In the A = [ var z*, x z, x := z0, x0 do [] ga 1 sa 1 [] ga 2 sa 2 [] ga 3 sa 3 od ] : u MACHINE ActionSystem INCLUDES Global_z, Global_u VARIABLES x INVARIANT I(x, z, u) INITIALISATION x:=x 0 OPERATIONS A 1 = SELECT ga 1 sa 1 A 2 = SELECT ga 2 sa 2 A 3 = SELECT ga 3 sa 3 Figure 10. An action system A and its embedding to a B machine [WS98]. B Method two machines are not allowed to update the same variable while the global variables of an action system may be referenced from other action systems. In B-action systems, the global variables, z and u, of A, are included as separate machines, Global_z and Global_u, respectively, in the machine ActionSystem. In the machine Global_z, in Figure 11, the exported global variable z is declared and given some properties J(z). Moreover, since a variable can only be updated in one machine, the variable z is assigned via the operation assign_z(v) in Global_z, where the value v is given as a parameter. The assignments to z in an action A i of the action system A, are then replaced by calls to assign_z in the corresponding operations in the machine specification ActionSystem. Thus, more than one abstract machine can assign the same global variables via the calls to the corresponding operations. 17

26 MACHINE Global_z VARIABLES z INVARIANT J(z) INITIALISATION z:=z 0 OPERATIONS assign_z(v) = J(v) z:=v Figure 11. Declaration of a global variable z in B [WS98]. 5.1 Procedures in B-action systems Procedures can be declared in a B-action system, too. These procedures can be local or exported [WS97]. The local procedures are declared and referenced within the same system, while the exported procedures may be referenced by other B-action system. An exported procedure of one system is an imported one of another system. Let us consider the exported procedure Exp_P declared in the machine B and called from the machine A shown below in Figure 12. MACHINE A INCLUDES B VARIABLES x INVARIANT I(z) INITIALISATION x:=x0 OPERATIONS A 1 = SELECT Q 1 T1 Exp_P MACHINE B VARIABLES y INVARIANT J(y) INITIALISATION y:=y0 OPERATIONS Exp_P = SELECT G Z Figure 12. Procedures in B-action systems. The B Method requires the calling operation and the procedure to be in separate machines. When the operation A 1 calls the procedure Exp_P, A 1 is enabled only if the procedure Exp_P is also enabled, i.e., Q 1 G holds. The procedure Exp_P and the operation A 1 are executed as a single atomic entity. Detailed studying on the procedures can be found elsewhere [WS97]. 18

27 5.2 Refinement of B-action Systems The refined B-action system is shown in Figure 13. As it can be seen, the structure of the B-action system machine refinement is similar to the B Method refinement. The machine refinement RefActionSystem refines the machine specification ActionSystem. REFINEMENT RefActionSystem REFINES ActionSystem INCLUDES Global_z, Global_u VARIABLES x, y INVARIANT R(x, y, z, u) INITIALISATION x, y:=x 0, y 0 OPERATIONS A 1 = SELECT ga 1 sa 1 A 2 = SELECT ga 2 sa 2 A 3 = SELECT ga 3 sa 3 B 1 = SELECT gb 1 sb 1 B 2 = SELECT gb 2 sb 2 Figure 13. The refined B-action system [WS98, PTWBEJ01]. The variables, the invariant and the actions of this B-action system form an abstract machine. The operations of the machine refinement refer only to the concrete variables x, as mentioned in section 4.2. Moreover, the operations B 1 and B 2 are given as B 1 = skip and B 2 = skip, respectively, in the machine specification ActionSystem. In order to prove that the machine refinement RefActionSystem in Figure 13 is a refinement of the machine specification ActionSystem in Figure 10, within the B-action systems, a number of proof obligations must be satisfied [PTWBEJ01]: 1. The initialization in RefActionSystem should be a refinement of the initialization in ActionSystem, and the initialization should establish the invariant R. 2. The operations A 1, A 2 and A 3 in RefActionSystem should refine the corresponding operations in ActionSystem, and they should preserve the invariant R. 3. The new operations B 1 and B 2 in RefActionSystem should only take into account the new variable y, and preserve the invariant R. 19

28 4. The new operations B 1 and B 2 in RefActionSystem should terminate, if they are executed in isolation. 5. Whenever an operation A i (i=1,2,3) in ActionSystem is enabled, the corresponding operation in RefActionSystem is enabled or, otherwise, one of the new operations B j (j=1,2) in RefActionSystem is enabled. 6. Whenever a fault-operation in ActionSystem is enabled, a fault-operation could also be enabled in RefActionSystem. Fault-operations in (6.) are the ones leading to a suspension state. A general faultoperation in ActionSystem is partitioned in specific faults during the refinement process. Assuming that there are the abstract system ActionSystem with a global procedure Proc and a refined system RefActionSystem with the refined procedure Proc. Then, in order for RefActionSystem to be a refinement of ActionSystem, two more proof obligations should hold: 7. The procedure Proc in ActionSystem should be refined by the corresponding procedure Proc in RefActionSystem and Proc should also preserve the invariant. 8. If the procedure Proc is enabled, the procedure Proc should be enabled, too, or then the operations in RefActionSystem should enable Proc. The proof obligations (3.), (4.), (5.), (6.) and (8.) are additional to the proof obligations generated for a refinement in the B Method, described in section 4.2. These proof obligations are important in order to be able to reason about distributed systems within the B Method. 20

29 6 Tool support In order to have confidence in the correctness proof of stepwise refinement step, use of a mechanical tool is inevitable. In this section an overview of the refinement tools that have been considered for this task is given, as well as the U2B (UML to B Method) translation tool and the UML tool. The derivation of correct programs from specification involves generating proof obligations that need to be checked. These proof obligations were described earlier. A refinement tool assists the user by generating and proving these proof obligations mechanically, sometimes automatically and sometimes interactively. The automatic generation of proof obligations has been considered for the case study in this Thesis. 6.1 Rational Rose Enterprise Edition Tool The Rational Rose Enterprise Edition tool has been used to design the UML diagrams for the case study presented in this Thesis. Detailed presentation of its features can be found elsewhere [Rational03]. Here, only some major features of this tool are presented that were needed for producing correct B-action systems. The structure of a Rational Rose window can be seen in Figure 14, given below. The class diagram of a train station example, which was given in section 2.3, is shown in this window, as well as all the features that can be selected and added into this diagram. Moreover, the operation specification window of the operation train_arrives of the class STATION is shown. This window appears when right clicking an operation of the class specification window. Important features of Rational Rose for the case study development of this Thesis are: Buttons in the operation specification window, of a class diagram, allow the user to input preconditions, semantics, postconditions, as well as parameters for the operation. When the General button, of the operation specification window, is active, it allows the programmer to write documentation for the operation, which is something very important when developing software systems. Return types and stereotypes can be input for each operation when the Detail button is active. Statechart diagrams can be attached to classes to model the dynamic behaviour of them. 21

30 Figure 14. Rational Rose Window. 6.2 U2B Tool The U2B tool [SB03] translates classes of class diagrams in UML to B machines. The important features for the U2B translation are: The class diagram defines the structure of B machines, the relationships to other classes, the attributes and the operations of each class. Further textual information in an adapted B form in the specifications of classes and operations defines the invariant, the initialization and operation semantics for the B machines. 22

31 The differences from normal B notation are that instance referencing can be used in an object-oriented style and reference to the current instance can be assumed implicit. The operations of the classes may be specified in statechart diagrams that are attached to these classes. The attributes and unidirectional associations are translated to variables with type defined as a function from the current instances to the attribute type or associated class. If the multiplicity of a class is set to 1..1 in the UML class specification, the attributes are translated to variables with the type given at declaration time. Let us consider the class diagram given above in Figure 14. The translated B machine for the class STATION is given below in Figure 15. In order to translate the class diagram, MACHINE STATION EXTS PLATFORM_CLASS SETS MSG={in_station,waiting} VARIABLES queue, platforms INVARIANT queue : seq(train) & platforms : POW(PLATFORM) & ran(queue)/\union(pp).(pp:platforms trains(pp)) = {} & size(queue)=card(ran(queue)) INITIALISATION queue := <> platforms := {} OPERATIONS outcome <-- train_arrives (tt) = tt:train & tt/: ran(queue) & tt/: UNION(pp).(pp:platforms trains(pp)) IF #(qq).(qq:platforms & platform_state(qq)=available) ANY pp WHERE pp:platforms & platform_state(pp)=available arrival(pp,tt) outcome:=in_station ELSE queue:=queue^[tt] outcome:=waiting.. Figure 15. U2B Translation for the class STATION of Figure

32 the user has to choose the option Export Class Diagram to B from the File menu of the Rational Rose environment. U2B uses mathematical categorizations of functions such as partial, total, injective, surjective, and range constraints to model the UML multiplicity constraints. The attribute types can be any valid B variable type. Definitions of type sets and constants for use in many machines can be included in class utilities which are classes that do not have any instances. Sets and constants can also be defined locally to a class s specification window in the documentation box. Moreover, any valid B clause can be added in this documentation box. Specific features of U2B that are used in the case study of this Thesis will be explained later during the development process. 6.3 Tools supporting the B Method In this Thesis the Atelier B [AtelierB03] mechanical tool has been used to verify the development steps. This tool consists of a set of functionalities: a type checker and a syntax analyzer, as well as an automatic and an interactive prover. Facilities such as C- code generation and documentation are incorporated into this tool, too. During a program development the tool is supplied with the abstract machine specification and refinements of this specification. The tool first checks the syntax and the types of the machines. Then, it automatically generates the proof obligations needed for proving the consistency of the specification and the correctness of the refinement steps. The proof obligations can be automatically or interactively proved using the corresponding provers. The provers are based on a mathematical library consisting of a collection of mathematical laws for the underlying set theory. The automatic prover tries to prove these proof obligations using this library. If this library is not enough, the user may apply new rules and with the help of the interactive prover discharge the rest of the proof obligations. 24

33 7 Modeling Control Systems The control system, which is developed as the case study of this thesis, is a kind of closed-loop control system [SG96]. It is so called, because the properties of the outputs of the process that have to be maintained by the control system are monitored. A closedloop control system with feedback is given below in Figure 16. The controlled variable Input variables Set point Controller s to manipulated variables Process Controlled variable Figure 16. Feedback Control [SG96] is the process variable whose value the system is intended to control. The input variables are the process variables that measure inputs to the process. A manipulated variable is a process variable whose value can be changed by the controller. The set points are given reference values. In this thesis, the structure of the control system is of the form given below in Figure 17. It consists of four entities. These entities are the controller, the sensors, the actuators and a plant [BSS96, LL95, PQS99, PRTWJ01]. They interact with each other in order for the control system to obtain the desired functionality. The plant in a control system describes the autonomous behaviour of the system. The task of the controller in a control system is to ensure that the plant operates within the predefined requirements. Hence, the controller reacts to changes in the plant. Plant Variables Controller Variables Plant operations Sensors Controller operations Plant Actuators Controller Figure 17. The structure of the control system specification 25

34 The feedback control system of Figure 16 corresponds to Figure 17 by mapping the Process to the Plant, the manipulated variables to the Actuators, the feedback to the controller from the controlled variable to the Sensors and the Controller of one system to the Controller of the other. 7.1 Determining the controller and the plant When all the details have been added to the system the development proceeds by decomposing the component specification into controller and plant specification pair, meaning that for a component both a controller and a plant specification is obtained. In B-action systems, the plant machine contains the transitions to the new states, but in order for the transition to take place, a controller procedure is called for handling the required decisions. The procedure is modeled as skip if the controller machine needs not to intervene. To obtain such decomposition, the operations of the machines have to be split and the variables are partitioned between the controller and the plant machines. Each operation of the form: Operation = SELECT state = act1 A B state := act2 is replaced with the operation in the plant: Operation = SELECT state = act1 A Act2, where the procedure Act2 of the controller is Act2 = state = act1 A B state = act2. It can be seen that the effect of the new operation Operation is the same as the effect of the old operation Operation. Adding procedures while keeping the old functionality agrees with the refinement rules in B-action systems. 7.2 Determining sensors and actuators In the last development step, the sensors and the actuators for the component, from the controller and plant specification, are determined. The sensor variables are set by the plant and read by the controller. Because of this, the sensors are modeled as a separate machine, which is included by the plant and seen by the controller. Accordingly, the actuators are modeled as a separate machine, which is included by the controller and seen by the plant. The invariant of the plant relates the state variable of the whole control system to the plant and the controller state variable, as well as to the sensor and to the actuator variables. The general decomposition schema can be seen in the Figure 18. The plant and the controller are represented as B-action systems with local variables and actions, and local variables and procedures, respectively. The actuators and the sensors become global variables to the plant and controller, respectively, and are put in separate machines. 26

35 Detailed studying of this decomposition process can be found elsewhere [Sekerinski99, PRTWJ01]. Figure 18 illustrates the decomposition process described above. REFINEMENT MachinePlant REFINES Machine INCLUDES MachineCtrl, MachineSensors VARIABLES plant state INVARIANT variable types refinement invariant for plant variables, controller variables, actuators, sensors INITIALISATION Plant state and sensors initialization OPERATIONS Operation_name = SELECT refined guard Plant state and sensors change OperCtrl ( parameters ) MACHINE MachineCtrl INCLUDES MachineActuators SEES MachineSensors VARIABLES controller state INVARIANT variable types INITIALISATION controller state and actuators initialization OPERATIONS OperCtrl ( parameters ) = state controller state and actuators change MACHINE MachineSensors VARIABLES sensors INVARIANT variable types INITIALISATION sensors : any value OPERATIONS SetSensor ( ss ) = sensor := ss MACHINE MachineActuators VARIABLES actuators INVARIANT variable types INITIALISATION actuators : any value OPERATIONS SetActuator ( aa ) = actuator := aa Figure 18. General decomposition schema [Sekerinski99]. 27

36 8 Presentation of the Wallac case study PerkinElmer Life Sciences designs, manufactures, develops, and markets analytical systems for use in drug discovery, research, mass population screening, and other bioresearch and clinical diagnostics areas. PerkinElmer Life Sciences [PerkinElmer03] was formed from the international Wallac group, and is today a worldwide organization with about one thousand employees. The company supplies complete analytical systems, which are used to provide researchers and clinicians with reliable processing of difficult to measure substances found in blood or other biological sample materials. The manufactured analytical systems include reagents, sample handling and measuring instrumentation, as well as computer software. Figure 19. The Fillwell workstation [Fillwell02]. The system being developed in this Thesis, is part of the Fillwell workstation that can be seen in Figure 19 above. The system belongs to the class of products for drug discovery and bioresearch. The Fillwell base unit consists of a Dispense Head, which dispenses liquid into microplates on an Operating Table, as well as on a Rotary Table being attached to the Operating Table as it is shown from the Figure 19 above. Moreover, there are four Stackers above the Rotary Table. The Fillwell workstation was the first liquid handling system designed for high density microplates. The Operating Table contains 3 plate positions. The Rotary Table consists of 6 plate positions. The gantry can move in XYZ-directions in order for the Dispensing Head to be able to reach all the positions on the Operating Table and the processing position on the Rotary Table. The gantry has a very high precision with an accuracy of 100 µm. 28

37 8.1 The requirements of the case study The Fillwell workstation consists of several interacting parts. The parts considered for this case study are the Rotary Table and the four Stackers. The task of every stacker is to destack, which means to place a plate to be analysed on the Rotary Table, and to stack, which means to remove/take off an analysed plate from the Rotary Table. Every stacker has a maximum capacity of twenty plates. The stackers have, also, arms in order to be able to hold and stack or destack the plates. The Rotary Table has six positions. In every position there is always a plate holder. The processing position of the Rotary Table is the position 1 and above the positions 2, 3, 5, and 6 there are the Stackers. The interfacing of the Rotary Table with the Stackers and the Dispensing Head can be seen in Figure 19 above. The top view of the Rotary Table itself is given below in Figure 20. pos 4 Plateholder pos 3 pos 5 pos 2 pos 6 pos 1 Figure 20. Top view of the Rotary Table. Initially there is not any plate on the Rotary Table and some stackers can be full while others can be empty. Due to the fact that the Rotary Table, the Stackers and the Dispensing Head may collide the following safety requirements are defined: When a Stacker is ready to destack a plate to the Rotary Table, the arms, holding a plate, may extend only if there is not a plate in the corresponding position of the Rotary Table. When a Stacker is ready to stack a plate from the Rotary Table, the arms may extend only if there is a plate in the corresponding position of the Rotary Table. The Rotary Table may rotate only when the arms of all the Stackers are retracted, and the Dispensing Head is not processing at position 1 of the Rotary Table. During a typical course of events the following sequence of actions occurs with a plate. The possible failures have not considered here. 1. A Stacker destacks a plate to the Rotary Table (destack). 29

38 2. The Rotary Table rotates the plate to the processing position 1 (rotate(steps)). 3. The Dispensing Head processes the plate. 4. The Rotary Table rotates the processed plate under a stacker (rotate(steps)). 5. A Stacker stacks the processed plate (stack). It can be mentioned that other courses of events are possible depending on how many stackers are working and in which order the commands rotate, destack and stack are given. 8.2 The integrated development process proposed for the case study The main idea of the whole development process is based on applying both safety analysis and B reasoning for correctness to an already constructed UML specification of the eventual control system. Usually such a specification is not obvious, nor straightforward to obtain for a complex final system, given only the initial requirements. A scalable approach is required for producing the first specification of the system. This first specification is very important to the whole development of a system, because introduced errors at this step may propagate along to the next more concrete steps of the development. The initial specification should ensure safety and its consistency must be proved. Details are added to the initial specification by introducing functionality details in a stepwise manner. The correctness of the refined UML diagrams, of the initial specification, into a specification taking into account these details is proved using the B- action systems. In every refinement step, the safety properties of the system are conserved. The goal for the operator and user of the whole system in this case study is careful functional and safety analysis for producing the eventual software. A combination of UML, formal methods and safety analysis for checking the quality of the eventual software and for producing this software is applied. As a result, this process consists of three main phases. First, a system specification is developed from the initial informal requirements. Second, when the consistency of this specification has been proved with these requirements, the specification is stepwise refined into a concrete, more detailed system. Third, when all the details have been introduced, the system is decomposed to a control system consisting of a plant, a controller, sensors and actuators. Safety and reliability considerations are taken into account for the entire process. 8.3 Safety aspects of the development The system being developed in this Thesis is safety critical. Thus, the development process should ensure safety and reliability of the system by incorporating safety analysis. Moreover, it should be ensured that the controlling software reacts in time on hazardous situations by trying to force the system back to a safe state. This can be achieved only if the information provided by the safety analysis is taken into account in the whole software development process. 30

39 In [PTWBEJ01] an approach for conducting software development in parallel with safety analysis was developed. This approach is presented in Figure 19. It was observed that both safety analysis and the stepwise program development conduct reasoning from an abstract to a concrete level. Hazards that are potentially dangerous are identified by safety analysis and then detailed descriptions of them are produced, together with finding the means to cope with these hazards. The development process starts by producing an abstract specification describing in general the services of the system without incorporating any details. In every refinement step more implementation details are added to the abstract specification, so that a program has been constructed at the end. As a result, the information that becomes available at every stage of the safety process, by performing corresponding refinements of the initial specification, can be incorporated to the development process. Therefore, during the system development the safety analysis will be composed into the UML development as will be seen in the following sections. Safety analysis Functional requirements Safety requirements Abstract specification Elaborated safety analysis Elaborated safety requirements Refined specification Safety analysis of implementation Implementation Elaborated safety requiremen Figure 21. Safety analysis and stepwise system development [PTWBEJ01]. 31

40 8.4 Presence of failures A control system consisting of a controller managing a plant is usually a safety-critical system. In order to build a controller able to handle components failures the following actions are required [PTWBEJ01]: to understand the nature of faults and their impact on the system, to decide on the detection procedures, repair procedures, functioning of the system when a failure occurs, to introduce effective maintenance procedure. In order to incorporate the results of safety analysis in the refinement process the following methodological aspects should be addressed [PTWBEJ01]: Modeling fault occurrence and detection Modeling system behaviour and synchronization when faults occur Modeling different operating modes and transition between them including the system failure Design and specification of a maintenance procedure Specification of the execution log. These actions of handling failures are taken into account in the UML and B-action systems development described in the following sections. 32

41 9 UML-development incorporating safety aspects The starting point of a system development is an informal specification describing the services required from the final product. Hints about the software and hardware parts may be considered in later steps. In this thesis, that is considered the most general starting point for the development process of a control system. The functional requirements of the case study are depicted in use case diagrams. Each use case is a service that the system will eventually provide to a user. The simplified operations form the protocol of the devices. There are three devices interacting with each other in this case study, but only two of them, the stacker unit and the Rotary Table, are developed within this case study. A typical protocol of a Stacker from the stacker unit can be as follows: 1. Destack a plate to the Rotary Table 2. Stack a plate from the Rotary Table A typical protocol for the rotary table can be: 1. Rotate clockwise or counterclockwise Thus the functional requirements of the Stackers are to destack and stack plates, while the functional requirement of the Rotary Table is only to rotate clockwise or counterclockwise. A use case diagram of a Stacker is given in Figure 22. Destack plate Actor Stack plate Figure 22. Use case diagram for the Stacker. A use case diagram for the Rotary Table is given in Figure

42 Rotate Actor Figure 23. Use case diagram for the Rotary Table. The Rotary Table and the Stackers interact by the Stackers stacking a plate from the Rotary Table or destacking a plate to the Rotary Table. The Stackers are the active partners while the Rotary Table is the passive partner during the interaction. In addition to the functional services, the reliability and safety issues related to these functional services are captured at a reasonable level of detail. These issues are captured in the specification of the use cases, expressed as structured English text. The basic functions for the eventual software of this case study are, to capture the protocol information when entered, to communicate the protocol information with the mechanical parts and to inform about failures and the failure points. 9.1 Use cases incorporating the possible failures Two use cases, stack and destack, have been identified for the Stackers, and one use case, rotate, has been identified for the Rotary Table as shown in Figures 22 and 23, respectively. These use cases are considered as subroutines, because it is more convenient with subroutines for the purpose of safety and reliability analysis [PTWBEJ01]. Subroutine Stack captures a Stacker stacking a plate from the Rotary Table. Typical course of events: 1. Stacker receives command stack a plate from plateholder at position ph_pos from protocol. 2. System checks if ph_pos is a valid plateholder position, i.e. 2, 3, 5, or 6 position on Rotary Table if not, then SF1. 3. System checks if there is plate on the plateholder at ph_pos if not, then SF2. 4. System checks if the Stacker is full if yes, then SF3. 5. Stacker stacks the plate from the plateholder at position ph_pos. 6. System checks if the plate has been stacked into the Stacker, i.e. there is no plate on the plateholder at ph_pos if the plate is still on the plateholder, then SF4. 7. Signal stack_ok. Failure reports: SF1. ph_pos is outside the valid plateholder position range. Remedy: User changes ph_pos, identifies the cause and resumes or aborts calling protocol execution. SF2. There is no plate on the plateholder to be stacked. 34

43 Remedy: Wait a while for the plate to become available. User places a plate manually on the plateholder and resumes or aborts calling protocol execution. SF3. Stacker is full. Remedy: User unloads the stacker and resumes or aborts calling protocol execution. SF4. Stacker has not stacked the plate. Remedy: User identifies the cause and resumes or aborts calling protocol execution. Subroutine Destack captures a Stacker destacking a plate onto the Rotary Table. Typical course of events: 1. Stacker receives command destack a plate onto plateholder at position ph_pos from protocol. 2. System checks if ph_pos is a valid plateholder position, i.e. 2, 3, 5, or 6 position on Rotary Table if not, then DF1. 3. System checks if there is not a plate on the plateholder at ph_pos if there is plate on the plateholder, then DF2. 4. System checks if the stacker is empty if yes, then DF3. 5. Stacker destacks a plate onto the plateholder at position ph_pos. 6. System checks if there is plate on the plateholder at ph_pos if not, then DF4. 7. Signal destack_ok. Failure reports: DF1. ph_pos is outside the valid plateholder position range. Remedy: User changes ph_pos, identifies the cause and resumes or aborts calling protocol execution. DF2. There is plate on the plateholder. Remedy: User takes the plate manually from the plateholder and resumes or aborts calling protocol execution. DF3. Stacker is empty. Remedy: User loads the Stacker and resumes or aborts calling protocol execution. DF4. Stacker has not destacked the plate. Remedy: User identifies the cause and resumes or aborts calling protocol execution. Subroutine Rotate captures the clockwise or counterclockwise rotation of the Rotary Table. Typical course of events: 1. Rotary Table receives command rotate p_steps steps from protocol. 2. System checks if p_steps is inside the valid range, i.e. from 5 to +5 steps if not, then RoF1. 3. System checks if it is safe to rotate if not, then RoF2. 4. Rotary Table rotates p_steps. 35

44 5. System checks if the rotation was successful if not, then RoF3. 6. Signal rotate_ok. Failure reports: RoF1. Input parameter p_steps is outside the valid range (-5..5) Remedy: User changes parameter p_steps, identifies the cause and resumes or aborts calling protocol execution. RoF2. Dispensing Head or Stackers are not safe. Remedy: Wait a while for the Dispensing Head or Stackers to become safe. User resumes or aborts calling protocol execution. RoF3. Rotary Table has not rotated p_steps steps. Remedy: Calibrate and resume or abort calling protocol execution. Failures: From the alternative courses of events defined above, the following failures can be derived for the system: a) Stacker stack failure b) Stacker destack failure c) No plate present d) Plate already present e) Stacker empty f) Stacker full g) Rotary Table rotate failure h) Not safe Having specified in a detailed manner the use cases given above, the next step is to determine the logically related use cases, and group them together. Each group of related use cases defines a component of a control system. 9.2 Component-oriented development The component oriented development is very useful when developing control systems, because it consists of reusing existing components, developing new ones and constructing new systems from them. The computation can already be distributed in this early development stage, supporting well reuse and scalability. From the use case diagrams in Figures 22 and 23 an associated component diagram can be constructed, which is given below in Figure 24. The Stackers interact with the Rotary Table by their provided services, which are stacking or destacking a plate, while the provided service of the Rotary Table is to rotate. 36

45 Destack plate Rotate Stacker Rotary table Stack plate Figure 24. A component diagram for the Rotary Table and a Stacker. 9.3 Class diagram of the specification At this level, each conceptual component can be shown as an active class in a class diagram. The class diagram of the system s specification model is given below in Figure 25. This diagram specifies the static view of the system. Statechart diagrams, which are attached to the classes of this diagram, specify the autonomous behaviour of the classes. For the specification model only the command variables, rcmd and scmd, of the Rotary Table and the Stacker, respectively, as well as the state variables are of interest. The state variables are not declared in the classes because U2B generates them automatically by checking the attached statechart diagrams. The arrows, in Figure 25, are pointing to the main operations/services of the classes, which capture the functional requirements of the system. Furthermore, the multiplicity of the ROTARY_TABLE class is set to one, because there is only one Rotary Table, and the multiplicity of the STACKER class is set to four, because there are four instances of a Stacker. The rest of the operations capture the correct commands given to the system and the safety requirements in an abstract way. 37

46 STACKER scmd : SCOMMAND ROTARY_TABLE rcmd : TCOMMAND RotateCommand(p_steps : INT) Rotate() RotateFail() RotateCommandRemedy() PreRotateNoRemedy() RotateOk() RotateNotOk() RotateRemedy() RotateNoRemedy() ServiceNotReady() Remedy() NoRemedy() DestackCommand() Destack() DestackFail() DestackCommandRemedy() PrepDestackNoRemedy() DestackOk() DestackNotOk() DestackRemedy() DestackNoRemedy() StackCommand() Stack() StackFail() StackCommandRemedy() PrepStackNoRemedy() StackOk() StackNotOk() StackRemedy() StackNoRemedy() ServiceNotReady() Remedy() NoRemedy() Figure 25. Specification Class Diagram for Rotary Table and Stacker 9.4 Collaboration diagram of the Stackers and the Rotary Table A collaboration diagram of the Stacker unit and the Rotary Table is given below in Figure 26. This diagram shows the four Stacker objects and the cooperation between them and the Rotary Table object. Moreover, the links between them can be seen, as well as the messages sent from one object to another. It can be seen as Stacker4 sends a message to Rotary Table informing that it is destacking a plate and the Rotary Table sends a message to Stacker1 to stack a plate from it. The third message in the sequence is from Stacker4 to Stacker3 saying to wait and then Stacker3 sends a message (4) to Rotary Table in order to inform Stacker2 (message 5) that it has to wait for a plate. Stacker1 Stacker2 5 : 2 : R o tary T ab le 4: Stacker 3 1 : Stac ker4 3 : Figure 26. Collaboration Diagram for the Stackers and the Rotary Table 38

47 This diagram corresponds to the class diagram of Figure 25 because it satisfies the multiplicities of the classes. Moreover, it is useful to the developer because it helps to understand better the cooperation between the objects of the system at a specific time. This kind of diagram is not further developed in this Thesis because they are not taken into account from U2B for the refinement steps. 9.5 Statechart Diagrams of the specification The classes of the system consist of attributes and methods and the autonomous behaviour is specified using statechart diagrams. For each service of the system a statechart diagram is developed The Rotary Table The first abstract statechart diagram for the Rotary Table is shown in Figure 27. RotateRemedy[ rcmd=rot_cmd ] RotateOk[ rcmd=rot_cmd ] rotate rot_suspended RotateNotOk[ rcmd = rot_cmd ] Rotate[ rcmd=rot_cmd ] RotateNoRemedy start RotateCommand / rcmd:=rot_cmd RotateFail[ rcmd=rot_cmd ] idle get_ready pre_rot_suspended abort stop Remedy PreRotateNoRemedy stop RotateCommandRemedy[ rcmd=rot_cmd ] ServiceNotReady suspended NoRemedy Figure 27. Specification Statechart Diagram for the Rotary Table. The service in this statechart diagram is derived from the service in the use case diagram. The service providing state rotate, together with the states idle, get_ready, pre_rot_suspended, suspended and abort, form the states in this abstract statechart diagram. The component evolves from a state idle to a state get_ready, and at the same time the corresponding rotate command, rot_cmd, is being assigned to the attribute rcmd which models the command of the Rotary Table. If an exception occurs, such as, the 39

48 service is not ready, the component evolves from the state idle to the state suspended, wherefrom, if a remedy is found, the component resumes to state idle. From the state get_ready, the component evolves to the state rotate performing the required service, provided certain conditions are satisfied. The certain condition at this stage is only that the attribute rcmd must be equal to rotate command rot_cmd. On the presence of an exception, the behaviour of the component is suspended and it evolves to the state pre_rot_suspended. If a remedy of this exception is found, the component can resume and go back to the state get_ready, where it can continue until the required service has been performed. Otherwise, the exception is a failure and the component aborts its execution. If the rotate service is successfully performed the component returns to its state idle. An exception of this service suspends the behaviour of the component, which evolves to the state rot_suspended. If a remedy occurs, the component can resume its service providing state. Otherwise, the component aborts its execution. The only reason that more than one suspended state are in the diagram, is to guarantee that the evolving of the component s behaviour continues from the state prior to suspension The Stacker The first abstract statechart diagram of a Stacker for the stack service is shown in Figure 28. For each of the two services of a Stacker, a statechart diagram is derived. This serves for simplicity reasons. The service providing state stack, together with the states idle, prepare, prep_sk_suspended, suspended and abort, form the states in this abstract statechart diagram, in a similar way as in the abstract statechart diagram of the Rotary Table. An instance of the Stacker component evolves from a state idle to a state prepare, NoRemedy StackNotOk[ scmd=sk_cmd ] suspended StackOk[ scmd=sk_cmd ] stack st_suspended Remedy ServiceNotReady StackCommand / scmd:=sk_cmd Stack[ scmd=sk_cmd ] StackFail[ scmd=sk_cmd ] StackRemedy[ scmd=sk_cmd ] StackNoRemedy PrepStackNoRemedy idle prepare prep_sk_susp ended abort start stop StackCommandRemedy[ scmd=sk_cmd ] Figure 28. Specification Statechart Diagram of a Stacker for the stack service. 40

49 and at the same time the corresponding stack command, sk_cmd, is being assigned to the attribute scmd modeling the command of a Stacker. In relevance to the Rotary Table, if an exception occurs, such as, the service is not ready, the Stacker evolves from the state idle to the state suspended, wherefrom, if a remedy is found, the component resumes to state idle. Otherwise, if there is no remedy, the Stacker aborts its execution. From the state prepare, the Stacker evolves to the state stack performing the required service, provided certain conditions are satisfied. The certain condition is only that the attribute scmd must be equal to the stack command sk_cmd. On the presence of an exception, the behaviour of the Stacker is suspended and it evolves to the state prep_sk_suspended. If a remedy of this exception is found, the component can resume and go back to the state prepare, where it can continue until the required service has been performed. Otherwise, the exception is a failure and the Stacker aborts its execution. If the stack service is completed successfully, the component returns to its state idle. An exception of this service suspends the behaviour of the component, which evolves to the state st_suspended. If a remedy occurs, the object can resume its service providing state. If not, the exception is a failure and the Stacker aborts. The corresponding abstract statechart diagram of a Stacker modeling the destack service can be found in Appendix A. 9.6 U2B translation to B-action systems and formal specification of the system At this point, the specification class and statechart diagrams can be translated to B- action systems, using the U2B tool, in order to be able to verify them with the Atelier B tool. U2B checks the multiplicities of the ROTARY_TABLE and the STACKER classes, in order to create instances of the classes if it is required. The ROTARY_TABLE class multiplicity is set to one, because there is only one instance of the Rotary Table. The multiplicity of the STACKER class is set to four, because there are four instances of the Stacker unit. U2B checks the multiplicity of the STACKER class, as mentioned above, and generates a constant STACKER, putting it in the STACKER_CLASS machine, with properties 1..4 meaning that there are four Stacker instances. Furthermore, U2B checks the attached statechart diagrams of the classes and translates automatically the set of states and the state variable, for which the name is the name of the state machine in UML. Moreover, the sets of possible commands of the Rotary Table and the Stacker are given in the machine def.mch in Appendix B.3. The translated specification machines for the Rotary Table and the Stacker unit can be found in Appendices B.1 and B.2, respectively. In Figure 29, below, the Rational Rose window of the Stacker class diagram is given. The SEES and INVARIANT B clauses can be seen in the documentation box of the class specification window. U2B adds in the invariant of the machine the attributes and their types. For the case of the STACKER class, U2B translates its attributes as functions in the B Method, with source set the STACKER constant, and target set the type of the variable given in the class. For example, the command attribute scmd, which can be assigned some value from the set SCOMMAND, consisting of the stack command, sk_cmd, and the destack command, dsk_cmd, is of type: scmd : STACKER SCOMMAND 41

50 in the abstract machine specification. This means that every instance of the Stacker has a command variable, scmd, which can be assigned the value stack command, sk_cmd, or destack command, dsk_cmd. Figure 29. Class Diagram of the Stacker. 42

51 The state variable is automatically initialized by U2B, which checks the starting point in the statechart diagrams. The start point in these diagrams is the black circle and the stop point is the black circle inside a white circle. The rest of the variables are initialized in the class diagram. U2B initializes automatically in a non-deterministic way variables that are not assigned any initial value. The event triggering state transitions correspond to operation names in the classes, as it can be seen from the class and statechart diagrams given above. If an event triggering state transition does not correspond to an operation name of the class, the body of this class operation is given as skip. The event transitions and the operation names in the classes correspond to operation names in the abstract machine specification. Lets consider the event transition StackCommand from Figure 28. The translated abstract machine operation is: StackCommand(thisSTACKER) = thisstacker : STACKER SELECT s_state(thisstacker) = idle s_state(thisstacker) := prepare scmd(thisstacker) := sk_cmd U2B parameterizes the operation with a parameter thisstacker of type STACKER. The initial state of the transition for thisstacker instance is given as SELECT guard, and the state as well as command variables are assigned the values prepare and sk_cmd, respectively. At implementation time the specific instance of the Stacker can be supplied to the machine operations, i.e. Stacker 1, 2, 3, or Formal specifications and safety analysis The initial specification of the system is abstract, because it just models transitions between states. Nevertheless, already in the initial specification a possibility of fault occurrence and system failure is preserved [PTWBEJ01]. Actions such as RotateFail model failure of execution of command. Erroneous commands are taken care in the protocol runner which its development is not part of this Thesis. RotateFail = SELECT rcmd = rot_cmd r_state = idle r_state := pre_rot_suspended The action ServiceNotReady models possible spontaneous fault occurrence even when a service is not requested. A spontaneous fault could be a primary hardware fault. ServiceNotReady = SELECT r_state = idle r_state := suspended 43

52 From the suspension states the system tries to perform recovery procedures and continue functioning as specified from the relevant remedy actions, i.e. Remedy = SELECT r_state = suspended r_state := idle When the fault tolerance limit has been reached, a failure of the system occurs and it enters the state abort. This is modeled with actions such as RotateNoRemedy: RotateNoRemedy = SELECT r_state = rot_suspended r_state := abort This kind of actions represents the transition of the system into a fail-safe state. 44

53 10 Refining the system It is useful to stepwise introduce details about the system when dealing with complex control systems. This way, the implementation details of the system do not have to be handled at once. After translating the basic class and statechart diagrams into a B-action system, the system is gradually refined. The requirements of the system are a good source of information when introducing variables in the refinement. Compared to the abstract machine specifications the refinement machines consist of more variables and have more detailed, as well as, newly introduced operations which change the variables. The guards consist of more precise conditions, too Class diagrams of the first refinement of the system The Rotary Table The class diagram of the first refinement of the Rotary Table and the Stacker unit can be found in Appendix C.1 and C.3, respectively. In this refinement step the introduced details for the Rotary Table are on: rotating the Rotary Table clockwise or counterclockwise, the status of the six plate holders on the Rotary Table, the presence of liquid in a plate holder, the position of a Stacker s arms, how deep in the plate the Dispensing Head is allowed to go when it is processing in position 1 of the Rotary Table, the minimum height that the Dispensing Head can be above the position 1 of the Rotary Table in order the Rotary Table to be able to rotate, and the position of the Dispensing Head above the Operating Table In order to be able to reason on the introduced details the following variables are added to the system. A variable temp_ph_pos1 is added in order to store the plate holder id being at the dispensing position DispPos before the rotation. Then, this variable is used to check the correctness of the rotation after the Rotary Table has rotated. Additionally, a variable ph_pos is introduced which models the position of the six plate holders on the Rotary Table. Furthermore, a variable pholder is added, which stores the height of a plate holder and senses whether a plate is present (TRUE) on a plate holder, or not (FALSE). This variable is a function from the plate holder id to a structure containing the variable height and the Boolean variable plate_present. Moreover, a variable liq_present is added to check if there is liquid present (TRUE) on a plate holder, or not (FALSE). In order to understand the rotation of the plate holders on the Rotary Table, Figure 30, which shows the changing of the plate holders position after a clockwise rotation of two steps, is given below. For example, the variable ph_pos(1) at 45

54 position 1 has the value 1 before the rotation and after the rotation it has the value 5 indicating that plate holder 5 is now at position 1. ph 4 ph 2 ph 3 pos 4 ph 5 ph 1 pos 4 ph 3 pos 3 pos 5 pos 3 pos 5 ph 2 pos 2 pos 6 pos 1 ph 6 ph 6 pos 2 pos 6 pos 1 ph 4 ph 1 ph 5 Figure 30. Position of plate holders after a two steps rotation. Also, a variable zminallowed is added in order to model the minimum height of a plate holder. The Dispensing Head needs to check this variable for safety reasons, i.e., not to try to go lower. Furthermore, a variable zmid is added in order to model the lowest z position possible when the Dispensing Head is moving in xy-direction. The variables temp_ph_pos1, ph_pos, pholder, liq_present, zmid and zminallowed, as well as the procedures that change their values, are given in the procedure class PLATEHOLDER. A variable ZCoord exists in the class ZDRIVER and is compared against the variable zmid in order to allow the Rotary Table to rotate. The ZDRIVER class belongs to the class diagram of the XYZ Driver of the Dispensing Head and is imported in the Rotary Table class diagram in order for the ROTARY_TABLE_R1 class to be able to see it. The development of the Dispensing Head is done elsewhere [BJW03] within the MATISSE project. Furthermore, a variable extpos is defined and updated in the procedure class XYZD_PROC of the XYZ Driver. This procedure class is imported in the class diagram of the first refinement of the Rotary Table, for the same reason as mentioned above. If extpos is smaller than or equal to three, it means that the Dispensing Head is not above the dispensing position one of the Rotary Table, but in one of the three positions of the Operating Table, thus the Rotary Table is allowed to rotate. The Rotary Table is an extension of the Operating Table as mentioned earlier. Moreover, a variable steps is added in this refinement step modeling how many steps and in which direction the Rotary Table to rotate. The minus sign indicates counterclockwise rotation, while the plus sign indicates clockwise rotation. The rotation could go on forever, so the steps variable is restricted and can be assigned values from 5 46

55 to +5, only, which means the Rotary Table can rotate maximum five positions counterclockwise, or clockwise. This additional variable can be found in the class ROTARY_TABLE_R1. In the procedure class of the Rotary Table, PLATEHOLDER, a local procedure, NewPlateholderPos, of the Rotary Table is given, which calculates the new plate holder position on the Rotary Table after the rotation has taken place. The operations of the Rotary Table are updated to reflect to the changes of the new variables. The subroutine Rotate is described in detail in Section , below. For this subroutine all possible failures are taken into consideration and a remedy is given for each failure if it is possible. As it can be seen in the ROTARY_TABLE_R1 class, two new operations, RotateArmsFail and RotateZCoordFail, have been added in order to model the subroutine s failures because of the Stacker s arms being down low on the Rotary Table and of the position of the Dispensing Head, respectively. These two operations correspond to the new transitions in the statechart diagram described below. The invariant of the Rotary Table classes The invariant written in the class documentation box of the ROTARY_TABLE_R1 class shows the relation between the state and the command of the Rotary Table and the variables steps, extpos, ZCoord, zmid and arms. Specifically, when the variable extpos has a value bigger than three and the Rotary Table is in the state rotate, the variable ZCoord, which is the z position of the Dispensing Head, has to be equal or bigger than the variable zmid, which models the lowest z position possible when the Dispensing Head is moving in xy-direction. Moreover, when the extpos variable has a value greater than three, meaning that the Dispensing Head is above the position 1 of the Rotary Table, the ZCoord variable has to have a value greater than or equal to the value of the zminallowed variable, which is the minimum height of a plate holder. Finally, when the Rotary Table is in the states rotate, the command, rcmd, has to be equal to the rotate command, rot_cmd. This invariant can be seen below. (extpos > 3 & r_state = rotate => ZCoord >= zmid) & (extpos > 3 => ZCoord >=zminallowed) & (r_state = rotate => rcmd = rot_cmd) The invariant written in class documentation box of the procedure class PLATEHOLDER shows the relation between the variables ph_pos, pholder, liq_present, zmid and zminallowed. The plate holder ids of the plate holder variable, pholder, have to be the same with the plate holder ids of the plate holder position variable, ph_pos. Moreover, if there is liquid present, liq_present, on the Rotary Table, there is plate holder with a plate present on the Rotary Table. This invariant can be seen below. ran(ph_pos) = dom(pholder) & dom(pholder) = dom(liq_present) &!xx.(xx:ph_id & (pholder(xx))'plate_present = FALSE => liq_present(xx) = FALSE) 47

56 The deferred set PH_ID, which contains the ids of the plate holders, is given in the class machine def2, together with the constants zmin, zmax and ROTARY_POS, and their properties. The six fixed positions of the Rotary Table are the properties of the ROTARY_POS constant The Stacker unit In this refinement step the introduced details for the Stacker unit are on: the position of a Stacker s arms, the position of the Stackers above the Rotary Table and, the capacity of each Stacker. A variable arms is added in order to model the position of the arms of each Stacker. At this stage two arms positions are taken into account, up and down. Moreover, a variable s_pos is added to model the position of every stacker above the Rotary Table. The stackers can be above the positions 2, 3, 5, and 6 of the Rotary Table. The variables arms and s_pos, as well as the procedure that changes the status of the variable arms, are given in the procedure class STACKER_PROC. Furthermore, a variable full is added modeling a Stacker sensing whether it is full (TRUE) or not (FALSE). If a Stacker is full, it cannot stack any more plates from the Rotary Table. A variable empty is added, too, modeling a Stacker sensing whether it is empty (TRUE) or not (FALSE). If a Stacker is empty, it cannot destack any plate to the Rotary Table. The variables full and empty are given in the class STACKER_R1. The invariant of the Stacker unit classes The invariant of the refinement class STACKER_R1 shows the relation between the variable state of this class and the variable state of the class STACKER, which refines. In this refinement step, the state variable required renaming because four more states are added to the set of states of a Stacker, two for the stack service and two for the destack service. Moreover, the relation between the state variable and the variable arms, as well as the commands of the Stackers is shown. When a Stacker is in the state ready_to_destack1, the arms of that Stacker have to be down. Also, when a Stacker is in the state stack1 or destack1, the command, scmd, has to be equal to the stack command, sk_cmd, or the destack command, dsk_cmd, respectively. The part of the invariant for the arms and the command is shown below. s_state1(thisstacker) = ready_to_destack1 => arms(stacker_proc(thisstacker)) = down & s_state1(thisstacker) = ready_to_stack1 => arms(stacker_proc(thisstacker)) = down & s_state1(thisstacker) = stack1 => scmd(thisstacker) = sk_cmd & s_state1(thisstacker) = destack1 => scmd(thisstacker) = dsk_cmd The set ARM_POS is given in the class machine def2, in the Appendix D.7 and contains the two possible arm positions, up and down. 48

57 10.2 Statechart Diagrams of the first refinement The Rotary Table The statechart diagram of the first refinement for the Rotary Table can be found in Appendix C.2. As it can be seen, there are not any new states compared to the initial specification diagram. A description of the refined, only, transitions is following. The component evolves from a state idle to a state get_ready, and at the same time the rotate command, rot_cmd, is being assigned to the variable rcmd. Additionally, a parameter p_steps is given to this event triggering transition, which is assigned to the variable steps. Moreover, as one of the actions of this transition, the SetOldPos local procedure of the Rotary Table is called from the PLATEHOLDER class. This procedure assigns to the variable temp_ph_pos1 the id of the plate holder being at the dispensing position one of the Rotary Table prior to the rotation, so that the correctness of the rotation can be checked afterwards. From the state get_ready the component evolves to the state rotate performing its service, provided certain conditions are satisfied. These certain conditions are now precisely specified. The command variable, rcmd, must be equal to the rotate command, rot_cmd, as in the specification statechart diagram. Then, the arms of all the Stackers must be up. Moreover, the Zcoord variable must be bigger than or equal to the zmid variable, meaning that the Dispensing Head must be at a certain height above the dispensing position one of the Rotary Table, or the Dispensing Head to be in one of the three positions of the Operating Table. The later is checked with the variable extpos. As it can be seen from the diagram decision pseudo states have been added in order to reduce guard complexity. Furthermore, as one of the actions of the Rotate transition, the NewPlateholderPos local procedure of the Rotary Table is called from the PLATEHOLDER class, in order to calculate the new plate holder position after the rotation and to update the zminallowed variable as well. A part of the statechart diagram is given below in Figure 31. rotate Rotate[ZCoord >= zmid or extpos<=3]/ NewPlateholderPos(steps) RotateZCoordFail[ZCoord<=zmid & extpos > 3] [!ss.(ss:stackers_proc =>arms(ss) = up)] RotateArmsFail[#ss.(ss:STACKERS_PROC & arms(ss) = down)] get_ready RotateFail[rcmd=rot_cmd] pre_rot_suspended RotateCommandRemedy[rcmd=rot_cmd &!ss.(ss:stackers_proc=>arms(ss)=up) & (ZCoord>=zmid or extpos <= 3)] Figure 31. A part of the 1 st refinement statechart diagram for rotate service. 49

58 On the presence of an exception, the component evolves from the state get_ready to the state pre_rot_suspended. In addition to the transition RotateFail, which models failure of execution of command, two new transitions have been added. The transition RotateArmsFail suspends the behaviour of the component to the state pre_rot_suspended, if there exists some stacker having the arms down. The transition RotateZCoordFail suspends the behaviour of the Rotary Table, if the Dispensing Head is not at the specified height above the position one of the Rotary Table in order the rotation to be allowed. If remedies of these exceptions are found, the component can resume and continue from the state get_ready until the required service has been performed. Otherwise, the component aborts its execution. If the service is successfully performed the component returns to the state idle. In the guard of this transition, RotateOk, is checked that the plate holder, with some id, which was at position one, has been rotated to a new position according to the number of steps given for the rotation. An exception of this service suspends the behaviour of the component to the state rot_suspended. If a remedy occurs, the component resumes its service providing state as in the specification diagram. In a different situation, the component aborts its execution The Stacker unit The statechart diagram of the first refinement for the stack service of a Stacker can be found in Appendix C.5. The corresponding statechart diagram for the destack service of a Stacker can be found in Appendix C.4. As it can be seen from these diagrams, some new states have been added. Thus, the state variable and the states required renaming and the relationship between the state variable of the specification and the state variable of the refinement is given in the invariant of the STACKER_R1 class. A detailed description of the refined and the new transitions of the statechart diagram for the stack1 service is following. The evolvement of a Stacker from the state idle1 to the state prepare is the same as in the specification diagram. From the state prepare1 the component evolves to the newly added state ready_to_stack1 provided specific conditions are satisfied. The conditions are that the command variable, scmd, must be equal to the stack command, sk_cmd, the Stacker is not full, and the plate holder under this stacker s position has a plate present. As an action of this transition, this Stacker calls the local procedure ChangeStArms from its procedure class STACKER_PROC. This procedure changes the position of the Stacker s arms to position down, in order for the Stacker to be able to hold (get) the plate. Decision pseudo states have been added in this diagram as well to reduce guard complexity. If an exception occurs on the conditions mentioned above, the component evolves from the state prepare1 to the state prep_sk_suspended1. Additionally to the transition StackFail, taking care of failure of execution of command, two new transitions have been added. The transition StackFullStackerFail suspends the behaviour of the component to the state prep_sk_suspended1 if the component is full. The transition StackPlateFail suspends the behaviour of the component to the state prep_sk_suspended1 if there is not a plate present on the plate holder under this Stacker. On the presence of a remedy of these exceptions, the component can resume and continue from the state prepare1. From the state ready_to_stack1 the component evolves to the state stack to perform its intended 50

59 service provided that the command variable, scmd, is equal to the stack command, sk_cmd, and the arms are down ready to take up the plate. If the arms are not down but up, the new transition StackArmsFail suspends the behaviour of the component to the state prestack_suspended1. If there is remedy for this exception, the component resumes and can continue from the state ready_to_stack1. Otherwise, the component aborts its execution. As actions of the Stack transition, the local procedure ChangeStArms is called to change the position of the arms to position up, and the exported procedure of the Rotary Table, PlateholderPlateRemove, is called from the PLATEHOLDER class to remove a plate from the plate holder being under this Stacker. Moreover, the component evolves back to the state idle1 from the service providing state stack1, provided that the command is satisfied, the arms of this Stacker are up and there is not a plate present under this Stacker. If the arms are down the behaviour of the component is suspended to the state st_suspended1 with the transition AfterSkArmsFail. If there is a plate present on the plate holder under this Stacker, the behaviour of the component is suspended with the transition AfterSkPlateFail to the state st_suspended1, too. From this state the component resumes to the service providing state stack1 if there is a remedy, or aborts its execution if there is not a remedy. A part of the statechart diagram for the stack service is given below in Figure 32. As it can be seen from the statechart diagram for the destack service of a Stacker in Appendix C.4, the transitions occur in a similar way as in the statechart diagram for the stack service. A description of the differences between these two diagrams is following. ready_to_stack1 PrepareStack[(pholder(ph_pos(s_pos(Stacker_proc)))) plate_present = TRUE]/ ChangeStArms(Stacker_proc, down) StackPlateFail[(pholder(ph_pos(s_pos(Stacker_proc)))) plate_present=false] [full = FALSE] StackFullStackerFail[full = TRUE] [scmd = sk_cmd] StackFail[scmd=sk_cmd] prepare1 prep_sk_suspended1 StackCommandRemedy[scmd=sk_cmd & full=false & pholder(ph_pos(s_pos(stacker_proc))) plate_present = TRUE Figure 32. A part of the 1 st refinement statechart diagram for stack service. 51

60 In order for the component to evolve from the state prepare1 to the state ready_to_destack1, the command variable, scmd, must be equal to the destack command, dsk_cmd, the Stacker must not be empty, and there must not be a plate present on the plate holder under this Stacker. If the Stacker is empty, the transition DestackEmptyStackerFail suspends the Stacker s behaviour to the state prep_dsk_suspended1. Moreover, if there is a plate present under this Stacker, the transition DestackPlateFail suspends the Stacker s behaviour to the state prep_dsk_suspended1. On the presence of a remedy the component evolves to the state prepare1, wherefrom it can continue until the required service has been performed. From the state ready_to_destack1 the component evolves to the service providing state destack1, provided that the arms of the Stacker are down, as in the corresponding stack service statechart diagram. Furthermore, as one of this transition s actions, the Rotary Table s exported procedure, PlateholderPlateAdd is called, which adds a plate to the plate holder being under this Stacker. From the state destack1, the component can return to the state idle1 provided that the arms of the Stacker are up and there is a plate present on the plate holder being under this Stacker. If there are exceptions on these conditions the component evolves to the state des_suspended1 from the state destack1, with the transitions AfterDskPlateFail and AfterDskArmsFail, having as guards that there is not a plate on the Rotary Table under the Stacker, and that the arms are down, respectively. From the state des_suspended1 the component resumes to the state destack1 if there is a remedy, otherwise it aborts U2B translation to B-action systems and first refinement of the system At this point the class and statechart diagrams of the first refinement of the system can be translated to B-action systems, using the U2B tool. Then the Atelier B tool can be used in order to verify that these diagrams refine the corresponding abstract ones. It can be seen from the Rotary Table s first refinement class diagram that dependency relationships are used between the classes, with a stereotype bind. U2B detects this kind of relationship with that stereotype and adds an INCLUDES clause with the names of the included machines in the ROTARY_TABLE_R1 refinement machine. An INCLUDES clause can be written manually in the documentation box of the classes as well. Furthermore, a realize relationship indicates that the ROTARY_TABLE_R1 class refines the ROTARY_TABLE class. As it can be seen, the specification class contains the same number of operations as the refinement class. This occurs in the UML diagram because the B-action systems formalism requires it. The operations that are new in the refinement and specified there, they are given as skip operations in the specification diagram. The PLATEHOLDER class does not have any statechart diagram attached. All the procedures are specified within this class. For every operation there is a specification window so that all the parameters, preconditions, and semantics can be written there. The SELECT guards are an important feature to B-action systems, so by giving the stereotype action system or event system to the logical view of the UML model, allows the U2B tool to translate all the conditions given in the precondition box of an operation, as SELECT 52

61 guards. The translated machines of the first refinement class diagram for the Rotary Table is given in Appendix D. One extra feature in the Stacker s first refinement class diagram compared to the Rotary Table s ones, is the association UML relationship between the STACKER_R1 class and the STACKER_PROC procedure class of the Stacker. The procedure class has the same multiplicity, four, as the STACKER_R1 class, and the four objects specified from each of these classes must be connected. Setting the cardinality of the association relationship to 0..1 at the STACKER_R1 class end, and to 1..1 at the STACKER_PROC class end, as it can be seen in Figure 33 below, is equivalent to a total injection in the B Method. Then Figure 33. Specification for role A of the association end. the Stacker_proc role name of the association is translated as a total injection function in the STACKER_R1 refinement, which relates the instances of the two classes. Stacker_proc : STACKER >-> STACKER_PROC Thus, wherever a procedure is called from the STACKER_PROC class, the Stacker_proc variable is used as a parameter in order U2B to automatically generate the instance parameter thisstacker. The variable Stacker_proc could be placed automatically in the statechart diagrams. The placement of this variable, Stacker_proc, into the statechart 53