IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO.
2, MARCH 2004
Multiparadigm Modeling in
Embedded Systems Design
Klaus D. Müller-Glaser, Member, IEEE, Gerd Frick, Member, IEEE CS, Eric Sax, and Markus Kühl, Member, IEEE
Abstract—Embedded electronic systems for monitoring and
control of technical processes (electronic control unit—ECU)
are systems comprised of heterogeneous components (hardware,
software, sensors, actuators, power electronics), thus making high
demands on their development. Describing different aspects and
views of the whole system, subsystem, or component requires
according modeling paradigms for requirements specification,
design, hardware implementation, software code generation,
verification, integration, and testing. The first part of the paper
surveys characteristic ECU features and describes a design
strategy and the related technology, bringing out the necessity
of multiparadigm modeling. Examples from automotive ECU
applications are used throughout the paper. With respect to
the problem that currently available tools provide insufficient
support, integration strategies for multiparadigm modeling based
on multiple tools are surveyed in the second part, concluding with
examples from our own research activities.
Index Terms—Automatic programming, code generation, code
integration, embedded systems, executable specifications, model-
based design, model integration, modeling, multiparadigm mod-
eling, software requirements and specification, tool integration.
I. INTRODUCTION
M ULTIPARADIGM modeling is a need for the design of
embedded electronic systems. To motivate, we will first
introduce characteristic features and show a typical example of
distributed embedded electronic systems in the automotive in-
dustry. As those embedded systems are comprised of heteroge-
neous components (hardware, software, sensors, actuators, and
power electronics) we need a system design flow with an ac-
cording meet-in-the-middle design strategy supporting system
design as well as component design. Describing different as-
pects and views of the whole system, subsystem or component
from requirements specification to design, verification, imple-
mentation, integration, testing and finally production requires
different modeling paradigms.
Embedded electronic systems are mainly used for measure-
ment and control functions (electronic control unit—ECU) in
any kind of technical processes (e.g., controlling a chemical
Manuscript received May 24, 2002; revised March 24, 2003. Manuscript
received in final form October 1, 2003. Recommended by Associate Editor
P. Mosterman.
K. D. Müller-Glaser is with the Institute for Information Processing Tech-
nology (ITIV), University of Karlsruhe, 76128 Karlsruhe, Germany (e-mail:
kmg@iniv.uni-karlsruhe.de).
G. Frick and M. Kühl are with FZI Forschungszentrum Informatik, Depart-
ment of Electronic Systems and Microsystems, 76131 Karlsruhe, Germany
(e-mail: frick@fzi.de; kuehl@fzi.de).
E. Sax is with IMH GmbH, MBtech Group, Stuttgart, 71063 Sindelfingen,
Germany (e-mail: Eric.Sax@mbtech-group.com).
Digital Object Identifier 10.1109/TCST.2004.824340
1063-6536/04$20.00 © 2004 IEEE
279
reactor, passenger car, airplane, internal cardiac pacemaker,
microwave oven, mobile phone, digital camera, etc.). Being
embedded an ECU is always a part of a larger system and,
usually, is not directly visible as an electronic system to the
human operator [1], [2]. Embedded systems demand for true
system integration, which means integrating the complete ECU
or a large part of it onto a single integrated circuit, a small
ceramic substrate, or a flexible printed circuit board housed
in an application specific formed package with application
specific interconnects to its environment [Fig. 1(b)]. ECUs are
heterogeneous systems [Fig. 1(c)] as they incorporate digital
and analog microelectronic circuitry, power electronics, various
sensors and actuators, as well as software (application software
and a real-time operating system) running on a standard hard-
ware platform using microcomputers, digital signal processors,
and field programmable arrays. Safety critical applications,
hard real-time requirements, and tough operating conditions
in a harsh environment (automotive, aerospace, incorporated
medical equipment) are other typical constraints for embedded
systems.
Although the design of complex ECUs has been accom-
plished for many years the miniaturization and integration of
mechanical and optical system components results in decreased
system dimensions and increased system compaction. This
mandates the consideration of parasitic effects and device
interactions (e.g., dependencies of actuator or sensor charac-
teristics on thermal coupling with components having high
power dissipation; electromagnetic compatibility (EMC) and
more general biological, chemical, and physical compatibility
(BCPC); reliability issues of safety related systems such as
pacemakers or an automotive airbag release system). The mani-
fold interactions, cross sensitivities, and the complexity of both
the overall system and the heterogeneous system components
mandates an exhaustive use of computer-aided tools, e.g., for
systems engineering, software engineering, design, and testing
(CAE, CASE, CAD, CAT).
A typical example for the use of embedded systems for
measurement and control (closed loop as well as reactive) is
the automotive industry where, in a luxury car, more than 70
ECUs serve for safety and comfort functions [Fig. 1(a)]. Those
ECUs communicating over a CAN-Bus class C (controller
area network—CAN, 1 Mbit/s [3]) are dealing with such
functions as power train control, motor management, gear con-
trol, suspension control, airbag release, anti-blocking brakes,
and electronic stability program. These ECUs implement
closed-loop control functions as well as reactive functions
and do have many safety critical hard real-time constraints
(thus running a standardized real-time operating and network
280 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
Fig. 1. Electronic control units.
management system like OSEK/VDX [4]). The so-called body
electronics serve the comfort functions like air conditioning,
power window and seat control, internal/external light control,
lock and alarm functions, voice command system, parking
aids, etc. These ECUs are mainly reactive systems with only
a few closed-loop control functions, they communicate via
CAN-bus Class B (100 Kbit/s) and they have only soft real-time
requirements. The fastest bus system is the optical data bus
(D2B, MOST, Firewire, 100 Mbit/s) for connecting the on
board entertainment/office system (video, sound, phone, global
positioning system, mobile office functions, etc.). These ECUs
are software intensive, incorporating millions of lines of code.
All these different buses are connected through a central
gateway, thus enabling the communication of all ECUs.
The challenge for the design of these distributed and net-
worked control units is to find and define all requirements
and constraints; to understand and analyze those manifold
interactions between the many control units, the car and the
environment (road, weather, etc.) in normal as well as stress
situations (crash); to perform failure mode and effects analysis;
and to ensure fail safe and fail operational units for safety critical
functions within a development process, which is concurrent and
distributed between the automotive manufacturer and several
suppliers. This requires a well understood life-cycle model, a
strictly controlled design methodology (like the V-Model [5]),
and using computer aided engineering and design tools to its
largest extent. The aerospace as well as the automotive industry
recognized that most of the problems and errors occurring
during the design of an ECU are directly or indirectly related
to requirement specifications, which too often are incomplete,
inconsistent, or even wrong. As requirement specifications
today are mostly given in sentences of a natural language within
a voluminous written document, too often requirements are
interpreted differently by the original equipment manufacturer
and the supplier. Since the mid 1990s, the industry realized
that, whenever possible, requirement specifications should be
given in formal notations (graphical or language based), thus
“design by specification,” executable specifications, model
based design, and CASE tool usage are the key words.
Thus, in Section II of the paper, we will discuss the overall
system design cycle and why multiparadigm modeling is
needed. Section III will show models of computation, lan-
guages, and tools of different paradigms used for modeling.
Section IV will explain different integration strategies for
multiparadigm modeling based on multiple tools. Finally, in
Section V, some application examples for different strategies
implemented in our own research activities will be given.
II. EMBEDDED SYSTEM DESIGN
A. Design Flow
As outlined in the previous section, the rising complexity and
heterogeneity of applications and the quality and safety con-
sidering real-time requirements demand a seamless component
and system design flow. Various lifecycle models [6] exist; es-
pecially the V-model [5] is adequate for embedded systems.
Starting from requirements definition the phases of this lifecycle
model are
• system analysis;
• specification;
• HW/SW partitioning;
• preliminary design;
• detailed design;
• component implementation;
• component test;
• component integration;
• module test;
• system integration;
• system test for system deployment.
An adapted example of this process is shown in Fig. 2 for the
automotive industry. After the deduction of a specification from
the requirements by means of modeling system functions and
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN
Fig. 2. The approach of a seamless design flow from idea to realization.
system behavior mostly based on a graphical notation, a first,
still abstract, executable prototype of the system can be imple-
mented. This executable model can be simulated on the desktop
level, for the sake of early requirements validation. Using a high
performance “rapid prototyping hardware platform,” an initial
implementation of specified functionality and behavior of the
ECU under design can be carried out under real time condi-
tions in an already existing car to further prove the concept. This
way, an “executable specification” embedded into the real en-
vironment exists. HW/SW partitioning, preliminary (raw) and
detailed (fine) design are furthermore challenging tasks. The in-
tensity of this phase depends on whether or not implementation
requirements have been defined in advance to lead to a specific
target based on standard hardware components as micro-con-
trollers, digital signal processors, field programmable gate ar-
rays, or application specific integrated circuits. Regarding soft-
ware implementation for embedded micro-controllers manual
coding should be replaced step-by-step by automated code gen-
eration. So, in the near future, code generation for dedicated
target controllers and operating systems (e.g., OSEK/VDX in
the automotive area [4]) will be a major focus of the implemen-
tation and integration phases.
Thus, executable specifications are used to reduce misinter-
pretations in the manufacturer–supplier interface; for early re-
quirements validation by system simulation; for proof of con-
cept by rapid prototyping; and for productivity increase by au-
tomated target code generation. Specification driven design in
using executable specification is the major brake through for
enhancing design productivity and design quality. As shown in
Section III, multiparadigm modeling is needed to cover all the
different aspects when modeling heterogeneous embedded sys-
tems. Afore, we need to discuss several aspects between system
design and component design.
281
B. Meet-in-the-Middle Design Strategy for System Versus
Component Design
Today, a large variety of very powerful domain specific
computer aided design, simulation, analysis, and test tools
provide support for the development of components such as
digital and analog microelectronics, software, mechanical sen-
sors and actuators, or optical components. There are also tools
available that support system-level design and analysis (see
below and Section III). However, most of these tools are in-
dividual tools (point tools); there are no or few interface stan-
dards, no common data bases, no common user interfaces,
and there are some gaps for important design steps, espe-
cially in early system design phases (requirements engineering,
tradeoff studies, performance estimation, cost estimation, etc.).
Due to the complexity of heterogeneous embedded system de-
sign, we believe that there will be no single integrated de-
sign system capable of handling all requirements for designing
and verifying the complete heterogeneous embedded system,
the system components and packaging, and interconnects. Be-
tween system design tools and the various component design
tools, well-defined interfaces and standards for methodology
and data models are necessary. Most essential is the inter-
face for library data, especially for multiparadigm modeling
to allow system simulation. A component designer must pro-
vide parameterized data from component characterization as
accurate as possible and may generate a macro-model as ac-
curate as necessary for the system designer. System designers
and component designers exchange information on all critical
parameters necessary in deciding whether or not a specific
component is usable for the design of a specific system and
what the macro-model should look like. Systems engineers and
component engineers “meet in the middle” [7] in a coopera-
282 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
tive, concurrent design process, joined by engineers dealing
with system integration, packaging, interconnects, as well as
parasitics and cross sensitivities.
Most crucial is a standardized interface format for models on
system level and component level using description languages
like SABER [8], VHDL-AMS [9], SDL [10], and upcoming lan-
guages like ROSETTA [11], [12] as well as standardized inter-
face formats like CDIF [13], EDIF [14], STEP [15], XML [16],
or XMI [17].
So for embedded system design, we find a large variety of
abstraction levels, components and aspects that cannot be sup-
ported by only one language or tool. The paradigms of modeling
for example continuous versus discrete systems, describing as-
pects of performance versus pure functionality or diagnosis rel-
evant information are too diverse. As a consequence, currently,
neither a single commercial tool nor a single language standard
supports the complete chain from system design to component
production with all its aspects. Multiparadigm modeling and de-
sign is the answer and sensible integration and combination ap-
proaches must be performed. Tool coupling, model exchange,
model integration, and automated code generation will be dis-
cussed next as the key topics to reach the goal.
III. HETEROGENEOUS MODELING IN EMBEDDED
SYSTEM DESIGN
A. Modeling Paradigms and Supporting Tools
Several notations exist for modeling each of the partial as-
pects along the complete design flow from requirements to pro-
duction. Each of them describes the system from a different
point of view; but none of them covers all aspects. As a result,
executable specifications for embedded systems are based on
multiparadigm modeling.
There are five major modeling paradigms for embedded sys-
tems, each supported by dedicated tools.
1) Ordinary differential equations (linear and nonlinear)
to model conservative systems or components having
“across” and “through” quantities (continuous in value
and time) like voltage and current in electrical systems,
speed and force in mechanical systems, temperature and
heat flow in thermal systems, or pressure and volume
flow in hydraulic systems. For all these systems, conser-
vation laws apply (e.g., Kirchhoff’s law). These models
are used for describing analog electrical networks of the
ECU or the mechanical behavior of the whole car or of
some mechanical components. Such simulators include
MATLAB/Simulink [18] and MatrixX/Systembuild
[19] with graphical user interfaces; the language based
SABER [8], VHDL-AMS [9], and SPICE [20]; the
equation based ACSL [21] or the language and equation
based Modelica [22].
Ordinary differential equations (linear and nonlinear)
to model nonconservative systems like closed-loop
control functions in system control or signal pro-
cessing algorithms. According simulators, all having
user friendly graphical interfaces, are, e.g., MATLAB/
Simulink with digital signal processing toolbox and com-
munication toolbox, MatrixX/Systembuild, ASCET-SD
[23] and Rodon [24] (this one, especially, to model
diagnosis in technical processes).
2) Partial differential equations for modeling behavior
in space and time, e.g., for mechanical components
like membrane, beam in bending, moving electrodes in
electromagnetic fields, thermal or fluidic behavior, etc.
Numerical solutions are calculated by finite-element
methods (FEM). Popular FEM simulators are ANSYS
[25], FLOTRAN, NASTRAN, ADAMS.
Wherever possible, due to the very long computing
times, FEM analysis is run without interaction to other
simulators. Results are analyzed and used to construct
more abstract models (macro-models) for ordinary dif-
ferential equation simulators (e.g., MAST, VHDL-AMS,
MATLAB/Simulink).
3) Finite-state machines, statecharts, Petri nets for discrete-
event modeling mainly for describing reactive sys-
tems (simulators are, e.g., GPSS, Statemate MAGNUM
[26], MATLAB/Stateflow) or digital circuitry (VHDL
Leapfrog [27], VSS [28], Verilog [29]).
4) Stochastic models, probability distributions, Markov
chains to describe and analyze system performance.
According simulators are HyPerformix Workbench [30]
and Foresight [31] for queuing problems, VCC [27]
for hardware/software performance analysis, SDT/SDL
[10], COSSAP [28], and SPW [27] for communication
network analysis.
5) UML [32] based descriptions for software-intensive
system components (Rhapsody [26], Rational Rose
Real-Time [33], ARTiSAN Real-Time Studio [34] are
software engineering tools which support UML with
real-time constraints and automatic code generation;
Rational Rose Real-Time is based on ROOM [35]).
For simulating embedded systems, both the ECU as well as
the real environment must be modeled. Depending on what is
modeled and what is real, we call it
[“software-in-the-loop”] ECU as well as the real environ-
ment is modeled (for early system validation);
[“rapid prototyping”] Real environment exists, ECU is
modeled (for early proof of concept);
[“hardware-in-the-loop”] ECU exists, real environment is
modeled (for exhaustive characterization of ECU).
In the automotive industry for example, models are required
for many different functions (telematics, measurement and con-
trol, technical processes) developed on different levels of ab-
straction so that proof of concept can be accomplished within
three different design phases in using rapid prototyping (Fig. 3;
prototype A: concept oriented, prototype B: architecture ori-
ented and prototype C: target oriented), thus requiring code gen-
eration for rapid prototyping as well as production code.
Instead of natural language textual descriptions, requirement
specifications should be given as executable model based
specifications whenever possible. To manage complexity,
hierarchical structuring of complex embedded systems in a
divide and conquer process must be possible (Fig. 4).
Math formulas, natural language text, hardware description
languages and graphical notations are used for the modeling
paradigms mentioned above. However, preferred are graphical
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN
Fig. 3. Simplified automotive V-model.
Fig. 4. Hierarchical structuring of a complex system.
notations such as those shown in Fig. 5. For the modeling of con-
tinuous systems signal flow diagrams are the medium of choice
(Fig. 5, left side). The algorithmic expressions for open- and
closed-loop control (system of ordinary differential equations)
can be graphically represented by combinations of blocks pro-
vided by tool specific libraries (often called “tool-boxes”). Hi-
erarchical descriptions are supported and even the integration
of user defined blocks (e.g., manual written expressions or even
code) is feasible.
Body control systems as communicating, reactive, and
state-based systems can be described using message sequence
charts (Fig. 5, top right) and statecharts [36] which enhance
traditional state-machines by hierarchy, concurrency, and
event broadcasting. Other descriptions exist for performance
modeling or diagnosis (Fig. 5, bottom right).
Statecharts for reactive systems and data flow graphs for
closed-loop control systems are de facto standards. However,
it is hard to unify them in a single tool, because the according
simulator kernel that interprets the modeling language follows
specific solution algorithms (i.e., discrete event modeling
for reactive systems versus continuous system modeling in
closed-loop control). There is a specific model of computation
behind the language (see Section III-C). Simulator kernels
today are optimized for either discrete event or continuous
modeling. Nevertheless, there exists increasing effort to intro-
283
duce a standard modeling language or another multiparadigm
approach that covers both aspects [37].
B. Aspects of Code Generation
Commercial CASE1 tools currently support certain levels of
the complete design flow from requirements to product and di-
agnosis. DOORS [38] for example is a widely used tool for
(text-based) requirements engineering. Frequently used mod-
eling tools are shown in Fig. 5.
After modeling is finished, validation through simulation is
the next task, followed by code generation. As the complexity
of embedded electronic systems is rising steadily, the extent of
the required code is increasing rapidly whereas time to market
is decreasing. Manual coding is reaching its limits to handle
this complexity. Therefore, a reuse of the models that have al-
ready been proved by simulation to a high extent is a solution.
That implies an automated step from modeling to code. Auto-
mated code generation for the real target (production code) is a
challenge, as the requirements include not only functional cor-
rectness, but memory efficiency (ROM/RAM sizes) and runtime
performance (timing correctness) as well. Rapid prototyping is
used for an early proof of concept (Figs. 2 and 3, prototype A),
the code being generated is targeted to a powerful and highly
expensive rapid prototyping platform, and thus this “prototype
code” does not need to be optimized like “production code.” Our
investigations show prototyping code is up to four times bigger
than manually written target code, and the high performing rapid
prototyping hardware platform is too expensive for high volume
production.
Thus, only generated code that is optimized for a certain
target controller may be labeled as a kind of “production code.”
Optimization affects, e.g., numerical data types and arithmetical
operations for micro-controllers without a floating-point unit
and variable allocation and memory management. Furthermore,
language features causing a dynamic overhead at runtime (like
virtual methods causing dynamic binding in object-oriented
languages like C++) have to be omitted. As of today, automated
code generators usually produce more lines of code and the
code is less efficient in comparison to code written by an
1Computer Aided Systems/Software Engineering
284
Fig. 5. Graphical notations for closed-loop control, reactive, and diagnostic functions.
experienced programmer [39]. Regarding data size, code
generators do not always choose the smallest possible word
length to cover the desired accuracy. Often, additional manual
coding remains necessary for the integration of operating
system or hardware specifics. Furthermore, the integration of
several micro-controllers into an interacting network requires
the integration of communication code in terms of a concrete
communication protocol. Here, seamless tool support is still
lacking. However, we are optimistic that next generation of
tools will reduce the current deficits tremendously, and even
today, tools like ASCET-SD [23], Rhapsody-in-MicroC [26]
and TargetLink [40] (the latter in combination with MATLAB)
support the automated production code generation in an already
acceptable way and point the way ahead.
Diagnosis is mainly a matter of finding the source of errors in
the test phases or in ordinary use. Being able to simulate diag-
nosis functions already in early system modeling and simulation
phases implies major benefits in order to better understand and
simplify the diagnosis functions when the system is maintained
at the user’s site. Failure mode and effects analysis (FMEA), tol-
erance definitions and the preparation of an onboard-diagnosis
are therefore techniques to be run in parallel to the other men-
tioned design tasks. Tools such as Rodon [24] are specialized on
that aspect.
IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
Testing the performance in an early design phase can addi-
tionally reduce late-detected and, therefore, cost-intensive prob-
lems tremendously. The design of system models by means of
extended directed graphs with queuing, supported for example
by HyPerfomix Workbench [30], is an adequate solution to gain
information on simulation level about these aspects.
As pointed out, a large variety of powerful but domain-spe-
cific computer aided design tools for requirements engineering,
simulation, analysis, testing, and diagnosis provide support for
the development of embedded systems’ components. However,
these are individual tools (point tools) that view the system only
from a specific angle and do not cover all the aspects needed to
perform an optimal result.
As already shown in Section II, due to the complexity of
embedded system design, today it is an accepted fact that a
single integrated design environment capable of handling all re-
quirements for designing and verifying the embedded system
does not exist. In addition, nowadays, there are only a few de-
sign standards and no common repositories in use. Furthermore,
from the users’ points of view, CASE tools do not release the
developers’ decision when to make which step to create their
design [41]. Many current CASE tools are oriented on software
modeling and construction methods, while not all factors that
matter for graphical engineering receive attention [42].
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN
For that reason, there exist gaps between important design
steps in a vertical design chain, especially in early system design
phases from requirements engineering to specification or for the
steps of component integration to the overall system. In addi-
tion, a horizontal unification covering all multiparadigm char-
acteristics from continuous to reactive modeling, performance
and cost estimation or test and diagnosis does not exist. Integra-
tion solutions are needed. Approaches to that will be shown in
the next chapter.
C. Models of Computation
Executable models are essentially computer programs con-
structed in a high level, preferably graphical language. There
is no principle difference between constructive modeling lan-
guages and programming languages, except that the models of
computation are more specialized. There is a variety of models
of computation reflecting different modeling and programming
paradigms. For example, the computational model underlying
both the procedural and the object-oriented paradigm is an im-
perative one, i.e., deals with a sequence of commands manip-
ulating the contents of value stores (variables). The model of
computation underlying functional languages is basically term
reduction. The execution of logic programs involves symbolic
reasoning. In contrast, embedded systems modeling mostly has
to deal with notions of concurrency and time. To this end, a va-
riety of models of computation exists including continuous time,
discrete time, discrete events, finite state machines, and commu-
nicating sequential processes [37].
The state-of-the-art modeling paradigms described in the
previous section are backed essentially by continuous and
discrete time, discrete event, and finite state machine models of
computation and are complemented by an imperative “action
language.”
Modeling of hybrid systems, involving more than one mod-
eling paradigm, has to deal with several—two in the easiest
case—models of computation. This can either be done by for-
mulating one in terms of the other, or by reducing both to a
common underlying primitive computational model, e.g., the
imperative model. For more than two paradigms, any combi-
nation of these two cases is possible.
D. Multiparadigm Modeling Languages
The most direct and easiest way to apply heterogeneous
system modeling involves modeling languages that have been
designed as multiparadigm or unified paradigm languages.
Multiparadigm languages integrate sublanguages of different
paradigms, while unified paradigm languages offer several
paradigms as special cases of a unified “all-in-one” paradigm
which can also be used directly [43]. As observed by Lee et al.
[37], a unified model of computation covering a wide area of
embedded systems modeling paradigms would be extremely
complex and difficult to use and synthesis and simulation tools
would be difficult to design.
An extensive multiparadigm modeling language is being
developed in the Ptolemy project, which studies heterogeneous
modeling, simulation and design of concurrent systems with a
focus on embedded systems [37]. The Ptolemy II system is an
extensible modeling environment for heterogeneous systems
285
supporting a wide variety of models of computation. It has
a component-based approach, relying on a common abstract
syntax (hierarchical graphs), a common abstract semantics
(as far as necessary) for domain interoperation as well as
domain-specific models of computation. The latter are defined
in terms of the Java programming model (object-oriented/im-
perative, multithreaded) which specifies the underlying basic
paradigm all domain-specific paradigms are reduced to. As
of now, Ptolemy II is only a modeling, simulation and design
environment. Code generation capabilities are planned to be
added in the future.
There are also commercial CASE tools which embody mul-
tiparadigm languages. The MATLAB [18] tool suite with its
Simulink/Stateflow system modeling environment integrates a
continuous time and (multirate) discrete time model of com-
putation (based on equation solvers) with a discrete event and
finite state machine model. The state machine engine is con-
trolled by the equation solver. ASCET-SD [23] is a graphical
programming tool dedicated to the development of automotive
ECU software. It has sublanguages for finite state machine and
continuous modeling which are strongly linked to the impera-
tive/object-oriented core language. State machines are consid-
ered higher level imperative control structures, continuous vari-
able modeling is layered on top of the object-oriented (impera-
tive) model of computation.
The unified modeling language (UML) [32], standardized by
the Object Management Group, has gained a lot of interest in
the software engineering community and is respected as a stan-
dard in object-oriented software development. However, it is a
unified language mainly in the sense that several competing ob-
ject-oriented methods with their own graphical notations have
been compiled into a “standard” visual language for object-ori-
ented modeling. Furthermore, an object-oriented version of stat-
echarts [36] is included, where the notion of objects encapsu-
lating state and behavior and communicating via messages has
been usefully combined with the finite state machine model. Ca-
pabilities for expressing real-time behavior are added by means
of the UML profile for schedulability, performance, and time
[44] and are to become an integral part of the upcoming UML
2.0 standard.
But UML (in the current versions) is expressly only a lan-
guage for discrete systems; continuous time modeling is out
of the scope of UML ([45, p. 4]). Therefore, on its own it is
not sufficient to model open and closed-loop control systems
as they are typically found e.g., in automotive applications. To
overcome this situation, while recognizing both the “standard”
appeal of UML and the special needs of automotive applica-
tions, the German car manufacturer BMW has initiated the de-
velopment of an automotive modeling language (AML), inte-
grating subsets of UML and the ASCET-SD modeling language
[46]. If successful, the result will be another example of a mul-
tiparadigm modeling language.
E. Multitool Design
Despite of the availability of CASE tools with multiparadigm
languages, there are situations where a single modeling lan-
guage or tool is insufficient to satisfactorily cover all modeling
aspects relevant for a certain application. Therefore, developers
286 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004

