03B-128
Model Based System Development in Automotive
Martin Mutz, Michaela Huhn, Ursula Goltz
Institute for Software, Program Development Department
Carsten Krömke
Volkswagen Inc., Electric/ Electronics
Copyright © 2002 Society of Automotive Engineers, Inc.
ABSTRACT
The paper presents a major part of the STEP-X project
(Structured Development Process by the example of XBy-Wire-Application in the automotive), namely a seamless, model based software development process in
automotive engineering.
Our process is model based and supported by a tool
chain. The tool DOORS is used for requirements management and engineering whereas the CASE tool Artisan
RtS based on the Unified Modeling Language (UML) and
the CASE tool Ascet SD are used for specification and
design purposes. Each of these tools has its particular
strength in a certain design phase.
We propose designing rules and modeling guidelines for
the development of state based behavior which conforms
to seamless model transformation in our tool chain. The
rules are checked by an embedded rule-checker.
Additionally we illustrate our approach in a case study on
a subsystem of the Volkswagen car electronics. The
case study is characterized by state-oriented and concurrent behavior as well as time and value-discrete
information processing.
INTRODUCTION
In the last years the role of software in vehicles has
grown dramatically. Body electronic features and driver
support functions turn out to be crucial for the success of
modern vehicles. Automotive software will become even
more complex and expensive in future. It is planned to
extend established functions and to implement new
functionality which will use the formerly isolated ECUs
(electronic control units) as an integrated network. These
functions will be realized as cooperating distributed realtime tasks. Thus, on the one hand system complexity will
grow, on the other hand short time-to-market cycles and
a considerable number of variants needs a well-
structured development process supporting the reuse of
components at all phases. We aim for a seamless
development process for automotive functions with
structured methods supported by case tools.
We start with the informal requirements documents as
they are presently in use. In a first step, the textual requirements are analyzed and improved w.r.t. aspects like
structure, completeness, and consistency. This is done
using the requirements management and engineering
tool DOORS. Next a model based function specification
and the system architecture are elaborated using the
UML tool Artisan RtS. When it comes to implementation,
the design is transferred to Ascet SD. Ascet SD allows
automated code generation optimized for controllers
specific in the automotive area. We consider not only all
phases from requirements engineering to code generation, but also the integration of tools and methods
proven in practice. This raises applicability and
acceptance of our approach, but for the prize of a more
heterogeneous tool chain.
Although many tools for embedded software design offer
object-oriented concepts for structuring and state-based
behavioral models (e.g. statecharts), the tools differ in
the modeling elements and semantical details. Thus the
exchange of models between different tools is not a
question of the file format, but a difficult problem of
semantic transformations. We have implemented an
automated transformation from UML statecharts modeling the design on an abstract level to more detailed
„implementation statecharts“ in Ascet SD notation. We
present design rules and modeling guidelines for UMLstatecharts, which are a prerequisite for the transformation and which can be automatically checked by a rule
checker module integrated in a Java program. We
demonstrate our model based design process and the
tool chain with a case study on a window lift system.
STRUCTURED DEVELOPMENT PROCESS
•
In the STEP-X project we follow a model based
approach. Different graphical notations are used in our
development process for embedded automotive systems.
A system description contains information about functions, architecture, distribution of ECUs, actors, sensors,
and the environment. The information is introduced in
different phases of the design process. For a seamless
development process, those information has to be
integrated tightly.
•
In the next subsections we present some phases of the
structured development process of the STEP-X project
(see fig. 1) in more detail.
Requirement Specification
Functional High Level Design
Partitioning
SW (hybr.) SW (discrete)
HW
Detailed Design
SW (hybr.) SW (discrete)
HW
Code Generation
SW (hybr.) SW (discrete)
Diagnosis
HW
Bus Configuration
and
Communication
Testing
HW
The software control of the four windows is distributed
over five different ECUs. An ECU processing the local
functions is assigned to each window. A central module
executes functionality common to all windows. Variants
specific for countries or vehicle types are not considered
in the model.
REQUIREMENT SPECIFICATION
The development process starts with the requirements
specification which is divided into two parts:
1. Functional requirements
2. Non-functional requirements
Analysis
Architecture Design
SW (hybr.) SW (discrete)
Timing constraints, e.g. delayed closing of all
windows during comfort closing
Multiple functionality of a switch
Functional requirements describe what the system shall
do, in particular the tasks of the electronic control. Nonfunctional requirements concern quality criteria, all kinds
of restrictions w.r.t. the design, performance and
maintainability, reuse of components, and the conformance to standards [2]. Non-functional requirements are
given as text or references to other documents. Functional requirements are additionally described by suitable
UML diagrams. The textual requirements and the
corresponding UML models are managed by DOORS.
Figure 1: Structured Development Process of STEP-X
DOORS
CASE STUDY – WINDOW LIFT SYSTEM
In order to illustrate our approach, we consider a window
lift system. The system model and its environment are
specified by UML diagrams, block diagrams and state
machines as supported by Artisan RtS and Ascet SD.
The case study is based on a specification of a
Volkswagen window lift system. It is characterized by
state-oriented and concurrent behavior as well as timeand value-discrete information processing.
The following functionality has to be considered:
•
•
•
•
•
1
Manual / automatic control of all 4 windows
1
Comfort closing / opening through key-operated
switch and radio remote control
Child protection
Primitive shut protection
Restriction / extension of the functionality depending
on the status of other components (ignition, door
position, etc.).
simultaneous closing / opening of all windows
The requirements management and engineering tool
DOORS by telelogic [6] is one of the leading tools in the
field and wide spread in automotive. It supports extensive
features for analysis and tracing of requirements.
DOORS offers a multi-user platform for the development
of structured requirements documents. DOORS offers
several structuring concepts like modules and headings.
In DOORS, elementary requirements are considered as
objects. They can be classified by freely definable
attributes. Related requirements are connected by links,
no matter whether they belong to the same or another
document. Via links, one can trace the dependencies in
requirements documents. DOORS offers comprehensive
support for managing these links. The evolution of
requirements during the development process can be
traced by various history functions. The embedded
language DXL is used to implement interfaces to other
tools. The interfaces can be modified or extended by
application programmers. Thereby UML-models or block
diagrams from continuous modeling can be linked to
DOORS objects.
Requirements Analysis
Artisan RtS
Based on existing documents, a new specific structure
for automotive requirements was worked out. Different
kinds of information like functional requirements, parameter lists or the glossary are split in separate documents (DOORS modules). Each document has its
specific internal hierarchical structure (see fig. 2). If
necessary, attributes are assigned to the requirements to
classify aspects like quality of service. Related
requirements and graphical representations are referenced via links. Also UML models of particular aspects
or components are linked to the corresponding requirements. Thereby the designer can navigate through the
textual and model based system descriptions and gets a
better understanding of the system under development.
The links are also used for completeness analysis.
Artisan Realtime Studio by ARTiSAN is a CASE tool
based on the UML. The tool supports most of the UML
diagrams. Additionally it offers diagram types for the
modeling of the system architecture, the distribution of
tasks and their communication (concurrency diagrams)
and non-functional aspects. The discrete system behavior is modeled by UML statecharts which can be
simulated. Artisan RtS provides automated code generation and reverse engineering. The repository handles
the access to the models and the configuration management in a multi-user project.
Analysis models
Scenarios show typical interactions between the user
and the system, exceptionary behavior or test cases.
They are represented by use case diagrams. Use cases
are still a mainly informal notation. (see fig. 3).
Figure 2: Functional requirements with DOORS
Figure 3: Scenario of the window lift system in a Use Case Diagram
In the STEP-X development process- as in other projects
on automotive software design like FORSOFT II [3] links are inserted for the following purposes:
1.
2.
3.
4.
Improving the understanding
Representing mutual dependencies on requirements
Navigation to models
Tracing of requirements
ANALYSIS
Next the system functions are defined. In the objectoriented analysis based on the DOORS requirements
documents, the objects and their methods are identified
and communication with the environment is specified. In
this phase, Artisan RtS is used for modeling.
Complex scenarios are refined into more detailed use
case diagrams. In case timing constraints or the ordering
of events is of importance, we introduce sequence
diagrams.
A major goal of this step is to improve the understanding
of the system under development. We consider the
system boundary at the interface to the user, the
interactions are determined by the sensors, buttons and
other hardware.
Functional Decomposition
Afterwards the functions of the system are specified. The
functions are modeled as modular logical entities on an
abstract level. Complex functions are decomposed to
increase the reuse of components. Then the data flow is
analyzed and specified using interfaces to ensure
modularity.
The communication of a complex function with other
system components or the environment is realized by a
coordinator class unique for each complex function. This
pattern was applied uniformly for the decomposition of all
components and all hierarchical layers.
Functions, interfaces, and signals are represented in
class diagrams. To improve readability, functions are
structured hierarchically. Signals sent and received by
functions on the same hierarchical layer are modeled by
dependency arrows.
Signals sent between functions from different hierarchical
layers are modeled by associations which are annotated
with the signal type (see fig. 4). Interfaces are modeled
using the UML lollipop notation.
FUNCTIONAL HIGH LEVEL DESIGN
In the high level design the variants are instantiated,
signals are refined and assigned to the instances, and
the behavior is specified using UML state diagrams. In
the following these steps are described in detail.
Variants
Now we build the variants of the functions and instantiate
them. Variants are introduced if we need several functions with similar structure and behavior. For instance, in
the window lift system we build three variants of a control
logic: one for the driver door, one for the passenger and
one for the rear doors. The control at the driver door
differs from the others as it allows to run all windows. The
control at the rear doors contains an additional subfunction for child protection. Variants are modeled by
class diagrams. Fig. 5 shows the variants of the window
lift system.
Figure 5: Variants of the window lift class
Figure 4: Decomposition of comfort window movement
Coordinator classes control the communication of the
sub-functions among each other and with the rest of the
system. At this early development phase, all information
about dependencies between functions is encapsulated
in the coordinator class. Later it may be spread in other
elements of the design.
To summarize the steps of the analysis:
1. Use case analysis: Identification of actors and
scenarios and use cases
2. Refinement of scenarios by textual descriptions and
sequence diagrams
3. Definition of system functions
4. Functional decomposition
5. Analysis of data flow and definition of interfaces
6. Modeling of hierarchical functions, interfaces and
data flows in class diagrams
Variants are linked to the original class through dependencies annotated by <<variant>>. In the window lift
system the variants only differ with respect to their
coordinator class.
It is possible that building variants generates new mutual
dependencies on the instances which were not known in
the analysis phase. These are added to the existing class
diagrams. Moreover, the interfaces are refined appropriately. Interfaces are modeled by parameterized
classes which are also called template classes. They
handle variable aspects of classes. A template class may
not be a super class or the target of an association. First
the parameters have to be bound to values. The
parameters are noted in a dashed box at the upper right
corner of a class symbol (see Fig. 6).
To keep communication more flexible, not only the
signals itself but also their source are first specified in a
parameterized way. By instantiating the templates, information on the source of signals may be added to the
interfaces.
E.g. the top level coordinator class of the window lift
system evaluates all sensor signals from the car
environment like sensors, buttons, remote control etc.
The signals are sent to the control units of the
corresponding window. At the local control units the
coordinator class determines how to react on a signal.
Analysis of signals from the environment
Next the signals from other parts of the vehicle are
analyzed in detail to refine actors and their interfaces. A
structured representation of signals from sensors,
buttons and switches is given in a class diagram (see fig.
7). Signals are usually named X_Y_Z or X_Z where X is
the source of the signal, Y the addressed window and Z
the type of the signal. In particular, D stands for driver, P
for passenger, RL/RR for rear left/right, and CP for child
protection. UEKB-stands for the overpressure exception
handling. O means Open, C Close, and UE-overpressure. The buttons have different states to trigger manual
opening and closing or the automatic drive of the
corresponding window.
Figure 7: Coordinator Statechart of window lift system
The coordinator consists of seven sub-states executed in
parallel. The upper four realize the window control for the
driver and the passenger windows and the two rear
windows. Each sub-state itself contains a statechart
describing the function in more detail. Figure 8 shows the
control of the driver window. By the buttons the driver
window can be opened or closed manually (the window
moves as long as the button is pressed) or in an
automatic drive until an upper or lower stop position is
reached.
Figure 6: In- and output signals from the environment
System behavior modeled by statecharts
The behavior of the system is modeled already in the
high level design by UML statecharts [4] to allow for early
simulation and testing of the design. Some remarks on
state charts are given in the section on design vs.
implementation automata. The last step of the high level
design is to assign state diagrams to the functions and
coordinator classes. All signals received from the
environment are handled by the top level coordinator
class which sends them to the addressed subordinate
function or coordinator. Figure 7 shows the state diagram
of a coordinator.
Figure 8: Behavior of the control in the driver door
Depending on the status of the ignition, a release signal
for the window lift system is set, which activates or
deactivates certain functionality. For instance an automatic window drive is only possible if the board net is
activated. The comfort closing is only activated if the
board net is down. The lowest parallel (orthogonal) substate in figure 8 models the child protection. If the child
protection is active the buttons at the rear doors are
deactivated.
As described earlier the control is located at the
coordinator class. The movement of the windows is
controlled by local classes which sent and receive signals
from the motor of the corresponding window. A
statechart for the local control of a window lift motor is
shown in figure 9.
Figure 10: Distribution of instances on five ECUs
Figure 9: Behavior of any window
Here the advantages of object-orientation show up, since
the motor control is only modeled once and then
instantiated for each window. Thus not only the design
(and the derived code) will be smaller, but also it
becomes more readable, quality assurance is more
efficient and maintainability is improved.
Within the components, the instantiated functions are
represented as objects. In order to improve the readability of the architecture we abstain from the representation of all instances in the nodes. If necessary
nodes can be represented more detailed in separate
diagrams. Increasing the degree of detail requires an
additional structuring. Software components communicate through interfaces which are represented as lollipop notation (see figure 11).
To summarize the steps of the architecture design:
To summarize the steps of the high level design:
1.
2.
3.
4.
Building of variants and analysis of new data flows
Classification of signal sources
Instantiation of variants
Refinement of data flows and binding of interface
template classes
5. Refinement of signals and the environment
6. Modeling of the refined class diagrams
7. Modeling of the system behavior by statecharts
1. Instantiation of variants and functions; representation
in class diagrams
2. Distribution of instances on logic ECUs;
representation by deployment diagrams
ARCHITECTURE DESIGN
In this phase instances are defined and distributed over
the logic electronic control units. The system architecture
(in particular some restrictions from the physical distribution) has to be considered in the instance creation. Depending on, whether a function is implemented in a
distributed manner or centrally, it must be instantiated
once or several times.
The instantiated functions and variants are assigned to
the ECUs. Deployment diagrams are used for
visualization. These diagrams show ECUs as nodes
(arithmetic unit and storage capacity) and the software
components available on them (see figure 10).
Figure 11: Details of the central ECU
DETAILED DESIGN
In the early development phases, the Unified Modeling
Language was applied for modeling, because on the one
hand it supports the object-oriented approach and on the
other hand it is a quasi industrial standard. Similar
approaches are taken in other automotive projects
[3,5,6]. A further benefit of the UML is that numerous
tools are available for modeling. These tools do not only
allow to draw models for documentation purposes but
also to simulate and partly verify the design. Code
generation from class diagrams and state charts is
supported by several tools. Unfortunately, the generated
code is presently not optimized for micro controllers.
Thus the tools are not suitable for the implementation
phase. Another drawback is that design models for
continuous components are often difficult to integrate.
This is a difference between Ascet SD classes and
object-oriented approach.
The deployment diagram from the high level is
transferred into Ascet SD. Blocks represent the UML
components and have fixed inputs and outputs. A vehicle
environment is modeled for simulation. For this purpose,
two different blocks are introduced: First a block
environment that contains all keyboard switches and
lights of the comfort system and secondly, the block
sensor-coordinator, which receives signals from the
sensors and thereby influences the behavior of the
window (e.g. shut protection). The functions and their
variants are modeled as classes and automata like in the
high level design. A part of the architecture of the window
lift system is shown in figure 12.
Modeling with Ascet SD
In our STEP-X development process, Ascet SD by ETAS
[8] is used in the implementation phase. It offers a
developing environment for ECUs. In particular Ascet SD
supports the phases from detailed design up to code
generation. Block diagrams are mainly used to structure
the system. In order to describe the behavior, state
machines can be used as well as C-code and the specific
language ESDL. In addition Ascet SD offers elements for
the specification of real-time behavior. Particular
advantages of the tool Ascet SD are the simulation
facilities for the state machines and the code generator
which generates optimized code for different micro
controller targets that are commonly used in automotive
applications.
Modeling architecture and behavior
The architectural model from the high level design and
the attached statecharts are the basis for modeling the
system structure and behavior. The architecture is
represented by Ascet SD block diagrams. Single
functional variants are represented by classes to which
state machines are assigned. The state machines are
discussed in detail in the following chapter where we
consider the transformation of UML state diagrams to
Ascet SD state machines.
The communication between functions is achieved by
method calls, similar as in the UML. An other and more
common way to realize communication is to embed the
classes and/or their instances into blocks. Thereby,
information can be exchanged by messages (global
variables). Contrasting methods which may only have a
single return value, in blocks several signals may be sent
to different components. Blocks may contain several
blocks and instances so that a hierarchical structure is
possible. However, blocks cannot be inherited.
Figure 12: Part of architecture of the window lift system in Ascet SD
The behavior of the functions is modeled by Ascet SD
state machines. The signals received by a block are
transmitted automatically to the embedded state machines where possibly a transition is triggered. However,
the semantics of UML and Ascet SD statecharts differ in
many points. In particular UML state charts offer powerful
modeling elements that are not available in Ascet SD.
How to adapt the two statechart semantics is discussed
in the next chapter.
To summarize the steps of the detailed design:
1. Designing the architecture with block diagrams
2. Definition of the communication channels
3. Modeling behavior by state machines
AUTOMATIC MODEL TRANSFORMATION
One of the major problems to be solved for the seamless
tool support of our development process is the transition
from the UML tool Artisan to Ascet SD, which generates
small and efficient code for ECUs from simple statecharts. On the one hand, we use comfortable modeling
features from UML statecharts which are not available in
Ascet SD, on the other hand the semantics implemented
in these tools differ even for common features. We aim at
developing tool support for a model transformation to
solve this problem. The following subproblems are being
solved:
•
•
•
•
A rule checker has been implemented which checks
statecharts with respect to user defined rules.
A tool for the (semi-)automatic transformation of
Artisan statecharts in Ascet SD state machines is
being developed. Basis of the transformation is an
analysis of the semantic differences.
A model optimizer is supposed to improve the model
which is generated by this transformation with the
aim of obtaining more compact code.
Finally, we will develop a tool for checking the
equivalence between Artisan and Ascet SD models
with respect to certain properties. One application of
this tool could be to check models used for
implementation against the models given in the
digital requirements specification.
Fig. 13 shows the structure of the model transformation
tool being developed. In the following, we explain the
parts in more detail.
Figure 13: Concept of the (semi-)automatic model transformation
DESIGN AUTOMATA VERSUS IMPLEMENTATION
AUTOMATA
One of the main difficulties for obtaining seamless tool
support is dealing with differences in the semantics of
models in the tools being used. It is important for our
methodology to be able to use the interplay between
different UML models and the comfortable modeling
features in statecharts as offered by Artisan RtS. On the
other hand, it is indispensable to use a tool specialized
for generating code for ECUs as Ascet SD to be able to
obtain compact code. To be able to integrate both tools
in our process, we thoroughly analyzed the semantic
features for statecharts in Artisan, respectively state
machines in Ascet SD.
Statecharts concept of Artisan RtS
UML state diagrams are an extension of transition
diagrams. The statecharts support hierarchy, structure
and orthogonality. UML statecharts consist of states and
transitions. A state can be basic, concurrent or
composite. If a state is basic it has no sub-states. A
composite state has sub-states and exactly one of them
is active at a certain point of time. A concurrent state has
composite sub-states. All of them are active if the parent
state is active. Composite, concurrent and basic states
form a tree structure and this hierarchy allows for
stepwise refinement of the behavior of complex systems.
States are connected by transitions.
In the simple case transitions are connected directly with
a source and a target state. UML allows the connection
of transition segments by different kinds of connectors
(join, fork, condition, selection and junction connectors).
They can be used e.g. to split an incoming transition into
multiple outgoing transitions with different guard
conditions. For further details we refer to [4]. Transitions
may be labeled by events, guards and actions. Events
trigger transitions: if the corresponding event occurs and
the transition guard evaluates to true, the transition has
to be taken immediately if there is no conflict with another
transition. A conflict happens e.g. if two transitions leave
the same state and both are enabled. Then only one of
them can fire. Transitions also may be in conflict if their
source states are related hierarchically. In this case the
UML priority scheme gives priority to transitions having
source states lower in the state hierarchy. Actions are
performed when a transition is taken; Examples for
actions are an assignment or a sending of events.
The UML assumes a data structure like a queue to store
events which shall be received in the next step by a
statechart. A dispatching mechanism selects one event
of the queue if processing of the previous event is fully
completed (run-to-completion). Temporal behavior can
be modeled through time events (events are sent delayed by a certain time) and scheduled actions (actions are
executed delayed). State transitions of the system occur
in a step-wise manner. A step contains a maximal nonconflicting set of transitions that fire simultaneously.
State Machines concept of Ascet SD
Ascet SD state machines consist of simple and of
hierarchical states. Substates are supported in the same
way as in Artisan RtS, however there is no orthogonality,
i.e. parallelism, in state machines (this will be one of the
main tasks in the model transformation).
Transitions are labeled with events, conditions and
actions, whereby events are required. Each transitions
must have an explicit priority such that the model will be
deterministic. For hierarchical states the priority concept
is opposite to UML: transitions higher in the hierarchy
have higher priority. Fork, join and junction connectors
are unified as one type of connector. Time aspects
cannot be specified by transition labels because all
Ascet SD transitions are time triggered.
RULE CHECKER
Our rule checker is part of the model transformation
entity we are implementing for a seamless tool chain. It
verifies whether user defined design rules on state charts
have been observed in a given model. For our
application, these rules are currently being designed. On
the one hand they aim for a compact, consistent and
uniform modeling on the UML layer, on the other hand
appropriate models for the transformation to Ascet SD
state machine shall be achieved.
The rule checker is parametric with respect to the rules
being checked, so it may be used also in other contexts.
Figure 14: Display of error through the tree
Fig. 14 shows the user interface of the rule checker and
the result of an analysis for an example statechart. In the
right window, the statechart is shown as a tree structure.
Different types of states (AND- , OR- and pseudostates)
are represented by different shapes of nodes. Using the
shift button one may obtain detailed information for each
node in a yellow box. In the left window, all messages
(warnings, errors and suggestions) are listed. Selecting a
message results in a red arrow pointing to the relevant
part of the tree.
The rule checker allows various input formats, based on
XMI. The model is checked according to user defined
rules. A set of predefined rules (49 rules ordered in 3
categories) is offered. A selection is given below:
If the model contains no errors, it may be stored and
delivered to the next module (e.g. the kernel of the model
transformation).
Design check
MODELTRANSFORMATOR AND VERIFICATION
•
The remaining parts of our framework (model
transformator, optimizer and verificator) are currently
being developed. For the transformator and the
verificator, we have obtained first results from preliminary
studies which are shortly outlined below.
•
•
•
Checks if the statechart contains two or more states
with equal names
Detects illegal denotation of statechart elements,
including state names, transition and trigger names
Detects transitions without any trigger, guard and
action
Detects isolated states (states without incoming and
outgoing transitions)
For the transformation of statecharts into hierarchical
state machines, the semantic studies exhibited that a
number of features may not be transformed. These are
for example
Consistency check
•
•
•
•
Ensures that the diagram does not contain empty
orthogonal components.
Detects defined events that are not used as a trigger
in any transition.
Checks if the root state contains an initial state.
Detects miracle states (states without incoming
transitions but with outgoing transition).
The rules can be changed or redefined by the user. Due
to a special format, they are independent of the
implementation in the tool. Rules can be activated or
deactivated by the user of the rule checker.
•
•
•
•
•
timed events and actions,
transitions with negated events,
create- and destroy-events,
nondeterminism,
C-functions.
These features may be forbidden by the rule checker and
will result in error messages.
The model transformator then has to solve the following
tasks:
•
•
•
Transform parallelism into sequential execution.
Modifying priorities according to the respective
semantics.
Adapt transformable constructs.
To prepare for verification, we will also allow to flatten
hierarchical states.
The resulting state machine will be optimized to obtain
compact target code (this part of our approach is still
future work).
The verificator, for which we are currently carrying out
prototypical studies, will compare statechart models with
hierarchical state machines. One way of using it would
be to compare state machine on the implementation level
with statechart specifications. In particular when dealing
with variables, we will face problems with complexity and
state explosion. One way of overcoming these problems
will be to use abstraction methods.
CONCLUSION
This paper presented the seamless structured
development process with the corresponding tool chain
and the design methodology being developed in the
STEP-X project. We used the window lifter as a case
study. The models were generated and simulated with
the UML tool Artisan RtS. For the system architecture,
we used UML deployment diagrams.
We outlined a tool supported transformation to obtain
Ascet SD state machines from Artisan RtS Statecharts.
The code generation for the electronic control units, the
partitioning of the system and the communication
between components is then obtained with Ascet SD.
Further research will concentrate on the integration of
testing and information for diagnosis in this process.
ACKNOWLEDGMENTS
This work has partially been funded by the Volkswagen
Inc. within the STEP-X project.
REFERENCES
1. C. Schröder, U.Pansa: UML@Automotive - Ein
durchgängiges und adaptives Vorgehensmodell für
den Softwareentwicklungsprozess in der Automobilindustrie, Praxis Profiline, IN-CAR-COMPUTING,
2000
2. B. Gebhard and M. Rappl: Requirements Management for Automotive Systems Development,
SAE2000, SAE Press 00P-107, 2000
3. M. von der Beeck, P. Braun, M. Rappl, C. Schröder:
Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke, VDI, 2000
4. OMG Unified Modeling Language Specification,
www.omg.org
5. M. Götze, W. Kattanek: Experiences with the UML in
the Design of Automotive ECUs, University Ilmenau
6. AUTOMITIVE-UML: DaimlerChrysler AG
http://www.automotive-uml.com/.
7. http://www.telelogic.com/products/doorsers/doors/
8. www.etas.de/
CONTACT
The authors’ e-mail addresses:
[email protected]
[email protected]
[email protected]
[email protected]
Web Address of the STEP-X project:
www.step-x.de