Towards User-centric DSLs to Manage IoT Systems

Moussa Amrani, Fabian Gilson, Abdelmounaim Debieche and Vincent Englebert

University of Namur, PReCISE Research Center, Namur, Belgium

Keywords:

Model-driven Engineering, Internet of Things, Domain-speciﬁc Language, Rule-based Semantics.

Abstract:

Hidden behind the Internet of Things (IoT), many actors are activelly ﬁlling the market with devices and

services. From this profusion of actors, a large amount of technologies and APIs, sometimes proprietary, are

available, making difﬁcult the interoperability and conﬁguration of systems for IoT technicians. In order to

deﬁne and manipulate devices deployed in domestic environments, we propose IoTDSL, a Domain-Speciﬁc

Language meant to specify, assemble and describe the behaviour of interconnected devices. Relying on a

high-level rule-based language, users in charge of the deployment of IoT infrastructures are able to describe

and combine in a declarative manner structural conﬁgurations as well as event-based semantics for devices.

This way, language users are freed from technical aspects, playing with high-level representations of devices,

while the complexity of the concrete implementation is handled in a dedicated layer where high-level rules are

mapped to vendor’s API.

1 INTRODUCTION

Facing the explosion of available connected devices,

many vendors are jumping into the market, propos-

ing a large spectrum of products ranging from con-

nected devices to associated end-user services (Lee

and Lee, 2015). This results in a wide heterogeneity

in software and hardware implementations, as well as

an ever growing list of concerns and opportunities in

terms of interoperability, data management, privacy

and scalability (Chaqfeh and Mohamed, 2012).

As the Internet of Thigs (IoT) inﬁltrates many as-

pects of people’s life through their cars, heating sys-

tems, phones and so forth, a critical challenge is to

provide end-users the possibility to beneﬁt from the

plethora of connected devices and conﬁgure them for

their particular needs. From the recent research con-

ducted at the University of Namur, we identiﬁed how

difﬁcult it is to make things cooperate, and describe

things conﬁgurations, because of the major inﬂuence

of distinct technologies. In order to hide vendor-

speciﬁc implementation details, we target a dedicated

technology-agnostic environment to adapt and com-

bine IoT solutions.

Model-Driven Engineering (MDE) has been

recognised during the last decade as a software en-

gineering technique dedicated to the design, man-

agement and evolution of computer languages en-

abling automatic generation of production code, di-

verse types of analysis and early veriﬁcations. Fol-

lowing this trend, we introduce IoTDSL, a prototype

Domain-Speciﬁc Language (DSL) meant to capture

IoT devices capabilities and their deployment conﬁg-

urations, while providing a declarative way to end-

users, letting them achieve their own scenarios.

Outline. We start in Section 2 by presenting archety-

pal scenarios of IoT devices usage to motivate why

and how it becomes important to bring end-users back

in control of the devices in their own domestic envi-

ronment. We then extract the main crucial IoT chal-

lenges speciﬁc to the use of DSLs and MDE tech-

niques to realise this vision. In Section 3, we intro-

duce IoTDSL, our prototype DSL to specify and in-

terconnect devices in an intuitive and general way,

and illustrate its use through a typical example. We

overview in Section 4 the use of DSLs for IoT, com-

paring existing approaches with ours and assessing

them against the challenges we identiﬁed; then con-

clude in Section 5 and present the main lines of work

ahead to transform our prototype in a fully functional

DSL.

2 CONTEXT & CHALLENGES

Domestic IoT devices could be used in many differ-

ent situations for many purposes. Consider these two

examplars for smart homes:

1. Alice lives in a house equipped with a number

of devices: door and window lock detectors, de-

vices controlling the lights, temperature and hu-

Amrani M., Gilson F., Debieche A. and Englebert V.

Towards User-centric DSLs to Manage IoT Systems.

DOI: 10.5220/0006285405690576

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 569-576

ISBN: 978-989-758-210-3

 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reser ved

569

midity, security devices for detecting smoke and

carbon dioxide, as well as a plethora of entertain-

ment devices for TV, music, and sport. She is

an active workwoman, so she often reconﬁgures

her home devices to accommodate her changing

lifestyle: for example during winter, she’s staying

inside, mainly teleworking, and needs her bath-

