2.1.1.  A basic abstraction model

There are different approaches to categorize abstraction levels. [DH99] defines six abstraction levels for embedded systems in the automotive industry, ordered by incremental refinement:
Scenarios.
A scenario is the highest abstraction level, describing systems in a big universality with fewest amount of information. The concept of events and their dependencies is used to model sort of use cases and “not use cases” by forming sequences of events. Use cases are examples of the aims, “not use cases” show the possible exceptions or errors as well as tests – for short, how a system may not be used.
Functions.
The functions abstraction level considers complete sequences and their structure. The sequences are still implementation independent. Structure is needed to provide a way to navigate through the usually huge system of functions. It is not important here to know which functions interact exclusively with or depend on other functions, only what they do.
Functional network.
This level adds information about instantiation of the defined functions to particular functional configurations, enlarging the name space. The mutual dependencies, which were not treated in the level above, now have to be defined and in case of conflicts, also have to be solved. Referring to [DH99] this is the first level where a “simulation of the overall system is possible”. A global time is invented, allowing to define the communication between the functions as event-driven and synchronous, based upon multi-casting.
Logical system architecture.
New orthogonal information classes are invented, dealing with the logical distribution and the information about sensors and actors that are part of the environment. The time is split up into two parts: the real time part or the universal time of the environment, and the system time part, which includes clocking. The communication between the functions is no longer event-based, but a clocked data-flow. This makes the synchronization of the two times crucial. If they diverge over a certain point of tolerance, the real-time capability of the system is violated.
Technical system architecture.
Here, the model is filled with information about concrete realizations of the architecture, specified in the above level, e. g. how buses are implemented. Additionally, the control unit specifications and the operating system are described. At this level a first performance simulation is possible.
Implementation.
The complete model from the above abstraction levels is now implemented. Code optimizations take place as well as adoptions to existing systems.

The presented taxonomy is perfectly right, but from my point of view it is far from being differentiated enough. It is more or less possible to identify the level of abstraction in which a design step takes place, but what I miss, is a description of what type of information is to be abstracted. Abstractions of different aspects like time, data, data-flow and functions are mixed in a one-size-fits-all view. So for classifying models it is nothing more than a very rough overview. For example it is not clear for me where the boundary between level 5 and 6 is erected. Where is RTL and where HDL coding done? Is it not too late to think of adoptions to existing systems when the actual implementation should be done?