rk, consisting of three service objects, ob1, ob2 and ob3, that are instantiated from three object types OB1, OB2 and OB3. The behaviour of an object type depends on a number of primitive service behaviours. For example, the behaviour of OB2 is a function of the behaviour that is associated 7 Concepts and Notations for Process Control Systems Modelling with S2 and S3. Note that the behaviour in a user port is a partial behaviour of the behaviour of the corresponding primitive service. A service network is created by instantiating object types and connecting them by service relations. As a result, the behaviour of the provider port of an object in the network becomes modified. For example, the object type OB2 has a behaviour in its provider port that is defined by S2. However, the instance ob2 has a partial behaviour of S2 in its provider port, defined by the user port of object type OB1. Figure 7.41 is a semantic diagram that shows information elements and concepts that are used in behaviour descriptions. isARelation PortState OverAll ObjectState (see Fig. 7.42) (see Sect. 7.5.3) State defines defines Result Precondition Activity Postcondition Communication Event Event (see Fig. 7.22) External Initiating Event Transition Internal refers Service Initiating isAspecification *) describes Behaviour Event RefinementOf Specification State *) All transitions must refer diagram the same initiating event Object Behaviour Behaviour Event Specification Specification specification Fig. 7.41 Concepts for behaviour specification A state diagram is a graphical representation of a behaviour, consisting of tran- sitions. Each transition is defined by: An initiating event, which is either one of the ten types of communication events that are defined by the operation classification system (see Fig.7.29), or an inter- nal initiating event. A precondition that defines states in which the initiating event is allowed. An optional activity reference. Note that activities cannot be referred to by peer objects (see Sect. 7.4.3). A postcon