room and living room to stay warm enough, but

not too much, while during summer, she spends

more time outside expecting her home to stay safe

and being notiﬁed of any intrusion.

2. Bob is 68 years old and leaves alone at home,

since his children have their own family lives on

the other side of the city. As many elderly, Bob

suffers from ageing diseases, but prefers to stay in

a familiar environment rather than leaving in an

dedicated institution. His house is equipped with

devices monitoring potential falls that can have

tragic consequences for him. It is also equipped

with nowadays entertainment devices such as a

smart TV and phone. He wants to feel safe at

home: if he falls and cannot stand up in the bath-

room, he would like to warn his family and notify

daycare nurses to rescue him quickly.

These typical conﬁgurations share two common-

alities. First, both houses integrate common con-

nected devices fulﬁlling the same functionalities, e.g.,

monitoring the temperature, or sending messages af-

ter the detection of an abnormal situation, but are

likely different in terms of vendors, communication

protocols and detailed properties. For example, a tem-

perature sensor could be paired with a heating sys-

tem to maintain a given temperature inside the house,

while in other conﬁgurations, both devices are clearly

separated. Second, the way these devices interact

with each others highly depends on the end user, and

more likely for the same user, on the actual context.

On the one hand, in Alice’s situation, different actions

on the same devices are required throughout the year.

On the other hand, Bob’s situation can be replicated

to another house, but with different sets of concerns

related to ageing diseases.

We argue that a good way of capturing those po-

tential variations of devices and situations is to pro-

vide to end-users, i.e. home inhabitants like Alice, or

technicians equipping houses like Bob’s one, a DSL

that provides the following features:

Device Description. A precise inventory of the de-

vices used in a speciﬁc deployment as well as the

high-level capabilities of these devices, described

in terms that are immediately understandable by

end-users, as opposed to conveying technical de-

tails about how those devices precisely operate;

Network Description. A way to capture where each

device is located and how it is possible to commu-

nicate with it, in order to receive or send data to

it;

Dynamics. A way to describe the interactions wished

by end-users, i.e. how to leverage the function-

alities of the devices to effectively realise one or

several scenarios that are convenient for the end-

users.

Those features are obviously not sufﬁcient to obtain a

fully-ﬂedged solution that becomes adaptable to any

situation, but they still represent necessary steps to

provide end-users the capacity to manipulate a collec-

tion of devices without relying on speciﬁc technolo-

gies. Though, the deﬁnition of such DSLs raises some

questions directly related to the hypotheses assumed

by those features, that we explore and relate to each

other in the rest of this section.

Capability Discovery. Providing the ability to drive

interconnected devices assumes the capacity of auto-

matically discovering devices’ capabilities in a stan-

dardised and uniform way (Chaqfeh and Mohamed,

2012). Similar processes exist for other technologies,

like USB devices plugged into computers that auto-

matically expose their natures and capabilities (e.g., a

pointing or video device). Classifying such capabili-

ties could be useful to build an ontology of normalised

functions that could result in powerful APIs to manip-

ulate devices.

Complex Event Processing (CEP). Letting end-

users deal with devices through their low-level

capability interfaces could lead to confusion and stiff

complexity for deﬁning usage scenarios (Ma et al.,

2013). Rather, providing a way of reifying low-level

device computations into high-level events could

help end-users leverage the complexity of devices

networks and pave the way to manipulate them freely

and transparently (Cugola and Margara, 2012). Since

CEP consists of deriving meaningful conclusions

from a stream of events occurring within a system

and responding to them as quickly as possible, it

provides a solution to extract meaningful events from

low-level computations. However, for a solution to be

complete and useful, the reverse operation should be

addressed: high-level actions should be adequately

translated into low-level actuations.

Protocol Interoperability. A domotic solution with

heterogeneous devices would often integrate elements

from various providers, thus communicating through

multiple protocols. In order to make them interact ef-

ﬁciently, without forcing end-users to stick with one

vendor that can dictate costs and restrictions, a pow-

erful DSL should provide ways for interoperability

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

570

over multiple communication protocols, without re-

quiring end-users to understand the protocols’ intrica-

cies, versions and technical restrictions (Gubbi et al.,

2013).

Scalability. As the number of application domains

increases, the amount of connected devices is ex-

