Development of Wireless Sensor Networks Applications

with State-based Orchestration

Alexandre Rabello Ordakowski, Marco Aur

elio Carrero and Carmem Satie Hara

Universidade Federal do Paran

a, Curitiba-PR, Brazil

Keywords:

Wireless Sensor Network, Application Development, Orchestration, State Machine.

Abstract:

The growing demand for sensor devices, key elements of cyber-physical systems and the Internet of Things,

requires fast development of new applications. However, the speciﬁcation and implementation of such systems

is a complicated task, especially because of the lack of support for code reuse and for deﬁning the program

execution ﬂow. Service orchestration is a technique that has been widely adopted for developing applications

for the cloud. In this paper we propose a similar technique for developing applications for Wireless Sensor

Networks (WSN). To this end, we propose a development model based on reusable software components for

WSN applications. For the components orchestration, which deﬁnes the application execution ﬂow, we pro-

pose a domain-speciﬁc language, called SLEDS-SD (State Machine-based Language for Sensor Devices). In

its current implementation, SLEDS-SD generates nesC code, which can be installed in TinyOS-based devices.

The evaluation involved the development of three cluster-based WSN models. The efﬁciency of the proposal

was evaluated by determining the amount of code reuse, while its efﬁcacy was evaluated by the generated code

correctness. For that, we compare the generated programs behavior with those reported in previous studies.

1 INTRODUCTION

Cyber-physical systems and the Internet of Things

(IoT) rely on sensor devices to capture information

from the environment and application users. They

are key components that compose the data acquisi-

tion layer of such systems. A common technique,

advocated by edge (Satyanarayanan, 2017) and fog

computing (Dastjerdi and Buyya, 2016), is to process

and store data either on or close to the source. In line

with this trend, in addition to the increase of storage

and processing capacities of current sensor devices,

we can envision a system architecture in which sen-

sors play an important role not only for data acqui-

sition, but also as active components for storing and

processing data.

One approach to deﬁne the interconnection among

the devices is by orchestration, which determines the

application workﬂow (Adel Serhani et al., 2020). The

complete IoT application not only involves the or-

chestration of the services provided by the devices,

but also the implementation of the services and, in

particular, of the sensoring component of IoT devices.

Sensors are fundamental components of IoT. Thus,

there is a need to investigate development models for

wireless sensor networks (WSNs) as well. However,

the development of such systems is a complex task.

It is observed that few studies in the literature pro-

pose an approach that supports the implementation

of WSN applications considering both orchestration

and code reuse. To address this problem, we propose

an orchestration approach to develop the sensor sub-

system of IoT applications. Such a sub-system may

involve both data storage and processing. In order to

reduce the time spent to develop new applications, our

model also promotes code reuse, based on the concept

of software components. We consider three types of

components: application components, which are re-

lated to the application’s tasks; library components,

which provide generic functions; and the coordination

component, responsible for orchestrating the program

execution ﬂow.

The orchestration is designed and implemented as

a state machine, which is a model adopted by several

previous works (Taherkordi et al., 2015; Braga, 2012;

Lekidis et al., 2018; Hussein et al., 2017). However,

in contrast to these works and traditional sensor and

network simulator languages (such as nesC and NS-2

and 3), which target only event-based transitions, our

state machine supports both event-based and logic-

based transitions. Event-based transitions may be ad-

equate to model the high-level behavior of the appli-

cation, but they are not sufﬁcient to model the internal

312

Ordakowski, A., Carrero, M. and Hara, C.

Development of Wireless Sensor Networks Applications with State-based Orchestration.

DOI: 10.5220/0010499703120319

In Proceedings of the 11th International Conference on Cloud Computing and Services Science (CLOSER 2021), pages 312-319

ISBN: 978-989-758-510-4

behavior of a sensor device, which is the focus of our

work. Logic-based transitions support the design and

development of complex data processing tasks, rather

than only data acquisition.

In order to support this orchestration model, and

allow the implementation of programs directly from

the state machine speciﬁcation, we have designed a

language, called SLEDS-SD (State Machine-based

Language for Sensor Devices), which supports the

concepts of states and transitions. We envision that

in the future, the same SLEDS-SD program can be

used to generate code for several languages, in order

to be installed on devices with heterogeneous plat-

forms. In this paper, we report on the translation of

SLEDS-SD programs to nesC (Gay et al., 2003), the

language used to develop programs for the TinyOS

platform. We have chosen this language because it

