ESPRIT Long Term Research Project 20072 - Deva: Design for Validation - TR 37Using Coordinated Atomic Actions toDesign Complex Safety-Critical Systems:The Production Cell Case StudyA.F.Zorzo1, A.Romanovsky, J.Xu, B.Randell, R.J.Stroud, and I.S.WelchDepartment of Computing Science, University of Newcastle upon Tyne, UKNovember 25, 1997AbstractCoordinated Atomic actions (CA actions) are a uni�ed approach to structur-ing complex concurrent activities and supporting error recovery between multipleinteracting objects in an dependable object-oriented system. This paper explainshow we have used the CA action concept to design and implement a safety-criticalapplication. We have used the Production Cell model that was developed in theForschungszentrum (FZI) Informatik, Karlsruhe, Germany, to present a realisticindustry-oriented problem, where safety requirements play a signi�cant role. Ourdesign consists of two levels: the �rst level deals with the scheduling of CA actions,and the second level of design deals with the interactions of the devices. Both thescheduling mechanism and the device interactions are enclosed by CA actions. Ex-ception handling and error recovery are incorporated into CA actions in order tosatisfy high safety and fault tolerance requirements. Based on the design, a con-trolling software was developed in the Java language to drive a graphical simulatorprovided by the FZI.Keywords: Cooperation, Coordinated atomic actions, Java, Object-oriented sys-tems, Production cell, Safety-critical systems1 A Case Study: Production CellThe Production Cell model was developed in the Forschungszentrum Informatik (FZI),Karlsruhe, Germany, as a case study to present a realistic industry-oriented problem,where safety requirements play a signi�cant role. It is not just a theoretical model, in factit is based on an actual industrial installation in a metal-processing plant in Karlsruhe [4].The FZI Production Cell model is composed of 6 devices (see Figure 1), 13 actuators,and 14 sensors. It processes metal plates which are taken to a press. Metal plates areconveyed to an elevating rotary table by a feed belt. A two-armed robot takes each plateas it arrives from the elevating rotary table and places the plate into the press using its�rst arm. The robot's �rst arm then withdraws from the press, and the press forges themetal plate. After the plate has been forged, the robot's second arm takes the forged metal1Lecturer at PUCRS/Brazil (on leave). 1

plate out of the press and puts it on a deposit belt. Finally, a travelling crane picks themetal plate up and takes it to the feed belt again, thus allowing the model to operate in acontinuous cycle without the need for an external operator.

���������������������������������������������

���������������������������������������������

���������������������������

���������������������������

���������������������

���������������������

Trav

ellin

g C

rane

Feed Belt Elevating

Arm 1

Arm 2

Press

Robot

Deposit Belt

Metal Plate

Rotary Table

Sensor

Figure 1: Production Cell1.1 Devices� Feed Belt: its task consists of transporting metal plates to the elevating rotarytable. The belt is powered by an electrical motor, which can be started up or stoppedby a control program. A photoelectric sensor is installed at the end of the belt; itindicates whether a plate has entered or left the �nal part of the belt.� Elevating Rotary Table: its task consists of rotating the plates by about 45degrees and lifting them to a level where they can be picked up by the robot's �rstarm. The vertical movement is necessary because the robot's arm and the feedbelt are located at di�erent levels, and because the robot cannot perform verticaltranslations. Rotation of the table is also required, because the arm's gripper cannotrotate and the robot is therefore unable to place the metal plates into the press in astraight position by itself.� Robot: its task consists of picking up metal plates from the elevating rotary table;loading and unloading the press with metal plates; and placing the forged metalplates on the deposit belt. The robot possesses two independent orthogonal arms.For technical reasons, the arms are set at two di�erent levels. Each arm can retract orextend horizontally. However, both arms rotate together. Mobility on the horizontalplane is necessary, since the elevating rotary table, press, and deposit belt are all2

placed at di�erent distances from the robot's turning centre. The end of each of therobot's arms is �tted with an electromagnet that allows the arm to pick up metalplates.� Press: its task consists of forging metal plates. The press consists of two platforms,with the lower platform being movable along a vertical axis. The press operates bypressing the lower platform against the upper one. Because the robot's arms are indi�erent horizontal planes, the press has three positions: i) in the middle position itis loaded by the robot's �rst arm; ii) in the upper position the metal plate is forged;and iii) in the lower position the press is unloaded by the robot's second arm.� Deposit Belt: its task consists of transporting the forged plates to the travellingcrane. A photoelectric sensor is installed at the end of the belt; it reports when ametal plate reaches the end section of the belt. The control program then has tostop the belt. The belt can restart as soon as the travelling crane has picked up themetal plate.� Travelling Crane: its task consists of picking up metal plates from the depositbelt, moving them to the feed belt and unloading them there. It acts as a link betweenthe two belts and thus makes it possible for the model to function continuouslywithout the need for an external operator. The crane has an electromagnet as gripperwhich can perform horizontal and vertical translations. Horizontal mobility serves tocover the horizontal distance between the belts, while vertical mobility is necessarybecause the belts are placed at di�erent levels.1.2 Controlling SoftwareThe FZI Production Cell has to be managed by a controlling software that uses a set ofsensors to detect the position of some devices (press, robot arms, elevating rotary table,and travelling crane) or to indicate if a plate is at the end of a belt; and a set of actuatorsto move, extend, rotate, activate, and deactivate the devices described in Section 1.1 (seeFigure 2).1.3 RequirementsThe controlling software must be implemented, according to the rules laid down in the casestudy. In particular, it is important to guarantee that the following requirements are met:safety: in order to ensure that the system operates safely at all times, it is necessary to� restrict machine mobility;� avoid machine collisions;� avoid dropping plates outside safe areas, i.e. deposit belt, feed belt, and press;3

���������������

���������������

ControllingSoftware

������

������

����������

����������

Figure 2: Controlling Software� keep plates su�ciently distant from each other;liveness: every metal plate introduced into the system via the feed belt will eventuallybe dropped by the crane on the feed belt again and will have been forged;Requirements such as exibility or e�ciency are to be taken in account but without a�ect-ing the above requirements. (For more details about the FZI Production Cell case studyrequirements see [4].)2 Coordinated Atomic ActionsCoordinated atomic actions (or CA actions) provide a mechanism for performing a groupof operations on a set of objects atomically. These operations are performed cooperativelyby one or more roles, i.e. internal processes or threads, executing in parallel within theCA action. The interface to a CA action speci�es the objects that are to be manipulatedby the CA action and the roles that are to manipulate these objects. In order to performa CA action, a group of threads must come together and agree to perform the set of rolesin the CA action concurrently with one thread per role.The multiple threads within a CA action communicate with each other via local objectsthat are purely internal to the CA action and are used to support cooperative concurrency.In this way, the threads within a CA action can coordinate their concurrent activities andagree upon the set of operations they wish to perform upon the objects that are manip-ulated by the CA action. These objects are considered to be external to the CA actionand can therefore be accessed competitively by other CA actions executing concurrently.To ensure correctness and prevent information smuggling, a CA action must behave likea transaction with respect to these external objects. Thus, the e�ects of any operationsthat the threads within a CA action perform on external objects are not visible to otherthreads or CA actions until that CA action terminates.Transactions are designed to deal with the problems of concurrency and hardware faults,and in transaction-based systems it is generally assumed that software faults are not an4