Fig. 6. Cosimulation.

may want to combine the modeling languages of several point

tools to a “virtual” multiparadigm language. The following two
cases have to be distinguished (assuming the minimum number
of two modeling tools combined):
1) one model by describing a subsystem complements the
other, resulting in a model of the complete system;
2) two models give different views to the same system (e.g.,
a constructive model for simulation and code generation,
and a derived model for performance analysis or model
based diagnosis).
Tool combinations requested in practice by automotive
industry companies include Statemate MAGNUM with
MATLAB/Simulink and a UML tool with ASCET-SD (case
1) and Statemate MAGNUM and MATLAB/Simulink with
Rodon (case 1, model-based diagnosis).
Multitool design requires an approach to the integration of
heterogeneous models and a corresponding tool integration
technology. Different strategies are discussed in the next
section.
IV. MULTIPARADIGM MODELING—STRATEGIES
FOR INTEGRATION
The existing strategies for the integration of heterogeneous
models constructed using different tools fall into the following
two categories:
1) integration of operations (analysis, synthesis) on models;
2) integration of models themselves via model translation
Approaches of the first category are primarily useful for the
first of the two cases described in Section III-E, i.e., for han-
dling the integration of a subsystem into a larger system. Both,
cosimulation (integrated simulation processes) and coordinated
code generation (integrated code generation processes) belong
to this category; furthermore, cross integrations between simu-
lation and code generation are possible. Model translation on the
other hand can be used to approach both of the cases described
in Section III-E. Different approaches of both categories are dis-
cussed in more detail in the rest of this section.
A. Cosimulation
Cosimulation lets partial models of a system be simulated in
different tools and integrates the simulation processes. The ef-
fect is a distributed simulation [47] run by the simulation en-
gines of the participating CASE tools and a simulation back-
plane [48] (see Fig. 6). The backplane is a central co-simulation
engine mediating between the simulators.
Its most difficult task is the synchronization of the simula-
tion processes, which, in case of coupling discrete event and
continuous systems, means combining two completely different
Fig. 7. Code integration.
Fig. 8. Cosimulation combined with code integration.
timing mechanisms. The simulation backplane provides the nec-
essary interpolation mechanisms. Sophisticated solutions with
so-called optimistic approaches (involving lookahead and roll-
backs in order to improve performance) even work with extrap-
olations and predictions [48].
Cosimulation is a partial solution for model validation across
tools. It appears to be useful and sufficient especially where sim-
ulation is the only purpose of model integration, which is the
case for the combination of a system model with a model of its
environment. In this case, only the system model, which is con-
structed completely in one tool, enters into the code generation
phase, whereas the environment model is only used for simu-
lation. If, on the other hand, both models are constructive and
intended to be used for code generation (e.g., an open-loop con-
trol system connected with a closed-loop one), cosimulation is
insufficient. Cosimulation is an approach used in current auto-
motive industry projects, such as the one described in [49].
B. Code Integration
Code generation is the second major operation on (construc-
tive) models. We assume that every modeling tool has an associ-
ated code generator. The original situation without tool integra-
tion is that the subsystem codes generated by the different tools
have to be integrated by hand (Fig. 7).
In this situation, the system cannot be validated as a whole be-
fore its coding stage. There is a need for early validation, i.e., for
simulation. Of course, code integration can be complemented by
cosimulation (Fig. 8). The problem with this is the conceptual
gap between cosimulation and (manual) code integration. Since
they are not technically related, behaviors may differ.
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN
Fig. 9. Black box integration of subsystem code into a system model.
C. Code Encapsulation
Encapsulation of code as a “black box” submodel is a feature
offered by many CASE tools, facilitating both overall system
simulation and automated code integration (Fig. 9). The sub-
system model is validated in isolation by simulation using the
modeling tool dedicated to it and is translated to C code by
the associated code generator. Then, encapsulated as a mono-
lithic submodel, it is integrated into the model of the enclosing
system, which is being constructed using another tool. There,
the overall system can be simulated, but without the possibility
of stepping into the subsystem. During code generation for the
enclosing system, the subsystem code will be automatically in-
tegrated. This tool integration approach is found even within
tool suites of a single vendor. An example of this is the inte-
gration of statemate continuous modeler (formerly known as
VisSim) into statemate MAGNUM (unfortunately for simula-
tion only because continuous modeler is not supported by the
associated Rhapsody in MicroC code generator).
D. Model Encapsulation (Coordinated Code Generation)
In contrast to manual integration of subsystem code (Sec-
tion IV-B) and semi-automatic code integration by manual
encapsulation of subsystem code as a subsystem model
(Section IV-C), model encapsulation completely automates
code integration (Fig. 10). An original subsystem model is
encapsulated as an equivalent subsystem model in the modeling
language of the enclosing system; and the code generation pro-
cesses are integrated: Code generation for the enclosing system
drives the code generator for the subsystem (coordinated code
generation). By leveraging both the driven code generator for
the subsystem and the techniques known from code encap-
sulation (Section IV-C), coordinated code generation can be
complemented with overall system simulation.
It is clear that the “master” tool in this scenario has to know
about the “slave” tool. This is different from an integration of
two independent tools as by, e.g., a simulation backplane (see
Section IV-A).
As a special case, which arises due to increasing interest in
software architectures in the field of embedded software, co-
ordinated code generation can be applied to software architec-
ture models integrated with component models. The compo-
nents take the role of subsystems in the above scenario and are
287
Fig. 10. Model encapsulation (coordinated code generation).
modeled with dedicated tools, while the architectural model rep-
resents the overall system. Code generated by the point tools for
the components is glued together by composition code gener-
ated from the architectural design.
For example, architectural design in the DaVinci Tool Suite
[50], [51], following the ideas of the TITUS [52] approach, is
integrated with modeling of components in dedicated “behav-
ioral modeling tools” (currently MATLAB/Simulink). But, as
of now, DaVinci pragmatically combines model encapsulation
with code encapsulation (a component entity consists of both a
model and the corresponding code generated from it offline) in-
stead of directly driving component code generation on the fly.
In the GeneralStore environment developed at ITIV [53]
(see also Section V-A), UML is used as the architectural
design language in combination with dedicated tools including
MATLAB/Simulink for behavioral modeling of specialized
subsystems. In this approach, model encapsulation is per-
formed not only logically but also physically, i.e., resulting in
a single-source representation of the overall model including
the subsystem model. Physical encapsulation is based on
syntactical transformation, where component models (e.g.,
in MATLAB/Simulink) are represented as UML instance
models (using object and class diagrams). By reversing the
transformation, the original subsystem model is retained and
can be fed into the dedicated code generator.
E. Model Translation
Model translation is the most rigorous approach to integra-
tion. It can be applied both to subsystem integration and to
the integrating of different views on the same system (cf. Sec-
tion III-E). In principle, a system model is (syntactically and se-
mantically) translated from one modeling language to another.
A subsystem model is translated to the language used to de-
scribe the enclosing system and then is included into its con-
text. The result is a homogeneous overall model, and one tool
chain can be used for further processing of the complete system
(Fig. 11); the other tool is used as a front end for developing the
subsystem model with a domain-specific language. With two
different models of the same system (e.g., one for construction
and one for diagnosis purposes) sharing some information (e.g.,
structural), an initial frame of one model can be generated from
the other (to be complemented manually with the information
specific to that model).
288 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
Fig. 11. Model translation.
Defining complete, semantics-preserving translations (as
required for subsystem translation) is far from an easy task.
Mappings between two high-level modeling languages are
almost necessarily difficult due to a conceptual mismatch,
otherwise there would be no need for multiparadigm modeling
at all. Therefore, a reasonable application of model translation
is from a higher level to a more basic paradigm, e.g., from
differential-algebraic equations to imperative algorithms. Such
a “reductive” model translation is basically an abstract variant
of code generation. This approach has been implemented, for
example, in the COMTESSA project at FZI [54] to realize
MATLAB/Simulink to Statemate MAGNUM subsystem
integration. Here, discrete-time Simulink models are reduced
to basic activities with action language mini specs. Another
example is the DES/M modeling environment, where discrete
event models are translated into Modelica components [55].
The advantage of reductive model translation when com-
pared to code encapsulation is that the integrated subsystem is
a model itself, not a black box. Thus, white-box simulation of
the subsystem within its environment is possible. Furthermore,
the target code generator can optimize the system globally.
For example, a subsystem that is applied with constant inputs
may be reducible to a form simpler than the general form with
variable inputs that has to be assumed when subsystem code
is generated in isolation (the general principle is known as
partial evaluation [56]). A presupposition for this, of course,
is that model translation itself is not a prevailing source of
inefficiencies.
Model translation between system views has been im-
plemented, for example, in the COMTESSA project for the
purpose of model-based diagnosis. From constructive system
models (MATLAB/Simulink or Statemate MAGNUM), skele-
tons of diagnosis models (Rodon) are generated.
F. Multiparadigm Intermediate Languages
Model translation can be combined with multiparadigm inter-
mediate languages in order to efficiently handle multiple inte-
gration constellations. Instead of bilateral model translators ex-
plicitly linking two specific tools, models are translated to and
from and within a tool-independent intermediate modeling lan-
guage. Thus, the syntactic and some of the semantic parts of the
translators related to one tool can be shared.
Fig. 12. Model translation via intermediate language.
For example, the different model translators developed in
the COMTESSA project are based on a multiparadigm inter-
mediate language called Extensible Formal Language (XFL)
for tool-independent model representation. A high-level model
translation (within the same paradigm) carries the source model
(Simulink or Statemate) to an intermediate model (XFL). A
reductive translation to another paradigm for the purpose of
subsystem integration (from Simulink to Statemate only) is
performed within the intermediate language, whence the target
model is generated; diagnosis models (Rodon) are directly
generated from the intermediate representation (Fig. 12). The
approach and the design principles of XFL have been described
in [57] (see also Section V-B).
More generally, intermediate languages may be used to share
the back end of a tool chain for several front ends. As another
example, CASE data interchange format (CDIF) [13] is used
by [58] as the input language of a rapid prototyping tool chain.
Converters from commercial CASE tools, used for model cap-
turing and simulation, to CDIF complete the chains. In this sce-
nario, the subsystems of heterogeneous systems modeled with
multiple tools dedicated to specific modeling paradigms can be
integrated on the CDIF level.
A major advantage of XFL over CDIF as an intermediate
language is its language design, which is influenced by pro-
gramming language theory. It tightly integrates the different
paradigms (e.g., special effort has be spent on layering a discrete
time computation model on top of the imperative computation
model, resembling the way code generators typically compile
discrete time models to C code) and enables effective reduction
techniques based on partial evaluation.
V. APPLICATION EXAMPLES
The authors and their colleagues have been working on
implementations of different integration strategies supporting
multiparadigm modeling; some of the projects have been men-
tioned in Section IV. In the following, examples are given for
two recent activities. The first follows the model encapsulation
approach (cf. Section IV-D); the second applies model transla-
tion based on an intermediate language (cf. Sections IV-E and
IV-F).
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN
Fig. 13. Design process for UML-based model representation.
A. UML-Based Model Representation
As pointed out in Section IV-D, the GeneralStore envi-
ronment developed at ITIV [53] takes UML as the primary
modeling language and allows subsystems to be modeled in
more specialized tools (such as MATLAB/Simulink). The
GeneralStore model management and tool integration envi-
ronment provides a single-source representation of the overall
model, syntactically encapsulating subsystem models in UML
(physically residing either in a MOF [59] database or serialized
in XMI [17] files). In the case of MATLAB/Simulink, this is
based on UML instance models (using object and class dia-
grams). The syntactical transformations between the original
MATLAB/Simulink files (*.mdl) and the equivalent UML
representation are bidirectional.
Fig. 13 shows a small footprint of the design process. It starts
with a requirements analysis in an UML CASE tool (actually
ARTiSAN’s Real-Time Studio), here for an automotive Cruise
Control application (see Fig. 13, step 1). A class cruiser is
singled out as belonging to the continuous-time modeling
domain. System analysis of the cruise control proceeds with
an archetypal implementation of the cruiser subsystem using
MATLAB/Simulink (see Fig. 13, step 2). In order to encap-
289
sulate the cruiser model into the cruise control, GeneralStore
analyzes the Simulink file and generates class and object
collaboration diagrams from the dataflow diagram (see Fig. 13,
step 3).
C++ code for both the main part of the system and for sub-
system integration is generated from the main UML model. Ac-
tually, a template-based code generator (based on the velocity
template engine [60]) as part of the GeneralStore environment
is used instead of the built-in code generator of the UML tool.
For the MATLAB/Simulink subsystem model, The Mathworks’
Real-Time Workshop (part of the MATLAB suite) was adapted
and linked to the integration platform via the back-transforma-
tion from the UML representation to the original Simulink file
format and via target language compiler (TLC) scripts config-
uring Real-Time Workshop to generate a widely target-indepen-
dent C-code. The C-code generated by Real-Time Workshop is
encapsulated by the generated subsystem integration code as a
C++ class.
B. XFL-Based Model Translation
As pointed out in Section IV-E, subsystem integration via
model translation has been one of the approaches implemented
290 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
Fig. 14. Window lift.
in the COMTESSA project [54]. The translation process uses
a multiparadigm language, called extensible formal language
(XFL), for an intermediate representation of the model (cf. Sec-
tion IV-F). Designed as an intermediate language to be pro-
cessed by tools, XFL has an XML [16] based concrete textual
syntax. The semantics of XFL cover discrete-time and discrete-
event systems, layered on top of basic imperative constructs.
The translation of discrete-time models built up from a library
of predefined basic blocks is supported by a native XFL im-
plementation of the MSR MEGMA standard block library [61],
[62] which has also been implemented for MATLAB/Simulink
and other tools.
The following example deals with the functional behavior
of a window lift for a car. The system is able to detect an ob-
stacle in the moving area of the window by evaluating a hall
sensor signal. Therefore, it is important to know the position of
the window so that it is clear whether the window reached the
closing position or something is obstructing. The frequency of
a hall sensor signal gives information about the moving speed
of the window, where higher frequencies correspond to higher
speed. If the frequency of the hall signal gets less than a spec-
ified frequency, a stall of the window is detected and all motor
action is stopped. The behavior of the motor [Fig. 14(b)], in-
cluding the realistic model of the hall sensor [Fig. 14(a)], is a
typical continuous modeling task, whereas the window control
and discrete events such as the detection of an obstacle demand
for discrete control [Fig. 14(c)].
A statemate model [Fig. 14(c)] is the framework for the
overall design, separating the model into control and en-
vironment. For the discrete control statemate has been the
tool of choice. For the environmental components (e.g., the
motor) MATLAB/Simulink has been used. The first pass of
the model translator generates an XFL representation from the
original MATLAB/Simulink model. For the concrete example
of Fig. 14(b), main parts of the code look as shown in Fig. 15.
The functional properties of the model, including its hierar-
chical structure and references to library blocks, are preserved
(i.e., a back-translation to Simulink would be possible in this
stage, although all graphical information is lost). Next, an
XFL-internal transformation (system reduction) produces a flat
system model with an imperative specification of the system’s
behavior (Fig. 16). Next, this reduced model is used to generate
a periodically triggered reactive activity specified in the (im-
perative) action language of statemate MAGNUM. Finally, the
integration of the converted Simulink subsystem into statemate
is done interactively in statemate, where interface variables
have to be mapped. Statemate’s mechanism of generic charts
and instantiation is used for this purpose.
MÜLLER-GLASER et al.: MULTIPARADIGM MODELING IN EMBEDDED SYSTEMS DESIGN 291

