o purposes of a service behaviour specification: to define how service objects shall behave in serv- ice relations, and to support service object specification. Specifying service behaviour is normally rather simple, provided that a suitable service network is defined, all service resource models are well understood and a suitable set of operations are defined. When modelling service behaviour, every object behind a provider interface that is involved in the execution of an operation can be regarded as an invisible part of the substructure of a virtual object (an imag- inary object that provides a service without using any other services). This is 6 Process Control System Modelling because the service resource model in such an interface abstracts all lower-level service resource models. Figure 6.15 exemplifies this for our PCS. Note that by introducing the virtual object concept, a service behaviour becomes a special case of object behaviour (i.e., the behaviour of a virtual object). Partial models for specifying The service network service behaviour These models consist only of users and virtual objects. S1, S2, etc. are identifiers for the services that are provided AccRoute CoreRoute AccRoute CoreRoute Controller Manager Manager Controller Controller Manager Manager Controller CNS Connection Control System Fig. 6.15 Service behaviour is the behaviour of virtual objects The interaction elements in a service relation are communication events, i.e. instances of ASPs (not messages!). Although there might exist some objects in a service network that are not state oriented, we assume that most objects are. A service behaviour can therefore be described in state diagrams, based on states that are defined by, e.g. the actual service resource model. Figure 6.16 shows how the service behaviour related to S1 (based on the TNW) between a calling TEC and the PCS can be described as AML state diagrams. The calling TEC exists on TE- SAPI=A and is requesting a call to TE-SAPI=D. The service relation identifier: The state diag