issue. In other words, if a transaction commits it is assumed to have produced the correctresults and a subsequent transaction will not have to abort because of an error in the �rsttransaction. In contrast, CA actions are intended to provide a more general frameworkfor dealing with both hardware and software faults that combines mechanisms for forwardand backward error recovery. However, it is recognised that the error recovery mechanismswithin a CA action might not be su�cient to achieve the desired outcome in every case.Thus, a CA action can be designed to have both a normal (desired) outcome, or zero ormore exceptional (i.e. degraded) outcomes.A structured acceptance test [2] can be used to ensure that a CA action achieves oneof its possible outcomes. The e�ects of performing a CA action only become visible ifthe acceptance test is passed. This is analogous to transaction commit except that theacceptance test allows both a normal outcome and zero or more exceptional outcomes, witheach exceptional outcome signalling a speci�ed exception to the surrounding environment.Conversely, if it is not possible to satisfy the acceptance test at the end of a CA action,even by signalling one of the speci�ed exceptions, the CA action is considered to havefailed. This is analogous to transaction abort and it is therefore necessary to undo thepotentially visible e�ects of the CA action in this case and signal an abort exception tothe surrounding environment. If the CA action is unable to satisfy the \all or nothingproperty" necessary to guarantee atomicity (e.g. because the undo fails), then a failureexception must be signalled to the surrounding environment indicating that the CA actionhas failed to pass its acceptance test and that its e�ects have not been undone. The systemhas probably been left in an erroneous state and this must be dealt with by the enclosingCA action (if any).Each of the threads that play a role in a given performance of a CA action should receivethe same indicated result: a normal outcome, an exceptional outcome, an abort exception,or a failure exception. If this does not happen, then the CA action mechanism itself hasfailed and this failure must be dealt with at a higher level in the system. (Achieving anagreed result might involve the use of an exception resolution mechanism - see below.)CA actions provide a basic framework that can support a variety of fault tolerancemechanisms. Hardware faults can be tolerated using two phase commit protocols andstable storage to ensure that the e�ects of CA actions are permanent. Software faults canbe addressed using fault masking and design diversity. Environmental faults will typicallybe dealt with using forward recovery strategies that involve sending compensatory messagesbetween the system and its environment, unless the objects in the system's environmentare capable of backward recovery.During the execution of a CA action, one of the threads that are involved in the actionmay raise an exception. If that exception cannot be dealt with locally by the thread, then itmust be propagated to the other threads involved in the CA action. Since it is possible forseveral threads to raise an exception at more or less the same time, a process of exceptionresolution [1] [10] is necessary in order to agree on the exception to be propagated andhandled within the CA action.Once an agreed exception has been propagated to all of the threads involved in theCA action, then some form of error recovery mechanism must be invoked. It may still be5

possible to complete the performance of the CA action successfully using forward errorrecovery. Alternatively, it may be possible to use backward error recovery to undo thee�ects of the CA action and start again, perhaps using a di�erent variant of each role inorder to tolerate design faults. If it is not possible to achieve either a normal outcome oran exceptional outcome using these error recovery mechanisms, then the CA action shouldbe aborted and its e�ects should be undone.It is important that these fault tolerance measures are properly integrated with thee�ects that the CA action is having on objects, both internal and external to the CAaction. For example, backwards error recovery must involve restoring the state of allthe objects involved in the CA action, including external objects, whilst forward errorrecovery must ensure that all of the objects are left in an acceptable state. Otherwise, afailure exception should be signalled to the external environment.handler H1

exceptionhandler H2

exception

Thread 1

accesses repairsExternal Object

start transaction

time

e1st attempt

1st attempt

Thread 2

commit transactionFigure 3: Coordinated Error Recovery Performed by a CA ActionFigure 3 shows a simple example in which two threads activate the roles in a CAaction synchronously. Within the CA action the roles communicate with each other andcooperate in pursuit of some common goal. However, during the execution of the CAaction, an exception e is raised by one of the roles. The exception is propagated to theother role and both roles transfer control to their handlers H1 and H2 for this particularexception, which then attempt to perform forward error recovery. The e�ects of erroneousoperations on external objects are repaired by putting the objects into new correct statesso that the CA action is able to continue its execution and exit with a successful outcome.(As an alternative to performing forward error recovery, the two participating threadscould undo the e�ects of operations on the external objects, roll back and then try again,possibly using diversely designed software alternates.)6

2.1 Why Use CA Actions?The FZI Production Cell problem is a safety-critical application which therefore has strongrequirements for system reliability and safety. CA actions, as a design structuring concept,can provide appropriate support for the following aspects of reliability and safety:1) Damage Con�nement: If an error is not detected and limited to a certain extent thenits e�ects may spread throughout the whole system inducing further errors. A CA actioncan con�ne the erroneous information ow by enclosing the interaction and cooperationbetween concurrent activities within its boundaries and by controlling access to externalshared objects.2) Complexity Control: like the atomic action concept, CA actions are a general toolthat can be used to structure complex concurrent systems and reason about the dynamicstructure of a system.3) Fault Tolerance: For many critical applications, fault tolerance is often the onlypossible way of achieving the required reliability and safety. CA actions provide a uni�edframework for handling exceptional situations, even ones involving complex concurrentbehaviour, into which various proven hardware and software fault tolerance techniques notjust simple fault masking or backward error recovery, can easily be incorporated.4) Critical Condition Validation: For many safety-critical systems, once an exceptionalevent occurs the system must be left in a well-de�ned safe state. CA actions providea framework for coordinating exception handling and ensuring that either an acceptabledegraded outcome is achieved or the e�ects of an action are undone, leaving the system ina previously achieved safe state.5) Nesting: CA actions can be nested. Nested CA actions can provide support for �nergrain damage con�nement and enable layered exception handling. For example, if a nestedCA action raises a failure exception, then appropriate recovery measures can be involved inthe enclosing action. A nested action also helps to control complexity by further enclosinga group of basic operations enclosed in the containing action. In principle, CA actions canbe thought of as an abstraction of an agreement protocol - some execution threads cometogether synchronously, perform some actions cooperatively, and agree upon the outcome.In the limiting case a nested action can reduce down to what is in e�ect a synchronisationaction which could be implemented by a synchronise operation.2.2 General Design DecisionsThe purpose of the research described in this paper was to demonstrate how CA actionscould be used as a system structuring tool for designing safety-critical applications byapplying them to the FZI Production Cell case study. Our priority was to provide a clearsystem design that is simple in structure and meets the case study's safety requirements.Our intention was to structure all critical system activities out of CA actions. We decidedto design ten top-level CA actions in our system (nine for the main production cycle andone for system initialisation). Each CA action controls one step of the plate processing andtypically involves passing a plate between two devices (see Figure 4). These ten top-level7

CA actions are composed of a set of smaller nested CA actions.���������������������������������������������

���������������������������������������������

���������������������

��������������������� ���

������������������������

���������������������������

LoadTable

TransportPlateUnloadDepositBelt

LoadDepositBelt

LoadPress

UnloadPress

ForgePlate

UnloadTableReloadPlateFigure 4: Set of actions in the Production CellOur main design decisions were as follows. To meet the safety requirements, the rolesand boundaries of CA actions were chosen in such a way that neither plates nor devicescould collide. Only one plate can be in a CA action, a plate cannot be involved in morethan one CA action and a device can participate in only one CA action at a given time.An informal analysis of the safety requirements showed that using CA actions to designthe system in this way allows us to guarantee all requirements concerned with concurrentactivities within the FZI Production Cell. The remaining requirements (limitations onthe movements of separate devices) are not connected with system concurrency and areprovided in our design by \defensive" and self-checking programming inside CA actions(e.g. checking each action's pre- and post-conditions).Using CA actions not only guarantees the safety requirements but simpli�es the systemdesign because CA actions are atomic and all internal CA action states are hidden fromthe outside. (We believe this is important for future formal analysis). In addition, usingCA actions guarantees such conventional features of concurrent programming as mutualexclusion: CA actions have synchronous entries, so an action cannot start until all of itsroles are ready, and synchronous exit, which means that participants can leave the actiononly when all roles have completed their execution.Each device has a corresponding thread called a device controller which is responsiblefor specifying the sequence of CA actions in which the device participates. For example, forsimple cyclic execution a device controller has a straightforward structure with an endlessloop, which means the table thread goes through actions LoadTable and then UnloadTable,and repeats this execution order again and again:8

