Accepted Manuscript

Taking Arduino to the Internet of Things: the ASIP programming

model

Gianluca Barbon, Michael Margolis, Filippo Palumbo,

Franco Raimondi, Nick Weldin

PII: S0140-3664(16)30074-3
DOI: 10.1016/j.comcom.2016.03.016
Reference: COMCOM 5285

To appear in: Computer Communications

Received date: 11 July 2015

Revised date: 31 January 2016
Accepted date: 8 March 2016

Please cite this article as: Gianluca Barbon, Michael Margolis, Filippo Palumbo, Franco Raimondi,
Nick Weldin, Taking Arduino to the Internet of Things: the ASIP programming model, Computer Com-
munications (2016), doi: 10.1016/j.comcom.2016.03.016

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service
to our customers we are providing this early version of the manuscript. The manuscript will undergo
copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please
note that during the production process errors may be discovered which could affect the content, and
all legal disclaimers that apply to the journal pertain.
 ACCEPTED MANUSCRIPT

Computer
Communi-
Computer Communications 00 (2016) 1–15 cations

Taking Arduino to the Internet of Things:

the ASIP programming model

T
Gianluca Barbona , Michael Margolisb , Filippo Palumboc,d , Franco Raimondib , Nick Weldinb

IP
a Universityof Grenoble Alpes, Inria, LIG, CNRS, France
b Department of Computer Science, Middlesex University, London, United Kingdom
c Institute of Information Science and Technologies, National Research Council, Pisa, Italy

CR
d Department of Computer Science, University of Pisa, Pisa, Italy

Abstract
US
Micro-controllers such as Arduino are widely used by all kinds of makers worldwide. Popularity has been driven by Arduino’s simplicity of use
and the large number of sensors and libraries available to extend the basic capabilities of these controllers. The last decade has witnessed a surge
AN
of software engineering solutions for “the Internet of Things”, but in several cases these solutions require computational resources that are more
advanced than simple, resource-limited micro-controllers.
Surprisingly, in spite of being the basic ingredients of complex hardware-software systems, there does not seem to be a simple and flexible
way to (1) extend the basic capabilities of micro-controllers, and (2) to coordinate inter-connected micro-controllers in “the Internet of Things”.
Indeed, new capabilities are added on a per-application basis and interactions are mainly limited to bespoke, point-to-point protocols that target
M

the hardware I/O rather than the services provided by this hardware.
In this paper we present the Arduino Service Interface Programming (ASIP) model, a new model that addresses the issues above by (1)
providing a “Service” abstraction to easily add new capabilities to micro-controllers, and (2) providing support for networked boards using
a range of strategies, including socket connections, bridging devices, MQTT-based publish-subscribe messaging, discovery services, etc. We
ED

provide an open-source implementation of the code running on Arduino boards and client libraries in Java, Python, Racket and Erlang. We show
how ASIP enables the rapid development of non-trivial applications (coordination of input/output on distributed boards and implementation of a
line-following algorithm for a remote robot) and we assess the performance of ASIP in several ways, both quantitative and qualitative.

Keywords: Arduino, MQTT, IoT, Service Discovery, Communication Middleware

PT

1. Introduction on a per-application basis and interactions are mainly limited to

bespoke, point-to-point protocols that target the hardware I/O
CE

The Internet of Things (IoT) paradigm bases its success on rather than the services provided by this hardware.
the pervasive presence around us of a variety of objects (such Several commercial off-the-shelf devices are available on
as Radio-Frequency IDentification -RFID- tags, sensors, actu- the market, but usually they are tightly coupled with specific
ators, mobile phones, etc.) which, through unique addressing vendors and require local gateways to export sensors and actu-
AC

schemes, are able to interact with each other and cooperate to ators as services on the Web. Instead, by embracing the open
reach common goals [1]. source and hardware principles, it is possible to offer a system
Surprisingly, in spite of being the basic ingredients of com- easily modifiable to suit the user needs and to be used as the
plex hardware-software systems, there does not seem to be a basis for new products in different scenarios. Micro-controllers
simple and flexible way to (1) extend the basic capabilities of such as Arduino are used widely by all kinds of makers world-
micro-controllers, and (2) to coordinate inter-connected micro- wide. Popularity has been driven by Arduino’s simplicity of
controllers in IoT scenario. Indeed, new capabilities are added use and the large number of sensors and libraries available to
extend the basic capabilities of these controllers. Using such an
Email addresses: [email protected] (Gianluca Barbon), inexpensive device makes the installation and maintenance of a
[email protected] (Michael Margolis), system easier. In this way, it is possible to offer a system easily
[email protected] (Filippo Palumbo), modifiable to suit the user needs and to be used as the basis for
[email protected] (Franco Raimondi), [email protected] new products in different scenarios.
(Nick Weldin)
1
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 2

A first approach using the Internet for interacting with real- the protocols used for RESTful architecture are not appropri-
world resource-constrained devices was to incorporate smart ate for resource constrained networks and devices [15]. The
things into standardized Web service architectures (such as large overhead of HTTP causes packet fragmentation and per-
SOAP, WSDL, UDDI) [2] or embedding HTTP servers into the formance degradation when dealing with M2M devices. Also,
devices. However, in practice, this resulted to be too heavy and TCP flow control is not appropriate for resource-constrained
complex for simple objects [3]. In order to face the problem of devices and the overhead is too high for short transactions.
interconnecting several resource-constrained nodes among each To extend the REST architecture for resource-constrained
other and to the Internet, several communication protocols have devices, a first solution presented in the literature is given by
been introduced [4]. These protocols are inspired by machine- the Constrained Application Protocol (CoAP) [16]. CoAP is a
to-machine (M2M) scenarios and share the same fundamentals protocol intended to be used in simple devices allowing them
of communication paradigms typical of standard computer net- to communicate over the Internet. CoAP includes a subset of
works. M2M communications occur among machines (objects the HTTP functionalities, optimized for M2M applications. It

T
or devices) with computing/communication capabilities with- also supports multicast, very low overhead, and asynchronous
out human intervention [5]. message exchanges over a user datagram protocol (UDP) [17].

IP
In this paper we present the Arduino Service Interface Pro- However, also in CoAP, the HTTP protocol is still present. It
gramming (ASIP) model, a new model that addresses the is- has not been designed to support persistent communication and,
sues above by (1) providing a “Service” abstraction to easily even if Web Sockets have been introduced in the recent draft of

CR
add new capabilities to micro-controllers, and (2) providing HTML 5 (offering a bidirectional communication channel be-
support for networked boards using a range of strategies, in- tween client and server), they totally hide the naming scheme
cluding socket connections, bridging devices, MQTT-based that makes REST so powerful: every resource having a stan-
publish-subscribe messaging, discovery services, etc. We pro- dard unique identifier, the URI. The Web Sockets approach re-
vide an open-source implementation of the code running on Ar-
duino boards and client libraries in Java, Python, Racket and Er-
lang. Our programming model allows to tackle the heterogene-
ity that is a distinguishing feature of several IoT applications;
US sults in non-standard solutions for manipulating resources [18].
In order to support collaboration between devices, there is the
need to unify the naming scheme of smart objects and the URIs.
For this purpose, a new communication paradigm has been pre-
AN
by heterogeneity we mean here hardware differences (different sented in the literature based on the “publish-subscribe” (pub/-
microcontrollers), performances/capabilities of different boards sub) mechanism [19, 20].
in terms of CPU power, memory, and storage, and software Directed Diffusion [21] is considered the earliest pub/sub
heterogeneity (e.g., choice of programming languages). We communication paradigm for WSN. It is a data-centric protocol
M

show how ASIP enables the rapid development of non-trivial in which named data is described by attribute-value pairs. The
applications (coordination of input/output on distributed boards subscriptions are called interests and are broadcasted through-
and implementation of a line-following algorithm for a remote out the whole WSN. Another early pub/sub middleware for
robot) and we assess the performance of ASIP in several ways, WSN is Mires [22]. It is implemented on top of TinyOS [23],
ED

