Joachim Schlosser: Development and Verification of fast C/C++ Simulation Models for the Star12 Microcontroller
[Next] [Previous] [Previous-tail] [Tail] [Up]
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?