d released when it is no longer needed. Between AM1 and AM2 there can be several service relations of the same type (S5) simultaneously. In this case, it is also not possible to use a primitive service identifier to identify the service object, i.e. service relations must be set up and identified before they can be used, and they must be released when no longer needed. Assume that AG4 initiates a ReportConfirm event. If there was only one possible detecting object in AM1, delivering the identifier S4 as part of the event would be enough for the OPH in AM1 to identify that object. If, however, there are sev- eral (as in this case), a service relation must be defined before AG4 can initiate events in its provider port. Thus, in general, to include the primitive service identifier in communication events between abstract machines is sometimes enough for the OPH in the detect- ing machine to find out which service object is the detecting one. If all accesses can be solved that way, no OBH is needed. Often, however, the only way to distinguish service relations within an abstract protocol is to use special service access opera- tions. An OBH defines such operations. Figure 7.65 shows the operation specifica- tions for handling service relations that are defined within AML. The operation seizeServRel can be used to create one or several service relations simultaneously. 7 Concepts and Notations for Process Control Systems Modelling The service relation identifier (SRid) in the Request ASP of seizeServRel sug- gests an identifier for a temporary relation between two service objects in differ- ent abstract machines. It is suggested by the initiating abstract machine. OPERATION seizeServRel Request (SEQUENCE OF WantedRel) WantedRel::=SEQUENCE{suggested SRid, reference CHOICE{OBid, PSid}] Confirm (SEQUENCE OF ServRel) ServRel::=SEQUENCE{SRid, result{accepted,rejected} Refuse (cause {...}} OPERATION relServRel Order (SEQUENCE OF SRid) Fig. 7.65 Service access operations for OBHs The Request event of seizeServRel identifies 