was developed for resource constrained devices, and

avoids dynamic typing and memory allocation. Thus,

if we are able to generate nesC code from SLEDS-

SD, most likely we will be able to generate code for

other modern languages with more expressive power.

SLEDS-SD extends the work proposed in (Car-

rero et al., 2021), which targets the development of

simulation code in NS-2. Here, by targeting a re-

source constrained language, to be installed in real

sensor devices, both the development model and the

language were modiﬁed.

In order to evaluate our proposal, we considered

the development of three cluster-based WSN mod-

els. Its efﬁciency was evaluated by determining the

amount of code reuse, which measures the reduction

of development effort. The efﬁcacy was evaluated by

determining the generated code correctness. For that,

we compare the generated programs behavior with

those reported in previous studies.

Paper Outline: Section 2 discusses related works. In

Section 3 our development model is presented. The

language SLEDS-SD is described in Section 4, while

Section 5 reports the results of the experimental evalu-

ation. Final considerations are presented in Section 6.

2 RELATED WORK

This section discusses existing works in the literature

with similar goals as our development model. Sen-

Net (Salman and Al-Yasiri, 2016), IoTSuite (Patel

and Cassou, 2015) and WiseLib (Baumgartner et al.,

2010) adopt different design models. In SenNet mod-

els are deﬁned based on the sensor’s functions in the

network topology, such as nodes and clustering. How-

ever, as opposed to SLEDS-SD, it does not adopt a

ﬂexible execution model. IoTSuite adopts a high-

level language that allows syntax customization ac-

cording to the IoT application domain. This approach

provides generality, but requires the work of a spe-

cialist to conﬁgure a new language for each domain.

Wiselib is a framework composed of a set of generic

libraries to generate code for different platforms, such

as TinyOS and ScatterWeb. Although it proposes an

efﬁcient method of code reuse, it does not adopt a

ﬂexible coordination execution ﬂow.

Tokenit (Taherkordi et al., 2015), X-Machine

(Braga, 2012), Hussein’s model for IoT (Hussein

et al., 2017) and RCBM (Carrero et al., 2021) are

models based on state machines. In Tokenit the pro-

grammer develops the activities in C, while the ex-

ecution ﬂow is speciﬁed in XML. Although Tokenit

separates the execution ﬂow from the activities ﬂow,

it requires some effort to describe the XML model

and then to manually interleave the generated code.

Our focus relies on providing services as a compo-

nent, and a language close to the speciﬁcation model

to generate the execution ﬂow. In X-Machine, states

represent hardware components, and are directly as-

sociated with their functionalities. Thus, it targets

applications on the hardware level, while we con-

sider states in the software level. Another state ma-

chine model to represent different system conﬁgura-

tions with event-based transitions, such as hardware

failures, is proposed by (Hussein et al., 2017). How-

ever, their focus is on system adaptability, while ours

is on code reuse of software components.

Our proposal shares with RCBM the same princi-

ples of code reuse and a language based on state ma-

chines. In fact, SLEDS-SD is an adaptation of their

proposed SLEDS language, by taking into considera-

tion a resource constrained language for sensor nodes,

such as nesC. This is because SLEDS was designed

to generate NS-2 simulation code, which is based on

C++ and thus supports dynamic typing. This feature

gives better support for component-based software

development, but usually does not exist in languages

for programming sensors. As a result, SLEDS-SD

modiﬁes all constructs in the language that relies on

dynamic typing. Moreover, SLEDS-SD promotes

a top-down development of application components

because the translation process from SLEDS-SD to

nesC also generates a set of components interfaces

that can later be implemented by the programmer.

We intend in the future implement a translation from

SLEDS-SD to several other IoT platforms. By do-

ing so, the same SLEDS-SD code can be deployed on

heterogeneous devices that compose the system.

Development of Wireless Sensor Networks Applications with State-based Orchestration

313

3 WSN APPLICATION

DEVELOPMENT MODEL

The development model proposed in this paper is

based on orchestration of software components us-

ing a state machine, and development of components

to implement speciﬁc tasks. The three steps of the

model are depicted in Figure 1: (1) speciﬁcation us-

ing a state machine, (2) development of an orchestra-

tion program in SLEDS-SD and development of ap-

plication components, and (3) code generation in a

target sensor language and system deployment.

3.1 Speciﬁcation Step

In the speciﬁcation of systems for WSNs, a widely

used model is their representation as state machines

(Ouadjaout et al., 2014), given the reactive nature of