both quantitative and qualitative. an event-based operating system for WSNs. In Mires each sen-
The rest of the paper is organized as follows. We review sor advertises its topics (e.g. temperature, pressure, luminos-
related work in Section 2; we introduce the ASIP model in Sec- ity, etc.) to the applications through a sink node. A slightly
tion 3, describing the software architecture, the communication different programming approach is used by TinyCOPS [24],
PT

protocol and the possible communication channels: serial, TCP, a component-based middleware that also provides a content-
and MQTT publish/subscribe messaging. We present a detailed based pub/sub service to WSN that tries to simplify the compo-
experimental evaluation of ASIP performance in Section 4. In sition of services through components (communication proto-
CE

Section 5, instead, we give a qualitative evaluation by providing col, supported data, and service extensions). Recently, Object
examples of how applications can be built on top of ASIP. Management Group (OMG) has published DDS, an open stan-
dard for data-centric publish-subscribe middleware platforms
with real-time capabilities [25]. TinyDDS [26] is the adopted
2. Related Work
AC

version of OMG DDS for WSN, based on TinyOS. It is a

The emerging IoT scenario, exploiting the advances made lightweight pub/sub middleware that allows applications to in-
in the M2M field, enables the possibility of building a huge Ser- teroperate across the boundary of WSNs and access networks,
vice Oriented Architecture (SOA) composed of several devices regardless of their programming languages and protocols.
offering services each other [2]. Existing application platforms All of these solutions are strictly coupled with the hardware
use REST architecture [6, 7, 8, 9, 10, 11, 12, 13, 14] as inter- platform and they usually need centralized hardware infrastruc-
faces in order to expose their services. The REST-style archi- ture (sink nodes or gateways) [27, 28]. Also the MQTT protocol
tecture consist of clients and servers. Clients initiate requests introduced by IBM uses hierarchical topic based [29] publish-
to servers; servers process requests and return the appropriate subscribe mechanism and facilitates the constrained devices by
responses manipulating the resources. A resource can be any enabling “pushing” [30] data from the cloud rather than polling
thing identified by URIs. REST uses the GET, PUT, POST, and by constrained device for the data from the server. In this case
DELETE operations of HTTP to access resources. However, the overlay infrastructure is a software component, the broker.
The broker is responsible for distributing messages to interested
2
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 3

clients based on the topic of a message. In the sensor domain, ually to take into account both low-level implementation details
IBM has come up with yet another protocol MQTT for Sensor and the high-level requirements of the application of which the
Networks (MQTT-SN) [31] which is designed in such a way micro-controller is part. Several solutions have been proposed
that the protocol is agnostic of the underlying networking ser- in order to address the issue of abstracting low-level implemen-
vices. tation details [45]. Most of them are tightly targeted to particu-
From the devices availability point of view, there are two lar applications [46] or hardware platforms [23]. Instead of re-
types of hardware platforms that can be connected to IoT ser- lying on a dedicated operating system, in this paper we propose
vice platforms. One is off-the-shelf commercial products that that sensors and actuators are exposed by micro-controllers as
are related to certain platforms, for example, Cosm consumer services, so that more complex software applications can be
products [6], ioBridge [32], NanoRouter [17], MicroStrain Sen- built by composing them. When restricted to the Arduino plat-
sors [33], and Digi routers [14]. The second type is an open form, the closest protocol to ASIP is the Firmata protocol [47],
hardware (development/hackable) platform that users can de- which enables a computer to discover, configure, read and write

T
velop themselves, such as Arduino [34], mBed [35], or Nan- a microcontrollers general purpose IO pins. However, ASIP has
ode [36]. Embracing the open source and hardware principles, a smaller footprint than Firmata (using around 20% less RAM).

IP
it is possible to offer a system easily modifiable to suit the user And uniquely, it supports high level abstractions that can be eas-
needs and to be used as the basis for new products in different ily attached to hundreds of different services for accessing sen-
scenarios. sors or controlling actuators. These abstractions can decouple

CR
Different solutions have been proposed in order to bring the references to specific hardware, thus enabling different micro-
IoT paradigm on the Arduino platform. In the healthcare field, controllers to be used without software modification. Although
a textile version of the Arduino platform, called LilyPad [37], ASIP is currently implemented for Arduino boards, the pro-
has been used to bridge wearable medical devices to IoT en- tocol is hardware agnostic. Moreover, as shown below, ASIP
abled infrastructure using a mobile device as gateway. In [38],
authors propose a model to enable the event reading and the
controlling of electrical devices using a master controller that
acts as a gateway that is a standard PC. In the energy monitoring
US supports communication over TCP and MQTT, while Firmata
is limited to serial communication.
AN
3. The ASIP programming model
scenario, [39] describes a non-intrusive load monitoring system
for domestic appliances where a web server is embedded on the In this section we describe the Arduino Service Interface
Arduino board. These solutions embed HTTP web servers on Programming model (ASIP), which has been developed to sim-
board that make easier to fetch the exposed information in one- plify and accelerate the development of applications in the IoT.
M

to-one client-server connections. Our aim is to avoid the pres- Applications for the IoT typically involve heterogeneous com-
ence of local gateways or embedded resource-consuming web ponents, both in terms of software and hardware. Machine-
servers, offering the possibility to coordinate inter-connected to-machine communications are the prevalent mechanism for
micro-controllers through Internet providing support for net-
ED

coordination and execution of tasks. The ASIP programming

worked boards with different strategies: socket connections, model addresses this issue, together with a mechanism to in-
bridging devices, and MQTT-based pub/sub messaging. tegrate with existing protocols such as MQTT. We note that,
Pairwise evaluations and comparisons of HTTP, CoAP and while providing a seemingly Arduino-specific solution, our pro-
MQTT protocols have been reported in the literature. For ex- gramming model is generic and can be implemented on top of
PT

ample, [40, 41, 42] compares the performance of MQTT, CoAP, microcontrollers with very limited resources. Our choice for
and HTTP in terms of end-to-end transmission delay and band- Arduino has been motivated by the open-source nature of the
width usage [41] and in terms of energy consumption and re- project and by the availability of hardware. Specifically, ASIP
CE

sponse time [42]. Based on their results, MQTT delivers mes- builds upon the notion of “service” for micro-controllers: a ser-
sages with lower delay than CoAP when the packet loss rate vice could be a temperature sensor, a servo motor, or any other
is low, while, due to its condensed header and small packet input or output device connected to a micro-controller. Each
size, CoAP is more efficient than HTPP in transmission time micro-controller can be controlled using textual messages, and
AC

and energy usage. Regarding the power consumption of the each micro-controller reports data using messages to so-called
devices, there is a detailed experiment for power consumption clients. The core ASIP implementation running on a micro-
comparison between HTTP and MQTT on mobile devices [43]. controller deploys one or more services: this enables the re-
The result shows that the MQTT protocol wins in all tests, usability of both micro-controller-specific code and of client
which include establishing, maintaining, and receiving/send- code, and it opens the possibility of model-based development
ing messages [44]. From these considerations, we choose to for complex applications involving multiple micro-controllers,
implement a simple text-based service discovery mechanism as described below.
to let several resource-constrained microcontrollers to discover In summary, the ASIP model provides:
each other with their functionalities and to exchange messages
among them. • A software architecture for code running on the micro-
From the programming model point-of-view, in order to ex- controller.
pose sensors and actuators as services, the components con-
nected to the micro-controller need to be programmed individ-
3
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 4

channel, a TCP socket or a MQTT pub/sub mechanism (please

refer to the system architecture described below for additional
AsipClass AsipServiceClass details). The AsipClass must implement a run method that
in : InputStream id : char executes the main ASIP loop. Before the execution of the main
out : OutputStream loop, an initialization mechanism is called to set up the commu-
begin() nication streams. The main loop performs the core operations
1 n
run() processRequest() to handle ASIP, acting like a dispatcher of messages to/from
begin() reportValues() services. First of all, it listens for incoming messages, and redi-
rects them to the proper service by recognizing the service iden-
tifier in the ASIP message header. A particular set of messages,
called systems messages, are not handled though a service but
Figure 1: ASIP simplified class diagram are processed through proper methods supplied by the Asip-

