ig. 7.60. The normal scenario: 1. The cause for an internal event is, in this case an event generated by AO and detected by EO. EO reads the corresponding EVS that defines the postcondition, and the SVS becomes modified. No external event is initiated in the provider port, i.e. the user is, SO far, not aware of this change of resource state. 2. We assume that the change of SVS concerned a "trigger variable" for an internal event. Trigger variables are defined in the resource model by attributes with the prefix iie, and by defining trigger threshold values. This information is compiled into the SVS. Every time the EO orders the SO (by a postOrder) to change SVS, SO checks if the change affected a trigger variable, and if so, if a threshold value is passed. 3. If so, SO immediately initiates an intEventRepCnf(<iieName>) towards EO. 4. EO uses the internal event name to find the corresponding EVS as usual, which, in this case, says only that a result event must be generated in the provider port. Some provider-initiated events will be generated (here a ReportConfirm is assumed). The forced state change scenario (this scenario is a "backward scenario" com- pared to normal modifier operations): 1. The user initiates an initiate operation that requests a state change in SVS. PO initiates a postOrder to SO that makes a trigger variable pass a threshold value. 2. SO immediately initiates an intEventRepCnf(<iieName>) towards EO. 3. EO handles the corresponding EVS and activity execution in the usual way. 4. When the transaction is finished, the EVS says that no postcondition has to be set and no resulting event has to be generated (since the user used an Order event). The final scenario, see Fig. 7.61, discusses the four types of error-handling mechanisms in the state machine, two of them performed by the PO, the others by the EO. PO has an important role in not burdening the EO when a requested opera- tion cannot be accomplished because of some types of event and state errors. EO must still handle other types of state err