A Mechanism for Data Interchange Between Embedded Software
Sub-systems Developed using Heterogenous Modeling Domains
Padma Iyenghar
1
, Benjamin Samson
2
, Michael Spieker
3
, Arne Noyer
3
, Juergen Wuebbelmann
2
,
Clemens Westerkamp
2
and Elke Pulvermueller
1
1
Software Engineering Research Group, University of Osnabrueck, Osnabrueck, Germany
2
Institute of Computer Engineering, UAS Osnabrueck, Osnabrueck, Germany
3
Willert Software Tools GmbH, Hannoversche Str. 21, Bueckeburg, Germany
Keywords:
Embedded Software Sub-systems, Model-based Embedded Software Development, Heterogenous Modeling
Domains, UML, Matlab/Simulink.
Abstract:
In the domain of embedded systems, the complexities involved in embedded software development are being
successfully addressed by the emerging field of model-based software development and testing. However, in
embedded systems, the underlying embedded software is often expected to collaborate with various hardware,
mechanical, electrical modules/technologies. To address this aspect of heterogeneity in embedded systems,
practitioners of model-based embedded software engineering are required to use more than one modeling
language. This is essential to address the multi-faceted design aspects/requirements of an embedded system.
This paper elaborates on the existing data interchange and coupling mechanisms between embedded software
sub-systems modeled using UML and Matlab/Simulink. While there are some existing coupling mechanisms
for data exchange among heterogenous modeling domains, they are all not applicable to all real-time oper-
ating systems and/or limited to a few simulation studies. This paper addresses the aforementioned gaps and
proposes a simple, generic methodology for data exchange between events (in UML domain) and signals
(in Matlab/Simulink domain). The proposed approach is elaborated using a seesaw (real-word) embedded
software system application scenario example. Initial prototype implementation of the proposed approach,
experimental results and some future directions are outlined.
1 INTRODUCTION
Model DrivenDevelopment(MDD) introduced by the
Object Management Group (OMG) (Object Manage-
ment Group, 2014), is regarded as the next/ongoing
paradigm shift in embedded software development. It
is deemed as a key for fast, error-free and automated
development of embedded software systems. On the
other hand, heterogeneity seems to be the essence of
all embedded systems: comprising of a subtle com-
bination of hardware and software sub-systems for
specifying data and control processing requirements.
Further,the embedded software developedis often ex-
pected to execute a feedback mechanism and/or ex-
change updated data and respond to various external
sensors/stimuli (e.g. mechanical, electronic modules)
(Vanderperren et al., 2012). This implies that, embed-
ded software developers adopting a MDD approach
are required to employ more than one modeling lan-
guage to address the multi-faceted design aspects of
an embedded software system. Thus, an embedded
software system may comprise of several software
sub-systems, developed using heterogenousmodeling
domains (Fig. 1).
Let us consider a simple heterogenous embedded
system comprising of two main sub-systems. One
sub-system is used for modeling the application level
aspects and the other sub-system is used for dealing
with the low-level/hardware-related continuous func-
tions. At the application level, the system architec-
ture could be modeled, for instance, using UML class
diagrams. Similarly, the discrete/event-based func-
tionality, at the application level, may be modeled us-
ing state machines. The application level sub-system
may be considered to be less time critical. Whereas,
the sub-system used to model the low-level/hardware-
419
Iyenghar P., Samson B., Spieker M., Noyer A., Wuebbelmann J., Westerkamp C. and Pulvermueller E..
A Mechanism for Data Interchange Between Embedded Software Sub-systems Developed using Heterogenous Modeling Domains.
DOI: 10.5220/0005335604190424
In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 419-424
ISBN: 978-989-758-083-3
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)





 !!"#$$
%
&'


