ics of systems. The model can, however, not be used for classifying systems. The model is a generic implemented system model, since its components are hardware and software. Implemented system models on this high level of modelling all look the same. Besides, we know that there are many ways in which a system with a given functionality and structure can be implemented, which is another reason why sys- tem models that consist of hardware and software elements are unsuitable for sys- tems classification. Let's instead look upon the functional entities of a system, no matter how they will be implemented, as we did in Fig. 1.5. By understanding the systems functions and the interactions that go on between the system and its environment, we can draw conclusions about which class or domain of systems we are dealing with. We 1.4 Processing Systems might find that the system is an information system, a processing system or just a process control system. The way control responsibility is distributed amongst functional entities in a process control system is a very prominent structural aspect of such systems. An elaborated logical model of the model in Fig. 1.5 is shown in Fig. 1.7. Resource Process Control System System M/E/I flows Sensor Resource Resource Controller Effector Process resource relation Controller Sensor Resource Resource M/E/I flows Effector Controller Fig. 1.7 A logical system model of a processing system The model of Fig. 1.7 depicts the functional structure of a processing system, without any references to which part will be implemented as hardware, software or hardware interfaces (as in Fig. 1.6). The model therefore represents all types of processing systems. The resource system handles the input and output flows. This system consists of resources that are related by some type of resource relations. Which types depend on the type of system. If we consider telecom systems, these relations might be points where transmission lines are connected to switches. The process control system consists of function