sensor devices. However, previous state-based works

consider only event-based transitions, such as the re-

ceipt of a message. This type of transition may be

sufﬁcient to model the general state of a device, such

as light on/off. However, our previous experience in

developing WSN applications showed that it is not

sufﬁcient to model the internal behavior of the sen-

sor to implement more complex data processing tasks.

Such tasks are now possible and desirable, given the

processing and storage capacity of modern sensors.

Based on this observation, our state machine also sup-

ports logic-based transitions. More speciﬁcally, we

can specify the execution ﬂow of a data processing

task as a state machine, and thus a sensor may be in a

different state of the task at any given time. It allows,

for example, to specify different reactions of the sen-

sor on the receipt of a message, based on its current

state. States in our model deﬁne logical steps for ac-

complishing a task, which may involve collaboration

among sensors, triggered by message interchanges,

and possibly controlled by a timer.

Thus, there are two types of event-based transi-

tions: triggered by a request, such as the receipt of a

message, and triggered by a timer timeout. We con-

sider that all sensors in a WSN are executing the same

application, although each of them may be in a differ-

ent state at a given time. They communicate via ra-

dio, through multi-hop message passing. Thus, when-

ever a sensor sends a message, all neighbors within

its radio transmission range receives it. However, it is

important to note that considering each sensor device

individually, there is no relation between the state in

which a message is sent and the state in which it re-

ceives it. That is, if a sensor sends a message from

state s, it is not always the case that its neighbors are

in the same state s. In fact, each of them may be in

Figure 1: Development model.

a different state, and react to the message in a dif-

ferent way. As a result, in our model, states have a

name and may be associated with two types of ac-

tions: send a message or initiate a timer. Receiv-

ing a message (or a timer timeout) triggers an event-

based transition that do not necessarily start from the

state that sent the message (or that initiated the timer).

Event-based transitions are labeled with their trigger-

ing event (message type or timer), while logical tran-

sitions may be labeled with a logical expression.

An example is shown in Figure 1(1). The state ma-

chine computes, for each sensor, its set of neighbors.

It starts with state INI, in which the sensor with ID

0 sends a SENSOR ID message in broadcast. All sen-

sors make a logical transition (depicted in red) to state

WaitFirstSensorID. In this state, the receipt of the

ﬁrst SENSOR ID message triggers the sensor to broad-

cast its own SENSOR ID message and make an event-

based transition (depicted in blue) to state Form

Neighbor List. In this state, a new timer tFlood

is initiated, and during this time it keeps receiving

SENSOR ID messages to create its list of neighbors.

Upon tFlood timeout, an event transition is made to

state ACK Neighbor List. In this state, sensors send

a conﬁrmation message to their neighbors and make

a logical transition to state StoreNeighborList. In this

state, sensors receive ACK SENSOR ID messages from

their neighbors and store their IDs during time tExit.

Upon its timeout, the application make a transition to

the EXIT ﬁnal state.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

314

3.2 Programming Step

Based on the state machine speciﬁcation, a cor-

responding program is developed in our language,

called SLEDS-SD. A SLEDS-SD program consists

of a set of states, which in turn, consists of a se-

quence of actions. An example of a state implemen-

tation can be found in Listing 1. It corresponds to

state FormNeighborList in Figure 1(1). Observe that

during (timer) on recvBroadcast is the command in

SLEDS-SD that indicates the initialization of a timer

and the receipt of messages during this period of time.

In the example, during tFlood time, the application re-

ceives messages of type SENSOR ID. Upon each re-

ceipt, the sensor id received in the message is stored

in a list sensorList. Finally, when the timer expires,

a transition is made to AckNeighborList state. It is

worth noticing the similarity between the state ma-

chine speciﬁcation and the constructs of the language,

which will be detailed in Section 4.

STATE F or m N ei g hb o r L i s t ( ) {

d u r i n g ( t F l o o d )

on r e c v B r o a d c a s t ( SENSORID , msdID , p k t S e n s o r I d ) {

s e n s o r L i s t . i n s e r t ( p k t S e n s o r I d . i d ) ; }

n e x t S t a t e A C K N e i g h b o r List ( ) }

Listing 1: Form Neighbor List state in SLEDS-SD.

While programming the states, some functions

provided by existing components or yet-to-be imple-

mented components may be called. Typically, there

are two types of components: library components and

application components. Library components provide

generic functions. Some languages, such as nesC,