TableController:loopLoadTable.table(plate);UnloadTable.table(plate);end loop;The CA actions themselves are the building blocks that guarantee system safety: their useprevents the building of a system in which plates and devices can collide. For example, ifone of the device controllers incorrectly orders the sequence of CA actions in which a givendevice takes part then the system will deadlock in a safe state. Moreover, if any CA actionfails and the controllers do not provide proper recovery then the system stops, because theparticipants of the CA action will not be ready for the execution of that or of the followingCA actions, unless the controller does some kind of error recovery and the pre-conditionsof the failed CA action or of the following CA action are satis�ed.Our design consists of nine top-level CA actions shown as dotted boxes in Figure 4 (plusa special one for the loading of plates into the system, not shown in the �gure). Theseboxes enclose the devices that take part in the corresponding CA actions. This is whyCA actions cannot be executed concurrently if the dotted boxes overlap. For example,LoadTable has the feed belt and the rotary table as its roles and UnloadTable has thetable and the robot as its roles. These two CA actions therefore cannot run concurrently.Moreover, our design guarantees that LoadTable cannot start with the next plate until thetable is ready, which means that the previous plate has been picked from the table by therobot arm.In addition to the devices (feed belt, press, rotary table, deposit belt, crane, and ro-bot) we have decided to include appropriate sensors as roles in corresponding CA actions.Within our design, the set of sensors associated with each device are programmed as ad-ditional CA action roles. Each sensor activated by a sensor controller which is responsiblefor specifying the sequence of actions in which this set of sensor takes part.The plates are external objects, which are shared by the CA actions. They are passedas input/output parameters among the CA actions (at the device controller level). Thecomplete run of each plate includes all actions and afterwards the plate is ready for thenext run. The FZI case study assumes cyclic processing of several plates.3 Production Cell DesignOur design for the FZI Production Cell separates the safety, functionality, and e�ciencyrequirements between a set of CA actions that will occur during system execution anda set of device/sensor controllers that will determine the order in which the CA actionswill be executed. Because the safety requirements are the most important in the system,we will attempt to satisfy them at the level of CA actions, while the other requirementswill be met by the device/sensor controllers, which can be programmed in several ways.These device/sensor controllers will communicate with each other in order to schedulethe execution of the CA actions. The \controlling software" (Section 1.2), for the whole9

FZI Production Cell is composed, in our design, of the set of CA actions and the set ofdevice/sensor controllers described in this section. The set of device/sensor controllers areroles inside a CA action that will enclose the whole Production Cell \controlling software",i.e. it is a enclosing CA action for our ten top-level CA actions. In Section 3.1 we presentthe set of top-level CA actions that will be used by the controller's roles. In Section 3.2we describe the possible outcomes the top-level CA actions can produce. In Section 3.3 wepresent the controller's roles. In the following sections when we use the term action we aremeaning CA action.3.1 ActionsIn this section we present the interface, and the pre- and the post-conditions of all thetop-level CA actions we have designed. These consist of the nine CA actions whose scopeof activity was shown in Figure 4, plus a LoadPlate CA action which is involved in theinitialisation of the system with an appropriate number of plates. (For more details aboutthe functionality of each CA action see Appendix A.)The CA actions that we have designed for the FZI Production Cell case study typicallyhave two basic roles, one that takes a plate as an input argument, and the other that takesa plate as an output argument. The device associated with the role that has the plate asan input argument passes the plate to the role that has the plate as an output argument.Some actions also have sensor roles that check whether or not the devices are in the rightposition. All CA actions will only be activated if the pre-conditions are valid. We assumethat if no exception is raised during the execution of a CA action, then its post-conditionsare met. (If necessary, the post-conditions could be checked dynamically using acceptancetests.)3.1.1 LoadPlate ActionLoadPlate:roles:FeedBelt (out plate)Operator (in plate)In LoadPlate a plate is sent to the action through the Operator role as an input parameter;that plate is returned as an output parameter of the FeedBelt role, meaning that theoperator has dropped a plate onto the feed belt. (The Operator role could of course beundertaken by a human being.)pre-conditions post-conditionsfeed belt o� feed belt o�no plate on the feed belt plate on the feed beltplate with the operator no plate with the operator10

3.1.2 LoadTable ActionLoadTable:roles:FeedBelt (in plate, in feedBeltActuator)Table (out plate, in tableActuator)FeedBeltSensor (in photoElectricSensor)TableSensor (in bottomSwitchSensor, in tableAngleSensor)In LoadTable a plate is sent to the action through the FeedBelt role and that plate isreturned by the Table role. This action controls the feed belt moving a plate from itsstarting position till the plate has dropped onto the table. Sensor roles check whether thetable is in the right position (TableSensor), and whether a plate has passed the end of thefeed belt (FeedBeltSensor).pre-conditions post-conditionsfeed belt o� feed belt o�plate on the feed belt no plate on the feed beltno plate on table plate on the tabletable in top position table in bottom positiontable angle 50o table angle 0o3.1.3 UnloadTable ActionUnloadTable:roles:Table (in plate, in tableActuator)Robot (out plate, in robotActuator)TableSensor (in topSwitchSensor, in tableAngleSensor)RobotSensor (in arm1ExtensionSensor, in robotAngleSensor)In UnloadTable a plate is sent to the action through the Table role and that plate is returnedby the Robot role. This action controls all the device movements that are required in orderfor arm1 of the robot to grab a plate from the table.pre-conditions post-conditionsplate on the table no plate on the tableno plate on arm1 plate on arm1arm1/arm2 extension 0.0 arm1/arm2 extension 0.0table angle 0o table angle 50orobot angle 50otable in bottom position table in top position11

3.1.4 LoadPress ActionLoadPress:roles:Robot (in plate, in robotActuator)Press (out plate, in pressActuator)RobotSensor (in arm1ExtensionSensor, in robotAngleSensor)PressSensor(in middleSwitchSensor)In LoadPress a plate is sent to the action through the Robot role and that plate is returnedby the Press role. This action controls arm1 of the robot dropping a plate into the press.pre-conditions post-conditionsarm1/arm2 extension 0.0 arm1/arm2 extension 0.0plate on arm1 no plate on arm1no plate in the press plate in the pressrobot angle �90opress in the bottom position press in the middle position3.1.5 ForgePlate ActionForgePlate:roles: Press (in out plate, in pressActuator)In ForgePlate a plate is sent to the action through the Press role and that plate is returnedby the same Press role. During this action, a plate is forged by the press, and externalinformation about the plate is updated, e.g. number of times the plate has been forged.pre-conditions post-conditionsn-times-forged plate in the press (n+1)-times-forged plate in the press3.1.6 UnloadPress ActionUnloadPress:roles:Robot (out plate, in robotActuator)Press (in plate, in pressActuator)RobotSensor (in arm2ExtensionSensor, in robotAngleSensor)PressSensor(in bottomSwitchSensor)In UnloadPress a plate is sent to the action through the Press role and that plate is returnedby the Robot role. UnloadPress controls arm2 of the robot grabbing a forged plate fromthe press. 12