pected to rise exponentially. When updating exist-

ing IoT conﬁgurations, current solutions may not col-

lapse when adding more elements (Mukhopadhyay,

2014). Furthermore, a DSL must provide a way to

absorb scalability problems, hiding as much as possi-

ble purely technical constraints regarding increases in

size and complexity of operating conﬁgurations.

Data Management. Analogously to scalability is-

sues, the massive increase in connected devices will

produce more and more data to be processed, stored

and, for some of them, post processed (Lee and Lee,

2015). More data means seemingly more storage ca-

pabilities and the required space to handle such ﬂow

of information will be at its highest ever. Further-

more, the multiplication of available (sensors) sources

is creating a whole new world of data processing and

mining possibilities, but also a profusion of diver-

gent concrete data types that sooner or later must be

mapped to equivalent concepts.

Non-Functional Properties. A powerful DSL

should encompass typical non-functional properties

of device networks to ensure long-life and secure

realisation of scenarios. Performance is crucial, and

depends both on the devices capabilities but also

on the quality of the communication network: any

source of latency could have dramatic impacts that

can lead to critical situations. Resource availability,

both in terms of computation and memory capabil-

ity, but also in terms of energy, is another crucial

bottleneck for the adoption of DSLs as a solution for

deﬁning scenarios. The code generated from the DSL

should not overload the devices with repetitive com-

munications or unnecessary computations that would

drain the device’s battery. Security is yet another

concern with respect to two aspects. First, sensitive

data could be exposed through the communication

network, endangering users privacy. Second, some

functionalities could be locked and only accessible to

authorised users (Tan and Wang, 2010).

3 IoTDSL

Building a well-calibrated DSL is known to be difﬁ-

cult and error-prone. It usually requires a broad ex-

pertise on a domain before a consensus emerges on

which concepts are ﬁrst-class citizens and how to ef-

fectively represent them. Fortunately, MDE technolo-

gies operated substantial breakthrough over the past

decade, allowing language designers to deﬁne their

own DSL structures and user interfaces more eas-

ily. Visual syntax is often a needed feature to any

language, allegedly to simplify its understanding and

manipulation. However, in order to rapidly obtain a

functional prototype, we chose to start from a textual

syntax, way easier to manipulate and evolve for lan-

guage designers. At last, we plan to propose a vi-

sual syntax: the transition should be facilitated since

our DSL is developed under GeMoC (Bousse et al.,

2016), a MDE framework that supports both visual

and textual representations as concrete syntaxes and

maintains a full synchronisation between them.

Based on the challenges identiﬁed in section 2,

we now introduce IoTDSL, our DSL devoted to fa-

cilitate the high-level manipulation of IoT systems.

At the heart of IoTDSL are two governing principles.

First, we promote a clean separation of concerns for

all aspects the DSL has to handle, embedding several

sublanguages. We believe this approach to be scal-

able, and to support independent evolutions of each

concern without impacting the other aspects, since

those aspects are composed through well-deﬁned in-

terfaces. Second, our DSL relies on events, a natu-

ral paradigm for specifying various models of inter-

actions that is widely used in embedded and critical

systems, and where a clear separation between the

system and its environment is performed, further em-

powering the separation of concerns.

Despite its early stage of development, IoTDSL

shows its ability to capture the deﬁnition of small-

scale IoT systems appropriately. We ﬁrst extract a

simple scenario from our project at the University of

Namur to demonstrate typical usages of IoT systems

deployed inside a house. We then simultaneously ex-

plain each part of the deﬁnition of IoTDSL through

dedicated examples.

3.1 Running Example

To illustrate our proposal, we consider a smart home

equipped with several devices illustrated in Figure 1.

At the entrance, the door is equipped with a lock de-

tector, checking when the door is opened or closed.

The hallway contains presence detectors, so that the

lights in the hallway as well as in the living room au-

tomatically switch on when Alice gets back home.

Furthermore, the living room also contains a pres-

ence detector because Alice wants the temperature

to be automatically monitored when she’s occupying

the room, being maintained between 20°C and 22°C.

Otherwise, when she is not home, the temperature

Towards User-centric DSLs to Manage IoT Systems

571

Figure 1: Alice’s smart home equipped with various de-

vices, interacting through a centralised gateway.

