omputer with larger capacity but slower real- time qualities for running the process controller, we end up with the physical struc- ture shown in Fig. 1.9 (disregarding, for the moment, the functional and physical aspects of service communication, see Sect. 2.2 instead). service communication Sensor Resource Resource Controller Effector Process Operator Controller Sensor Resource Resource Controller Effector Fig. 1.9 A possible physical structure of a processing system This model defines a possible physical structure of a processing system, without any preconceived assumptions on which functional entities will be implemented as software and which as hardware (compared with the model in Fig. 1.6). Physical structures belong, therefore, to the description of sysnets as well. Note that as long as the designers have not decided which type of processors, operating systems, platforms, design languages, circuit technologies, component libraries, etc., they are going to use, the physical model still does not represent an implemented sys- tem. First, if the model becomes annotated with those decisions, it will be an imple- mented system model. System Models A system model is an information model that describes a particular concrete sys- tem or some type of system abstraction. System models should be kept separated, according to the classification structure of system models that was shown in Fig. 1.4 and for reasons that were discussed in Sects. 1.2 and 1.3. It is most likely that different modelling languages will be used on different lev- els of systems abstraction, since one wants each model type to be expressive and suitable for its purpose. For example, a standardized system model will focus on protocols and network structures, an applied system. model will focus on process- ing aspects and a software system model may focus on software object class struc- tures and collaborations (sometimes called "class diagram" and "collaboration diagram" respectively). A concrete system model will most likely focus on con- 1 Introd