ors, and all problems with executing activi- ties. The user sees by the type of error response (generalFault, stateError, Refuse and ReportRefuse) which type of error has happened. The responses provided by 7 Concepts and Notations for Process Control Systems Modelling generalFault and stateError are independent of the content of the particular opera- tion. These operations are therefore specified as part of AML. Responses given by Refuse and ReportRefuse are unique for the particular operation, and must be specified in the corresponding operation specification. generalFaultRepCnf stateErrorRepCnf errorResponses Refuse ReportRefuse Fig. 7.61 Error handling in the state machine Figure 7.61 shows where in the model some type of error handling is performed. 1. For external initiating events, port objects provide all checks associated with the operation specification of concern. Primarily port objects must check that time constraints are fulfilled, and that the partner initiates valid responses. Optionally, port objects can check a number of other things that otherwise should be han- dled by the protocol element in which the state machine runs. All errors that are detected by a port object are reported to the partner with the event generalFaultRepCnf. This event tells the partner that some operation requirements are violated, and that the machine remains in the prior resource state. Note that in all these error situations, neither EO nor SO are involved. 2. A provider port object also provides part of the state error control, called exist- ence control. This type of control is based on the fact that all entities of the resource model must have an identifier property (#). When the specifications are compiled, the compiler types the corresponding variable in the operation speci- fication as an IDENTITY type. When users request modifier operations, PO looks for parameters of the IDENTITY type. Before PO allows EO to start working, PO checks against SO that the referred entity exists in the SVS. PO uses the operation exi