may not drop below 16°C. For security reasons, Al-

ice’s kitchen contains a smoke detector and a temper-

ature monitor. When she cooks, it happens that she

burns something; but she wants to make sure to de-

tect any departing ﬁre: she considers a critical situa-

tion when the temperature remains above 40°C con-

sistently during ﬁve minutes while there is also smoke

in the kitchen.

3.2 Type Deﬁnition

In this section, we deﬁne IoT devices’ types, i.e.

which capabilities are available to the users in terms

of environment sensing and actuating. In our sce-

nario, type deﬁnitions either come from an advanced

user who is able to reason properly about a partic-

ular device and extract the relevant information, or

from a preexisting devices database, either being an

repository the system is connected to, or a library of

devices-off-the-shelf.

The concepts dedicated to type deﬁnition are

shown in Figure 2 (green background). This part is

similar to the notion of Classiﬁer in MOF-like lan-

guages: a Type is either a PrimitiveType, or a user-

deﬁned DeclaredType. We distinguish between gen-

eral Gateways, which centralise information and pro-

cessing, and Nodes deployed in the environment, hav-

ing capabilities and transfering data to Gateways. A

Capability is basically a MOF-like operation with a list

of Parameters that either captures data from the envi-

ronment, or acts on it. A Node can mix both kinds

of capabilities, allowing us to represent complex be-

haviour in a uniform fashion.

For now, types are deﬁned in speciﬁc ﬁles that can

be imported and combined easily within IoT speciﬁ-

cations. We plan to propose a graphical interface to

facilitate the browsing and integration of library com-

ponents into IoT systems.

1 gateway Central

2 device DoorLock {

3 sensing opened()

4 sensing closed()

5 }

6 device LightBulb {

7 actuating on()

8 actuating off()

9 actuating b link()

10 }

11 device TempSensor {

12 sensing getTemp()

13 }

14 device SmokeDetector

{

15 sensing smo ke()

16 }

17 device Heater {

18 actuating warm(in delay:

Int)

19 actuating stop ()

20 }

21 device Alarm {

22 actuating s ound()

23 }

24 device Timer {

25 actuating set(in delay:

Int)

26 sensing timeout()

27 }

28 device PresenceDetector {

29 sensing detected()

30 actuating isPresent(out p

:Bool)

31 }

Listing 1: Type declarations in IoTDSL: sensing or actuating

capabilities as high-level events.

Listing 1 illustrates how devices are declared in

IoTDSL. Each device is introduced by the keyword de-

vice, has a name and capabilities that correspond to

reporting events (sensing) or operating over the en-

vironment (actuating). A special device, introduced

by the keyword gateway, centralises data from all de-

vices connected to it (cf. Section 3.3). Note that this

is the visible part of IoTDSL: in the background, events

declared for all devices need to be mapped to concrete

low-level APIs events using a dedicated mapping lan-

guage that is not detailed here for space reasons.

3.3 Network Conﬁguration

The conﬁguration-related constructs are speciﬁed in

the purple-part of Figure 2. A concrete device is mate-

rialised by a NodeInstance and is typed by an abstract

Node, e.g. a Device or a Gateway. Instances may

communicate with other IoT devices through prede-

ﬁned CommunicationPaths. Such paths deﬁne, among

others, one or more protocols used to interact. We

actually rely on existing platforms, such as OpenRe-

mote

or SmartThings

to handle the intricate details

of the protocols since such details are, from an end-

user point of view, technical aspects rather than es-

sential matters. By knowing which protocols are used

between each pair of devices, we can automatically

perform data conversion in the proper format required

by the protocols: most of those protocols are already

implemented in General-Purpose Programming Lan-

guages (GPLs), like Java or C.

http://www.openremote.org

https://www.smartthings.com/

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

572

Figure 2: Metamodel of IoTDSL, separated in three concerns: Type Deﬁnition captures devices’ capabilities (top green part),

Network Conﬁguration details how device instances are connected to each others (middle purple part), Business Rules deﬁnes

the functionalities expected from the IoT installation (bottom yellow part).

Concretely, we can easily imagine that network

conﬁgurations are automatically established if de-

vices follow the recommendation of discovery proto-

cols (Al-Fuqaha et al., 2015). By concentrating the

