l, we need a general language for resource system modelling, i.e. a language for concep- tual modelling, such as an entity-relation type of language. SM&AML provides its own, quite traditional general language for resource system modelling, see Sect. 7.3, but any other language with corresponding properties could be used. However, since in sysnet modelling we emphasize expressiveness of models, every domain of processing systems is expected to define its own language for resource system modelling. Therefore, from a methodology point of view it is important that domain-specific languages for resource system modelling can be mapped on a general, entity-relation type of language. This paradigm is depicted in Fig. 6.2. Having described the RS in a way that can be used in PCS design, the next ques- tion is how the structure and behaviour of a PCS is modelled. Obviously, a PCS can be (and certainly is, in telecom networks) a sysnet of its own. Therefore, a PCS may be a distributed system that has to be modelled over all five integration levels 6.1 Introduction of the integration hierarchy. However, modelling the PCS on levels 2-4 (protocol network, logical network and physical networks) follows the same principle as for any other system, and will not be discussed in this chapter. Process Control System (PCS) Resource system Translate Resource system Compile model in a domain- model in a Resource system model specific language general language (Data representation) Fig. 6.2 The three forms of a resource system model Thus, in PCS design we can focus entirely on integration level 0 (service net- work) and level 1 (abstract network). These levels are characterized by the fact that they, from a communication point of view, are transparent to any logical, physical or spatial distribution problem. The units in service networks and abstract networks are abstract entities in the sense that they communicate by instances of abstract service primitives (ASP), referring to operations. In these models all problems related to connect