pre-conditions post-conditionsplate in the press no plate in the pressno plate on arm2 plate on arm2arm1/arm2 extension 0.0 arm1/arm2 extension 0.0robot angle 35opress in top position press in bottom position3.1.7 LoadDepositBelt ActionLoadDepositBelt:roles:Robot (in plate, in robotActuator)DepositBelt (out plate)RobotSensor (in arm2ExtensionSensor, in robotAngleSensor)In LoadDepositBelt a plate is sent to the action through the Robot role and that plate isreturned by the DepositBelt role. This action controls arm2 of the robot dropping a plateonto the deposit belt.pre-conditions post-conditionsplate on arm2 no plate on arm2no plate at the beginning of the deposit belt plate at the beginning of deposit beltdeposit belt o� deposit belt o�arm1/arm2 extension 0.0 arm1/arm2 extension 0.0robot angle �90o3.1.8 TransportPlate ActionTransportPlate:roles:DepositBelt (in out plate, in depositBeltActuator)DepositBeltSensor (in photoElectricSensor)In TransportPlate a plate is sent to the action through the DepositBelt role and that plate isreturned by the same DepositBelt role. This action controls the transporting of plates fromthe beginning of the deposit belt to the end of the deposit belt, i.e. after the photoelectricsensor. pre-conditions post-conditionsplate at the beginning of the deposit belt no plate at the beginning of the deposit beltno plate at the end of the deposit belt plate at the end of the deposit beltdeposit belt o� deposit belt o�13

3.1.9 UnloadDepositBelt ActionUnloadDepositBelt:roles:DepositBelt (in plate)Crane (out plate, in craneActuator)CraneSensor (in upperSwitchSensor, in craneHeightSensor)In UnloadDepositBelt a plate is sent to the action through the DepositBelt role and thatplate is returned by the Crane role. UnloadDepositBelt controls the crane grabbing a platefrom the deposit belt.pre-conditions post-conditionsno plate on the crane plate on the craneplate at the end of the deposit belt no plate at the end of the deposit beltdeposit belt o� deposit belt o�crane upper switch o� crane upper switch oncrane height 0.6593 crane height 0.65933.1.10 ReloadPlate ActionReloadPlateroles:FeedBelt (out plate)Crane (in plate, in craneActuator)CraneSensor (in upperSwitchSensor, in craneHeightSensor)In ReloadPlate a plate is sent to the action through the Crane role and that plate is returnedby the FeedBelt role. This action controls the crane dropping a plate onto the feed belt.pre-conditions post-conditionsfeed belt o� feed belt o�no plate on feed belt plate on the feed beltplate on the crane no plate on the cranecrane upper switch on crane upper switch o�crane lower switch o� crane lower switch oncrane height 0.6593 crane height 0.65933.2 Action OutcomesFor each of the actions presented in the previous section we have described the post-conditions that hold if the CA action has executed without failure. The CA actions wehave designed for the FZI Production Cell can in fact produce three di�erent outcomes:normal, abort, or failure outcome. 14

A normal outcome is achieved if a CA action is able to satisfy its post-conditions andthereby ful�ll its obligations. An abort outcome occurs if a CA action is unable to ful�ll itsobligations for some reason but is able to roll-back the system state and undo any e�ectsit might have had. The last possible outcome is a failure outcome. If a failure outcome isproduced by a CA action, we cannot assume anything about the system state because thisoutcome implies that the CA action tried to roll back and recover but it could not.3.3 ControllersIn Section 3.1 we presented a set of actions to execute various critical operations, i.e.passing a plate between devices. The activation of these actions and the order in whichthey execute is the responsibility of a set of device/sensor controller roles described in thissection which can be thought of as belonging to a bigger CA action. The roles in this outerlevel CA action are activated by external executing threads created immediately after thesystem begins its execution.The controllers presented in this section make the following assumptions:� The number of plates (N) introduced into the FZI Production Cell does not exceed7 (otherwise the system will deadlock).� three local queue objects (robotQueue, robotSensorQueue, and feedBeltQueue) areshared between the controllers and are used to send messages between them. Thesequeues have two methods: put and get. Put stores an element in the tail of the queue,and get retrieves an element from the head of the queue. If there is no element inthe queue, then get blocks the calling thread until an item is put on the queue.� sensor objects are local to the corresponding sensor controller.� actuator objects are local to the corresponding device controller.� plates are external objects.System initialisation, i.e. loading the FZI Production Cell with plates, is performed bya special controller, OperatorController, that is executed once and then terminates. Itsresponsibility is to put a set of plates onto the feed belt one at a time. When the operatoris ready to execute the LoadPlate action, it sends a message to the FeedBeltController, viafeedBeltQueue, and enters the LoadPlate action.OperatorController(plate[N]):loop i:1..N times f// wait user commandfeedBeltQueue.put(PLATE WITH OPERATOR)LoadPlate.Operator(plate[i])g 15

The FeedBeltController waits for messages from both OperatorController and CraneCon-troller. When it receives a message it chooses one of the two possible loading actions:LoadPlate or ReloadPlate. If FeedBeltController receives a PLATE WITH OPERATOR mes-sage from the OperatorController, then it executes LoadPlate action; otherwise it receivesa PLATE ON CRANE message from the CraneController and executes ReloadPlate action.After a plate has been deposited on the feed belt, FeedBeltController enters the LoadTableaction. When the plate has been passed to the TableController in LoadTable action, Feed-BeltController waits for a new message to arrive, and so on.FeedBeltController:Actuator feedBeltActuatorloop forever fmessage = feedBeltQueue.get()if (message == PLATE WITH OPERATOR)LoadPlate.FeedBelt(plate)else if (message == PLATE ON CRANE)ReloadPlate.FeedBelt(plate)LoadTable.FeedBelt(plate, feedBeltActuator)gThe TableController repeatedly receives a plate from the feed belt by calling LoadTable andthen passes the plate to the robot by calling UnloadTable. Note that LoadTable will notbe ready until FeedBeltController, FeedBeltControllerSensor, and TableSensorControllerare all ready, and UnloadTable will not be activated until RobotController, RobotSensor-Controller, and TableSensorController are all ready to participate in it, together withTableController. After the TableContoller has executed the LoadTable action, it sends aPLATE ON TABLE message to the RobotController signalling that there is a plate on thetable and the RobotController can execute an UnloadTable action.TableController:Actuator tableActuatorloop forever fLoadTable.Table(plate, tableActuator)robotQueue.put(PLATE ON TABLE)UnloadTable.Table(plate, tableActuator)gThe order in which CA actions are executed by RobotController depends on the messagesit receives from the other controller roles. RobotController waits for a message to ar-rive, via robotQueue, and then decides which action to execute depending on the stateof the arms of the robot. Sometimes the RobotController is not able to execute an ac-tion, e.g. if the TableController delivers messages to the RobotController faster than thePressController, it is highly probable that two PLATE ON TABLE messages arrive beforethan a FORGED PLATE IN PRESS message, so arm1 of the robot will still be holding a plateand therefore the robot will be unable to pick another plate up from the table. When sucha situation occurs, the RobotController stores the received message into the queue again.16