connections on a gateway in charge of centralising

joining and leaving devices, e.g., phones that enter or

leave a house, it becomes possible to gather informa-

tion on new devices and connect them appropriately

to other devices in the network according to their ca-

pabilities, communication protocols, and so on. Al-

though IoTDSL empowers Nodes to be passed as Pa-

rameters, enabling devices’ deﬁnition to be discov-

ered thanks to the Gateway.

Listing 2 shows the connection between the de-

vices presented in Figure 1. A speciﬁc device is con-

sidered as an instance of a deﬁned type such that par-

ticular devices with the same set of capabilities may

be distinguished via identiﬁable references. Commu-

nications are purely declarative and only mention the

protocol type (introduced by the via keyword). Note

that we added an extra instance timer : Timer used

to simulate time periods. This pseudo device is used

to artiﬁcially set a clock time, whose behaviour is di-

rectly linked to the supporting platform of the gate-

ways for time management.

1 configuration MyHome {

2 node gw : Central

3 node livingTemp : TemperaturSensor

4 node kitchenTemp : TemperaturSensor

5 node livingHeater : Heater

6 node frontdoor : DoorLock

7 node corridorLight : Lig ht Bulb

8 node livingLight : LightBulb

9 node timer : Ti mer

10 node alarm : Al arm

11 node corridorDe tector: PresenceDetector

12 node livingDetect or : PresenceDetector

13 node smokeDetector : SmokeDetector

15 from livingTemperature to gw via MQTT

16 from HomeTemperature to gw via DDS

17 from livingHeater to gw via DDS

18 from frontdoor to gw via MQTT

19 from light to gw via MQTT

20 from timer to gw via DDS

21 from alarm to gw via DDS

22 from bodydetector to gw via MQTT

23 from smokeDetector to gw via MQTT

24 }

Listing 2: Network Conﬁguration for Alice’s House.

3.4 Business Rules

This last part of our DSL is the heart of IoT systems

manipulation and is detailed in the bottom yellow part

of Figure 2. It relies on an event-based framework

consisting of a set of Rules that implement various

functionalities an end-user wants to achieve. Rules’

triggers are cyclically evaluated against the surround-

Towards User-centric DSLs to Manage IoT Systems

573

ing environment. Whenever a trigger Expression be-

comes true, it executes the appropriate reaction asso-

ciated to the rule. A trigger is deﬁned as an expres-

sion, whose precise deﬁnition is omitted here since it

simply follows any expression language available in

GPLs for navigating nodes and evaluating boolean or

arithmetic expressions (note our DSL does not con-

tain boolean negation, since detecting the absence of

events is known in CEP as being difﬁcult). A reaction

deﬁnes a sequential or parallel combination of capa-

bilities, enabling to sort actions by, or require data

from some identiﬁable devices. A typical reaction

may be to switch on all lights in a house, or only the

ones of a certain type.

For now, our approach is purely middleware-

oriented: rules are gathered into a gateway. For ef-

ﬁciency and resource consumption reasons, we are

also exploring how to automatically identify parts of

the business logics that can be exported to advanced

nodes with sufﬁcient processing and power resources,

in order to lower network and gateway overuses.

We now explain how the scenario presented in

the running example is translated in business rules in

IoTDSL. We identiﬁed three different situations where

Alice needs to specify what she expects from the de-

vices of her house:

1. When Alice gets home (and thus opens the front

door), she wants the lights in the hallway and the

living room to be automatically switched on.

1 rule SwitchLightsWhenEnter:

2 when ( frontdoor.opened() and after

corridorDetector.detected()) do {

3 corridorLight.on() || livingLight.on()

4 }

2. When Alice is in the living room, the temperature

inside the room should be maintained between

comfortable temperatures; whereas when she is

not, the temperature should not drop below 16°C.

1 rule PresentInLiving:

2 when ( timer.timeout()) do {

3 livingDetector.isPr es en t () || presenceTimer.

set(TIMEDETECT)

4 }

5 rule MonitorLivingTempInStop:

6 when ( livingDe tector.detected() and livingTemp.

getTemp > IN_MAX) do {

7 livingHeater.stop()

8 }

9 rule MonitorLivingT empInStart:

