le in the state diagram. Thereby, service objects loose their black box characteristics, and state diagrams tend to turn into flow charts (i.e. descriptions of implementations). The state diagram for the TEC user port: The structures of the state diagrams in Fig. 6.16 are defined by reactive states and active states. The diagram introduces two additional reactive state types: pending state and interrupt state. A pending state is a reactive state in between two service states, i.e. while in a pending state, the resource state is unknown. A pending state is also a state where the service object is waiting for a response. When one of the objects in a service relation is in a pending state (in this case, the user), the other is in an active state (in this case, the provider). 6 Process Control System Modelling The transitions to and from an active state take no time. The object in an active state is normally expected to finish the activity com- pletely before it is prepared to react to additional events. A transition from an active state is done either by a certain precondition becom- ing true (as a result of the performed activity), or an internal initiating event of type interrupt, caused by the reception of a communication event. If interrupted, the state machine goes to a an interrupt state, which is a transient state where the event that caused the interrupt is detected. The resource state in an interrupt state is unknown. The transition from an interrupt state should bring the state machine back to some known resource state. The solution in the previous diagram (Fig. 6.16) did not allow users to withdraw from a service request before the PCS had responded in some way or another. Most teleservice users (and operators) would not be very happy with that restriction, which is why the solution in Fig. 6.17 is more attractive. The TEC now has access to a timer object, which allows it to withdraw from its previous service request (by a userServIntOrd) from the pending state. Note that this requires an additional opera