RobotController:Actuator robotActuatorBoolean arm1Free = TRUEBoolean arm2Free = TRUEloop forever fmessage = robotQueue.get()if ((message==PLATE ON TABLE) and arm1Free)frobotSensorQueue.put(PLATE ON TABLE)UnloadTable.Robot(plate1, robotActuator)arm1Free = FALSEgelse if ((message==PLATE FORGED IN PRESS) and arm2Free) frobotSensorQueue.put(PLATE FORGED IN PRESS)UnloadPress.Robot(plate2, robotActuator)arm2Free = FALSEgelse if ((message==DEPOSIT BELT FREE) and not arm2Free)frobotSensorQueue.put(DEPOSIT BELT FREE)LoadDepositBelt.Robot(plate2, robotActuator)arm2Free = TRUEgelse if ((message==PRESS FREE) and not arm1Free)frobotSensorQueue.put(PRESS FREE)LoadPress.Robot(plate1, robotActuator)arm1Free = TRUEgelse robotQueue.put(message)gPressController is responsible for activating three actions: LoadPress receives a plate fromarm1 of the robot; ForgePlate is the pressing process; and UnloadPress passes the plate fromthe press to arm2 of the robot. PressController is also responsible for sending messages tothe RobotController to signal if the press is free (PRESS FREE), or if there is a forged platein the press (FORGED PLATE IN PRESS).PressController:Actuator pressActuatorloop forever frobotQueue.put(PRESS FREE)LoadPress.Press(plate)ForgePlate.Press(plate)robotQueue.put(FORGED PLATE IN PRESS)UnloadPress.Press(plate)gDepositBeltController receives a plate in LoadDepositBelt, from arm2 of the robot, trans-ports the plate through the deposit belt by calling TransportPlate, and �nally sends the17

plate to the crane in UnloadDepositBelt. Depending on the number of plates that havebeen introduced into the FZI Production Cell, the DepositBeltController executes actionsin di�erent orders, but allows at most two plates to be on the deposit belt at any one time.The DepositBeltController sends the DEPOSIT BELT FREE message to the RobotControllerevery time the beginning of the deposit belt is free signalling that the RobotController canexecute the LoadDepositBelt action. The beginning of the deposit belt is free when the\controlling software" starts, and after TransportPlate has been executed.DepositBeltController:Actuator depositBeltActuatorrobotQueue.put(DEPOSIT BELT FREE)LoadDepositBelt.DepositBelt(plate)loop forever fTransportPlate.DepositBelt(plate, depositBeltActuator)robotQueue.put(DEPOSIT BELT FREE)if (N > 2) fLoadDepositBelt.DepositBelt(plate)UnloadDepositBelt.DepositBelt(plate)gelse fUnloadDepositBelt.DepositBelt(plate)LoadDepositBelt.DepositBelt(plate)ggCraneController will receive a plate when it executes UnloadDepositBelt, together withDepositBeltController and CraneSensorController, and will send this plate to the feed beltduring ReloadPlate. When CraneController has �nished UnloadDepositBelt action, it sendsa PLATE ON CRANE message to the FeedBeltController signalling that there is a plate on thecrane, so that the FeedBeltController can execute the ReloadPlate action.CraneController:Actuator craneActuatorloop forever fUnloadDepositBelt.Crane(plate, craneActuator)feedBeltQueue.put(PLATE ON CRANE)ReloadPlate.Crane(plate, craneActuator)gIn addition to the controllers shown above, we have controllers for the sensor(s) of eachdevice in the system. These controllers send information about the sensors of a givendevice to an action. Here for example is the RobotSensorController (see Appendix B forall sensor controllers): 18

RobotSensorController:Sensor arm1ExtensionSensor, arm2ExtensionSensor, angleSensorloop forever fmessage = robotSensorQueue.get()if (message == PLATE ON TABLE)UnloadTable.Robot(arm1ExtensionSensor, angleSensor)else if (message == PLATE FORGED IN PRESS)UnloadPress.Robot(arm2ExtensionSensor, angleSensor)else if (message == DEPOSIT BELT FREE)LoadDepositBelt.Robot(arm2ExtensionSensor, angleSensor)else if (message == PRESS FREE)LoadPress.Robot(arm1ExtensionSensor, angleSensor)g

Table

Crane

Operator

Load

Unload

means that the Controller participates in that Action, and a plate is sent/ received to/from that Action

Press

BeltDeposit

Press

Press

FeedBelt

Arrow connecting Action and Controller

Robot

Controlling Software

Load

DepositLoad

Belt

TableUnload

TableLoad

ReloadPlate

BeltDepositUnload Transport

Plate

Plate

ForgePlate

Shaded circles represent ActionsWhite circles represent Controllers

Dotted arrows represent message passing

Figure 5: Relations among Actions and Device ControllersFigure 5 shows the relations between actions and device/sensor controllers. A solidline represents that the controller executes a role in the action. An arrow in a solid linerepresents the plate being sent from one device to another through an action. Dashed linesrepresent the passing of messages between the controllers. Shadowed circles represent theset of top-level actions we have designed and the white circles represent the device/sensorcontrollers. 19

3.4 Action ImplementationIn this section, we describe implementation issues related to the set of actions that thecontroller roles use to control the sequence of operations that the devices will execute (fora complete implementation of all actions see Appendix A). All actions are designed in orderto guarantee the safety requirements of the Production Cell. For example, the requirementof keeping plates su�ciently distant is guaranteed because only one plate can be inside anaction at a time and the areas enclosed by the actions are su�ciently distant from eachother. Typically, each CA action represents the interaction between two devices as thesedevices exchange a plate.All CA actions manipulate an external object (plate) that is passed to the CA actionas an input parameter. Only when the CA action is �nished can the object be used byanother action.For safety reasons, all the actions designed for the FZI Production Cell are synchronousactions, i.e. they begin only when all participants have \arrived" (called a role in the action)and end only when all participants are ready to \depart" (have �nished executing theirrespective roles).Wait

MoveTableUp

ExtendArm1Robot

Plate

Arm1

Rotate

Retract

Table

Rotate

Table Plate

Plate

TableSensor

Robot

RobotSensor

Figure 6: UnloadTable CA actionIn our design, every action is composed of a set of roles, a set of internal objects, anda set of external objects (in our case just one plate). Note that synchronous entry andexit, global exception handling, recovery, consistency and atomicity of external and localobjects, and so on, are guaranteed by the CA action abstraction [6] (See Section 2).Inside an action, each role is represented by a name and a set of parameters, inputor output. Local objects within each action are used to support cooperation between theroles by allowing them to send information between themselves. For example,UnloadTablehas four roles: Table, TableSensor, Robot and RobotSensor. The Table role receives a plateas input parameter, and this same plate is sent to the Robot role via a special local objectcalled channel. In Figure 6 we represent the passing of a plate from one role to anotheras a solid arrow. When the Robot role receives the plate via channel, it changes the stateof the plate and returns the plate as an output parameter. The accessing to the external20