Figure 1: Embedded Software Development Using Hetero-
geneous Modelling Domains.
related aspects, handles the continuous signals and
contains more time critical tasks. This could be mod-
eled, for instance, using Matlab/Simulink (Matlab
and Simulink, 2014) or LabVIEW (LabVIEW System
Design Software, 2014)) (Fig. 1).
Data exchange among these sub-systems is a crit-
ical and challenging task. To bring the requirements
of both the levels together and enable bi-directional
data exchange, a coupling concept must be developed.
A key aspect in bi-directional data exchange, is the
conversion (of data) from events to signals and vice
versa. In the existing literature and tool support, some
coupling concepts are discussed and supported (Nico-
lescu et al., 2012), (Hooman et al., ). However, such
coupling methods are not applicable to all real-time
operating systems and/or limited to a few simulation
studies.
This paper addresses the aforementioned gaps and
demonstrates a novel methodology to convert events
to signals and vice versa. The main contribution of
this paper is the proposal of a simple and a generic
mechanism for bi-directional data exchange among
sub-systems modeled using heterogenous modeling
domains, e.g. UML and Matlab/Simulink.
The remaining of this paper is organized as
follows. Related work pertaining to data ex-
change/coupling between UML and Matlab/Simulink
domains is discussed in section 2. A seesaw model
example, developed using heterogenous modeling do-
mains is introduced in section 3. The proposed ap-
proach and initial results are discussed in section 4.
Section 5 presents a conclusion.
2 BACKGROUND AND RELATED
WORK
Related work pertaining to alternatives for data ex-
change and coupling between Matlab/Simulink and
UML domains, used for modeling heterogenous em-
bedded software systems, is discussed in this section.
2.1 Coupling UML and
Matlab/Simulink
Coupling the execution of UML and Matlab/Simulink
models can be achieved by (a) co-simulation, (b)
model-level coupling and (c) source-code level cou-
pling.
In the case of co-simulation, both the UML and
Simulink tools are linked by a coupling tool (Van-
derperren et al., 2012). However, in this approach,
special attention to a consistent notion of time is cru-
cial to guarantee proper synchronization between the
UML tool and Matlab/Simulink (Vanderperren and
Dehaene, ) (Nicolescu et al., 2012) (Hooman et al.,
).
Model-level coupling of heterogenous embedded
systems discussed in (Reichmann et al., 2004) uses
model-to-model transformation and bi-directional
transformation rules. On the other hand, such model-
to-model transformation of large system architec-
ture during the development process is suscepti-
ble to errors. Further, scalability of such model-
based coupling of software components and time-
discrete/continuous parts for a real-life industrial case
study is missing. Scalability issues of the approach
proposed in (Reichmann et al., 2003) can be attributed
to the lack of a commercial version of the tool Gener-
alStore outlined in (Reichmann et al., 2004).
The third alternative for coupling the execution
of UML and Matlab/Simulink models is integra-
tion based on the underlying source code or exe-
cutable language. This approach can be considered
more advantageous, for small and medium projects.
This methodology paves the way for integration of
time-discrete and time-continuous sub-systems at the
source code level, without having to consider cou-
pling the entire sub-system at the source-code or
model-level.
A combination of the model-level and source-
code level coupling between the Matlab/Simulink and
UML domains is available in a MDD tool Rhap-
sody (IBM Rational Rhapsody Developer, Ver 8.4,
2014). Integration of Matlab/Simulink with Rhap-
sody can be performed by using a feature called
”SimulinkBlocks” supported by Rhapsody. In this
method, blocks (e.g. objects created in a given Rhap-
sody project) are stereotyped with ”SimulinkBlock”
stereotype. Then the required Matlab/Simulink files
are imported to this object. Once the import is suc-
cessful the values to be exchanged between Mat-
lab/Simulink and Rhapsody are assigned as flowports
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
420
(a feature in Rhapsody) in these objects. The cou-
pling mechanism using the Systems Modeling Lan-
guage (SysML) follows a similar path (in MDD tool
(IBM Rational Rhapsody Developer, Ver 8.4, 2014)).
Both these methods depend on the usage of flowports
as interaction points and interfaces between blocks
(Systems Modeling Language (SysML), 2014); a fea-
ture which cannot be supported by all real-time oper-
ating systems.
Thus, in the existing literature/tool support, a
generic methodology for data interchange between
events and signals (time discrete and time continuous
domains) is not yet available. This paper elaborates
on this aspect and proposes a simple, generic mech-
anism for data exchange between UML and Mat-
lab/Simulink domains.
3 A SEESAW MODEL EXAMPLE
In this paper, a seesaw application (Fig. 2) is used as a
real-life embedded system example for the evaluation
of the proposed approach.
Figure 2: Seesaw model.
3.1 Construction and Design
A seesaw is equipped with two ventilators, one at each
end. One ventilator produces a momentum in clock-
wise direction, the other in anti-clockwise direction,
to accelerate the seesaw. The speed of the ventilators
is controlled by Pulse Width Modulation (PWM). The
corresponding/current angle of the seesaw is mea-
sured with a potentiometer and converted with an
Analog-To-Digital Converter (ADC). The seesaw ap-
plication moves the seesaw to different angles, one
after another.
3.2 Implementation
In this example, the discrete modeling domain (mod-
eled using UML in MDD tool Rhapsody (IBM Ratio-
nal Rhapsody Developer, Ver 8.4, 2014)), is respon-
sible for setting the desired angle of the seesaw. This
sub-system output (angle of the seesaw) is transferred
to a global variable and controlled by a closed loop
control. The closed loop control sub-system is im-
plemented in the Matlab/Simulink modeling domain
(Fig. 3). The PID control unit is generated with the
MATLAB/Simulink Embedded Coder. It handles the
parameters received from the discrete modeling do-
main. Fig. 4 shows the implementation of the PID
controller in MATLAB/Simulink. It also describes
the mapping between ADC values and degrees for the
ventilator. The output values are converted to PWM
values.
Figure 3: System control loop.
Figure 4: PID loop controller.
The embedded software thus developed, runs on a
Keil LPC1700 Board (Embedded development tools
, 2014), which contains an ARM Cortex M3 CPU
from NXP. The compiler is the Keil/ARM MDK us-
ing µVision. The RTOS used is OO-RTX single
threaded UML based RTOS from (Willert Software
Tools, 2014). Table 1 shows a simplified set of sig-
nals, events and examples of boundary conditions re-
quiring event to signal conversion and vice versa. Fur-
ther implementation aspects such as, double buffer-
ing for read/write data between the two domains,
cyclic functions invoking control loop and measure-
ment functions are not elaborated here.
4 PROPOSED APPROACH
In this section, a generic notation for describing a
heterogenous embedded system is introduced. A set
of procedures based on the generic notations are de-
scribed, proposing a simple but effective methodol-
ogy for data exchangebetween UML (discrete events)
and Matlab/Simulink (continuous signals) domains.
Examples of event to signal conversion and vice versa
AMechanismforDataInterchangeBetweenEmbeddedSoftwareSub-systemsDevelopedusingHeterogenousModeling
Domains
421
Table 1: Events, Signals and boundary conditions in seesaw example.
Variable Type Description of the example
ADCValue Signal Seesaw angle, Output from UML domain
PWMValue Signal Ventilator speed, Output from M/S domain
evRelease event Used in event to signal conversion
evReset event Used in signal to event conversion
$
* Boundary condition for event to signal conversion: on button press, generate (event) evRelease and set (signal) ADCValue.
$ Boundary condition for signal to event conversion: If PWMValue (signal) is greater than threshold, generate (event) evReset, to reset
angle of seesaw.
are explained with the help of the seesaw model.
4.1 Generic Representations
Let us consider a heterogenous embedded soft-
ware system HE
ss
= {SS
1
,SS
2
,..., SS
n
}, where SS
1
,
SS
2
, ..., SS
n
are sub-systems modeled using various
modeling domains such as UML, Matlab/Simulink
and LabVIEW. In the seesaw example, HE
ss
=
{SS
UML
1
,SS
M/S
2
}, where SS
UML
1
is the sub-system
modeled using UML (discrete domain, Rhapsody
tool) and SS
M/S
2
is the sub-system modeled using
Matlab/Simulink (continuous domain, e.g: PID con-
troller). In the context of this paper, let us con-
sider only the events and signals in the UML and
the Matlab/Simulink domains respectively. The
events and signals can be represented as SS
UML
n
=
{e
1
n
,e
2
n
,e
3
n
,..., e
n
n
,} and SS
M/S
n
= {s
1
n
,s
2
n
,s
3
n
,..., s
n
n
} .
Here, e
1
n
, e
2
n
, e
3
n
... e
n
n
are representation of the events
in the sub-system modeled using UML (SS
UML
n
). Sim-
ilarly, {s
1
n
, s
2
n
, s
3
n
, ..., s
n
n
} is a representation of
the signals in the sub-system modeled using Mat-
lab/Simulink (SS
M/S
n
).
In UML, the tag value of an event can be used
to specify additional information to the event. In our
approach, consider that each event is associated with
two tag values, one each for event to signal conver-
sion and vice versa. Then, the tag values correspond-
ing to e
1
n
, e
2
n
, ... e
n
n
for event to signal conversion can
be represented as Tag
e
1
n
EvtoSi, Tag e
2
n
EvtoSi, ...,
Tag
e
n
n
EvtoSi. Similarly, the tag values correspond-
ing to e
1
n
, e
2
n
, ... e
n
n
for signal to event conversion can
be represented as Tag
e
1
n
SitoEv, Tag e
2
n
SitoEv, ...,
Tag e
n
n
SitoEv.
4.2 Event to Signal Conversion
For event to signal conversion, let us consider a sim-
ple scenario: on an external button press (available in
Keil LPC1700 board (Embedded development tools
, 2014)), the seesaw is expected to go to a new/next
position. The idea here is that on a button press, an
event (e.g: evRelease) is generated, which in turn is
expected to be converted/mappedto a signal. The sig-
nal value is the angle of the seesaw (e.g: signal name
=ADCValue), managed by the PID controller (Fig 3,
4) in the Matlab/Simulink domain. Thus a mechanism
for communication between the discrete and continu-
ous domains is necessary for data exchange. Mapping
the aforementioned examples to generic notations,
the examples can be represented as SS
UML
1
= {e
1
1
=
evRelease} and SS
M/S
1
= { s
1
1
= ADCValue} (Table 1).
A procedure for event to signal conversion is
shown in algorithm 1. The inputs for this algo-
rithm are the events e
1
n
,e
2
n
,..., e
n
n
(UML domain) and
their respective event to signal tag, Tag
e
1
n
EvtoSi,
Tag e
2
n
EvtoSi, ..., Tag e
n
n
EvtoSi. The output of this
algorithm is setter methods for signals w.r.t the corre-
sponding events.
Algorithm 1: Event to Signal Conversion.
Input: SS
UML
n
= {e
1
n
,e
2
n
,..., e
n
n
} and Tag e
1
n
EvtoSi,
Tag e
2
n
EvtoSi, ..., Tag e
n
n
EvtoSi ;events and
tags
Output: Setter methods for event to signal conver-
sion
1: if SS
UML
n
6= 0 then
2: create W = setterForSignals ;object/wrapper
class
3: create St
W
in W ; new statechart with default
transition
4: create new events with name corresponding to
tag value, as ev
Set|Tag e
1
n
EvtoSi|;
5: create setter methods in newly created events,
ev
Set|Tag e
1
n
EvtoSi| = |Tag e
1
n
EvtoSi|
6: else
7: exit
8: end if
The setter methods are created (as action values)
corresponding to the events and tags in a newly cre-
ated state chart (in a wrapper class/object), by the
algorithm 1. The wrapper class and the statechart
created inside the wrapper class are represented as
W = setterForSignals and St
W
respectively. Please
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
422
note that, in this paper it is assumed that in the stat-
echart, an action is executed upon receiving a trigger
(i.e., an event).
Let us consider our example event evRelease (e
1
1
)
with corresponding tag value as Tag e
1
1
EvtoSi =
{ADCValue = 20}. Given this input, the algo-
rithm 1 creates an object/wrapper class (step 2) and
a new state chart with default state and transition
(step 3). The wrapper class and the state chart cre-
ated inside the wrapper class are represented as W =
setterForSignals and St
W
respectively.
In the next step (step 4), new events are added to
the statechart created in the previous step. The events
are created based on the tag values of the events given
as input. For example, for the event e
1
1
= evRelease}
with tag Tag
e
1
1
EvtoSi = {ADCValue = 20}, the
newly created event is evSetADCValue.
In step 5, the algorithm creates setter method
in the action field of the newly created event
ev
SetADCValue. The action field value for
ev SetADCValue is ADCValue = 20. Thus algorithm
1 creates setter methods for the events in UML do-
main, for setting the corresponding signal values in
Matlab/Simulink domain. It is up to the end-user to
make use of these setter methods in the UML domain
to invoke exchange of data values in the Matlab do-
main. For example, the event ev
SetPWMValue can
be invoked in the action field of evRelease to set the
signal value on button press on the target board.
4.3 Signal to Event Conversion
In the proposed approach, the required boundary con-
dition for signal to event conversion is specified in the
tag value (Tag
e
n
n
SitoEv) of an event (e
n
n
) in the UML
domain. A procedure for signal to event conversion
is shown in algorithm 2. The inputs for this algo-
rithm are the events e
1
n
,e
2
n
,..., e
n
n
(UML domain) and
their respective signal to event tag, Tag
e
1
n
SitoEv,
Tag e
2
n
SitoEv, ..., Tag e
n
n
SitoEv. The output of this
algorithm is the respective call to fire events, which
are inserted inside of the step functions. This achieves
signal to event conversion, in a simple but effective
way.
As seen in algorithm 2, in step 1, the
tag values of the signal to event tag in each
event in the given UML sub-system is parsed.
In our example, this can be represented as
e
2
1
= evReset} (event) with Tag e
2
1
SitoEv =
{FIRE IF RISING systemInput 20} (tag value). The
meaning of this tag is the following: fire an event
(evReset) when the threshold value of the variable
systemInput in UML domain (represents the value of
the signal PWMValue) increases above the value 20.
Algorithm 2: Signal to Event Conversion.
Input: SS
UML
n
= {e
1
n
,e
2
n
,..., e
n
n
} and Tag e
1
n
SitoEv,
Tag e
2
n
SitoEv, ..., Tag e
n
n
SitoEv ;events and
tags
Output: Function calls to fire respective events
(e.g. FIRE
IF RISING(destination, event, signal,
threshold))
1: if SS
UML
n
6= 0 then
2: parse the value of signal to event tag,
Tag
e
n
n
SitoEv
3: create function calls based on tokens parsed
4: Insert function call (inside step function) in
UML domain, to fire respective events;
5: else
6: exit
7: end if
Note that, as a first step in the prototype im-
plementation, only two types of macros such as
FIRE IF RISING(destination, event, signal, thresh-
old) and FIRE
IF FALLING(destination, event, sig-
nal, threshold) are implemented. These are used to
support invocation of firing of events when the thresh-
old of signals rise or fall below a specified threshold.
In step 2, function calls based on the tokens parsed
in the previous step is created. For our example, the
function call created is FIRE IF RISING(destination
(self), evReset, PWMValue, 20). In the final step, the
function call thus created as a result of parsing the tag
value is inserted in the the appropriate step function
to facilitate signal to event conversion.
5 CONCLUSION AND FUTURE
WORK
This paper describes a simple, but effective method-
ology for event to signal conversion and vice versa,
allowing the coupling between heterogenous embed-
ded software sub-systems. A generic notation for de-
scribing a heterogenous embedded software system is
introduced. A set of procedures based on the generic
notation are described, proposing a simple but effec-
tive mechanism for data exchange between UML (dis-
crete events) and Matlab/Simulink (continuous sig-
nals) domains. A prototype of the proposed generic
methodology and algorithms is implemented in the
programming language Java with the aid of APIs (Ra-
tional Rhapsody API Reference Manual, 2014) in the
MDD tool used (IBM Rational Rhapsody Developer,
Ver 8.4, 2014). The prototype is evaluated in a seesaw
model real-world embedded software system applica-
tion scenario, modeled using heterogenous modeling
AMechanismforDataInterchangeBetweenEmbeddedSoftwareSub-systemsDevelopedusingHeterogenousModeling
Domains
423
domains such as UML and Matlab/Simulink.
Future directions include: supporting more than
one controller for Matlab/Simulink domain and ex-
ploring possibilities to specify boundary conditions in
UML (other than tags).
ACKNOWLEDGEMENT
This project is supported by a grant from the fed-
eral ministry of Economics and Technology (BMWi),
Germany. This work is carried out in close coopera-
tion with the industrial partner Willert Software Tools
GmbH.
REFERENCES
Embedded development tools (2014). http://
www.keil.com/.
Hooman, J., Mulyar, N., and Posta, L. Coupling simulink
and UML models. In Formal Methods for Automa-
tion and Safety in Railway and Automotive Systems,
FORMS/FORMATS 2004, pages 304 – 311.
IBM Rational Rhapsody Developer, Ver 8.4 (2014).
http://www.ibm.com.
LabVIEW System Design Software (2014).
http://www.ni.com/labview/.
Matlab and Simulink (2014). http://www.mathworks.com/.
Nicolescu, G., O
´
Connor, I., and Piguet, C. E. (2012). De-
sign Technology for Heterogeneous Embedded Sys-
tems. Springer.
Object Management Group (2014). http://www.omg.org.
Rational Rhapsody API Reference Manual (2014).
http://www.ibm.com/.
Reichmann, C., Kuehl, M., Graf, P., and Muller-Glaser, K.
(2004). GeneralStore - a CASE-tool integration plat-
form enabling model level coupling of heterogeneous
designs for embedded electronic systems. In 11th
IEEE International Conference and Workshop on the
Engineering of Computer-Based Systems, 2004. Pro-
ceedings.
Reichmann, C., Kuehl, M., and Maeller-Glaser, K. (2003).
An overall system design approach doing object-
oriented modeling to code-generation for embedded
electronic systems. In Pezzae, M., editor, Fundamen-
tal Approaches to Software Engineering, volume 2621
of Lecture Notes in Computer Science, pages 52–66.
Springer Berlin / Heidelberg.
Systems Modeling Language (SysML) (2014).
http://www.sysml.org.
Vanderperren, Y. and Dehaene, W. From UML/SysML to
Matlab/Simulink: Current state and future perspec-
tives. In Design, Automation and Test in Europe,
DATE 2006, proceedings.
Vanderperren, Y., Mueller, W., He, D., Mischkalla, F., and
Dehaene, W. (2012). Extending UML for electronic
systems design: A code generation perspective. In
Nicolescu, G., O’Connor, I., and Piguet, C., editors,
Design Technology for Heterogeneous Embedded Sys-
tems. Springer.
Willert Software Tools (2014). http://www.willert.de/.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
424