t any point in time, know the exact static structure of the RS, its transient state, and how that state can be altered to establish and release different kinds of services. This information is stored in the PCS as a data representation of a model of the RS, the resource sys- tem model, see Fig. 6.1. So far we have identified the general requirements for any PCS, whether a con- trol system for a telecom system, a control system for a fabric-dying process, a paper mill control system or a missile control system. What constitutes a particular PCS is basically only the particular resource system model that the PCS handles. Therefore, theoretically, we could design a single PCS for all processing systems, if we have access to a general language for describing RSs. However, in reality we have to consider many other factors (required characteristics, capacity needs, phys- ical distribution of units of the RS, users, etc.), which makes this prospect not feasi- ble beyond the level of general computer platforms, sensors and effectors (see the model of Fig. 1.6). However, no matter which architecture we design for a PCS, it must have access to information about the RS it controls. Resource system modelling is therefore at the very heart of PCS design. Note that the purpose of creating a resource system model has nothing to do with how the components of the implemented PCS will be designed. The primary purpose of the model is to understand and specify every controllable aspect of the RS, as a requirement on how the PCS must work. This information will then be stored as data and manipulated by the PCS in some way or another, whether the PCS is implemented in software or hardware only and whether an object-oriented architecture or some other structural approach is defined for the PCS implementation. In Sect. 3.4 we discussed how telecom RSs can be modelled. Although this is a major theme in this book, from a PCS-design point of view, we cannot use this notation in general. To support modelling and simulation of PCSs in genera