object plate is represented by a dotted arrow in Figure 6. See the pseudo-code for theUnloadTable action below:roles:TableSensor (in topSwitchSensor, tableAngleSensor) fRotateTable.TableSensor(tableAngleSensor,50)MoveTableUp.TableSensor(topSwitchSensor)gTable (in plate, tableActuator)fRotateTable.Table(tableActuator)MoveTableUp.Table(tableActuator)Wait.Table()channel.put(plate)gRobot (out plate, in robotActuator)fRotateRobot.Robot(robotActuator)ExtendArm1.Robot(robotActuator)Wait.Robot()robotActuator.arm1MagnetOn()plate = channel.get()plate.changeState('Arm1Robot')RetractArm1.Robot(robotActuator)return plategRobotSensor (in arm1ExtensionSensor, robotAngleSensor) fRotateRobot.RobotSensor(robotAngleSensor, 50)ExtendArm1.Robot(arm1ExtensionSensor, 0.5208)RetractArm1.Robot(arm1ExtensionSensor, 0.0)glocal:CAaction ExtendArm1,RetractArm1.RotateRobot,Wait,RotateTable,MoveTableUpChannel channelOur approach to dealing with sensors and actuators basically relies on the general ideasfrom [8], which proposes two ways of dealing with peripheral devices: synchronous andasynchronous. When a device is served synchronously, each input/output operation issynchronous and active waiting is hidden inside the operation. External software (e.g.an action role) operates with this device by using an interface provided by the synchron-ous wrapper. With asynchronous wrapping, each device is represented as an active rolewhich operates with the device, executes active waiting and can inform other roles aboutchanges of the device state. These two ways are obviously complementary and, generallyspeaking, each device is manipulated in a synchronous way on one system level and in anasynchronous way on another; we believe that the choice should depend on the application.After analysing the FZI Production Cell and our control system we decided to treatall actuators and sensors as the local objects of the corresponding controllers. Using21

application-speci�c information from our system design (in particular, the facts that thereis no action competition for these objects, that these objects are used only by actions butnot by the controllers, and that the mutual exclusion of action executions is guaranteed byour design) we chose the following ways of using these objects. Sensor-objects are passedas input-output parameters to the corresponding actions. Actuator objects are used withinactions without any coordination (this makes the design simpler, since the exclusive use ofthese objects is guaranteed by the fact that the corresponding sensors can take part only inone action at a given time). In addition, we have designed a separate sensor role for eachdevice used in an action. This role cooperates with other action roles and informs themabout changes of the sensor states. To do this it waits actively for changes in these states.These roles manipulate sensor-objects which know the peculiarities of the device and wrapit properly (without hiding the active waiting). The actuators are wrapped in such a waythat the synchronous method call is provided, this is why each of them is attached to (usedby) a particular action role. The implementation of these objects can include hidden activewaiting.We have implemented a special role in the outmost enclosing CA action in order tomonitor the state of all plates in the FZI Production Cell. This monitor role competes withthe top-level CA actions to check the state of the plate objects based on some transactionalsemantics. When a plate object is not being used by a CA action the monitor can haveaccess to it by starting a transaction on that plate object. If the plate is being used bya CA action, then the monitor has to wait until the CA action is �nished. The monitorcannot see any intermediate states of the plate. For example, when an exception is raisedin a CA action, the monitor will not be able to see any change of the plate state beingcaused by forward or backward error recovery. On the other hand, each execution of a CAaction should also, in some sense, behave like a transaction with respect to the plate objectit accesses. What is needed therefore is an underlying mechanism or system that controlsconcurrent access to shared external objects.In our system, the transactional semantics of CA actions are achieved by implementinga multi-threaded CA action interface on the top of JavaArjuna system. The Arjuna sys-tem is an object-oriented programming system that supports nested atomic transactionsfor structuring fault-tolerant applications [7]. It was originally implemented in C++ andis currently improved and re-written in the Java language, hence the name JavaArjuna.Arjuna employs nested transactions to control state changes of objects and to ensure thatonly consistent state transformations occur on objects despite concurrent access and fail-ures. Our implementation of CA actions issues a transaction on the external objects of theaction (e.g. the plate objects) whenever a new CA action starts, and ends the transactionwhen the CA action terminates. The multi-threaded mechanism in JavaArjuna is exploitedas follows: the thread that �rst arrives at the CA action interface starts a transaction, andother subsequent threads will then join the same transaction. At the exit, the transactionis ended by removing all the participating threads from the transaction synchronously.We omit further details of our implementation here due to limitation of space; a reportdetailing our JavaArjuna-based implementation as a whole is now in preparation.22

3.5 Fault Tolerance in the Production CellThe FZI Production Cell case study considers that the safety requirements are the mostimportant requirements in the system. As we explained before we have introduced anCA action every time there is an interaction between devices or the plate is forged. Weassume that transient faults can happen at any time during the execution of an action.When a fault is detected, an exception is raised and the CA action manager informs all theother participants in the CA action that they have to interrupt their execution. After allparticipants are ready to handle the fault, an exception is raised in all participants. Theythen use backward error recovery to move the system back to the state it was in when theaction started.Down

Table

Move

Move

TableBack

Robot

Rotate

Table

Robot

Back

Rotate

TableUp

RotateRotate

Table Plate

TableSensor

Robot

RobotSensor

ExceptionPlate

ActionUnloadTable

Execution

Normal

See

Recovery

PlateFigure 7: Backward Error Recovery in UnloadTable ActionIn Figure 7 we show an exception being raised after the robot has rotated and beforethe robot has extended its arm (see Figure 6). This exception is caught by the CA actionwhich informs all participants. When all participants are ready to handle the exception,they enter a recovery phase where they are rolled back to their initial state (the state theparticipants had when they started the action). When the recovery phase is �nished theaction restarts by reactivating all the participants.3.6 DiscussionWe are aware that a realistic Production Cell would have di�erent execution phases, e.g.i) initialisation phase - the cell is �lled with plates; ii) stable, or cyclic, execution phase- the cell processes the plates in a cyclic way; and iii) �nalisation phase - all the platesare removed from the cell before the system �nally stops. In the task description of theFZI Production Cell case study [4], only the cyclic execution phase is addressed, withoutmentioning other phases. Most of the published solutions to the case study do not dealwith both the initialisation and �nalisation phases, and only a few take the initialisation23

