ble by computers. This allows tools to be developed for checking the model for consistency, completeness and logical errors, as well as for compiling the model to implementation-oriented models, and thereby for at least semi-automatic generation of test-cases and products. In conclusion, formal system models that are produced and maintained in pre- design phases have an enormous potential for improving system engineering projects, with respect to process qualities such as productivity, system quality and leadtime. Projects that deal with complex systems and that rely only on the ad-hoc models and reports from very early phases often exhibit productivity, quality and leadtime figures that are far from satisfying. Formal system models can act as bridges between the very early phase and the design phase, and, if carefully mod- elled and maintained, can document most system design decisions that are taken before product design starts. To make such a schema work, however, puts some tough requirements on the modelling language. It must be suitable (i.e. domain specific), formal with respect to human interpretation, intuitive, expressive, complete and of minimum complex- ity. If the schema shall work over the whole development process or the lifetime of the system concept, more can be gained if the language is also machine interpreta- SM&AML has all those qualities, with regard to the targeted system domain. In order to support both human and machine interpretation of models, AML also pro- vides separate notations for those needs. Tools that support the systems modelling language are needed to a varying degree, depending on to what extent the models will be used in a project and over the lifetime of a system concept. Note, however, that SM&AML only constitutes the language requirements for tools. Other, more process-oriented concerns are issues to be solved by tool-makers. System Abstractions In this section we will discuss some general concepts for classifying models of sys- items, and see how SM&AML fits in that conte