ces for accepted service relations, and rejections for those that cannot be accepted. 4. OPH collects the result and associates each accepted local object reference with the suggested SRid, and initiates the response to the other protocol element. Events between the elements will all have an SRid-value prefix. When OPH detects such an event, it translates the SRid to the local object reference, and dis- tributes the ASP data to that object. Note that whenever abstract protocols define service objects, communication events normally require some kind of a service relation prefix (either an OBid or an SRid). The only exceptions are when all service objects are unique in the abstract protocol (in which case, a PSid is sufficient) and when all operations within the abstract protocol are unique. The last exception is seldom recommended, although it is a quite common in existing abstract protocols (as, e.g. in MAP, see the discus- sion at the end of Sect. 5.2.2). 7.7.3 Abstract Protocol Behaviour Abstract protocols are primarily needed for product verification. The behaviour an abstract protocol describes is implied by the behaviour of the service relations in the corresponding service networks, modified by the operations of OBH services. Figure 7.67 gives an example, based on the model in Fig.7.63. The diagram shows the behaviour of the abstract machine AM2 in the abstract protocol AP1 (actually only for one single initiating event, caused by an event in the S1 service relation). The behaviour description can be automatically generated by a suitable tool, since it is given by the model in Fig. 7.63, and by the state diagrams that describe the behaviour of all objects that are visible in the protocol. 7 Concepts and Notations for Process Control Systems Modelling AG1 behaviour AG2 behaviour S1/op1Ref VO1 behaviour S3/op1Ref S2/op1Ref S3/op1Req S1/op1Req S4/op1Req S2/op1Req S2/op1Req S2/op1Req S2/op1Cnf S2/op1Cnt S4/op1Cnf S2/op1Ref S3/op1Cnf S4/op1Ref S1/op1Cnf S3/op1Req VO2 behaviour S4/op1Ret S1/op1Cnf S3/op1Ref S3/op