already provide some, like the timer component. It

can be used to generate events at regular intervals of

time. Additional library components can be imple-

mented, such as the data aggregation component, to

provide functions, like sum, average, maximum and

minimum, to be computed from the values in a list.

Application components are directly associated to en-

tities in the application domain. As an example, in

a cluster-based WSN model, application components

may include sensor, gateway and cluster. Each com-

ponent provides a set of functions. For example, the

cluster component may have functions for choosing

the cluster-head (CH), where the CH is the sensor

responsible for storing cluster members information

and answering query requests.

In SLEDS-SD, programs that use components

must contain explicit use statements at the beginning

of the program. Library components are ready to be

reused by any application. Application components,

on the other hand, may or may not have been previ-

ously implemented. To support the idea of reusing

existing components, while allowing the deﬁnition

of new ones, and still adhering to a static typed tar-

get sensor programming language, our model uses

the following strategy. If the component or its in-

terface exists, types are checked, in the same way

as traditional compilers. However, if they do not ex-

ist, a header ﬁle with their interfaces is generated to

guide the developer on how to complete the applica-

tion. This strategy, while promoting code reusability,

helps the developer determine which functions should

be implemented for each application component.

3.3 Code Generation and Deployment

In the last step, SLEDS-SD code is compiled and

translated to a target sensor programming language.

In our current implementation, we generate code in

nesC. Thus, the SLEDS-SD compiler generates nesC

code that corresponds to the speciﬁed state machine,

along with a header ﬁle for each application compo-

nent. The set of ﬁles are given as input to the nesC

compiler, which generates the executable code to be

deployed on the sensor devices.

Our model simpliﬁes the development of WSN

applications with a clear separation between the spec-

iﬁcation and implementation, while helping the im-

plementation with a high-level programming lan-

guage that closely resembles the speciﬁcation model.

Moreover, it promotes code reuse, with the creation

of connectable components.

4 THE SLEDS-SD LANGUAGE

This section presents the SLEDS-SD language and its

translation to nesC. Most of its constructs derive from

SLEDS (Carrero et al., 2021), a language proposed to

generate simulation code for NS-2. Thus, in this sec-

tion we focus on the main constructs of the language

and the changes made in order to allow its translation

to nesC.

u s e com pSen sor a s C o mpone n tSen s or ;

u s e compLibMSG as Co mponent Lib Mes sag e ;