T
Class. Moreover, the loop allows services to reply continuously
in case periodic status messages have been enabled, for instance
• A textual protocol for messages exchanged between ASIP

IP
to report a distance reading at regular time intervals.
clients and micro-controllers implementing the software
architecture mentioned above.
3.2. The syntax of ASIP messages

CR
• A network architecture for the connection between micro- Messages exchanged between micro-controllers and clients
controllers and client that can be written in several high- are plain text messages with a standard format. They can be
level programming languages. divided into command messages and event messages. The first
are sent by ASIP clients to micro-controllers, while the latter
These various components are described in the subsections
below.

3.1. Basics: software architecture

US are sent on the opposite direction by the micro-controller. ASIP
messages consist of an ASCII header, followed by ASCII char-
acter fields separated by commas, and terminated by the new-
line character.
AN
As mentioned above, at the core of ASIP is the notion of ser- Command (or request) messages to a micro-controller be-
vice. We model it by means of the class AsipServiceClass gin with a single character to indicate the desired service, fol-
(see right-hand side of Figure 1). Each service, e.g. a distance lowed by a comma and a single character tag to identify the
sensor, must have a unique ID and it can reuse existing Arduino nature of the request. Requests that contain a parameter are
M

libraries developed specifically for the given component (sen- separated from the tag with a comma. As an example, the mes-
sor, shield, motor, etc.) to obtain data from that component. sage I,d,13,1 invokes the service with ID I (typically, an In-
Each service must implement the following methods: put/Output service), requesting an operation d (in this case it is
ED

a request to write on a digital pin) with parameters 13 and 1.

• begin(), to set up the service appropriately, for instance These parameters indicate, respectively, pin 13 and the value 1
by initialising the pins or by enabling interrupts. (high).
In the other direction, reply messages from the microcon-
• processRequest(), to process messages for the service
troller begin with one of the following characters:
PT

dispatched by the class AsipClass, as described below.

• ”@” defines an event message responding to a request or
If the service returns values, for instance in the case of a
autoevent. These messages are composed of three bytes
temperature or distance sensors, then the service should also
CE

following the ”@” character: a character indicating the

implement the method reportValues(). This method con-
service, a comma, and the tag indicating the request that
verts data into ASIP messages, using the syntax of ASIP mes-
triggered this event respectively.
sages described below. A number of services is already pro-
vided with the ASIP implementation that we describe in this • ”˜” defines an error message reporting an ill formed re-
AC

