UML-to-ASCET Information Transfer - ETAS

By Marcel
Hachmeister,
Robert Bosch
GmbH
24
RT 1.2007
UML-to-ASCET
Information Transfer
Supporting all development phases from software
architecture through implementation
A core element of the transmission control software development process is the software
continuity spanning the range from initial architecture design through implementation.
This article discusses the manner in which fine-tuned tools support each development phase
while ensuring the consistency of the development process.
T he
increasing size and complexity
of software complements call for
description languages providing a
higher level of abstraction. There is the
old adage that a picture is worth a
thousand words and, after assembler
and C language programming, the
trend points to graphical description
languages.
Therefore, in an effort to arrive at
an efficient software development
process, Robert Bosch GmbH deploys
a precision-tuned combination of
graphical design and development
tools in the development of software
for transmission controls.
The software architecture or basic
design is specified in UML (Ameos by
Aonix), whereas the detailed design
and the entry of implementation information
are handled in ASCET by
ETAS. The process automatically transfers
all of the required information
from the UML model to ASCET. This
transformation is handled by the
aquintos.M2M model converter tool
by model-to-model transformation
specialist aquintos (Figure 1).
The results obtained in the various
phases are subject to a fixed interrelation.
This interdependency must not
be lost, and it is therefore safeguarded
by linking suitable tools. In this way,
high product quality is achieved and
the number of recursions limited to a
minimum, which effectively excludes
any occurrence of the heretofore experienced
inconsistencies (e.g., design
documentation no longer matches the
program code, etc.) caused by ”maverick
developments” within individual
development phases.
This article discusses the basic design
creation by means of UML (Unified
Modeling Language), the transfer of
the static software structure to ASCET,
as well as the subsequent detailed
design and software implementation.
Software architecture and basic
software subsystem design
Robert Bosch GmbH uses the Unified
Modeling Language (UML) in its transmission
control projects. The use of
this standardized and internationally
recognized description language prevents
misunderstandings and ensures
readability. The graphical notation
makes it possible to depict complex
situations in a clearly structured manner.
UML is specifically designed for
object-oriented development tasks.
Due to the required high level of
C code efficiency in embedded realtime
systems, the software for the
transmission control is programmed in
C language. For this reason, the possibilities
inherent in both object orientation
and UML description elements
are used only to a limited extent.
Figure 1:
Phases of software
development.
Figure 2:
UML class diagram.
The OMOS concept (German acronym
standing for object-oriented modeling
concept for ECU software) of Robert
Bosch GmbH was developed in order
to utilize essential elements of object
orientation, and to visualize these in
C code.
OMOS is available as a supplement in
the Ameos modeling tool.
The OMOS concept is based on two
major strategies:
• Handling and configuration of software
variants
• Linkage between basic design and
detailed design/implementation (e.g.,
mapping object-oriented methods
to C language by means of C code
frame generation)
Although the manner of implementation
of these strategies is briefly
described below, a detailed discussion
of OMOS would exceed the scope of
this article.
Inheritance is the principle used in
the description of variants. The objective
is to model the common software
components for a variety of projects in
the parent class. The project-specific
components are modeled in the child
class. As shown in Figure 2, this stylistic
device is also used to hide entire
functions (to accommodate a variety
of project requirements).
SW System Architecture
Architecture/Basic Design
of Software Subsystem
Detail Design
of Software Subsystem
ASCET Editor
«1-Class»
CL_TSiCnr
«1-Class»
CL_TSiDhl
«1-Class»
CL_TSiFo
«1-Class»
CL_TSiHil
Partial Object Diagram ---->
Software Structuring
Ameos
Implementation + Code Generation
of Software Subsystem
«1-Class»
CL_TSi_Bas
«1-Class»
CL_TSiHot
«1-Class»
CL_TSiWu
«1-Class»
CL_TSiWtr
«1-Class»
CL_TSiStgo
The objects are defined in the UML
class diagram. In the current example,
this is a class, and therefore the objects
are not explicitly represented. Class
diagrams comprise the central UML
element of the OMOS concept.
The software is configured in the
Configuration Editor. It defines both
the originating class and objects to
be instantiated, and defines the association
of classes with a (customer)
project.
Transformation
of Result of Basic
Design/Formulation
of Transformation
Rules
«1-Class»
CL_TSiStgo
«1-Class»
CL_TSiStgo_Bas
-bActv : bool
-sDet: uint8
-bDwnShft21: bool
-ctDwnShft21: uint8
-swtPlrTab_C: bool
-tTraMax_C: uint8
-rAccPedCst_C: uint8
-drAccPedRngB_C:
sint16
-rAccPedRngA_C: uint8
-rAccPedRngB_C: uint8
-nTosRngA_C: uint16
-nTosRngB_C: uint16
-ctDwnShft21_C: uint8
+CalcSituation()
+Is_bActv() : bool
«1-Class»
CL_TloTra
«1-Class»
CL_TloTcp
«1-Class»
CL_TloPed
«1-Class»
CL_TloW
Inheritance Diagram ---->
Representation of Variants.
The CL_TSiStgo_Bas
class can be removed
through configuration.
This initial phase creates the foundation
for the subsequent software expandability
and variance. The following
properties provide specific support
to developers:
• Graphical description
• Mechanisms for software characterized
by a large number of variants
(multiple use, project-specific variations)
Only the class diagram has a direct
effect on the detailed design/implementation.
The function of all remaining
diagram types is merely one
of a descriptive and thus supplementary
nature (e.g., sequence, state, and
activity diagrams).
Transformation of basic design to
implementation
For software subsystems possessing
only limited suitability for graphical
programming (e.g., the memory management
of an ECU, characterized
by its high ratio of tables and pointer
systems), a C code frame generation
function is provided (see OMOS). By
their very nature, the C code frames
automatically contain all essential UML
model information (e.g., measuring
and calibration variables from attributes,
INCLUDE instructions based on
communication interrelations, program
rumps for methods). The implementation
of the function contained
in the program rumps is then handled
by a standard C code editor, such as
CodeWright.
A graphical development tool with
auto code generation is used for all
other software subsystems, which
further increases software development
efficiency and quality. To this
end, the transmission control department
deploys ASCET.
Handling the model transformation
from UML to ASCET, the aquintos.
M2M model converter provides the
option to specify transformation rules.
The transmission control dept. is
currently working on mapping the
UML/OMOS models to ASCET V5.1.
Because the consistent use of classes
was not possible at the time of the
pilot phase, the mapping process uses
only modules in ASCET. The root
cause originated in an internal tool for
the management of measurement and
application variables.
To gather experiences with regard to
the development process, the initial
version is designed to serve as a prototype.
In the future, transformation
rules will be extended to include
ASCET classes as well.
Figure 3 depicts a transformation
aided by the M2M tool. ASCET modeling
occurs in modules.
For the UML model classes, transformation
rules were defined in consideration
of the OMOS concept.
Mapping includes all entity, communications,
and inheritance relations.
■➔
25
2007.1 RT