prog r am M a xMinC o o rdina t o r ( ) {

c o n s t t C l u s t e r = 2 5 ;

i n t ro und , myID , w inne rID , myCH;

l i s t <i n t> s e n s o r L i s t [ 5 ] ;

s t a t e I n i ( ) {

winnerI D =compS ensor−>g e t S e n s o r I d ( ) ;

n e x t S t a t e FloodMax ( w i n nerID ) ; }

Listing 2: Structure of a SLEDS-SD program.

Development of Wireless Sensor Networks Applications with State-based Orchestration

315

A SLEDS-SD program consists of three parts: (i)

component import declarations; (ii) data declarations;

and (iii) state deﬁnitions, as depicted in Listing 2.

Among the data declarations, it is required that the

structure of messages transmitted among sensors, as

well as their identiﬁers be deﬁned using the syntax

shown in Figure 2. Listing 3 provides examples of

these declarations, along with the declaration of a

variable of type msgSensorId. The message type

declaration is similar to an enumeration type in C and

deﬁnes a set of message type identiﬁers. They help

the implementation of events that receive messages,

allowing different types of messages be handled prop-

erly. message declarations deﬁne new types in the

language, with the structures of the messages. The

language primitives for exchanging messages (send,

broadcast, recv and recvBroadcast) have a parameter

of this type.

Figure 2: Message type and message structure syntax.

mess a ge t y p e {SENSORID , MAXWINNER, MINWINNER};

mess a ge msgSen s o r I d { i n t i d ; } ;

mess a ge msgMaxWinner { i n t ma xWinn erId ; } ;

mess a ge msgMinWinner { i n t min W inne r Id ; } ;

m s g S e n s o r I d p k t S e n s o r I d ;

Listing 3: Message type and message declarations.

All programs must have an Ini state, where the

execution starts, and one or more ﬁnal states. The

language primitives to implement states include the

traditional control ﬂow statements, such as if, for and

while, as well as ones concerning events and state

transitions

• nextState: makes a transition to another state;

• broadcast: sends a message in broadcast;

• send: sends a message to a speciﬁc sensor;

• on recvBroadcast: receives a broadcast message;

• on recv: receives a message addressed to a spe-

ciﬁc sensor;

• during: triggers a timer.

The language also supports composite actions.

They have been identiﬁed as commonly used for de-

veloping applications for WSNs. They deﬁne that a

sensor waits for messages of a given type during a pe-

riod of time:

The complete SLEDS-SD language speciﬁcation can

be found at https://github.com/sleds-sd.

• during (t) on recvBroadcast (message)

{ActionList} nextState state: composite ac-

tion for receiving broadcast messages during time

t, followed by a state transition.

• during (t) on recv (message) {ActionList}

nextState state: composite action to receive mes-

sages addressed to the sensor itself during time t,

followed by a state transition.

A state with a composite action is shown in Listing

1. In this example, we can now see that the parameters

for recvBroadcast are: the message type, a unique

message identiﬁcation, and a message variable, as de-

clared in Listing 3. Statements recv, broadcast,

and send have the same parameters. Moreover, vari-

able sensorList has been declared in Listing 2 as a

list of type int, which has insert among its associ-

ated functions. Deﬁnitions of lists of all atomic types

in the language as well as message types were among

the extensions needed in the SLEDS language in or-

der to enable the translation to nesC.

4.1 Translation to nesC

The translation from SLEDS-SD to nesC generates

one nesC method for each state in the source code.

The nesC method and the corresponding SLEDS-SD

state code are quite similar when they do not involve

events (timer and message receipt). However, the

translation is not so simple when events are present.

In this case, parts of the state code have to be gen-

erated in different parts of the nesC program. This is

because the end of a timer and the receipt of messages

in nesC are considered asynchronous events with re-

spect to the execution ﬂow of the application or the

current state. Thus, nesC requires all messages to be

handled by a single receive event. Moreover, a timer

timeout triggers the execution of an associated fired

event. Thus, the translation from SLEDS-SD to nesC

requires spreading the code of a SLEDS-SD state into

both the corresponding nesC method and the events.

Moreover, in order to perform the actions associated

to these events deﬁned in each SLEDS-SD state, we

introduce the variable currentState in the nesC code

to store the sensor’s processing state.

To exemplify the process, consider the state ma-

chine that speciﬁes part of the clustering algorithm

of the MAX-MIN model (Amis et al., 2000) de-

picted in Figure 3. This model adopts a very dis-

tinctive ﬂow of execution, with multiple ﬂooding

rounds to collect information from the neighbors, and

then, based on this information, creates clusters, se-

lects cluster-heads and gateways. Consider the state

StoreMaxWinner, shown in Listing 4, which contains

a during-on recv composite statement. Its trans-

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

316

INI

[If ID==0

send SENSOR_ID]

FloodMAX

[send MAX_WINNER]

Store_MAX_WINNER

[initTimer(tFloodMAX)]

recv MAX_WINNER

Select_MAX_WINNER

timer tFloodMAX

[ If dHOps < Threshold ]

FloodMIN

[send MIN_WINNER]

Store_MIN_WINNER

[initTimer(tFloodMIN)]

recv MIN_WINNER

Select_MIN_WINNER

timer tFloodMIN

[ If dHOps < Threshold ]

Event state change

Logical state change

State of the coordinator

Figure 3: FloodMax and FloodMin State Machine.

lation to nesC is presented in Listing 5. Observe

that the code is generated in 3 different parts. The

ﬁrst block of code is generated in the correspond-

ing state StoreMaxWinner method. In this method,

the current state is stored in the currentState variable,

by assigning the value STOREMAXWINNER. In addi-

tion, it starts a timer, which corresponds to the during

statement. The second block of code is generated in

the receive event. This event manages all messages

received by the sensor. Thus, this event is mainly

composed of a sequence of if-else if statements

that checks the value of the currentState variable,

and includes in this portion of the program the list of

actions within the SLEDS-SD on recv instruction.

Similarly, the third block of code is generated in the

timer ﬁred event, with a similar structure. That is,

it checks whether variable currentState contains the

value STOREMAXWINNER and the associated action

is to make a state transition, by calling the method

state SelectMaxWinner.

STATE Sto r eMax Winn er ( ) {

d u r i n g ( tFloodMAX )

on r e c v (MAXWINNER, msgID , pktMaxWinner ) {

List M axWin n er . i n s e r t

( pktMaxWinner−>winne r I D ) ; }

n e x t S t a t e S e lectMaxW i n n e r ( ) ; }

Listing 4: StoreMaxWinner state in SLEDS-SD.

Spreading the code in different methods and

events make the implementation in nesC a hard task.

A program in SLEDS-SD, on the other hand, supports

the development of the program as a state machine, al-

lowing the entire logic of each step to be coded within

a single state. As a result, SLEDS-SD programs are

more compact and easier to develop and maintain.

voi d s t a t e S t o r e M a x W i n n e r ( ) {

c u r r e n t S t a t e = STOREMAXWINNER;

c a l l Tim er . s t a r t O n e S h o t ( tFloodMAX ) ; }

e v e n t m e s s a g e t ∗ R e c e i v e . r e c e i v e ( m e s s a g e t ∗

msg , void ∗ p a y l o a d , u i n t 8 t l e n ) {

[ . . . ] / / s u p p r e s s e d cod e

} e l s e i f ( c u r r e n t S t a t e == STOREMAXWINNER) {

msgMaxWinner∗ pktMa xWinner =

( msgMaxWinner ) p a y l o a d ;

c a l l c o m p L i s t . i n s e r t ( List Max Winn er ,

pktMaxWinner−>winne r I D ) ;

} [ . . . ] / / s u p p r e s s e d cod e

r e t u r n msg ; }