paper, but additional ones could be defined by implementing quest or some other problems affecting the server. These
an AsipServiceClass to handle appropriate messages. It is as- messages contain the service and tag associated with the
sumed that all implementations of ASIP support at least the ba- error followed by an error number and error string.
sic Input/Output ASIP service, which provides basic I/O oper-
ations at the pin level. On an Arduino board these operations • ”!” defines an informational or debug message consist-
include writing and reading values from digital and analog pins, ing of unformatted ASCII text terminated by the newline
thus permitting the control of LEDs or reading potentiometer character.
values.
Service are put togethet in the class AsipClass (left-hand- Some reply event messages have a payload with a variable
side of Figure 1. The AsipClass is the core of ASIP and is number of fields with the following format:
responsible for managing services. The AsipClass on the mi- • a numeric value that precedes the message body indicat-
crocontroller is connected to a stream, which can be a serial ing the number of fields in the body
4
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 5

Request explicit distance measurement:

Header Separator Tag Terminator
‘D’ , ‘M’ ‘\n’

Request distance autoevents:

Header Separator Tag Separator Period Terminator
‘D’ , ‘A’ , Numeric value in milliseconds ‘\n’

Reply:
Header Separator Tag Separator Distance in CM Terminator
‘D’ , ‘M’ , Numeric digits ‘\n’

T
Figure 2: ASIP Messages: example of syntax for a distance service

IP
• curly brackets used to indicate the start and end of fields • Racket:
in the message body https://github.com/fraimondi/racket-asip

CR
• if a message contains sub fields, these are separated by a • Erlang:
colon (for instance, in case of analog pin mapping mes-
sage) https://github.com/ngorogiannis/erlang-asip

• all numeric values are expressed as ASCII text digits and

are decimal unless otherwise stated.

Figure 2 reports the syntax for a distance service.

US 3.3.2. TCP and MQTT bridges
Before introducing the TCP and the MQTT architecture we
introduce the notion of bridge to address the issue of network
connection for micro-controllers. Indeed, a micro-controller
AN
such as an Arduino board needs an additional ethernet or a wi-
3.3. System Architecture fi device to communicate on a network. This device may be
Micro-controllers can be connected to clients in a number of an Arduino shield, or an external device. In the first case, the
way: directly using a serial connection (over USB), by means of Arduino ASIP client sketch integrates the code needed to talk
M

TCP sockets, or using an MQTT-based publish/subscribe mes- to the shield. In the latter case, instead, the Arduino sketch can
saging mechanism. be connected using a standard serial connection to the external
Serial sockets and TCP connections are used in point-to- device and it does not require modifications. Thus, it is the ex-
point connections, when a client has exclusive access to a de- ternal device that will take care of the network communications.
ED

vice, for instance for controlling a robot. The MQTT-based ar- We call this kind of devices bridges.
chitecture allows sending and receiving data to and from multi- The bridge logic is very simple: the bridge listens to incom-
ple devices, thus resulting useful in applications such as sensor ing messages from the network and routes them to the serial
networks (smart homes, etc.). port. In the other direction, the bridge listens to incoming mes-
PT

sages from the micro-controller over its serial connection and

3.3.1. Serial connection it redirects them to the network interface. A bridge does not
The serial connection uses the USB bus in order to connect implement ASIP classes or services, because its only function
CE

to a micro-controller from a computer. This is the basic con- is to permit the communication between different transmission
figuration for the ASIP architecture. The micro-controller must medium. In order to avoid the presence of errors in the conver-
run an implementation of the AsipClass described above, with sion between two transmission channels, error checking can be
at least the implementation of the Input/Output Service. Theo- implemented.
AC

retically, on the computer side of the connection, a simple serial Bridges can be implemented using different kinds of hard-
monitor could send instructions and read values being reported. ware platforms. For the testing phase of this paper, the Rasp-
In practice, applications are written in a high-level language berry PI 2 has been used as hardware platform. However, lighter
to make use of the services installed on the micro-controller. platforms can be adopted [48] and we have successfully em-
Various implementations of the serial client exist for different ployed the ESP8266 chip, a lightweight SoC that features low
languages: power consumption and includes a wi-fi antenna 1 .
Bridges can be employed both for TCP and for MQTT con-
• Java: nections, as explained below. The Java and Python implemen-
https://github.com/fraimondi/java-asip tations of ASIP clients include bridges for TCP and for MQTT.

• Python:
1 See https://github.com/michaelmargolis/mdx_prototypes/
https://github.com/gbarbon/python-asip tree/51145bd1347625df9bc4e79b7eb11726f243a401/ASIP/Lua.

5
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 6

topic asip/BOARDNAME/out. Conversely, a client of a spe-

The adoption of bridges brings some advantages: cific board should subscribe to topic asip/BOARDNAME/out
to receive messages from the board, and publish messages to
• a single board can be used by different clients; asip/BOARDNAME/in to send messages to the board.
Implementations of MQTT bridges and sample clients are
• use of low cost devices instead of expensive Arduino
available in the Java and Python repositories.
shields (like the Ethernet and Wi-Fi shields);
• use of devices with very low power consumption; 3.4. Service-level discovery mechanism
In order to let the devices know the presence of other de-
• reduction of the workload on the Arduino board. vices and their embedded sensors/actuators exposed as services,
we propose a service discovery overlay that exploits the MQTT
3.3.3. TCP protocol capabilities. We follow the approach presented in [49],

T
Connecting to an Arduino through TCP may require the where the service discovery functionality is realized by intelli-
adoption of a bridge, depending on how the micro-controller gent buses, namely the context, service and control buses. All

IP
is connected to the network. A micro-controller implementing communications between devices can happen in a round-about
ASIP messaging over TCP must have an IP address and a dedi- way, via one of them. Each of the buses handles a specific type
cated TCP port open to connections. Once a client opens a con- of message/request and is realized by different kinds of MQTT

CR
nection to the address and port creating a socket, the exchange topics. This approach has been proven useful in different ap-
of messages continues identically to the serial communication. plication scenarios, spanning from ambient assisted living [50],
In fact, client applications developed to work over serial com- mobile [51], and energy monitoring [52] infrastructures.
munication can be immediately translated into TCP-based ap- In particular, as soon as a micro-controller is turned on, it
plications just by replacing the client connection class. Code
for TCP clients is provided in the Java and Python repositories
mentioned above.
US
Even if the micro-controller is limited to single connections,
announces his presence publishing a message containing his
unique identifier on the service bus topic (asip/servicebus)
and it subscribes to the same topic in order to be notified by
the MQTT broker about existing (already announced) or new
AN
nothing prevents the client from opening connections to multi- services to be announced. In this way, all the devices can dis-
ple, networked devices, thus enabling the coordination of net- cover its presence and start to listen for its messages subscrib-
worked micro-controllers. Notice that sockets can be created ing to the relative context bus topic (asip/BOARDNAME/out).
even over internet, thus enabling the control of possibly very Micro-controllers, if capable, can also accept commands, sub-
M

remote micro-controllers. In addition, if an appropriate DNS scribing to their control bus (asip/BOARDNAME/in) and wait-
record can be provided for each micro-controller, standard do- ing for messages published by other micro-controllers/services
main naming mechanisms can be used to identify boards and on the same topic. Figure 3 shows an example of a possible in-
bridges. teraction among different micro-controllers (B1,...,B4) and
ED

a remote service translating MQTT topics to REST resources

3.3.4. MQTT (the description of this kind of service is out of the scope of this
ASIP messages can be exchanged using MQTT. The main paper, see [18, 44] for possible solutions). A micro-controller
advantage is in the implementation of clients that need to con- can also expose different sensors/actuators as services (B4 in
PT

nect to multiple boards: instead of opening a socket for each the figure announcing sensor S1 and actuator S2). In the exam-
micro-controller, the client can simply subscribe and publish ple, B4 announces itself and its sensors/actuators publishing the
messages to a broker. Similarly, MQTT bridges forward serial relative identifiers on the service bus topics:
CE

messages from the board to publish actions for appropriate top-

ics and route subscribed messages to the serial channel. More PUBLISH asip/servicebus B4
in detail, we assume that each micro-controller is identified by PUBLISH asip/servicebus/B4 S1
a unique name and we employ the following scheme for topics: PUBLISH asip/servicebus/B4 S2
AC

• Messages from a specific board are published by the then, it starts publishing data from B4/S1 on the relative
board (or by its bridge) to the MQTT broker with topic context bus topic and it subscribes to the context bus topic rela-
asip/BOARDNAME/out, where BOARDNAME is the unique tive to B4/S2, waiting for incoming commands:
identifier of the micro-controller.
PUBLISH asip/B4/S1/out data
• Messages to a specific board are published by clients to SUBSCRIBE asip/B4/S2/in
the MQTT broker with topic asip/BOARDNAME/in.
In the depicted example, micro-controllers B1, B2, and B3
In practical terms, an MQTT bridge for a board should are consumers of B4/S1 and they have already subscribed to the
subscribe to topic asip/BOARDNAME/in and forward mes- relative context bus topic, so they start receiving the required
sages received on this topic to the serial connection. The data. In the meantime, the REST service exposes B4/S1 and
same bridge should publish serial messages from the board to B4/S2 as web resources and can send a command to the actua-
tor B4/S2 publishing on the relative control bus topic:
6
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 7

http://example.com/B4/S1/
http://example.com/B4/S2/ REST

SUBSCRIBE asip/servicebus SUBSCRIBE asip/B4/S1/out

B4, B4/S1, B4/S2
service bus
data data data context bus Broker
PUBLISH control bus
asip/B4/S2/in command
PUBLISH

T
asip/servicebus B4
B1 asip/servicebus/B4 S1
B2

IP
asip/servicebus/B4 S2

CR
S1
PUBLISH
asip/B4/S1/out data B4
B3

US
Figure 3: An application scenario exploiting the service discovery functionality.
S2
AN
PUBLISH asip/B4/S2/in command
M

4. Quantitative Evaluation Arduino UNO wave generator

In this section we provide a quantitative experimental eval-

uation of ASIP. In particular, we to assess the throughput (how
ED

many messages per second can be sent?) and the latency (what Original wave to
oscilloscope

is the delay between a request and a response?) for the possible

network architectures described above: direct serial connection, Resulting wave to
oscilloscope

TCP socket, and MQTT publish/subscribe.

Raspberry PI 2 + ASIP
PT

4.1. Throughput
In this work we define throughput for ASIP as the number Arduino UNO + ASIP
CE

of messages per second that can be sent over a communica-

tion channel. Intuitively, this corresponds to the maximum fre-
quency of updates that can be achieved, for instance to control
a robot. Figure 4: Serial testing set-up.
AC

4.1.1. Experimental set-up

Figure 4 sketches our experimental set-up. At a high level, • The Arduino depicted on top acts as the signal generator
we use a signal generator to generate periodic impulses that are by emitting a signal on pin 9. The Arduino is running a
received by a micro-controller running ASIP on input pin 2. simple sketch that generates a periodic signal with a spe-
A client is connected to the Arduino using one of the possible cific frequency (in our sketch this value can be changed
channels (serial, TCP, MQTT) and it sets the value of output pin on-the-fly).
13 according to the value read on pin 2. We then use an external
• The Arduino depicted on the lower part of the figure runs
oscilloscope to track the original signal entering pin 2 and the
ASIP and is connected to a client through pins 0 and 1.
signal generated by the ASIP client on pin 13 to make sure that
the frequencies are the same. If this is the case, then ASIP can • The Raspberry Pi runs ASIP client code, which could be
process this number of messages per second. More in detail, in written in Java or in Python. Notice that the Raspberry
Figure 4: Pi could be replaced by a laptop connected to the Ar-
7
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 8

other machine. We have used a Macbook Pro and a Mac-

book Air (see below for details).
• In the case of networked connection: hardware and soft-
ware configuration of the bridge.
• In the case of MQTT: broker location. Notice that we
employ MQTT QoS level 0 (“at most once”).

We report detailed experimental results in the following sec-

tion.

4.1.2. Results

T
We present throughput experimental results separately for
Java and for Python clients. The possible hardware configura-

IP
tions are:

• MacBook Pro: 2.4 GHz Intel Core i7, 16 GB of RAM,

CR
Figure 5: Oscilloscope output. running Mac OS X 10.10.
• MacBook Air: 1.7 GHz Intel Core i5, 4 GB of RAM,
duino using a USB connection, or it could be replaced running Mac OS X 10.8.
by a bridge for TCP or MQTT, which could in itself be a
Raspberry Pi or an ESP 8266 chip.

• An external two-input oscilloscope (not depicted in the

US • RPi 2: Raspberry Pi, 900MHz quad-core ARM CPU,
1GB RAM, running the default Raspbian Linux image.
• Micro-controller: Arduino Uno running the default ASIP
AN
figure) compares the signal generated by the Arduino de-
code available at:
picted on top with the signal generated on pin 13 of the
Arduino depicted on the bottom. https://github.com/michaelmargolis/asip

We used an oscilloscope in order to see the difference be- Additionally, in terms of network architecture for the exper-
M

tween the wave generated by the wave generator and the result- iments, we employ the following abbreviations:
ing wave obtained after “travelling” through the ASIP network.
This allowed to have a visual feedback about the throughput, in • MacBook Pro, MacBook Pro Air: the client and the TCP
bridge (or MQTT broker) all run on the same machine to
ED

order to check the maximum rate allowed by ASIP. An exam-

ple output for the oscilloscope is depicted in Figure 5. In this which the Arduino is connected using a USB cable.
figure, the signal in the lower part is the signal from the signal • RPi 2: the client runs on a Raspberry Pi 2. In the case of
generator, while the signal on top is the signal from the ASIP TCP or MQTT connections, the bridge or the broker run
PT

board (the drift between the two waves is the latency, assessed on a separate Raspberry Pi. The two Raspberry Pi are
separately in the section below). The figure depicts a frequency connected using ethernet cables and a router.
for which the ASIP client can track the signal correctly, because
the number of peaks is the same in both traces. When the fre- • RPi 2 bridge + MBP client: in this configuration the
CE

quency of the original signal increases above a certain thresh- software client runs on the MacBook Pro while the TCP
old, the top wave fails to track the signal and misses some of bridge (or the MQTT broker) runs on the Raspberry Pi.
the peaks. Connection is through a router and ethernet cables.
Notice that the logic of the test is all performed in the ASIP
AC

client. The incoming signal from pin 2 is sent through an ASIP • RPi 2 bridge + MBA client: as above, but the client runs
message from Arduino to the client. The client processes the on the MacBook Air.
message, reads the value and establishes the value of pin 13. • RPi 2 + MB broker: the MQTT broker runs on the Mac-
Finally it sends a message to the Arduino with the new value Book Air and the client runs on the Raspberry Pi.
for pin 13. Essentially, the aim of this set-up is to replicate the
behaviour of the signal generator using ASIP. The parameters Figure 6a presents the experimental for the assessment of
that can be varied are: throughput using Java clients. In this set-up we employ the code
available at https://github.com/fraimondi/java-asip.
• Type of connection: serial, TCP or MQTT. The serial library is provided by JSSC (https://code.
• Software for the ASIP client: Java or Python language. google.com/p/java-simple-serial-connector/) while
the MQTT library is provided by the Paho Java client (https:
• Hardware where the client is running: Raspberry Pi or //eclipse.org/paho/clients/java/). The MacBook Pro
8
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 9

200 200
Serial

T
180 TCP
160 MQTT
Throughput [msg/s]

IP
140
120
100

CR
100
80 80 80 80 80 80 80
80 70
65
60
40
20
0
MacBook Pro MacBook Air
12

US
RPi 2
12
-

RPi 2 bridge
+ MBP client
-

RPi 2 bridge
+ MBA client
- -
20

RPi 2 bridge
+ MB broker
AN
Testbed configuration
(a)
200 Serial
M

180 TCP
160 MQTT
Throughput [msg/s]

140
ED

120
100 90
80 80 80
80
60
PT

60 50 50 50 50 50
40
40
20
20 14 10
CE

- - - -
0
MacBook Pro MacBook Air RPi 2 RPi 2 bridge RPi 2 bridge RPi 2 bridge
+ MBP client + MBA client + MB broker
Testbed configuration
AC

(b)

Figure 6: Throughput for Java (a) and Python (b) clients with various testbed network configurations.

9
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 10

runs Oracle JVM 1.8, the MacBook Air and Raspberry Pi run
Oracle JVM 1.6.
Figure 6b presents the experimental for the assess-
ment of throughput using Python clients. In this set-up
we employ the code available at https://github.com/
gbarbon/python-asip. The serial library is provided by
pySerial (http://pyserial.sourceforge.net/) while
the MQTT library is provided by the Paho Python client
(https://eclipse.org/paho/clients/python/). All
experiments have been run using Python 2.7 but notice that the
code is compatible with Python 3. Arduino UNO + ASIP Raspberry PI 2 + ASIP

T
Discussion: The results presented in figures 6a and 6b show (a)
that ASIP can achieve a rate of messages up to 200 messages

IP
per second when the serial connection is used. In this case the
limiting factor is the CPU speed of the client. As expected,
TCP and MQTT performance is inferior to direct serial com-

CR
munication, but it is still more than adequate even for applica- TCP / MQTT Bridge

tions that require continuous monitoring, such as controlling a

robot. The reduction in throughput is associated to the multiple
communication layers introduced by the network libraries. Java
outperforms Python in all tests; we argue that this is caused by
the better performance of the Oracle JVM and its Just-in-Time
compiler with respect to the Python interpreter. Interestingly,
the throughput for TCP and MQTT connections is similar, with
US Network Connection
AN
only minor differences in some circumstances. As mentioned Arduino UNO + ASIP ASIP Client

above, MQTT connections are run at QoS level 0, and therefore

there is not guarantee of message delivery, while TCP connec- (b)
tions have built-in retransmission and sequencing guarantees. Figure 7: The hardware set-ups used for latency testing: (a) serial connection
M

On the other hand, MQTT messaging allows broadcasting and and (b) TCP and MQTT connection.
the easy deployment of sensor networks.

Overall, we consider these results extremely promising and, In nearly all case, with the exception of two configurations
ED

in the case of serial connections, very close to the physical ca- running on resource-limited Raspberry Pi, the latency remains
pacity of the communication channel, as explained in the fol- below 15 ms. We consider these very positive results, as the
lowing sections. physical limitations of the serial communication channel intro-
duce a latency of approximately 6.7 ms. This figure is com-
PT

4.2. Latency puted by considering that 32 ASCII characters are exchanged

in the ASIP messages for this application, by considering the
Testing for latency is performed using a single board. At a
additional bits required in each serial frame, and by consider-
very high level, the test is performed by connecting an output
ing the serial speed of 57600 baud.
CE

pin with an input pin on the board, and then writing an ASIP
It is interesting to notice that latency is only minimally af-
client that sets the first pin to high and waits for a notification
fected by the choice of the programming language and by the
for the change of value of the second pin. The time difference
communication channel.
between setting the output pin and measuring the change in the
AC

input pin is assumed to be the latency.

Similarly to the throughput test, we perform an assessment 5. Qualitative Evaluation
for serial connections (see Figure 7a) and for networked archi-
tectures using either TCP or MQTT (see Figure 7b). In this section we provide examples of how ASIP can be
For each one of the configurations described above we per- used and extended: we present how a simple distributed appli-
form 100 tests and we take the average value. cation can be built in Python, how a robot can be driven using
a Proportional-Integral-Derivative (PID) controller [53] using
4.2.1. Latency results Java and, finally, we show how to add a new service, both on
the micro-controller and on the client code.
As in the case of throughput, we perform latency measures
both for Java and for Python clients. The results for Java are
5.1. Building a distributed application
reported in Figure 8a, while the results for Python are reported
in Figure 8b. In this section we build a simple distributed application to
coordinate two Arduino boards connected to the network using
10
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 11

50 Serial TCP MQTT

T
45
40 38.4

IP
35
Latency [ms]

30

CR
25
20
14 14.8 14.1 13.7
15 12.9 13.4
11.9 11.5 11.9 12.2
10.9 10.6 10.2

US
10
5
- - - -
0
MacBook Pro MacBook Air RPi 2 RPi 2 bridge RPi 2 bridge RPi 2 bridge
AN
+ MBP client + MBA client + MB broker
Testbed configuration
(a)
50 Serial TCP MQTT
M

45
45
40
35
ED
Latency [ms]

30
25
20 16.44 16.5
14.8 15
PT

13.6 13 13.2 13.8 13.5

15 11.4
11.1 11.1 11
10
5
- - - -
CE

0
MacBook Pro MacBook Air RPi 2 RPi 2 bridge RPi 2 bridge RPi 2 bridge
+ MBP client + MBA client + MB broker
Testbed configuration
AC

(b)

Figure 8: Latency for Java (a) and Python (b) clients with various testbed network configurations.

11
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 12

Producer 34 if self .buttonState != self . oldstate :

35 if self .buttonState ==1:
36 self .board2. digital write ( self .ledPin, 1)
37 else:
38 self .board2. digital write ( self .ledPin, 0)
39 self . oldstate = self .buttonState
40
41 if name == ” main ”:
42 Broker = ”192.168.0.1”
43 TwoBoardSwitch(Broker)

From a practical point of view, the developer needs to in-

stall ASIP on the two Arduino boards from https://github.
com/michaelmargolis/asip, set up the two Raspberry Pi us-
Consumer
MQTT Broker
Asip ing either the Python or the Java MQTT bridges and, finally,
Client
implement an ASIP client. This client can run on a machine

T
or on one of the two Raspberry Pi depicted in the figure. Ex-
cerpts for a Python client are presented in Listing 1. This

IP
client defines a class (line 7) composed of two boards of class
SimpleMQTTBoard (lines 10 and 11), whose implementation is

CR
provided by the Python library available on github. Each board
needs to be connected to a Broker (specified on line 42) and
is identified by an ID. After initialising environment variables
(lines 13 to 17) and setting the pins to appropriate modes (lines
Figure 9: Button and LED application

MQTT. In particular, an input button is connected to a board,

and a LED is connected to the other board. Each board employs
US 22 and 23), the logic of the application is implemented in the
loop of the main class between lines 29 and 39. The loop simply
reads the state of the input pin on board1 (line 31). If the state
has changed, then the state of the LED is changed appropriately
AN
(lines 36 or 38).
a Raspberry Pi as a bridge to connect to an MQTT broker, as
Notice how the communication mechanism is abstracted in
depicted in Figure 9. The aim of the application is to turn on
this implementation. The physical location and the connection
the LED on the second board when the input button is pressed
mechanism is irrelevant for the logic of the application in the
on the first board. The logic of the application is implemented
main method: the only modification required to support a serial
M

by an ASIP client (not depicted in the figure). We assume that

connection (or a TCP connection) is the definition of the boards
the Arduino boards have the standard I/O service installed and
on lines 10 and 11.
that there is an MQTT broker in the network with IP address
The expected performance in terms of latency and through-
192.168.0.1.
ED

put for this kind of applications has been discussed in Section 4.

Listing 1: Python example code for two boards connected using MQTT
1 from asip client import AsipClient 5.2. Controlling a Robot
2 from simple mqtt board import SimpleMQTTBoard
3 [...] In this section we show how a robot can be controlled over
PT

4 a TCP connection. In particular, we present the code to im-

5 # A simple board with just the I /O services on a fixed port .
6 # The main method simulates a light switch. plement a line following algorithm for the Middlesex Robotic
7 class TwoBoardSwitch(): Platform (MIRTO) [54]. For the purposes of this example, we
8
employ three infrared sensors mounted under the robot and we
CE

9 def init ( self , Broker):

10 self .board1 = SimpleMQTTBoard(Broker, ”board1”) exploit the ability of controlling each wheel individually to the
11 self .board2 = SimpleMQTTBoard(Broker, ”board2”)
12 desired speed. The line to follow is a strip of black electric tape
13 self .buttonPin = 2 # the pin on board1 for the input button on a white table. When the infrared sensors are on the white
14 self .ledPin = 13 # the pin on board2 for the output (LED)
AC

15 # initialise the variable for when we press the button surface they report a value close to 0, while when the sensors
16 self .buttonState = 0 are perfectly on black they report values close to 1000. Any
17 self . oldstate = 0
18 value in the 0-1000 range represent a partial overlap of the sen-
19 def init conn ( self ): sor with the black tape.
20 try :
21 [...] The robot is equipped with a bespoke PCB using an At-
22 self .board1.set pin mode(self.buttonPin, AsipClient.INPUT PULLUP) mel 328P chip, compatible with an Arduino Mini. The chip
23 self .board2.set pin mode(self.ledPin, AsipClient.OUTPUT)
24 [...] runs a version of ASIP including, in addition to the standard
25 except Exception as e: I/O service, services for infrared sensors and for wheel con-
26 sys.stdout. write ( ”Exception: caught {} in setting pin modes\n”.format(e))
27 trol. The Arduino code for this robot is available at https:
28 def main(self ): //github.com/michaelmargolis/asip in the sketch called
29 while True:
30 # check the value of the pin mirto.ino. The ASIP client for this service are available at
31 self .buttonState = self .board1.digital read ( self .buttonPin) https://github.com/fraimondi/java-asip in the class
32
33 # check if the value is changed with respect to previous iteration JMirtoRobot.
12
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 13

The idea of a proportional-integral-derivative controller The Java code can be run on a client connected to the same
(PID) is that an error can be computed from the reading of the network to which the robot is connected. A typical line fol-
infrared sensors. The greater the error, the farther away the lowing algorithm performs smoothly at a frequency of approx-
robot from the line. We set a target speed and the correction of imately 10 Hz, which can be easily achieved given the results
this speed, for each wheel, is proportional to three components: presented in the previous section for throughput. A video of
this example is available at this link: https://www.youtube.
• The current error (Proportional component) com/watch?v=KH_3766gNcM
• The rate of change of the error (the Derivative compo-
nent) 5.3. Adding new services
We conclude this section by showing how ASIP can be ex-
• The sum of the errors so far (the Integral component).
tended to include new services that are not yet available in our
This is normally capture by the following formula: implementation. Adding a new service typically involves build-

T
Z t ing code that runs on the Arduino and client code. In this sec-
d tion we show how the distance service can be implemented.

IP
C(t) = K p e(t) + Ki e(τ)dτ + Kd e(t)
0 dt The first step is to implement the class AsipServiceClass re-
where C(t) is the correction at time t, e(t) is the error com- ported in Figure 1. A possible implementation is reported in
Listing 3.

CR
puted at time t and K p , Ki , Kd are the coefficients for the three
components of the correction mentioned above. Listing 3: C++ code for the distance service
1 class asipDistanceClass : public asipServiceClass
Excerpts from the Java implementation for the PID algorithm 2{

US
3 public :
are presented in Listing 2. The key points here are: 4 asipDistanceClass(const char svcId);
5 void begin(byte nbrElements, const pinArray t pins []);
• Line 6 sets up a TCP connection to a bridge at IP address 6 // send the value of the given device
7 void reportValues(int sequenceId, Stream ∗ stream);
192.168.0.1. This is the IP address of the Raspberry Pi 8 void processRequestMsg(Stream ∗stream);
running on the robot.
AN
9 private :
10 int getDistance(int sequenceId);
11 };
• The values of the infrared sensors are read at lines 12
10-12. The method getIR is provided by the class 13 // [...]
14 void asipDistanceClass::processRequestMsg(Stream ∗stream)
JMirtoRobotOverTCP that is available at https:// 15 {
M

github.com/fraimondi/java-asip. 16 int request = stream−>read();

17 [...]
• The values of the infrared sensors are used at line 16 and 18 if (request == ’M’) {
19 reportValues(stream); // send a single measurement
20-21 to compute, respectively, the current error and the 20 }
ED

correction to be applied to the motors. 21 [...]

22 }
23
• The speed of each wheel is updated at line 23 24 void asipDistanceClass::reportValues(int sequenceId, Stream ∗ stream)
with the method setMotors, which is provided by 25 {
26 if ( sequenceId < nbrElements) {
JMirtoRobotOverTCP
PT

27 stream−>print(getDistance(sequenceId));
28 }
29 }
Listing 2: Java ASIP implementation for a PID line following robot 30
31 int asipDistanceClass::getDistance(int sequenceId)
1 import uk.ac.mdx.cs.asip.JMirtoRobotOverTCP; 32 {
CE

2 33 [...]
3 public class AsipMirtoPIDFollower { 34 // The sensor is triggered by a HIGH pulse of 2 or more microseconds.
4 35 // Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
5 public void navigate() { 36 byte pin = pins[sequenceId];
6 JMirtoRobotOverTCP robot = new JMirtoRobotOverTCP(”192.168.0.1”); 37 pinMode(pin, OUTPUT);
7 // Additional code to set up pins goes here 38 digitalWrite (pin, LOW);
AC

8 // [...] 39 delayMicroseconds(4);
9 while (true) { 40 digitalWrite (pin, HIGH);
10 int leftIR = robot.getIR(2); 41 delayMicroseconds(10);
11 int middleIR = robot.getIR(1); 42 digitalWrite (pin, LOW);
12 int rightIR = robot.getIR(0); 43 pinMode(pin, INPUT);
13 44 long duration = pulseIn(pin, HIGH, MAX DURATION);
14 // computeError is a method to compute the current error as 45 int cm = (duration / 29) / 2;
15 // described above. 46 return cm;
16 curError = computeError(leftIR,middleIR,rightIR ); 47 }
17
18 // computeCorrectionLeft and Right computes the correct speed for This code implements the class asipDistanceClass, ex-
19 // each motor using the coefficient described above
20 speedLeft = computeCorrectionLeft(curError,Kp,Ki,Kd); tending asipServiceClass. As a result, the class inherits a
21 speedRight = computeCorrectionRight(curError,Kp,Ki,Kd); number of methods required to communicate over a stream etc.,
22
23 robot.setMotors(speedLeft,speedRight); and it only needs to implement the actual service to be deliv-
24 } ered. Concretely, in Listing 3 this means defining a unique ID
25 }
26 } for the service (used in the constructor at line 4) and defining
13
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 14

the commands that can be sent to the service in the method • a communication and network architecture that can be
processRequestMsg, as exemplified at line 18 where the dis- based on direct serial (USB) links, TCP sockets, and
tance service implements a response to the command ’M’ by MQTT publish/subscribe messaging.
calling method reportValues which, in turn (line 27) calls
the private method getDistance. This private method (lines We have provided a concrete implementation for Arduino
31 to 47) is the method that implements the actual service and micro-controllers and libraries for a range of programming lan-
in the case of other services it may employ specific libraries guages. All our source code has been released as open source.
for a service, such as for controlling wheels. By compiling this We have performed an extensive assessment of the performance
code and uploading it to the micro-controller it is now possible of the ASIP infrastructure using Java and Python clients both
to send ASIP messages of the form D,M: these will be captured direct serial connections and over networked connections. The
by the processRequestMsg method that, in turn, will gener- results obtained are very encouraging and show that latency and
ate a response of the form @D,e,1,{0:42} meaning that this is throughput are adequate for controlling precise navigation of a

T
a message from a Distance service reporting a distance event; robot over a wireless network. Besides performance considera-
there is only one distance sensor attached and that its current tion, we have provided a qualitative evaluation showing how ap-

IP
reading is 42 cm. Additional sensors can be added without any plications can be developed by exploiting the existing libraries
modification of the code, see line 26 in Listing 3. using only a few lines of code and delegating the communi-
Typically, clients are extended to support the new ser- cation and coordination issues among microcontrollers to the

CR
vices deployed on the micro-controller. As an example, underlying ASIP infrastructure.
Listing 4 shows excerpts from the Java client for the dis- For the future, we are currently working on the implemen-
tance service described above. The full code is available in tation of ASIP bridges based on the ESP8266 chip. While this
the file DistanceService.java at https://github.com/ paper has focussed on the practical implementation for Arduino
fraimondi/java-asip.
Listing 4: Java client for the distance service (excerpts)
1 public class DistanceService implements AsipService {
US micro-controllers, we remark that the service model described
is independent from the actual micro-controller hardware. The
only requirement is that the micro-controller should support a
communication stream and support execution loops.
AN
2
3 private char serviceID = ’D’; From a system and software engineering point of view we
4 // This is the last measured distance (−1 if not initialised ) consider this work a first step in the direction of model-based
5 private int lastDistance;
6 // [...] development for complex applications involving multiple micro-
7 controllers. Our aim is to enable automatic code generation
8 public void requestDistance() {
M

9 this.asip.getAsipWriter (). write (this.serviceID+”,”+’M’+”\n”); from our service model, working in the direction of verification
10 } and certification activities for complex domains [55].
11 // [...]
12
13 public void processResponse(String message) {
ED

14 if (message.charAt(3) == DISTANCE EVENT) { References

15 String distances = message.substring(message.indexOf(”{”)+1,
16 message.indexOf(”}”)); [1] L. Atzori, A. Iera, G. Morabito, The internet of things: A survey, Com-
17 this.lastDistance = Integer .parseInt(distances. split ( ” , ” )[ this.distanceID ]);
puter networks 54 (15) (2010) 2787–2805.
18 }
19 } [2] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, D. Savio, Interacting with
PT

20 } the soa-based internet of things: Discovery, query, selection, and on-

demand provisioning of web services, Services Computing, IEEE Trans-
As in the case of the code running on the micro-controller, actions on 3 (3) (2010) 223–235.
the Java class extends a superclass that provides most of the [3] D. Guinard, V. Trifa, F. Mattern, E. Wilde, From the internet of things to
the web of things: Resource-oriented architecture and best practices, in:
methods already. The new subclass only needs to implement the
CE

Architecting the Internet of Things, Springer, 2011, pp. 97–129.

method to process responses, see line 15. This new class is then [4] Z. Sheng, S. Yang, Y. Yu, A. Vasilakos, J. Mccann, K. Leung, A survey
ready to be used in conjunction with ASIP applications. Notice on the ietf protocol suite for the internet of things: Standards, challenges,
how the developer only needs to implement the specific feature and opportunities, Wireless Communications, IEEE 20 (6) (2013) 91–98.
[5] J. Kim, J. Lee, J. Kim, J. Yun, M2m service platforms: survey, issues,
AC

of a service and can re-use all the networking infrastructure. and enabling technologies, Communications Surveys & Tutorials, IEEE
16 (1) (2014) 61–76.
[6] Cosm, accessed: 2016-01-29.
6. Conclusion URL https://cosm.com
[7] Thingspeak, accessed: 2016-01-29.
In this paper we have introduced the Arduino Service Inter- URL https://www.thingspeak.com/
face Programming model (ASIP). This is an infrastructure that [8] Nimbits, accessed: 2016-01-29.
comprises: URL https://www.nimbits.com/
[9] Evrythng, accessed: 2016-01-29.
• a software architecture to manage micro-controllers as URL http://evrythng.com/
[10] Oneplatform by exosite, accessed: 2016-01-29.
clients of higher-level languages;
URL http://exosite.com/
[11] Axeda platform, accessed: 2016-01-29.
• a language for messages exchanged over a range of URL http://www.axeda.com/
communication channels between micro-controllers and [12] Sensorcloud, accessed: 2016-01-29.
clients; URL http://www.sensorcloud.com/
14
 ACCEPTED MANUSCRIPT

/ Computer Communications 00 (2016) 1–15 15

[13] Neuaer, accessed: 2016-01-29. URL http://mbed.org/

URL http://www.neuaer.com/ [36] nanode, accessed: 2016-01-29.
[14] idigi device cloud, accessed: 2016-01-29. URL http://www.nanode.eu/
URL http://www.digi.com/ [37] Lilypad arduino main board, accessed: 2016-01-29.
[15] W. Colitti, K. Steenhaut, N. De Caro, B. Buta, V. Dobrota, Rest enabled URL https://www.arduino.cc/en/Main/
wireless sensor networks for seamless integration with web applications, ArduinoBoardLilyPad/
in: Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th Interna- [38] H. G. Cerqueira Ferreira, E. Dias Canedo, R. T. De Sousa, Iot architec-
tional Conference on, IEEE, 2011, pp. 867–872. ture to enable intercommunication through rest api and upnp using ip,
[16] Z. Shelby, K. Hartke, C. Bormann, The constrained application protocol zigbee and arduino, in: Wireless and Mobile Computing, Networking and
(coap). Communications (WiMob), 2013 IEEE 9th International Conference on,
[17] Sensinode, accessed: 2016-01-29. IEEE, 2013, pp. 53–60.
URL http://www.sensinode.com/ [39] P. Barsocchi, E. Ferro, F. Palumbo, F. Potorti, Smart meter led probe for
[18] M. Collina, G. E. Corazza, A. Vanelli-Coralli, Introducing the qest bro- real-time appliance load monitoring, in: SENSORS, 2014 IEEE, IEEE,
ker: Scaling the iot by bridging mqtt and rest, in: Personal Indoor and 2014, pp. 1451–1454.
Mobile Radio Communications (PIMRC), 2012 IEEE 23rd International [40] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, M. Ayyash,

T
Symposium on, IEEE, 2012, pp. 36–41. Internet of things: A survey on enabling technologies, protocols, and
[19] P. T. Eugster, P. A. Felber, R. Guerraoui, A.-M. Kermarrec, The many applications, Communications Surveys & Tutorials, IEEE 17 (4) (2015)
2347–2376.

IP
faces of publish/subscribe, ACM Computing Surveys (CSUR) 35 (2)
(2003) 114–131. [41] D. Thangavel, X. Ma, A. Valera, H.-X. Tan, C. K.-Y. Tan, Performance
[20] T. Sheltami, A. Al-Roubaiey, A. Mahmoud, E. Shakshuki, A publish/sub- evaluation of mqtt and coap via a common middleware, in: Intelligent
scribe middleware cost in wireless sensor networks: A review and case Sensors, Sensor Networks and Information Processing (ISSNIP), 2014

CR
study, in: Electrical and Computer Engineering (CCECE), 2015 IEEE IEEE Ninth International Conference on, IEEE, 2014, pp. 1–6.
28th Canadian Conference on, IEEE, 2015, pp. 1356–1363. [42] W. Colitti, K. Steenhaut, N. De Caro, B. Buta, V. Dobrota, Evaluation of
[21] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, F. Silva, Di- constrained application protocol for wireless sensor networks, in: Local
rected diffusion for wireless sensor networking, IEEE/ACM Transactions & Metropolitan Area Networks (LANMAN), 2011 18th IEEE Workshop
on Networking (ToN) 11 (1) (2003) 2–16. on, IEEE, 2011, pp. 1–6.
[22] E. Souto, G. Guimarães, G. Vasconcelos, M. Vieira, N. Rosa, C. Ferraz,
J. Kelner, Mires: a publish/subscribe middleware for sensor networks,
Personal and Ubiquitous Computing 10 (1) (2006) 37–44.
[23] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,
US
D. Gay, J. Hill, M. Welsh, E. Brewer, et al., Tinyos: An operating system
[43] S. Nicholas, Power profiling: Https long polling vs. mqtt with ssl, on
android, accessed: 2016-01-29.
URL http://stephendnicholas.com/archives/1217/
[44] H. W. Chen, F. J. Lin, Converging mqtt resources in etsi standards based
m2m platform, in: Internet of Things (iThings), 2014 IEEE International
AN
for sensor networks, in: Ambient intelligence, Springer, 2005, pp. 115– Conference on, and Green Computing and Communications (GreenCom),
148. IEEE and Cyber, Physical and Social Computing (CPSCom), IEEE,
[24] J.-H. Hauer, V. Handziski, A. Köpke, A. Willig, A. Wolisz, A compo- IEEE, 2014, pp. 292–295.
nent framework for content-based publish/subscribe in sensor networks, [45] P. Derler, E. Lee, A. S. Vincentelli, et al., Modeling cyber–physical sys-
in: Wireless Sensor Networks, Springer, 2008, pp. 369–385. tems, Proceedings of the IEEE 100 (1) (2012) 13–28.
[25] O. OMG, Data distribution service for real-time systems, Tech. rep., [46] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler,
M

Technical Report OMG Available Specification formal/07-01-01, OMG A. Y. Ng, Ros: an open-source robot operating system, in: ICRA work-
(2006). shop on open source software, Vol. 3, 2009, p. 5.
[26] P. Boonma, J. Suzuki, Self-configurable publish/subscribe middleware for [47] H.-C. Steiner, Firmata: Towards making microcontrollers act like exten-
wireless sensor networks, in: Proceedings of the th IEEE Conference on sions of the computer, in: New Interfaces for Musical Expression, 2009,
ED

Consumer Communications and Networking Conference (CCNC), pp.–, pp. 125–130.

IEEE Press, 2009. [48] Particle (formerly spark) — build your internet of things, accessed: 2016-
[27] A. Castellani, N. Bui, P. Casari, M. Rossi, Z. Shelby, M. Zorzi, Archi- 01-29.
tecture and protocols for the internet of things: A case study, in: Per- URL https://www.particle.io/
vasive Computing and Communications Workshops (PERCOM Work- [49] F. Palumbo, J. Ullberg, A. Štimec, F. Furfari, L. Karlsson, S. Coradeschi,
PT

shops), 2010 8th IEEE International Conference on, IEEE, 2010, pp. 678– Sensor network infrastructure for a home care monitoring system, Sensors
683. 14 (3) (2014) 3833–3860.
[28] Q. Zhu, R. Wang, Q. Chen, Y. Liu, W. Qin, Iot gateway: Bridgingwire- [50] F. Palumbo, P. Barsocchi, F. Furfari, E. Ferro, Aal middleware infrastruc-
less sensor networks into internet of things, in: Embedded and Ubiqui- ture for green bed activity monitoring, Journal of Sensors 2013.
tous Computing (EUC), 2010 IEEE/IFIP 8th International Conference on, [51] F. Palumbo, D. La Rosa, S. Chessa, Gp-m: Mobile middleware infras-
CE

IEEE, 2010, pp. 347–352. tructure for ambient assisted living, in: Computers and Communication
[29] U. Hunkeler, H. L. Truong, A. Stanford-Clark, Mqtt-sa publish/subscribe (ISCC), 2014 IEEE Symposium on, IEEE, 2014, pp. 1–6.
protocol for wireless sensor networks, in: Communication systems soft- [52] P. Barsocchi, E. Ferro, L. Fortunati, F. Mavilia, F. Palumbo, Ems@
ware and middleware and workshops, 2008. comsware 2008. 3rd interna- cnr: An energy monitoring sensor network infrastructure for in-building
tional conference on, IEEE, 2008, pp. 791–798. location-based services, in: High Performance Computing & Simulation
AC

[30] M. Franklin, S. Zdonik, data in your face: push technology in perspective, (HPCS), 2014 International Conference on, IEEE, 2014, pp. 857–862.
in: ACM SIGMOD Record, Vol. 27, ACM, 1998, pp. 516–519. [53] K. H. Ang, G. Chong, Y. Li, Pid control system analysis, design, and
[31] A. Stanford-Clark, H. L. Truong, Mqtt for sensor networks (mqtt-sn) pro- technology, Control Systems Technology, IEEE Transactions on 13 (4)
tocol specification (2013). (2005) 559–576. doi:10.1109/TCST.2005.847331.
[32] iobridge - connect things, accessed: 2016-01-29. [54] K. Androutsopoulos, N. Gorogiannis, M. J. Loomes, M. Margolis,
URL http://iobridge.com/ G. Primiero, F. Raimondi, P. Varsani, N. Weldin, A. Zivanovic, A Racket-
[33] Lord sensing microstrain, accessed: 2016-01-29. based robot to teach first-year computer science, in: 7th European Lisp
URL http://www.microstrain.com/ Symposium, 2014, pp. 54–61.
[34] Arduino, accessed: 2016-01-29. URL http://eprints.mdx.ac.uk/14027/
URL http://www.arduino.cc/ [55] RTCA, DO-178C, software considerations in airborne systems and equip-
[35] Armmbed, accessed: 2016-01-29. ment certification (2011).

15