10 when ( livingDe tector.detected() and livingTemp.

getTemp < IN_MIN) do {

11 livingHeater.warm(TIMEHEAT)

12 }

13 rule MonitorLivingTempOutStart:

14 when ( timer.timeout() and before livingTemp.

getTemp < OUT_MIN) do {

15 livingHeater.warm(TIMEHEAT)

16 }

3. There is a critical ﬁre situation when smoke is de-

tected in the kitchen while temperature is upper

40°C for at least ﬁve minutes.

1 rule AlarmWhenSmokeAndHighTemp:

2 when ( kitchenTemp .getTe mp() > 45

3 within 5 min from smokeDetector .smoke()) do

{

4 alarm.sound()

5 }

These rules show some particularities of IoTDSL’s

Rule language. First, it is possible to deﬁne local or

global variables and reuse them as part of parame-

ters or expressions (cf. Rules PresentInLiving or Mon-

itorLivingInStop, among others). Second, it is pos-

sible to compose reactions either in sequence (class

SeqComposition in the metamodel of Figure 2, tex-

tually represented as «;») or in parallel (class Paral-

lelComposition, represented as «||»), like Rule Pre-

sentInLiving demonstrates. Third, IoTDSL’s expression

language integrates a simple mechanism for events

time management: the before and after event mod-

iﬁers check that an event happens in a reasonable

time window before/after the one it is combined to (in

Rules SwitchLightWhenEnter and MonitorLivingTem-

pOutStart, events are combined with and for checking

quasi-simultaneity); while the within...from construct

detects the occurrence of an event within a given dura-

tion after another event (cf. Rule AlarmWhenSmoke-

AndHighTemp). Fourth, because IoTDSL cannot check

the non-occurrence of events, time management is

crucial for ensuring a sound detection of interesting

non-events: for example here, Rule PresentInLiving

is used to periodically check for presence in the liv-

ing room (with the actuation isPresent()); but when

nobody is detected, we still have to maintain the tem-

perature above OUT_MIN = 16°C. By detecting that

timeout() occurred previously, we still are capable of

adjusting the living room temperature adequately.

4 RELATED WORK AND

DISCUSSION

A series of overviews have been recently conducted

on several aspects of IoT. In (Al-Fuqaha et al., 2015;

Xu et al., 2014a), the authors reviewed the applica-

tions, protocols and technologies used in the distinct

IoT layers, while (Singh et al., 2014; Gubbi et al.,

2013) focused on architectural aspects and (Tan and

Wang, 2010; Xu et al., 2014b) reviewed security ones.

Most of these contributions identify a number of chal-

lenges crossing the application domain of a DSL for

IoT, from which we identiﬁed the most relevant ones

to our contribution.

Capturing variations of a domain with explicit

constructs close to the domain concepts resides at the

essence of DSLs. In that regard, many DSLs were pro-

posed for various purposes in the IoT stack. CHAR-

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

574

IOT (Pradhan et al., 2015) addresses Cyber-Physical

Systems by providing a component model that clearly

distinguishes between communication and computa-

tion, while ensuring resilience features in highly re-

conﬁgurable systems. In (Brandtzæg et al., 2012)

is presented a DSL aimed at facilitating the deploy-

ment of applications, based on a component model

of the environment used to locate the architecture

nodes where business logic can be leveraged. ALPH

(Munnelly and Clarke, 2008) is a DSL for ubiqui-

tous healthcare that focuses on three concerns: mo-

bility, by helping users to manage frequent devices

disconnections; context-awareness to adapt applica-

tion behaviour to environmental changes; and infras-

tructure, for managing the heterogeneity of commu-

nication protocols. Midgar (García et al., 2014) of-

fers a visual interface to support end-users in control-

ling interconnected devices and generate the glue ap-

plication making these devices interoperate. In (Sal-

ihbegovic et al., 2015), the authors present a visual

DSL for capturing the features and intercommunica-

tions of devices distributed in various application do-

mains spanning from smart homes to patient moni-

toring. These contributions target different applica-

tion domains at different abstraction levels, but pos-

sess every key features we identiﬁed in Section 2 in

a more or less explicit way. Since our DSL targets

end-users with no prior knowledge in programming,

we contrast with these contributions by having a tex-

tual representation for now, but by offering a more

