tion, the userServIntORDER, to be added to S1. However, this creates a problem with the state diagram on the provider side: Fig. 6.16 shows that there is only one transition between the AnotInCall state and the AandDinCall state. Therefore, by using reactive states alone on the provider side, there is no way to specify that the provider can receive and react to a userServ- IntOrder from a user in a pending state, since that reception would then be a task in the activity of a transition between reactive states, which (by definition) is invisi- ble. A solution to this problem is to also introduce an active state in the provider port diagram, see Fig. 6.17. Reactive states are used preferably when the normal service behaviour (one or a few sequences of activities) requires intermediate information exchange with the other object (the normal situation in process control systems), i.e. the state machine needs an input to be able to continue. Therefore, in state diagrams based primarily on reactive states, the communication aspect dominates. Active states are used preferably when the normal service behaviour does not require intermediate infor- mation exchange with the other object (other than in exceptional situations), i.e., the state machine does not normally need an input to be able to continue. The state machine may, however, allow activities to be interrupted in active states, or prema- turely stop the activity if some problems are encountered. 6.2 A Service Network Modelling Case S1 operations: (TE-SAPI=A) servREQUEST userServIntORDER Timer operations: userServRelORDER setTimeORD nwServRelC_REPORT timeOutC_REP TEC user-port behaviour: SRid-UserServRelOrd SRid-user ServintOrd activity state (noCall) iie: startCall SRid-servRef(...) /T-setTimeOrd(T1) SRid-servReq(D,...) pending state) SRid-servCnf(...) SRid-nwServRelRepCnf T-timeOutRepCnf(...) interrupt state activity state (inCall) iie: endCall iie: interrupt PCS provider-port behaviour: SRid-nwServRelRepCnf() EFSM state SRid-servRef(...) (AnotInCall) SRid-servReq