phase into account. Since considering all three phases might further complicate the designof the entire system, we followed this example and chose to ignore the �nalisation phasein this paper.Note that the order in which CA actions are executed by the controllers in our systemdepends on the number of plates introduced into the Production Cell. For example, if fourplates fP1, P2, P3, P4g are introduced into the Production Cell then one of the possibleinitialisation phases is shown in Figure 8, and one of the possible cyclic phases is shown inFigure 9 (to simplify the �gures we do not include the sensor's controllers).

Press

DepositBeltLoad

TableUnload

Table

DepositBelt

Unload

Unload

Load

FeedBelt

Table

P1 P2 P3 P4

P4P3

P2

P2

P1 P2 P3

P1

P1

P2 P3

P1

P1

Operator

Press

DepositBelt

Crane

P1

P1

P2

P1

P1Robot

P1 P1

LoadTable

P1

P1

ForgePlate

LoadPress

LoadTable

LoadPlate LoadPlate

LoadTable

LoadPlate LoadPlate

Figure 8: Initialisation Phase with four PlatesIn our design, we have concentrated on clear system structuring rather then on max-imising the system performance, e.g. having more parallel actions (for example, we couldhave designed a special action to move the table back to its original position, actuallythis is done inside LoadTable action). Performance could be enhanced but at the cost ofsimplicity, maintainability and as a result future safety. We did not investigate perform-ance issues in any detail because the performance essentially depends on data about thetime required to execute each operation (which is not provided as part of the case study).Without this data it is not possible to choose the solution with the best performance. Atthe same time we have tried to allow as much parallelism as possible without sacri�cingsafety. It is interesting that if we had \too many" parallel actions then actually they wouldoften wait for each other.Our system is logically correct and safe when it works with any number between oneand seven plates. But it would require additional analysis and real application-dependentdata to �nd what is the best performance and how many plates should be put in the systemto achieve it. 24

Plate

Load

TransportDepositBelt

LoadDepositBelt

PlateTransport

DepositBeltUnload

FeedBelt

Table

P4 P1

P3

P2 P3

P4

P2

P1P1

Crane

P1

Robot

Press

DepositBelt

P3

P2P2

P1

P2

P2

P2

P1

P2 P2

P3

Cycle

LoadTable

P2

LoadPress

ForgePlate

UnloadTable

UnloadPress

ReloadPlate

ReloadPlate

LoadPress

Figure 9: Cyclic Phase with 4 PlatesIn the future we will extend our system to demonstrate the full power of CA actionsbut this requires extending the de�nition of the FZI case study. One likely direction is theintroduction of exception handling features, both within the lower-level CA actions, andwithin the top-level CA action, to deal with erroneous situations that are detected via thesensors, or via error-checking code.3.7 Driving the FZI Production Cell SimulatorA full implementation of the design described in this document has already been producedusing the Java programming language. The controlling software implemented in Java isused to drive a simulator provided by FZI which is implemented in Tcl/Tk.Figure 10 is a screen dump which shows the FZI Production Cell Simulator being drivenby our implementation. Outlines of the CA actions are superimposed on the simulatordiagram, and these outlines are gradually coloured in to represent progress through aCA action. In Figure 10 three actions are active and being executed: UnloadDepositBelt,UnloadTable, and ForgePlate. When an exception is raised in one of the actions, the colourof the �lling is changed to represent the action has entered in its exception handling phase.During the simulation our controlling software also shows a console window for the activeactions, and a monitor window with the state of the plates.25

Figure 10: Java Implementation4 Concluding RemarksOur system allows plates to be fed into the FZI ProductionCell initially and then cyclescorrectly once the chosen number of plates has been loaded. (The problem of systeminitialisation is not mentioned in the original FZI Production Cell task description butmust be addressed in any simulation.)We have designed 10 CA actions which are activated by controller roles belonging toan enclosing CA action; the order of action executions is imposed by these controller roles.Each device of the FZI Production Cell has a corresponding controller role. Each CA actiontypically controls one step of the plate processing and involves passing a plate between twodevices. The actions are designed in such a way that the main safety requirements areguaranteed because only one plate can be in an action at a given time and because anydevice can be only in one action at a time. The actions are safe atomic building blocksthat can be used for programming di�erent systems. Indeed, we produced various solutionsto the FZI Production Cell problem, all safely using the same set of CA actions, beforesettling on the one presented here.The design and implementation of a system that guarantees the safety requirementswas greatly facilitated by the use of CA actions. The resulting system has a clean design26

which is easy to understand, and we believe that this will facilitate its formal validation.We would like to mention that although the case study and hence our design do not ad-dress any timing properties, it would be straightforward to extend pre- and post-conditionsto make use of timing speci�cations, though guaranteeing acceptable real time behaviourwould obviously be a signi�cant (albeit conventional) real time design task. However whatwould be particularly interesting would be to investigate how well our CA action structure,and the use of physically separate computers for each of the controllers, could be used inconnection with the temporal �rewalls approach [5] to structuring complex distributed realtime systems.5 AcknowledgementsThis research has been supported by ESPRIT Long Term Research Project 20072 on\Design for Validation" (DeVa). Avelino Zorzo is also supported by CNPq (Brazil) undergrant number 200531/95.6. It has bene�tted from discussions with a number of colleaguesin DeVa, in particular A. Burns, A. Wellings, and S. Mitchell (York/UK), and D. Buchs,G. Di Marzo, C. Peraire, and N. Guel� (EPFL/Switzerland).References[1] R. H. Campbell and B. Randell, \Error Recovery in Asynchronous Systems". In IEEETransactions on Software Engineering, SE-12(8), pp. 811-826, 1986.[2] F. Cristian, \Exception Handling". In Dependability of Resilient Computers (ed. T.Anderson), pp. 68-97, Blackwell Scienti�c Publications, Oxford, UK, 1989.[3] N. Francez and I. R. Forman, Interacting Processes - A Multiparty Approach to Co-ordinated Distributed Programming. Addison-Wesley Publishers Ltd., 1996.[4] C. Lewerentz and T. Lindner. \Formal Development of Reactive Systems: Case StudyProduction Cell". In Lectures Notes in Computer Science 891, Springer-Verlag, Janu-ary 1995.[5] H.Kopetz, R.Nossal. \Temporal Firewalls". In Large Distributed Real-Time Systems.Research Report 7/97. ITI, TU Wien. 1997.[6] B. Randell, A. Romanovsky, R. J. Stroud, J. Xu, and A. F. Zorzo. \CoordinatedAtomic Actions: from Concept to Implementation". Department of Computing Sci-ence, Technical Report TR595, University of Newcastle upon Tyne, 1997.[7] S. Shrivastava, G. N. Dixon, and G. D. Parrington, \An Overview of the ArjunaDistributed Programming System". In IEEE Software, 8(1), pp. 66-73, 1991.27

[8] N. Wirth. \Toward a Discipline of Real-Time Programming". In CACM, 20, 8, August,1977.[9] J. Xu, B. Randell, A. Romanovsky, C. Rubira, R. Stroud, and Z. Wu. \Fault Tolerancein Concurrent Object-Oriented Software through Coordinated Error Recovery". InProceedings of the 25th Int. Symp. on Fault-Tolerant Computing, IEEE CS Press,Pasadena, USA, 1995, pp. 450-457.[10] A. Romanovsky, J. Xu and B. Randell, \Exception Handling and Resolution in Distrib-uted Object-Oriented Systems". In Proceedings of 16th IEEE International Conferenceon Distributed Computing Systems, pp.545-552, Hong Kong, May 1996.6 Appendix AIn this section we present the implementation of all the CA actions, using pseudo-code.We omit the description of exception handling, and the checking of the pre-conditions inthe beginning of each action. Some of the pre- and post-conditions can be easily checkedby looking at the state of the sensors, while post-conditions will be considered valid if thereare no exceptions during the execution of an action.6.1 LoadPlatePlate

Plate

FeedBelt Plate

Operator

Figure 11: LoadPlateLoadPlate:roles:Operator (in plate) fchannel.put(plate)gFeedBelt (out plate) fplate = channel.get()plate.changeState(\FeedBelt\)return plateg 28

local:Channel channel6.2 LoadTable

PlateMove

Plate

TableRotate

DownTableMove

FeedBeltSensor

Table

FeedBelt Plate

Plate

TableSensor

Wait

Figure 12: Action1LoadTable:roles:TableSensor (in bottomSwitchSensor, in tableAngleSensor) fMoveTableDown.TableSensor(bottomSwitchSensor)RotateTable.TableSensor(tableAngleSensor,0)gTable (out plate, in tableActuator)fMoveTableDown.Table(tableActuator)RotateTable.Table(tableActuator)Wait.Table()plate = channel.get()plate.changeState(\Table\)return plategFeedBelt (in plate, in feedBeltActuator) fWait.FeedBelt()MovePlate.FeedBelt(feedBeltActuator)channel.put(plate)gFeedBeltSensor (in photoElectricSensor)fMovePlate.FeedBeltSensor(photoElectricSensor)glocal: 29

CAAction MovePlate,Wait,RotateTable,MoveTableDownChannel channel6.3 UnloadTableWait

MoveTableUp

ExtendArm1Robot

Plate

Arm1

Rotate

Retract

Table

Rotate

Table Plate

Plate

TableSensor

Robot

RobotSensor

Figure 13: UnloadTableUnloadTable:roles:TableSensor (in topSwitchSensor, in tableAngleSensor) fRotateTable.TableSensor(tableAngleSensor,50)MoveTableUp.TableSensor(topSwitchSensor)gTable (in plate, in tableActuator)fRotateTable.Table(tableActuator)MoveTableUp.Table(tableActuator)Wait.Table()channel.put(plate)gRobot (out plate, in robotActuator)fRotateRobot.Robot(robotActuator)ExtendArm1.Robot(robotActuator)Wait.Robot()robotActuator.arm1MagnetOn()plate = channel.get()plate.changeState(\Arm1Robot\)RetractArm1.Robot(robotActuator)return plategRobotSensor (in arm1ExtensionSensor, in robotAngleSensor) fRotateRobot.RobotSensor(robotAngleSensor, 50)30

ExtendArm1.Robot(arm1ExtensionSensor, 0.5208)RetractArm1.Robot(arm1ExtensionSensor, 0.0)glocal:CAactionExtendArm1,RetractArm1.RotateRobot,Wait,RotateTable,MoveTableUpChannel channel6.4 LoadPressArm1

Retract Arm1Robot

Extend

MiddlePress

Plate

Rotate

Move

Press

Plate

Plate

PressSensor

Robot

RobotSensor

Wait

Figure 14: LoadPressLoadPress:roles:PressSensor(in middleSwitchSensor) fMovePressMiddle.PressSensor(middleSwitchSensor)gPress (out plate, in pressActuator) fMovePressMiddle.Press(pressActuator)Wait.Press()plate = channel.get()plate.changeState(\Press\)return plategRobot (in plate, in robotActuator)fRotateRobot.Robot(robotActuator)Wait.Robot()ExtendArm1.Robot(robotActuator)robotActuator.arm1MagnetOff()channel.put(plate)RetractArm1.Robot(robotActuator)31

gRobotSensor (in arm1ExtensionSensor, in robotAngleSensor) fRotateRobot.RobotSensor(robotAngleSensor, -90)ExtendArm1.Robot(arm1ExtensionSensor, 0.6458)RetractArm1.Robot(arm1ExtensionSensor, 0.0)glocal:CAaction ExtendArm1,RetractArm1,RotateRobot,Wait,MovePressMiddleChannel channel6.5 ForgePlatePlate

Press Plate Plate

Figure 15: ForgePlateForgePlate:roles:Press (in out plate, in pressActuator) fpressActuator.forge()plate.changeState(\ForgedInPress\)return plateg6.6 UnloadPressUnloadPress:roles:PressSensor(in bottomSwitchSensor) fMovePressDown.PressSensor(bottomSwitchSensor)gPress (in plate, in pressActuator) fMovePressDown.Press(pressActuator)Wait.Press()channel.put(plate)g 32

ExtendArm2

RetractArm2Robot

DownPress

Plate

Rotate

Move

Press

PressSensor

Plate

PlateRobot

RobotSensor

Wait

Figure 16: UnloadPressRobot (out plate, in robotActuator) fRotateRobot.Robot(robotActuator)Wait.Robot()ExtendArm2.Robot(robotActuator)robotActuator.arm2MagnetOn()plate = channel.get()plate.changeState(\Arm2Robot\)RetractArm2.Robot(robotActuator)return plategRobotSensor (in arm2ExtensionSensor, in robotAngleSensor) fRotateRobot.RobotSensor(robotAngleSensor, 35)ExtendArm2.Robot(arm2ExtensionSensor, 0.7971)RetractArm2.Robot(arm2ExtensionSensor, 0.0)glocal:CAaction ExtendArm2,RetractArm2,RotateRobot,Wait,MovePressDownChannel channel6.7 LoadDepositBeltLoadDepositBelt:roles:DepositBelt (out plate) fplate = channel.get()plate.changeState(\BeginningDepositBelt\)return plategRobot (in plate, in robotActuator) f33

Arm2RetractArm2

Extend

Plate

RobotRotate

DepositBelt

Plate

Plate

RobotSensor

Robot

Figure 17: LoadDepositBeltRotateRobot.Robot(robotActuator)Wait.Robot()ExtendArm2.Robot(robotActuator)robotActuator.arm2MagnetOff()channel.put(plate)RetractArm2.Robot(robotActuator)gRobotSensor (in arm2ExtensionSensor,in robotAngleSensor) fRotateRobot.RobotSensor(robotAngleSensor, -90)ExtendArm2.Robot(arm2ExtensionSensor, 0.5707)RetractArm2.Robot(arm2ExtensionSensor, 0.0)glocal:CAaction ExtendArm2,RetractArm2,RotateRobotChannel channel6.8 TransportPlatePlate

DepositBeltSensor

DepositBelt Plate Plate

Wait

Figure 18: TransportPlateTransportPlate: 34

roles:DepositBelt (in out plate, in depositBeltActuator) fdepositBeltActuator.on()Wait.DepositBelt()depositBeltActuator.off()plate.changeState(\EndDepositBelt\)return plategDepositBeltSensor (in photoElectricSensor) fwhile (photoElectricSensor.off()) ;while (photElectricSensor.on()) ;Wait.DepositBeltSensor()glocal:CAAction Wait6.9 UnloadDepositBeltMoveCraneDown

MoveCrane

Deposit

Plate

CraneToUp

Move

DepositBelt

Crane

Plate

Plate

CraneSensor

Figure 19: UnloadDepositBeltUnloadDepositBelt:roles:Crane (out plate,in craneActuator) fMoveCraneToDeposit.Crane(craneActuator)MoveCraneDown.Crane(craneActuator)craneActuator.magnetOn()plate = channel.get()plate.changeState(\Crane\)MoveCraneUp.Crane(craneActuator)return plategDepositBelt (in plate) f 35

channel.put(plate)gCraneSensor (in upperSwitchSensor, in craneHeightSensor) fMoveCraneToDeposit.CraneSensor(upperSwitchSensor)MoveCraneDown.CraneSensor(craneHeihtSensor,0.9450)MoveCraneUp.CraneSensor(craneHeihtSensor,0.6593)glocal:CAAction MoveCraneToDeposit,MoveCraneDown,MoveCraneUpChannel channel6.10 ReloadPlateToFeed

Move

Plate

Crane

Crane

FeedBelt Plate

Plate

CraneSensor

Figure 20: ReloadPlateReloadPlate:roles:FeedBelt (out plate) fplate = channel.get()plate.changeState(\FeedBelt\)return plategCrane (in plate, in craneActuator) fMoveCraneToFeed.Crane(craneActuator)craneActuator.magnetOff()channel.put(plate)gCraneSensor (in lowerSwitchSensor, in craneHeightSensor) fMoveCraneToFeed.Crane(lowerSwitchSensor,craneHeightSensor)glocal:CAAction MoveCraneToFeed 36

Channel channel7 Appendix B - Sensor ControllersFeedBeltSensorController:Sensor photoElectricSensorloop forever fLoadTable.FeedBeltSensor(photoElectricSensor)gDepositBeltSensorController:Sensor photoElectricSensorloop forever fTransportPlate.DepositBeltSensor(photoElectricSensor)gPressSensorController:Sensor middleSwitchSensor, bottomSwitchSensorloop forever fLoadPress.PressSensor(middleSwitchSensor)UnloadPress.PressSensor(bottomSwitchSensor)gCraneSensorController:Sensor upperSwitchSensor, lowerSwitchSensor, craneHeightSensorloop forever fUnloadDepositBelt.CraneSensor(upperSwitchSensor,craneHeightSensor)ReloadPlate.CraneSensor(lowerSwitchSensor, craneHeightSensor)gTableSensorController:Sensor bottomSwitchSensor, topSwitchSensor, tableAngleSensorloop forever fLoadTable.TableSensor(bottomSwitchSensor, tableAngleSensor)UnloadTable.TableSensor(topSwitchSensor, tableAngleSensor)g

37