erns are handled in the context of SM&AML. We have designed complex systems (think e.g. of the public telephone network, often said to be the world's most complex machine) for many decades, and design methodologies for systems engineering are continuously discussed, developed, tested and applied in industry and in the academic world. Why then is another modelling language needed? This question is discussed in Sect. 1.1 by looking in the rear-view mirror. "Why should we bother to produce formal system models?", "Who will benefit from them?", "Is there a business case for system modelling?" Section 1.2 sheds some light on these questions. To discuss systems modelling, it is vital to have some consensus about what we mean by "system" and "system model", since there are many types of systems around and many interpretations of this concept. Most commercial modelling languages focus on software systems, others on electronic systems (often called "hardware systems"), and yet others on information systems, embedded sys- items, distributed systems, real-time systems and reactive systems. What are the limitations and possibilities for systems modelling with SM&AML in this con- text? This is discussed in Sect. 1.3. T. Muth, Modeling Telecom Networks and Systems Architecture © Springer-Verlag Berlin Heidelberg 2001 1 Introduction to Systems Modelling From an architectural standpoint, a fundamental common denominator for most systems we deal with in systems engineering is that they are processing systems (additionally, they may be distributed systems, real-time systems, etc.). A processing system produces something useful for mankind other than informa- tion, as e.g. the paper that is produced by a paper-mill or the connectivity for transporting data through a telecom network. This requires that a processing system includes special resources (collected in a resource system) for producing the utility. Processing systems operate with a certain degree of autonomy, which requires that utility provisioning is controlled by a proce