 on the assumption that the previous activity succeeded. The result is an inconsistent state of the system, which might imply that the user must interrupt whatever doing and start some kind of recov- ery action. For operations that must provide a response, ROSE defines two operation classes, one synchronous and one asynchronous. This kind of information does not concern the definition of which sequences of events are allowed in a particu- lar operation, and should therefore not be part of the definition of operation classes. In AML synchronization properties are declared as operation properties, see Sect. 7.4.5. 7 Concepts and Notations for Process Control Systems Modelling To avoid state inconsistencies, it is important that whenever the user's future actions depend on the outcome of an activity, the response shall define if the activ- ity succeeded or not. If no response is given, it should be because the user's future actions do not depend on the outcome of the operation request (as, e.g. when a con- nection user requests disconnection; whether the provider succeeds in removing the connection is of no concern to the user). The AML operation classification system is inspired by ROSE, but improves and purifies the concept of operation class, to be more supportive for modelling the service networks of process control systems. It is based on four criteria: 1. Which party is the initiator of the activity: the user or the provider, 2. When the provider is the initiator, is the activity run with or without the user's consent, 3. Is the outcome of the activity confirmed or not, 4. Positive and negative responses are separated as different ASPs. Applying these criteria for sequences of communication events for an operation, one gets six general (valid for any operation) sequences, according to Fig. 7.29. User initiates Provider initiates Provider initiates User has no say User decides REQUEST REPORT INVITE Invite Request ReportConfirm Request Confirm or Refuse activity ReportRefuse Reject confirmed Confirm or Refuse OR