supporting system design as well as component design. The

description of the heterogeneous parts and of different aspects
and views of the whole system, subsystem or component over
different phases of development requires different modeling
paradigms. Partial descriptions of a system have to be inte-
grated mainly for simulation and code generation; different
descriptions of a system for different purposes (e.g., design
versus verification) have to be related.
As a single multiparadigm modeling language and supporting
tools covering all aspects of embedded systems design are un-
available, several languages and tools have to be integrated. The
paper describes different strategies for integration, focusing on
the needs of simulation, code generation, and model-based di-
agnosis, and thus provides a classification for a variety of in-
dustry practices and state of the art. The basic principle is ei-
ther the integration of operations on models (such as simulation
or code generation) or model translation. Model translation is
successfully applicable to mappings from “higher” (i.e., more
abstract) to “lower” paradigms. As the authors have been in-
volved in several research activities related to the concepts pre-
sented here, application examples for two of the approaches are
included in the last part of the paper. Results obtained from the
integration of tools widely used for automotive applications are
very promising.

Fig. 15. Corresponding XFL representation.
Fig. 16. XFL representation of reduced system model.
VI. SUMMARY
First, we have shown that multiparadigm modeling is needed
for the design of embedded electronic systems, as they are
found, e.g., in the automotive industry. Being comprised of
heterogeneous components these systems need a system design
flow with an according meet-in-the-middle design strategy
REFERENCES
[1] Embedded Systems Glossary, M. Barr. [Online]. Available:
http://www.netrino.com/Publications/Glossary/
[2] A. S. Berger, Embedded Systems Design: An Introduction to Processes,
Tools, and Techniques. Lawrence, KS: CMP, 2001.
[3] W. Lawrenz, CAN System Engineering: From Theory to Practical Ap-
plications. Berlin, Germany: Springer-Verlag, 1997.
[4] OSEX/VDX Homepage (2004). [Online]. Available: http://www.osek-
vdx.org
[5] Das V-Modell (1997). [Online]. Available: http://www.v-modell.iabg.de
[6] Systems Engineering Standards and Models Compared, S. A. Sheard
and J. G. Lake. [Online]. Available: http://www.software.org/pub/exter-
nalpapers/9804-2.html
[7] K. D. Müller-Glaser, “CAD of microsystems: A challenge for system
engineering,” in Invited Talk at EURO-DAC’96 With EURO-VHDL’96.
Geneva, Switzerland: IEEE Computer Society Press, 1996.
[8] Saber Product Home Page (2004). [Online]. Available: http://www.syn-
opsys.com/products/mixedsignal/saber/saber.html
[9] IEEE 1076.1 (1999). [Online]. Available: http://www.vhdl.org/analog
[10] Specification and description language (SDL) ITU-T Recommendation
Z.100 (2000). [Online]. Available: http://www.sdl-forum.org
[11] P. Alexander and C. Kong, “ROSETTA: Semantic support for model-
centered systems-level design,” Comput., vol. 34, no. 11, pp. 64–70,
2001.
[12] , “Heterogeneous modeling support for embedded systems design,”
in EMSOFT 2001, ser. Lecture Notes Comput. Sci.. Berlin, Germany:
Springer-Verlag, 2001, pp. 1–13.
[13] Introduction to CDIF, J. Ernst. (1997). [Online]. Available: http://www.
eigroup.org/cdif/intro.html
[14] EDIF (2000). [Online]. Available: http://www.edif.org
[15] STEP: Standard for the Exchange of Product Model Data , 1994.
[16] Extensible Markup Language (XML) 1.0. W3C Recommendation
(1998). [Online]. Available: http://www.w3.org/TR/1998/REC-xml-
19 980 210
[17] XML Metadata Iinterchange (XMI), Version 1.1 (1999). [Online]
[18] The MathWorks, Inc. (2004). [Online]. Available: http://www.math-
works.com
[19] MATRIXx (2004). [Online]. Available: http://ni.com/matrixx/
[20] SPICE (2004). [Online]. Available: http://bwrc.eecs.berkeley.edu/
Classes/IcBook/SPICE/
[21] ACSL (2004). [Online]. Available: http://www.ACSLsim.com
[22] Modelica (2004). [Online]. Available: http://www.modelica.org
[23] ETAS (2004). [Online]. Available: http://www.etasgroup.com
[24] R.O.S.E. INFORMATIK (2002). [Online]. Available: http://www.
rose.de
292 IEEE TRANSACTIONS ON CONTROL SYSTEMS TECHNOLOGY, VOL. 12, NO. 2, MARCH 2004
[25] AANSYS, Inc. (2004). [Online]. Available: http://www.ansys.com
[26] I-Logix (2004). [Online]. Available: http://www.ilogix.com
[27] Cadence Design (2004). [Online]. Available: http://www.cadence.com
[28] Synopsys, Inc. (2004). [Online]. Available: http://www.synopsys.com
[29] Verilog (2004). [Online]. Available: http://www.verilog.com
[30] HyPerformix, Inc. (2004). [Online]. Available: http://www.hyper-
formix.com
[31] Foresight-Systems, Inc. (2004). [Online]. Available: http://www.fore-
sight-systems.com
[32] OMG Unified Modeling Language Specification, Version 1.3, 1999.
OMG Document ad/99-06-08.
[33] Rational Rose RealTime (2004). [Online]. Available: http://www.
ibm.com/software/awdtools/developer/technical
[34] ARTISAN (2004). [Online]. Available: http://www.artisansw.com
[35] B. Selic, G. Gullekson, and P. T. Ward, Real-Time Object-Oriented Mod-
eling. New York: Wiley, 1994.
[36] D. Harel, “Statecharts: A visual formalism for complex systems,” Sci.
Comput. Programming, vol. 8, pp. 231–274, 1987.
[37] “Technical Memorandum UCB/ERL M01/11,” Univ. California,
Berkeley, CA, http://ptolemy.eecs.berkeley.edu/publications/papers/01/
overview, 2001. Available.
[38] Telelogic AB (2004). [Online]. Available: http://www.telelogic.com
[39] G. Low and V. Leenanuraksa, “Software quality and CASE tools,” pre-
sented at the IEEE Software Technology and Engineering Practice, Pitts-
burgh, PA, 1998.
[40] dSPACE (2004). [Online]. Available: http://www.dspaceinc.com
[41] D. Greefhorst, M. van Elswijk, M. Maat, and R. Maijers, Evaluating
OO-CASE Tools: OO Research Meets Practice, ser. Lecture Notes
Comput. Sci.. Berlin, Germany: Springer-Verlag, 1998, pp. 486–488.
[42] S. Jarzabek and R. Huang, “The CASE for user-centered CASE tools,”
Commun. ACM, vol. 41, no. 8, pp. 93–99, Aug. 1998.
[43] O. L. Madsen, “Toward a unified programming language,” in Proc.
2000 Eur. Conf. Object-Oriented Programming (ECOOP’00), Cannes,
France, 2000, pp. 1–26.
[44] UML Profile for Schedulability, Performance, and Time Specification,
2002. OMG Document ptc/02-03-02.
[45] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Lan-
guage Reference Manual. Reading, MA: Addison-Wesley, 1999.
[46] M. von der Beeck, P. Braun, M. Rappl, and C. Schröder, “Model-based
software development for automotive ECU networks,” Electron. Syst.
Veh., ser. VDI-Berichte, no. 1646, pp. 293–331, 2001.
[47] R. M. Fujimoto, Parallel and Distributed Simulation Systems. New
York: Wiley, 2000.
[48] S. Schmerler, “Prädiktive Methoden für Optimistische Synchronization-
sprotokolle in der Verteilten Simulation (Predictive Methods for Opti-
mistic Synchronization Protocols in Distributed Simulation,” Doctoral
dissertation (in in German), Univ. Karlsruhe, FZI-Pub. 3/98, Karlsruhe,
Germany, 1998.
[49] M. Horstmann, S. König, G. Bikker, and A. Wegele, “Model integration
by co-simulation applied to hybrid automotive systems,” in Proc. 4th
Mathmod, I. Troch and F. Breitenecker, Eds., Vienna, Austria, Feb. 2003.
[50] (2002) DaVinci: Function Development of Vehicle Networks [Online].
Available: http://www.vector-informatik.de/kongress/VeCo_Vortrag06
_Wernicke.pdf
[51] M. Wernicke, “Verteilte systeme im griff (Mastering distributed sys-
tems)” (in in German), Automot. Electron. Syst., no. 6/02, pp. 28–30,
2002.
[52] U. Freund et al., “Interface Based Design of Distributed Embedded Au-
tomotive Software: The TITUS Approach,”, ser. VDI-Berichte, 2000.
[53] C. Reichmann, M. Kühl, and K. D. Müller-Glaser, “An overall system
design approach doing object-oriented modeling to code-generation for
embedded electronic systems,” in Proc. FASE 2003, Warsaw, Poland,
2003, pp. 52–66.
[54] COMTESSA Project (2002). [Online]. Available: http://www.fzi.de/
esm/projects/Comtessa/Comtessa_uk.html
[55] M. A. P. Remelhe, S. Engell, M. Otter, and P. J. Mostermann, “An en-
vironment for the integrated modeling of systems with complex con-
tinuous and discrete dynamics,” in Modeling, Analysis, and Design of
Hybrid Systems. Berlin, Germany: Springer-Verlag, 2002.
[56] T. Sheard, “Accomplishments and research challenges in meta-program-
ming,” presented at the Proc. SAIG 2001, Florence, Italy, 2001.
[57] G. Frick and K. D. Müller-Glaser, “Semantic integration of modeling
languages based on a reference language,” in Proc. 4th Mathmod,
I. Troch and F. Breitenecker, Eds., Vienna, Austria, Feb. 2003, pp.
1564–1573.
[58] A. Burst, “Rapid Prototyping eingebetteter elektronischer Systeme auf
Basis des CDIF-Datenaustauschformats (rapid prototyping of embedded
electronic systems based on the CDIF data interchange format),” Doc-
toral dissertation (in in German), ITIV, University of Karlsruhe, Karl-
sruhe, Germany, 2000.
[59] Meta Object Facility (MOF) Specification, Version 1.3, 1999. OMG
Document ad/99-09-04.
[60] Velocity (2004). [Online]. Available: http://jakarta.apache.org/velocity/
[61] MEGMA (2004). [Online]. Available: http://www.msr-wg.de/megma/
[62] Standardization of Library Blocks for Graphical Model Exchange,
Version 1.09 (2000). [Online]. Available: http://www.msr-wg.de/
megma/downlo.html
Klaus D. Müller-Glaser (M’03) received the
Dipl.-Ing. and Dr.-Ing. degree from the University of
Karlsruhe, Germany, in 1972 and 1977, respectively.
From 1977 to 1986, he worked for Siemens
AG, Synertek Inc., Honeywell Inc., and Bell Labs,
Allentown, PA, before he became responsible for
setting up the first commercial U.S. AT&T ASIC
Design Center in Sunnyvale, CA. In 1986, he was
appointed a Full Professor at the University of
Erlangen-Nürnberg, Nürnberg, Germany. In April
1993, he became a Full Professor and Director
of the Institute for Information Processing Technologies, Department of
Electrical Engineering and Information Technology, University of Karlsruhe.
He is a Director of FZI Forschungszentrum Informatik (Research Center for
Information Technologies), University of Karlsruhe. From 1996 to 2002, he
served as President of FZI. Currently, he is the Dean of the department. He
is author or coauthor of more than 150 publications in the field of design,
verification, and test for embedded electronic systems, microsystems, and SoC.
Gerd Frick (M’03) received the Dipl.-Information
degree in computer science from the University of
Kaiserslautern, Kaiserslautern, Germany, in 1998.
He joined the Electronic Systems and Microsys-
tems Group, FZI Forschungszentrum Informatik,
Karlsruhe, Germany, as a Scientific Assistant. His
current research is focused on languages and design
methodologies for embedded real-time systems.
Eric Sax received the Dipl.-Ing. degree in electrical
engineering from the University of Karlsruhe,
Karlsruhe, Germany, in 1993 and the Doctoral
degree from University of Karlsruhe, Karlsruhe,
Germany, in 2000.
He joined the Electronic Systems and Microsys-
tems Group, FZI Forschungszentrum Informatik,
Karlsruhe, Germany. While Manager of this research
group, from June 2000 to September 2002, he was
involved in various projects, mostly in the area
of the establishment of a seamless design flow
from idea to prototype. Since October 2002 he has been with IMH GmbH,
a DaimlerChrysler subsidiary within the MBtech Group. The projects he
manages are mainly about testing of automotive electronic control units. His
research activities address an integrated test approach from specification to
prototypical realization and production. His current challenge is mainly to turn
these innovative ideas from the academic field into daily use in the development
departments.
Markus Kühl (M’03) received the Dipl.-Ing. degree
in electrical engineering from the University of Karl-
sruhe, Karlsruhe, Germany, in 1997.
He then worked for the Institute for Information
Processing Technology (ITIV) as a Member of the
scientific research team. His topics were rapid proto-
typing and design of embedded systems. He joined
FZI Forschungszentrum Informatik, Karlsruhe, Ger-
many, in June 2002, where he now is the Manager of
the Electronic Systems and Microsystems Research
Group.