hat the event object defines in the precondition. To trigger internal events. Every time the event object orders the state object to change state, the state object verifies whether if any of the variables that were changed was a trigger variable (classified as an iie property in the resource model), and if so, whether it reached a trigger value. If so, the state object initi- ates a intEvRepCnf(<iieName>) towards the event object. The event object stores event specifications for all modifier operations and eval- uates the referred event specification for each devRepCnf(<external event>) and intEvRepCnf(<iieName>). During the evaluation it uses: The operation preREQ for checking whether there is a state error. The activity objects for executing the referred activity. The operation postORD for changing the state. The operation gevORD for generating external events. None of the objects mentioned thus far can perform any changes in the resource system. The state object only records state changes, it does not produce any. Resource state changes can only be caused by activities that are performed by activity objects, under the control of the event object. The name of the activity (aTR in our example) refers a transaction specification. A transaction specification describes how the activity objects will be used for the actual operation. Figure 7.57 shows an example. 7 Concepts and Notations for Process Control Systems Modelling Transaction specification for aTR aTRRequest(...); Event object RA-routeAna(in:...;out: resp,RM1,RM2); refers Case resp chSeizeReq Refuse aTRRefuse(...) Confirm -> routeld=RM1; L1: routeld-chReserve(out:resp,chid); Case resp Refuse-> if (route=RM1) then goto L2 else return aTRRefuse(...): Other Confirm -> return aTRCnf(routeld,Chld): Route Route Routing activity L2: routeld=RM2; manager manager analyser objects goto L1; Activity objects Fig. 7.57 A transaction example The event specification for hSeizeRequest refers the transaction specification for aTR. This specification uses three activity obj