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 specification and implementation of such systems
is a complicated task, especially because of the lack of support for code reuse and for defining the program
execution flow. 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 defines the application execution flow, we pro-
pose a domain-specific 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 efficiency of the proposal
was evaluated by determining the amount of code reuse, while its efficacy 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 define the interconnection among
the devices is by orchestration, which determines the
application workflow (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 flow.
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 sufficient 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
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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 specification, 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 modified.
In order to evaluate our proposal, we considered
the development of three cluster-based WSN mod-
els. Its efficiency was evaluated by determining the
amount of code reuse, which measures the reduction
of development effort. The efficacy 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 defined 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
flexible 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 configure 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
efficient method of code reuse, it does not adopt a
flexible coordination execution flow.
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 flow is specified in XML. Although Tokenit
separates the execution flow from the activities flow,
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 specification model
to generate the execution flow. 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 configura-
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
modifies 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 specific tasks. The three steps of the
model are depicted in Figure 1: (1) specification 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 Specification Step
In the specification 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
sufficient 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
sufficient 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 specifically, we
can specify the execution flow 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 define 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
first 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 confirmation 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 final state.
CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science
314
3.2 Programming Step
Based on the state machine specification, 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 specification 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 definition
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 file 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 specified state machine,
along with a header file for each application compo-
nent. The set of files are given as input to the nesC
compiler, which generates the executable code to be
deployed on the sensor devices.
Our model simplifies the development of WSN
applications with a clear separation between the spec-
ification and implementation, while helping the im-
plementation with a high-level programming lan-
guage that closely resembles the specification 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 definitions, as depicted in Listing 2.
Among the data declarations, it is required that the
structure of messages transmitted among sensors, as
well as their identifiers be defined 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
defines a set of message type identifiers. They help
the implementation of events that receive messages,
allowing different types of messages be handled prop-
erly. message declarations define 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 final states. The
language primitives to implement states include the
traditional control flow statements, such as if, for and
while, as well as ones concerning events and state
transitions
1
:
nextState: makes a transition to another state;
broadcast: sends a message in broadcast;
send: sends a message to a specific sensor;
on recvBroadcast: receives a broadcast message;
on recv: receives a message addressed to a spe-
cific sensor;
during: triggers a timer.
The language also supports composite actions.
They have been identified as commonly used for de-
veloping applications for WSNs. They define that a
sensor waits for messages of a given type during a pe-
riod of time:
1
The complete SLEDS-SD language specification 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 identification, 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. Definitions 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 flow 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 defined 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 specifies 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 flow of execution, with multiple flooding
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
first 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 fired 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
2
.
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
flow. As a result, our experimental analysis is relevant
for determining the impact of our model when devel-
oping a new system with an execution flow 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
flow, 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 first CH on the
Gateway route
2
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 flow 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 flows, 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 flow. 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 flow when it exists, and by reducing
the development effort with a high-level language that
closely resembles the specification model.
5.2 Generated Code Correctness
The purpose of this experiment is to determine the
correctness of the code generated by our translator
0
20
40
60
80
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 field 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 confidence 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 field. 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 defined 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) specification of the flow 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 flow 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 specifica-
tion to first 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 fulfilling in-
tensive sensory data-driven iot workflows. 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 fio usando communicating x-
machine. Master’s thesis, Programa de P
´
os-graduac¸
˜
ao
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 flexible 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-efficient 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