A Mechanism for Data Interchange Between Embedded Software

Sub-systems Developed using Heterogenous Modeling Domains

Padma Iyenghar

, Benjamin Samson

, Michael Spieker

, Arne Noyer

, Juergen Wuebbelmann

Clemens Westerkamp

and Elke Pulvermueller

Software Engineering Research Group, University of Osnabrueck, Osnabrueck, Germany

Institute of Computer Engineering, UAS Osnabrueck, Osnabrueck, Germany

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 ﬁeld 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

 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 ﬁles

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 ﬂowports

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 ﬂowports

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 simpliﬁed 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

,..., SS

}, where SS

, ..., SS

are sub-systems modeled using various

modeling domains such as UML, Matlab/Simulink

and LabVIEW. In the seesaw example, HE

{SS

UML

,SS

M/S

}, where SS

UML

is the sub-system

modeled using UML (discrete domain, Rhapsody

tool) and SS

M/S

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

,..., e

,} and SS

M/S

= {s

,..., s

} .

Here, e

, e

... e

are representation of the events

in the sub-system modeled using UML (SS

UML

). Sim-

ilarly, {s

, s

, ..., s

} is a representation of

the signals in the sub-system modeled using Mat-

lab/Simulink (SS

M/S

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

, e

, ... e

for event to signal conversion can

be represented as Tag

EvtoSi, Tag e

EvtoSi, ...,

Tag

EvtoSi. Similarly, the tag values correspond-

ing to e

, e

, ... e

for signal to event conversion can

be represented as Tag

SitoEv, Tag e

SitoEv, ...,

Tag e

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

= {e

evRelease} and SS

M/S

= { s

= 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

,..., e

(UML domain) and

their respective event to signal tag, Tag

EvtoSi,

Tag e

EvtoSi, ..., Tag e

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

= {e

,..., e

} and Tag e

EvtoSi,

Tag e

EvtoSi, ..., Tag e

EvtoSi ;events and