e v e n t void T ime r . f i r e d ( ) {

[ . . . ] / / s u p p r e s s e d cod e

} e l s e i f ( c u r r e n t S t a t e == STOREMAXWINNER) {

s t a t e S e l e c t M a x W i n n e r ( ) ;

} [ . . . ] / / s u p p r e s s e d cod e }

Listing 5: NesC code of StoreMinWinner state.

5 EXPERIMENTAL STUDY

We have implemented a translator from SLEDS-SD to

nesC using Flex and Bison for developing the lexical

and syntactical analyzers, respectively. The transla-

tor, as well as the applications code presented in this

section, are available in a repository on GitHub

In order to evaluate our approach, we applied the

development model to implement three cluster-based

WSN models: LCA (Baker and Ephremides, 1981),

LEACH (Heinzelman et al., 2000) and MAX-MIN

(Amis et al., 2000). In these models, some sensors in

the network are elected leaders, called cluster-heads

(CH), and they are responsible for storing the readings

of a group of sensors (cluster-members) that compose

a cluster. Table 1 shows the main characteristics of

each model. LCA and LEACH have been chosen be-

cause they follow a traditional clustering execution

ﬂow. As a result, our experimental analysis is relevant

for determining the impact of our model when devel-

oping a new system with an execution ﬂow similar

to one that has already been implemented following

our approach. On the other hand, MAX-MIN was se-

lected because it involves a very distinctive execution

ﬂow, as illustrated in Figure 3.

We have conducted two experiments: (i) to deter-

mine the impact of code reuse and (ii) to validate the

correctness of our implementation by applying it to

the same evaluation scenario and parameters reported

in (Amis et al., 2000).

Table 1: Main features of compared models.

Model Cluster-Head Election

Cluster Formation

LCA The lowest ID

CH with the highest

radio signal intensity

LEACH

Probabilistic divided

into rounds

CH with the highest

radio signal intensity

MAX-MIN

The lowest ID in the list

of highest IDs

The ﬁrst CH on the

Gateway route

SLEDS-SD repository: https://github.com/sleds-sd

Development of Wireless Sensor Networks Applications with State-based Orchestration

317

Table 2: Number of states, lines and reused code.

Model

#states

SLEDS

#lines

SLEDS

#lines

nesC

Reused

lines

Coordinator

LCA 7 92 153 99.48 %

LEACH 7 98 164 95.97 %

MAX-MIN 14 140 233 24.28 %

Components

LCA 113 78.76 %

LEACH 119 74.78 %

MAX-MIN 242 32.32 %

5.1 Reusability Analysis

Table 2 presents the the amount of code reuse pro-

moted by our development model. Recall that in

our model the ﬂow of execution is implemented in

SLEDS-SD, while the components are implemented

in nesC. Here, we denote the SLEDS-SD program as

the Coordinator. As the LCA and LEACH models

adopt similar execution ﬂows, their coordinators con-

tain more than 95% identical lines of code in SLEDS-

SD. The code differs only to take into consideration

distinct criteria for the CH election. For MAX-MIN,

however, the percentage of identical lines is around

24%, given its distinctive execution ﬂow. Turning to

