dition that defines the changes to the state when the transition is fin- ished. One or several result events (optional). Result events are communication events. AML offers two forms for behaviour specifications: state diagrams and event specifications. To translate a state diagram into a set of event specifications is an example of specification refinement. 7.5 Behaviour Descriptions A state diagram is a graphical description of the behaviour, where the same type of initiating event can occur in many transitions. State diagrams are intended for human interpretation. An event specification is a textual description of all transitions that have the same type of initiating event. Event specifications are used for simulation and code generation. Since behaviour descriptions rely on the behaviour defined by primitive service specifications, a distinction must be made between port state and object state. Port states are used for describing service behaviour, object states for describing object behaviour. By definition, an object state is a relation over all ports that the object has. For example, if an agent with one user port, at a particular point in time, has state ps in its provider port and state us in its user port, the agent's state is {ps, us}. 7.5.2 Port State Since the purpose of process control systems is to control the state of resources, AML takes the following view on behaviour: The purpose of interactions between service objects is to change states, or to report state changes that are defined by resource models. Thus, behaviour descriptions describe transitions between states (with the exception of invoked transformer operations). For a behaviour description to pro- vide some meaningful information, every referred state must be specified. In this section, we will therefore discuss the different kinds of port states and how they are specified. Figure 7.42 is a semantic diagram that includes all relevant concepts. Most of these concepts were exemplified in the case study in Sect. 6.2. ExplicitState Interrup