xt. 1 Introduction to Systems Modelling We have already seen that the concept "system" can be interpreted in many ways. For example, are we talking about all systems in general, a domain-specific artifact system, a biological system or a software system? It is impossible to imag- ine a modelling language of any practical use that has such qualities that it can be used for specifying all kind of properties for all kinds of systems. In his book on living systems, Miller (1978) defines a class of systems he calls "concrete systems", which seems to fit quite nicely to the needs of systems engi- neering. Although Miller derived his criteria from studying living systems, they are applicable to most domain-specific systems of interest to systems engineering, including telecommunication networks and systems. Miller's definition is, in sum- mary: A concrete system is built on, and feeds on, matter, energy and information (M/E/I). If the system is "open", it interacts with systems in its environment through flows of matter, energy and information over the system boundary. Miller's concrete systems also have processing capabilities (which may com- prise all or some of M/E/I). They also have an internal structure of interacting functions, which they can maintain and adapt within certain limits. This implies that Miller's concrete systems, to a varying extent, are autonomous, i.e. they can, within certain limits, take their own decisions. Concrete systems, therefore, must include a decision function, called by Miller "decider". In SM&AML we use the term process control system for the part of a concrete sys- tem that takes decisions. The purpose with all concrete systems is to survive during changing environ- mental conditions. The goal of a concrete system is domain specific. Both living systems and man-made systems belong to the class of Miller's con- crete systems. With the pace of research in microelectronics, artificial intelligence and microbiology, the time may come when it will be hard to say if a concrete sys- tem is 