s long as it is not broken). However, the provider may also ask a nearby person what time it is, which obviously is a totally different way (i.e. activity) to obtain the same result. From the user's point of view, it does not matter how the response to the calInfoRe- quest(time) is produced. Thus, "operation" and "activity" must be treated as differ- ent concepts: An operation name refers to a wanted result (modified by parameter values) of the execution of an activity. Communicating service objects must have a com- mon understanding of the expected result, based on the service resource model. An operation does not assume any specific way (i.e. activity) of producing the result. The execution of an activity is initiated by an event that refers to an oper- ation name. A response might (or might not) be provided, and will then refer to 7 Concepts and Notations for Process Control Systems Modelling the same operation name. The concept "operation" is only used in communica- tion between user and provider. An activity identifies a method for producing the result of a particular operation. There may exist many alternative activities for the same operation, which the user need not know. The execution of an activity can produce a change in service and object state. However, the fact that a user requests an operation does not necessarily mean that there will be any state change. The activity may fail, or it may not have the effect of changing state, even if it succeeds. For example, many operations only access information in the resource model, which does not change the state of anything. In that case, there is no activity either, since the OPH handles such requests. Thus, operation is a language element in the communication between service objects, used to refer expected or wanted outcomes of activities. Activities are the ways (or "methods") used by service objects to produce the result that is referred to by a particular operation. Therefore, when describing the service CAS and the service behaviour of the provider, th