intuitive, declarative style for expressing the system’s

dynamics through semantics rules.

ThingML (Harrand et al., 2016) is the closest con-

tribution to our DSL: it uses a similar device descrip-

tion with messages and communication ports attached

to devices, but describes the dynamics of devices and

systems through state machines, which appear to be

more obscure for end-users. However, the conceptual

drawbacks are similar in both paradigms: state ma-

chines need to be deterministic on their transitions,

while rules have to avoid multiple concurrent ﬁring to

avoid executing several rules at the same time.

Other approaches, e.g. (Cheng et al., 2016; Bhan-

dari and Bergmann, 2013), relying on the Event Con-

dition Action (ECA) paradigm, share a similar view

for IoT devices orchestration through CEP, though not

having the same expressiveness for devices’deﬁnition.

All previous contributions take advantages of

MDE technologies and tools. More general MDE

framework like GeMoC (Bousse et al., 2016) or

ThingML allow to specialise the description of inter-

connected devices, for example to describe Arduino

systems speciﬁcally in ArduinoML (Mosser et al.,

2014).

5 CONCLUSION AND FUTURE

WORK

In this paper, we presented a prototype DSL named

IoTDSL, designed for capturing the deﬁnition of de-

vices’ capabilities and their concrete deployment in

speciﬁc conﬁgurations. It provides a declarative lan-

guage based on rules where end-users may deﬁne

their own scenarios by manipulating devices through

high-level concepts. We also identiﬁed key challenges

from the literature speciﬁc to DSL engineering in the

area of IoT.

At the heart of IoTDSL is a clear separation of three

main concerns that any DSL for IoT should address.

By raising the abstraction level and offering a concep-

tual view of devices’ capabilities, IoTDSL promotes

reuse through dedicated device libraries, strongly sug-

gesting a standardisation of interfaces like the ones

already existing in other domains (for example, the

many computer devices using USB). Since IoTDSL

is developed with MDE tools, adding a visual syn-

tax is almost straightforward. The communication

between devices is a volatile domain, with new pro-

tocols emerging every year. By only declaring how

things communicate, we push the burden of translat-

ing / extracting data from low-level protocols to high-

level interfaces towards technicians in charge of deﬁn-

ing and understanding such protocols. However, this

task is done only once per protocol, and can reuse the

experience and techniques already available in other

areas. For users, this aspect enforces live reconﬁgura-

tion of networks of things, as we already experience

in our daily life.

Despite promising results we experienced while

using our DSL on small examples with our industrial

partners, we acknowledge that many challenges re-

main. First, reconciling high-level device capabilities

with low-level complex communication frameworks

available for the plethora of devices will require Com-

plex Event Processing, a now mature ﬁeld with pow-

erful techniques. Second, evaluating our declarative

sublanguages, for network conﬁgurations and busi-

ness rules, on large-scale deployments will provide

us insight on how to improve each sublanguage and

identify which patterns need to be integrated into li-

braries to facilitate such deﬁnitions. Finally, non-

functional properties need to be enforced through ap-

propriate code generation both in a centralised and

distributed conﬁgurations.

Towards User-centric DSLs to Manage IoT Systems

575

REFERENCES

Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari,

M., and Ayyash, M. (2015). Internet of things: A

survey on enabling technologies, protocols, and ap-

plications. IEEE Communications Surveys Tutorials,

17(4):2347–2376.

Bhandari, S. R. and Bergmann, N. W. (2013). An internet-

of-things system architecture based on services and

events. In 2013 IEEE Eighth International Conference

on Intelligent Sensors, Sensor Networks and Informa-

tion Processing, pages 339–344.

Bousse, E., Degueule, T., Vojtisek, D., Mayerhofer, T.,

Deantoni, J., and Combemale, B. (2016). Execution

framework of the gemoc studio (tool demo). In Pro-

ceedings of the 2016 ACM SIGPLAN International

Conference on Software Language Engineering, SLE

2016, pages 84–89, New York, NY, USA. ACM.

Brandtzæg, E., Mohagheghi, P., and Mosser, S. (2012). To-

wards a domain-speciﬁc language to deploy applica-

tions in the clouds. In Third International Confer-

ence on Cloud Computing, GRIDs, and Virtualization,

pages 213–218.