Figure 3:
Transformation using
aquintos.M2M tool.
Figure 4:
Excerpt from
Architecture/Basic
Design of ”Speed
Selection” software
subsystem.
26
RT 1.2007
«1-Class»
CL_FZGG
«1-Class»
CL_FZGG_KOMP
«1-Class»
CL_TDpDyn
«1-Class»
CL_TDpDyn_Bas
-idRdoAct : uint8
+GetGearReq( xGear:uint8 ) : uint8
TDpDynDUsp
TDpDynUsp
TDpDynDsp
«N-Class»
CL_TDpDynTab
-idAct : uint8
-xCtlTab_C : uint8
«1-Class»
CL_SIWA
«1-Class»
CL_SIWA_CUST
Ameos
«RAM_Groesse» -FWA : uint8
«RAM_Groesse» -CMO : uint8
«Kennwert» -HDK : uint8
«Kennwert» -CMOMIN : uint8
«Kennlinie» -ECMO : uint16
+IstWarmlauf( uint8 )
+IstWaBew( uint8 )
+ErmittleWarmlauf()
+DetermineWarmUp()
+ExitCondition( uint8 )
ASCET
+IsActive( idSp:uint8 ) : bool
+Reset()
«1-Class»
CL_MOT_LL
«1-Class»
CL_FSIT
XMI-Interface
COM API
«1-Class»
CL_MOT
«1-Class»
CL_MOT_AHK
«1-Class»
CL_MOT_ERW
«1-Class»
CL_FSIT_DEV
«1-Class»
CL_TloTra
«1-Class»
CL_TRcAdm
The implementation by means of
ASCET is carried out with the use of
several useful segments of the UML
model (selection of individual classes).
The selected classes are termed reference
classes, and they are marked
accordingly in the UML model. Because
the inheritance principle is unknown
in ASCET, inheritance relations
are subject to the following rule cited
here as an example:
”Proceed through the inheritance tree
of the reference class to the so-called
parent class, and collect all of the
attributes to be inherited. The attributes
thus collected are then transferred
to the reference class.”
Multiple instantiations with ASCET
As discussed earlier, the use of ASCET
classes in transformation is not yet
supported. To facilitate the use of
multiple instantiations (N-classes) in
ASCET, work on the extension of the
transformation guideline is ongoing.
The extension is depicted in the class
diagram in Figure 4. The diagram describes
interrelations between classes
and defines the names and numbers
of instantiations.
Readily recognizable are the three
instantiations of the CL_TDpDynTab
class as well as the communications
interrelations with adjacent classes.
As depicted in Figure 5, the multiple
instantiation must find its counterpart
in ASCET if the detail design and
implementation are to be effected.
To this end, the CL_TDpDynTab class
is created in ASCET. The methods and
attributes are adopted from the
class diagram. As shown in Figure 6,
the three instantiations of the
CL_TDpDynTab class are created in
the form of local attributes in the
CL_TDpDyn_Bas class.
Detailed design, implementation,
and automatic code generation
Both the detailed design and implementation
are carried out with the aid
of graphical programming – one of the
core elements in ASCET. The block
diagram frames for graphical programming
are provided as a result of
the transformation. Figure 5 depicts
an example of graphical programming
in the block diagram. The implementation
information for measurement
and calibration variables (attributes)
is completed in ASCET. At this point,
the automatic code generation can be
started.
The code generation is handled by
ASCET’s standard code generator with
customer-specific adaptations. The
code generator writes well-defined
C code. At the transmission control
department, one C file is generated
for each class, and optimizations for
1-classes are automatically considered
by ASCET. The executable program
(HEX file) is generated outside of
ASCET by means of the standard development
environment.
The measurement and calibration
variables (attributes) must be measurable
by a calibration tool. For the modules
and classes, ASCET generates
associated files in accordance with the
MSRSW standard. The same standard
also contains implementation information
for C code. This information
permits the generation of c and h files.
In this way, the measurement and calibration
variables are made available in
the application program (Figure 7).
ASCET and its code generation is
successfully deployed in several divisions
of Robert Bosch GmbH.
Summary
The development process under discussion
provides developers with the
capability to graphically describe their
software from the point of designing
the architecture to final implementation.
Variant handling, which is so
essential in the automobile industry,
is integrated in the process. Each process
phase makes use of specifically
optimized tooling. Because the information
belonging to individual development
phases is permanently interlinked,
it is not possible for these
phases to become dissimilar or suffer
from ”maverick development”. As part
of the design process, the graphical
UML notation unambiguously describes
even complex circumstances.
ASCET makes it possible to also perform
function development at the
graphical level. At the same time, the
graphical modeling of algorithms
provides an excellent documentation.
The deployment of the described development
process prevents recursions
and significantly increases development
efficiency.
Three instantiations of
CL_TDpDynTab class
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Usp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
DUsp
CL_TDpDynTab
PAR_idTyp
PAR_idRdo IsActive
Dsp
Figure 5:
CL_TDpDynTab
class in ASCET
with Detail Design/
Implementation.
Figure 6:
Local instantiations
of CL_TDpDynTab class.
Figure 7:
Excerpts from
ASCET-generated
files for build
process.
C Language File MSRSW File
27
2007.1 RT