ors take action when something goes wrong in the resource system that the process control system does not know how to handle. Operators also take action when something goes wrong in the process control system itself. The operator performs his duty pri- marily by communicating with the process controller. The last functional elements of the model that might be needed are some means for service communication between users, the process control system and process operators. The processing system might provide different kind of services (e.g. dif- ferent types of communication channels), and the users are the ones who determine which service they want, when the services are needed, and when they are no longer needed. Users will therefore communicate their needs to either the process controller or to the operators (or both, depending on the type of service), which requires some means for communication. By adding these missing functional elements, we end up with the model shown in Fig. 1.8. This model is now valid for any type of process control system. service communication Resource Process Control System System M/E/I flows Sensor Resource Resource Controller Effector Process resource Operators relation Controller Sensor Resource Resource M/E/I flows Effector Controller Fig. 1.8 A complete functional model for processing systems However, sysnet models do not just describe functional structures, they may also describe physical boundaries, and thereby the physical structure of a system. Crea- tion of a physical structure from the model in Fig. 1.8 can be done in many ways. Physical boundaries are already represented in the model wherever we have an M/E flow. We cannot model M/E interfaces with SM&AML, SO we will regard sen- 1.5 System Models sors, effectors and their corresponding resources as indivisible physical entities. We might also assume that operators are humans (i.e. physical entities). If we also assume that there will be special hard real-time processors to run some of the resource controllers, and a central c