Chaqfeh, M. A. and Mohamed, N. (2012). Challenges

in middleware solutions for the internet of things.

In 2012 International Conference on Collaboration

Technologies and Systems (CTS), pages 21–26.

Cheng, B., Zhu, D., Zhao, S., and Chen, J. (2016).

Situation-aware iot service coordination using the

event-driven soa paradigm. IEEE Transactions on

Network and Service Management, 13(2):349–361.

Cugola, G. and Margara, A. (2012). Complex event pro-

cessing with t-rex. Journal of Systems and Software,

85(8):1709–1728.

García, C. G., G-Bustelo, B. C. P., Espada, J. P., and Cueva-

Fernandez, G. (2014). Midgar: Generation of het-

erogeneous objects interconnecting applications. a do-

main speciﬁc language proposal for internet of things

scenarios. Computer Networks, 64:143 – 158.

Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M.

(2013). Internet of things (iot): A vision, architectural

elements, and future directions. Future Generation

Computer Systems, 29(7):1645–1660.

Harrand, N., Fleurey, F., Morin, B., and Husa, K. E. (2016).

Thingml: A language and code generation frame-

work for heterogeneous targets. In Proceedings of the

ACM/IEEE 19th International Conference on Model

Driven Engineering Languages and Systems, MOD-

ELS ’16, pages 125–135, New York, NY, USA. ACM.

Lee, I. and Lee, K. (2015). The internet of things (iot):

Applications, investments, and challenges for enter-

prises. Business Horizons, 58(4):431 – 440.

Ma, M., Wang, P., and Chu, C. H. (2013). Data management

for internet of things: Challenges, approaches and op-

portunities. In 2013 IEEE International Conference

on Green Computing and Communications and IEEE

Internet of Things and IEEE Cyber, Physical and So-

cial Computing, pages 1144–1151.

Mosser, S., Collet, P., and Blay-Fornarino, M. (2014). Ex-

ploiting the internet of things to teach domain-speciﬁc

languages and modeling: The arduinoml project. In

Demuth, B. and Stikkolorum, D. R., editors, Pro-

ceedings of the MODELS Educators Symposium co-

located with the ACM/IEEE 17th International Con-

ference on Model Driven Engineering Languages and

Systems (MODELS 2014), Valencia, Spain, September

29, 2014., volume 1346 of CEUR Workshop Proceed-

ings, pages 45–54. CEUR-WS.org.

Mukhopadhyay, S. C., editor (2014). Internet of Things:

Challenges and Opportunities, volume 9 of Smart

Sensors, Measurement and Instrumentation, pages 1–

17. Springer, Cham.

Munnelly, J. and Clarke, S. (2008). A domain-speciﬁc lan-

guage for ubiquitous healthcare. In 2008 Third In-

ternational Conference on Pervasive Computing and

Applications, volume 2, pages 757–762.

Pradhan, S. M., Dubey, A., Gokhale, A., and Lehofer, M.

(2015). Chariot: A domain speciﬁc language for ex-

tensible cyber-physical systems. In Proceedings of the

Workshop on Domain-Speciﬁc Modeling, DSM 2015,

pages 9–16, New York, NY, USA. ACM.

Salihbegovic, A., Eterovic, T., Kaljic, E., and Ribic, S.

(2015). Design of a domain speciﬁc language and ide

for internet of things applications. In 2015 38th In-

ternational Convention on Information and Commu-

nication Technology, Electronics and Microelectron-

ics (MIPRO), pages 996–1001.

Singh, D., Tripathi, G., and Jara, A. J. (2014). A survey

of internet-of-things: Future vision, architecture, chal-

lenges and services. In 2014 IEEE World Forum on

Internet of Things (WF-IoT), pages 287–292.

Tan, L. and Wang, N. (2010). Future internet: The internet

of things. In ICACTE, volume 5.

Xu, L. D., He, W., and Li, S. (2014a). Internet of things in

industries: A survey. IEEE Transactions on Industrial

Informatics, 10(4):2233–2243.

Xu, T., Wendt, J. B., and Potkonjak, M. (2014b). Secu-

rity of iot systems: Design challenges and opportuni-

ties. In 2014 IEEE/ACM International Conference on

Computer-Aided Design (ICCAD), pages 417–423.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

576