the implementation of components, the similarity of

nesC lines of code for LCA and LEACH is around

75%, while for MAX-MIN it is 32%. Here the simi-

larity follows from the existence of some functions in

the components that are identical in all models, such

as computing the set of neighbors for each sensor de-

vice (as illustrated in Figure 1(1).

Table 2 also shows, for each model coordinator,

the number of states, number of lines of code in

SLEDS-SD, and number of lines of code in nesC gen-

erated by the translator. LCA and LEACH contain 7

states, and 92 and 98 lines of SLEDS-SD code, re-

spectively. MAX-MIX has 14 states, with 140 lines

of SLEDS-SD code. We can notice that the SLEDS-

SD program is roughly 40% smaller than the one gen-

erated in nesC by our translator. This suggests that

the development effort for SLEDS-SD is also smaller

than for nesC.

These results show that our approach can poten-

tially reduce the time spent to develop new WSN ap-

plications, both by reusing a coordinator with a sim-

ilar execution ﬂow when it exists, and by reducing

the development effort with a high-level language that

closely resembles the speciﬁcation model.

5.2 Generated Code Correctness

The purpose of this experiment is to determine the

correctness of the code generated by our translator

100

120

140

100 200 300 400 500 600

Average Number of Cluster-Heads

Number of Sensors in the System

Max-Min (Amis et al., 2000)

Max-Min generated fom SLEDS-SD

LCA (Amis et al., 2000)

LCA generated from SLEDS-SD

LEACH 10% limit

LEACH generated from SLEDS-SD

Figure 4: Impact of network density on number of CHs.

from SLEDS-SD to nesC. To do so, we compare the

behavior of the generated code with those reported by

(Amis et al., 2000). The simulation parameters are

also the same as the ones adopted by (Amis et al.,

2000). It considers a 200x200 square meters moni-

tored region, and network densities of 100, 200, 400

and 600 sensor devices. The radio range of every sen-

sor on the ﬁeld was set to 20 meters. The results pre-

sented in this section correspond to the average of 35

simulations executed on TOSSIM, the TinyOS simu-

lator, with a conﬁdence interval of 95%.

Figure 4 shows the number of CHs for each net-

work density, measured both by the code generated

from SLEDS-SD and reported by (Amis et al., 2000).

The graph shows that the values are quite similar and

that they present a consistent growth ratio with the in-

crease of the network density. The small differences

are due to the network topology, that may not be iden-

tical in both works. In our experiments, for each of the

35 executions and each network density, we randomly

generated the position of the sensors on the ﬁeld. For

LCA and MAX-MIN, the maximum number of wire-

less hops between a node and its cluster-head was set

to 2. For LEACH, the number of CHs is deﬁned as

a percentage of the number of devices, which was set

as 10%. In the graph the exact 10% of of sensors is

presented in purple, while the number generated by

SLEDS-SD is in blue. It closely follows the expected

value, with 38.4 sensors elected as CHs for a net-

work density of 400 (9.6%) and 61.3 sensors elected

as CHs for a network density of 600 (10.21%). These

results show that our strategy for translating SLEDS-

SD code to nesC is correct and does not impact the

quality of the generated code.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

318

6 CONCLUSION

In this paper we proposed a development model for

WSNs based on state machines. The goal was to sup-

port the implementation of new applications based on

two principles: (i) speciﬁcation of the ﬂow of exe-

cution as a state machine, and (ii) implementation of

components that provide reusable services. We intro-

duced a language, called SLEDS-SD, and developed

a translator from SLEDS-SD to nesC in order to gen-

erate code to be installed on devices of real WSNs.

We presented an experimental study that shows that

SLEDS-SD programs are about 40% smaller than the

generated nesC code, which suggests that our ap-

proach reduces the development effort. Moreover,

the evaluation of code reuse showed that applications

with a similar execution ﬂow have more than 95% of

identical lines of SLEDS-SD code. The rate of code

reuse of components implemented in nesC ranged

from 32% to 78% following our approach.

As future work, we intend to extend our develop-

ment model to generate code for both network simu-

lators, such as NS-3, as well as other WSN and IoT

platforms, such as Contiki (Dunkels et al., 2004) and

RIOT (Baccelli et al., 2013). With such extensions it

will be possible to use the same high-level speciﬁca-

tion to ﬁrst evaluate a clustering model using simula-

tors and then deploy the application in different real

platforms with much less effort. We also intend to

extend the experimental study by analyzing the gen-

erated code quality, both in terms of legibility as well

as of resources utilization by the sensor devices. An-

other lines of investigation include support for search-

ing reusable components, and support for two-level

orchestration: on device-application level and on ap-

plication internal behavior level.

ACKNOWLEDGEMENTS

This work was partially funded by CNPq and CAPES-

PrInt-UFPR.

REFERENCES

Adel Serhani, M., El-Kassabi, H. T., Shuaib, K., Navaz,

A. N., Benatallah, B., and Beheshti, A. (2020). Self-

adapting cloud services orchestration for fulﬁlling in-

tensive sensory data-driven iot workﬂows. Future

Generation Computer Systems, 108:583 – 597.

Amis, A. D., Prakash, R., Vuong, T. H., and Huynh, D. T.

(2000). Max-Min D-Cluster formation in wireless ad

hoc networks. In Proc. of the IEEE Conf. on Computer

Communications, volume 1, pages 32–41.

Baccelli, E., Hahm, O., G

unes, M., W

ahlisch, M., and

Schmidt, T. C. (2013). Riot os: Towards an os for

the internet of things. In IEEE Conf. on Computer

Communications Workshops, pages 79–80.

Baker, D. J. and Ephremides, A. (1981). A distributed algo-

rithm for organizing mobile radio telecommunication

networks. In ICDCS, pages 476–483.

Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis,

C., Kroller, A., and Pyrgelis, A. (2010). Wiselib:

A generic algorithm library for heterogeneous sensor

networks. In European Conf. on Wireless Sensor Net-

works, pages 162–177.

Braga, M. d. L. (2012). Gerac¸

ao autom

atica de c

odigo para

redes de sensores sem ﬁo usando communicating x-

machine. Master’s thesis, Programa de P

os-graduac¸

em Engenharia El

etrica - UFAM, Manaus.

Carrero, M. A., Musicante, M. A., dos Santos, A. L., and

Hara, C. S. (2021). A DSL for WSN software compo-

nents coordination. Information Systems, 98:101461.

Dastjerdi, A. V. and Buyya, R. (2016). Fog computing:

Helping the internet of things realize its potential.

Computer, 49(8):112–116.

Dunkels, A., Gronvall, B., and Voigt, T. (2004). Contiki-

a lightweight and ﬂexible operating system for tiny

networked sensors. In 29th Annual IEEE Int. Conf. on

Local Computer Networks, pages 455–462.

Gay, D., Levis, P., Von Behren, R., Welsh, M., Brewer, E.,

and Culler, D. (2003). The nesc language: A holis-

tic approach to networked embedded systems. Acm

Sigplan Notices, 38(5):1–11.

Heinzelman, W. R., Chandrakasan, A., and Balakrishnan,

H. (2000). Energy-efﬁcient communication protocol

for wireless microsensor networks. In Proc. of the

33rd Annual Hawaii Int. Conf. on System Sciences. 10

pages vol.2. IEEE.

Hussein, M., Li, S., and Radermacher, A. (2017). Model-

driven development of adaptive iot systems. In MOD-

ELS (Satellite Events), pages 17–23.

Lekidis, A., Stachtiari, E., Katsaros, P., Bozga, M., and

Georgiadis, C. K. (2018). Model-based design of iot

systems with the bip component framework. Soft-

ware: Practice and Experience, 48(6):1167–1194.

Ouadjaout, A., Lasla, N., Bagaa, M., and Badache, N.

(2014). Static analysis of device drivers in tinyos. In

Proc. of the 13th Int. Symposium on Information Pro-

cessing in Sensor Networks, pages 297–298.

Patel, P. and Cassou, D. (2015). Enabling high-level appli-

cation development for the internet of things. Journal

of Systems and Software, 103:62–84.

Salman, A. J. and Al-Yasiri, A. (2016). Sennet: a program-

ming toolkit to develop wireless sensor network ap-

plications. In Proc. of the 8th IFIP Int. Conf. on New

Technologies, Mobility and Security, pages 1–7.

Satyanarayanan, M. (2017). The emergence of edge com-

puting. Computer, 50(1):30–39.

Taherkordi, A., Johansen, C., Eliassen, F., and R

omer, K.

(2015). Tokenit: Designing state-driven embedded

systems through tokenized transitions. In Int. Conf.

on Distributed Computing in Sensor Systems, pages

52–61.

Development of Wireless Sensor Networks Applications with State-based Orchestration

319