MedicineLakex

 

Untitled

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 Architecture for Uniform (Re)Configuration and Processing Over Embedded Sensor and Actuator Networks José Cecilio and Pedro Furtado Abstract—Deployment of embedded systems in industrial
the world involve programming every detail of processing and environments requires preconfiguration for operation, and, in
communication by hand, both within the WSN and outside of it.
some contexts, easy reconfiguration capabilities are also desir-
With our proposed MidSN middleware, standard components able. It is therefore useful to define a mechanism for embedded
and formats are designed, and anyone (e.g., control engineers devices that will operate in sensor and actuator networks to be
remotely (re)configured and to have flexible computation capa-
from the site without any specialized knowledge on program- bilities. We propose such a configuration, reconfiguration, and
ming the heterogeneous systems) can deploy node software and processing mechanism in the form of a software architecture.
the server-side configuration user interface, requiring only basic A node component should be deployed in any embedded device
instructions. Then, without ever programming a single line of and implements application programming interface (API), con-
code, the system can be used. With this architecture, the only figuration, processing, and communication. The resulting system
provides remote configuration and processing of data in any node
programming that is necessary is by "driver suppliers" to de- in a most flexible way, since every node has the same uniform API,
velop the node component for a specific platform that may come processing, and access functionalities. The experimental section
to life, but this is done only once for each new operating system.
shows a working deployment of this concept in an industrial
An important research issue in that context is how to provide refinery setting, as part of the EU FP7 project Ginseng.
interoperability between different nodes and provide a single Index Terms—Adaptable, embedded devices, (re)configuration,
configuration and data processing model in that kind of systems software architecture, wireless sensor and actuator network
that handles different realizations.
Our work aims at designing a well-defined architecture for simply deploying and configuring the servers and embeddeddevices with operations at the beginning of deployment, pro- viding configuration flexibility prior to operation through re- dreds or thousands of sensors and actuators which au- completely static and node-specific code into each device. In- tomate monitoring and control functionalities. About a decade stead, simple configuration commands are issued remotely over ago, industry suppliers started deploying wireless sensor and ac- tuation solutions, which are easier to deploy and less costly than The remainder of this paper is organized as follows. Section II totally cabled ones.
discusses related work concerning strategies to configure and The inclusion of embedded devices (the mote) in industrial program sensor network devices and to connect those to ex- control and monitor applications provides flexibility and cost ternal applications/internet. In Section III requirements needed savings when compared with entirely cabled deployments. In for WSN industrial applications are specified. Section IV de- industrial setups, there will typically coexist wired sensors, scribes the proposed architecture. It explains how the architec- wireless sensor networks (WSNs), and wired backbone nodes, ture achieves remote easy (re)configuration and processing flex- forming a heterogeneous programmable distributed system.
ibility of any embedded systems. Section V shows an example Typically, from the user's point of view, a networked con- of practical implementation and results obtained from an oil re- trol system with WSN subnetworks offers configuration capa- finery, where data collection, alarms, and actions must be de- bility that allow users to configure any node (including WSN fined over the devices to prevent accidents. Finally, Section VI nodes in subnetworks) and to configure operations in the whole concludes the paper.
system. From the point of view of engineers, developing theheterogeneous systems that include WSN nodes and the rest of The approach proposed in this paper provides configuration/ Manuscript received September 20, 2011; revised December 27, 2011, reconfiguration capabilities for embedded devices such as WSN August 15, 2012, January 08, 2013; accepted May 06, 2013. Date of pub- motes. With it, distributed sensor and actuator networks can be lication May 14, 2013; date of current version December 12, 2014. Paper managed without any custom programming, using only simple no. TII-11-548.
The authors are with the Department of Informatics Engineering, Univer- configuration commands. Related work includes strategies to sity of Coimbra, Coimbra 3030-290, Portugal (e-mail: [email protected]; configure and program sensor network devices and to connect those to external applications/internet.
Color versions of one or more of the figures in this paper are available online In the literature, there exist several works that address recon- Digital Object Identifier 10.1109/TII.2013.2262944 figuration. Several research groups have explored the benefits 1551-3203 2013 IEEE IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 of HW reconfiguration by designing ad hoc reconfigurable de- Concerning programming—typically the dynamic upload vices prepared to be adapted to a set of prerecorded applications approaches are targeted a configuring a single WSN (e.g., [5], [16]. Traditionally, reconfigurable devices are based on TinyOS), while our approach configures heterogeneous mixed complex programmable logic (CPLDs) or field-programmable WSN–non-WSN environments; many dynamic uploading gate arrays (FPGAs) that have capabilities to adapt to hardware approaches also concentrate only on the technical uploading changes. However, those are mostly targeted at hardware optimization issues, but the user needs to develop the code for changes and do not offer the application configuration flexi- the nodes. Therefore, this requires expertise in the program- bility that our approach does. Computational solutions provide ming languages of the platforms involved, plus developing the necessary flexibility to adapt to industrial process changes.
the code by hand for the portion outside of the WSN and the Over-the-air programming and dynamic software updating interconnections. It is also a lengthy and buggy process (since over WSNs was surveyed in [18] and [19]. Such mechanisms the programmer will be coding multiple nodes in a distributed allow reconfiguring the nodes without physically removing system that needs to interact correctly). In comparison, our them from the deployment site, programming them, and putting approach only requires users to specify operation configuration them back into the site. We next review some recent works on commands with no further programming, and the application the subject, and then we reach conclusions on the comparison programming interface (API is available for external applica- with our approach.
tions to use directly.
Some recent works on dynamic uploading and over-the-air Approaches such as IrisNet [11] or GSN [7] are configura- programming include [1] and [8]–[10]. In [1], [8], and [9], tion-based solutions to connect sensor input to the internet, how- the authors consider over-the-air approaches based on rateless ever those do not allow configuring functionality within sensor codes, which significantly improves over-the-air programming network WSNs, since they are only focused on wrapping data by drastically reducing the need for packet rebroadcasting. The coming from sensor sources for sharing and processing over the work in [1] proposes a design and implementation based on two rateless protocols, rateless Deluge and ACKless Deluge.
Finally, there are some middleware works that address re- They tested the approach and show that it saves a significant configuration of a WSN using software, but they are for a spe- amount of communication over regular Deluge. The work in [8] cific operating system, typically built on top of TinyOS, and proposes an approach called SYNAPSE, which was designed are restricted to configuring processing within the WSN only.
to improve the efficiency of the error recovery phase. The work TinyDB [17] is a query processing middleware system based described in [9] refers to a new design of a boot loader which on TinyOS. TinyDB approach treats the sensor network as a allows, at runtime, switching between SYNAPSE++ and any virtual database. Each sensor node contains a tiny database, of the disseminated applications.
and this database is queried by using SQL like query language The authors of [10] discuss the dissemination time. They pro- called Tiny SQL. Agilla [4] is the "first mobile agent middle- posed to reduce the time and energy consumption through com- ware for WSNs that is implemented entirely in TinyOS". It has pression. Several compression algorithms are studied and com- a stack-based architecture which reduces code size. Up to four pared in the paper.
agents are supported on a single sensor node.
Over-the-air approaches related with Macro-programming TinyLime [14] is implemented based on TinyOS exploiting and middleware are proposed in [2], [3], [12], [13]. These ap- Crossbow's Mote platform. TinyLime follows an abstraction proaches typically use a middleware to reprogram the network.
model based on shared tuple space, which contains sensed data.
Most consist of mobile agents which run over virtual machines.
It supports data aggregation.
They receive agents over-the-air, and can put them to run over None of these works handles the distributed configuration the middleware. Typically, the agent code is generated by spe- issue that we address in this paper. With MidSN, standard com- cific frameworks. Specific communication protocols are also ponents and formats exist that are followed by any node, and, developed to upload the code. For instance, the approach in in order to deploy a system, either on-site control engineers or [13] is based on a tiny communication-centric virtual machine.
system supplier engineers simply deploy node component soft- The goal is to develop very short code to reduce the energy cost ware for each platform without programming.
of transmitting new programs.
Generically, over-the-air programming approaches offer code III. REQUIREMENTS flexibility, but they have relevant differences when compared The design of the approach, labeled MidSN, started from the with our proposal.
definition of several functional requirements: data processing, Concerning performance and simplicity—in spite of all opti- configuration, user operations, and nonfunctional requirements, mizations, there is a significant time overhead associated with such as interoperability, adaptability, and performance, which dynamically loading the code or code fragments, and there are are detailed in here.
usually specific dynamic upload protocol requirements, while • Data acquisition and processing: Data acquisition is cen-
our approach is very fast. For instance, our testbed is able to tral to WSN management architecture. Data have to be ac- (re)configure one or many nodes by sending simple commands quired and stored in the first place. Then, it needs to be through three 10-ms downstream slots (one per tree level) that processed (e.g., format adaptation, filtering), transferred, were made available in the preplanned schedule-based TDMA; further processed or merged and delivered to users.
the fact that our approach fits nicely into any runtime environ- • System configuration and Adaptability: Network pa-
ment and requires no complex specific extra code updating pro- rameters (e.g., sample time for data acquisition and tocols and related structures is a positive point for simplicity.
sending period) have to be configured in order to perform

CECILIO AND FURTADO: ARCHITECTURE FOR UNIFORM (RE)CONFIGURATION AND PROCESSING OVER WSANs Fig. 1. Network structure.
Fig. 2. MidSN architecture.
the monitoring of the environment. Alarm thresholds andactuations also need to be configured for measurements the sensor network, including any PC and any type of computa- performed by nodes.
tion-capable node.
• Users: Different classes of users, with different knowl-
The architecture works on top of a network communication edge, have to be considered. The proposed architecture infrastructure that is used to exchange data messages between must be simple to be managed by experts or nonexperts.
nodes, send configuration commands to nodes (nodes have a All of them should be able to configure system parameters MidSN-NC) and send acknowledgements from them.
and access node's data.
Node interactions are based on a small set of primitives: user • Interoperability: the architecture should make different
configuration requests are routed to the appropriate node(s) in sensor networks and different applications interoperate the form of command messages that will configure node func- transparently. All nodes have to be provided with standard tionality; messages (which specify a type) are also used to send interfaces to access the data (different nodes have to be alarms, actuation values, and notifications from and to nodes; abstracted and accessed in the same way using a common streams are used to collect sensed data, to compute and filter that data, and to exchange resulting data between nodes.
• Performance: Response time has to be bounded, and there
In Fig. 2, flow (1) labeled "Sensor Data" represents sensor must be the possibility to reconfigure due to timing require- data flows. These can be to/from any two MidSN nodes. The ments, in order to make the use of the architecture in indus- flow (2), labeled "Config Command and Ack," represents com- trial scenarios (factories/refineries).
mands that are sent through the network layer by the MidSN re- • Contention avoidance: In industrial settings, there should
mote configuration component (MidSN-RConfig) to configure be performance guarantees. Industrial standards, such as nodes, and the acknowledgement reply. This component allows WirelessHart [6], or alternative ones such as the MAC to (re)configure any node in the network. User configurations layer protocol developed under the Ginseng project will translate into command packets that are sent to nodes, gen- (GinMac [15]), apply scheduled-based protocols. These erating configuration commands flows. When a command is re- replace contention-based schemes, therefore eliminating ceived by a node, an acknowledgement is generated and it is collisions, overhearing, and idle listening.
sent to MidSN-RConfig.
Outside applications and configuration user interfaces access IV. MIDSN ARCHITECTURE the MidSN-RConfig component through an API provided by Here, we describe the architecture that provides the remote that component. The external applications submit calls to the (re)configuration and processing capabilities to any embedded API, which provides configuration-related calls. It also provides device and to the distributed system comprising embedded de- data subscription services, whereby external applications sub- vices and other computing devices. The proposed architecture scribe to streams to receive the data coming from somewhere builds an intermediate computing layer which will serve as an in the networked system. In Fig. 2, API calls are represented by abstraction hiding the different hardware implementations from flow (3), labeled as "API Config calls." embedded devices networked applications.
We assume an extensible architecture, where there are a basic It assumes a networked distributed monitoring and actua- set of configuration commands and operations, but it is possible tion context, in which nodes can be completely heterogeneous.
to add other types of commands and operations to fit the context For instance, it may include resource-constrained sensor nodes, requirements, by adding functionality to modules in the system.
such as embedded devices, and more powerful nodes such as In the following sub-sections we detail the node component PCs or servers, as shown in Fig. 1. In this model, PCs are not (MidSN-NC) and the MidSN-RConfig component.
just data sinks but may fully participate in the distributed com-putation environment.
A. Node Component Architecture The system in Fig. 1 has three different WSN (sub-) networks, The node component (MidSN-NC) provides uniform node however, the architecture allows outside applications and users configuration and processing capabilities over heterogeneous to see and use the system as a single, coherent distributed sensor, distributed sensor and actuator networks. It must be developed actuator, and computing system.
only once for each hardware and/or operating-system and of- Fig. 2 shows the MidSN architecture. MidSN defines a node fers functionality to allow any node to be configured remotely component (MidSN-NC) that must be included in all nodes of for the same operations.

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 Fig. 3. MidSN-NC modules.
Fig. 4. Timer events flowchart.
MidSN can be developed for hardware with at least a cer- tain number of features. The minimum requirements to run itare: a programmable micro-controller; a communication stackfor data exchange (wired or wireless); enough ROM memoryto hold the MidSN-NC software component—for our TelosB Fig. 5. Configuration example.
implementation the ihex image occupied 30 KB, of which theMidSN-NC part occupied approximately 4 KB, and the rest wasoperating system. The amount of RAM needed is configurable, from either the hardware adapter or from other node(s), it can since it depends on the number of operation-related structures send an actuation to the HW Adapter.
that are allowed (we used 3 K in TelosB). Sensing nodes must MidSN-NC operation is based on timer and network events.
also have ADCs to connect to sensors and actuators need DACs When a timer event arrives, it is processed as depicted in Fig. 4.
to interface with external hardware.
There are three main types of timer events in our prototype Fig. 3 shows the MidSN-NC architecture.
(these can be extended depending on application context re- The MidSN-NC runs at application level and has a set of quirements), corresponding to the flows in Fig. 4, and they are modules that provide communication capabilities, whereby the
node will be able to exchange messages with any other node in • Acquisition: triggers acquisition of sensor signals.
the system, data collector and processor capabilities, whereby
• Computation: computes from data that is in memory. For the node will be able to look and compute on data it collects instance, to compute averages or maximum values, to filter from either sensors or other nodes, to take decisions and to data, to raise alarms, to merge data from streams.
route data, acquisition capabilities, whereby sensor nodes will
• Send: sends data (streams or alarms) to other nodes or ex- be able to periodically acquire sensing values or issue actuation commands (e.g., WSN motes connected to wired analog sensor Network events are messages that arrive through the network cables through DACs and ADCs), and configuration manage-
interface. A parser identifies the type of the message, which ment, whereby nodes will be able to configure themselves based may be either a configuration command or a data message.
on commands provided by other nodes or servers. With this Data message—If the message is a data message (a data
component, nodes are capable of, for instance, raising alarms, stream), then the data is sent to the Data Collector module for issuing actuations, or computing simple measures such as aver- storage and operation.
ages or maximum values for use in alarm or actuation function- Configuration command—If the message is a configuration
alities or to send to other nodes.
command, then the node is configured to operate accordingly.
Fig. 3 also shows the flows/interactions between compo- There are two major configuration command types: nents. Incoming messages are delivered by the I/O adapter • Node Operation: commands that configure the node, such to the Config. Manager module [flow (1)]. This module will as start, stop, reboot, ping, node status, loading and un- analyze the message and choose two possible operations: 1) loading controllers, and actuation commands. Actuation if the message is a configuration command, it will configure commands are commands that order a node to write a value some functionality of the node and 2) if the message is a data to a hardware actuator (DAC).
message, it will send the data to the destination module (Data • Configuration of periodical operations—Streams, Alarms Collector, HW Adapter or both) [flow (2)]. Flow (3) represents and Conditional Actuation: commands that configure indi- data that is to be sent to other nodes (e.g., a stream periodically vidual data streams, alarms and condition-based actions to sends data from the node to another node). Flow (4) represents operate. Fig. 5 shows an example of configuration.
both sensed data going to the data collector module and ac- Configuration of periodical operations sets up operation tuation commands (sensor and value) going to the hardware structures, that is, structures that keep information for timer events to know what to do when they are triggered. Those When the data is collected by the HW Adapter, it is sent to the structures keep the following information: Data Collector for storage and processing. If closed-loop con- • Structure type—this refers to whether the structure is a
trol is configured, after the data collector processes data coming data stream, an alarm, or a conditional periodic actuation.

CECILIO AND FURTADO: ARCHITECTURE FOR UNIFORM (RE)CONFIGURATION AND PROCESSING OVER WSANs • Sensor acquisitions and periodicity—this refers to which
sensor is to be acquired and with what periodicity. As aconsequence, the module also configures a timer event re-lated to acquisition (data stream).
• Send values (select)—this specifies what values the
stream should send to other nodes requesting the data.
Fig. 6. MidSN-NC drivers.
• Stream window size, operations and filters—this config-
ures the stream data window size and operations that thestream should implement, such as computing an averageor a maximum over a window of size 10.
• Alarm condition (where) and periodicity—this config-
ures the threshold and condition for an alarm, and conditionevaluation periodicity. The condition is tested periodicallyand an alarm message is sent to specified nodes when analarm is raised.
• Actuation based on a condition (where)—this configures
an actuation based on a condition. The command specifies Fig. 7. MidSN-RConfig modules.
a periodicity, a threshold and condition for the actuationand also an actuation value. The condition is tested period- The Acquisition driver must be present in nodes doing
ically and an actuation done if the condition is true.
sensing. It performs all sensor actions required to gather data MidSN-NC includes a Data Collector (and processing) from sensors.
module (DC), which manages data readings collected by sen- The Timer driver allows scheduling timer events. The driver
sors or received from other nodes and stores them in memory.
must offer functionalities to set, reset and stop a timer, as well The memory available for each data reading type is limited as one function to check if a timer is expired.
by a window size parameter specified during creation of the Lastly, the Memory Allocation driver is used to interface
stream. The module uses a circular window, which means that the MidSN-NC memory requirements with the operating system old readings, after the remaining window size has been filled, memory resources. This driver is composed by two functions: are overwritten by new readings.
alloc and dealloc. The alloc function allows reserving a specific The DC module uses stream structure fields to implement an size of memory to be used by MidSN-NC. The dealloc function SQL (structured query language for declarative data manage- allows releasing the unnecessary memory.
ment) and ECA (event-condition-action triplets for conditional These drivers must be developed according to the hardware processing) based approach for selecting which data and which and/or communication protocols. Each driver must be linked to operations to use and specifying which conditions (where the MidSN-NC during installation of software in a node.
clauses) should be tested against the data (conditional pro-cessing) (Fig. 5).
C. Remote Configuration Component Through the analysis of the select measures, expressed during Remote Configuration Component (MidSN-RConfig), de- configuration, DC uses the sensor data readings to compose the picted in Fig. 7, abstracts a sensor network and encapsulates stream message to send to other nodes.
network protocols by providing applications with a high-levelinterface to allow configuration and maintenance of the network B. Abstracting MidSN-NC From Operating System to satisfy the requirements of client applications.
The MidSN-NC node component was designed to be "plat- MidSN-RConfig is constructed as a set of modules that allows form and communication protocol"-independent in terms of de- dealing with configurations coming from users via API calls sign and formats, which allows the system to run over heteroge- and translates them into commands. The commands are then neous distributed platforms, with constrained embedded devices sent as messages to any destination node. Nodes reply with an as well as other computing devices.
acknowledgment as soon as they apply the command.
Since every node of systems will use the same APIs and MidSN-RConfig is composed by three main modules and the formats, they will have totally interoperability with simple catalog: an API, a configuration module, and a network adapter, deployment of the nodes. In order for MidSN-NC to run over plus a catalog to hold all information concerning nodes and different hardware and communication protocols, it needs drivers to manage files, handle different communication proto- The API provides functions for external applications to cols and sensors, as well as drivers to handle timer events and submit configuration commands and to subscribe to data memory requirements (Fig. 6).
(streams) coming from nodes.
The File system driver allows managing data log files in the
The Configuration Module is responsible for handling the node. It allows creating and deleting log files from the node, as configuration API calls and for configuring the network. It is well as adding and reading data from them.
composed by a set of functions that allows dealing with stream The Communication driver is essential to abstract the com-
configurations, network maintenance, stream subscriptions, and munication protocol. It must offer functions to open and close a peer-to-peer connection and send and receive messages (con- Stream configuration allows creating, removing, or
figuration commands and data messages from other nodes).
changing streams in any node or group of nodes in the network.

IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 Fig. 9. Layout of node placement.
(id), a global network IP, a reference to communication pro-tocol, an address for specific communication protocol, and aport used to communicate, as well as a channel reference if Fig. 8. Extract of MidSN-Catalog.
needed. As also identified in Fig. 8, the Catalog identifies nodesconnected to a gateway through a specific tag in the catalog It allows defining which sensors will be used and their sampling . If a node supports IP, the control station period, how many samples are kept per sensor, which data pro- sends a command directly to the node. Otherwise, a command is cessing technique is applied over sensor data, and which rate is sent through a gateway which does the translation of addresses.
used to send streams.
Data messages sent by nodes connected to a gateway are sent to Network maintenance allows the system to know node
the gateway, which translates between protocols.
status information. It allows knowing how many nodes arerunning, their configurations and status (e.g., battery, packet V. PROTOTYPE IMPLEMENTATION AND EVALUATION Data streams subscription allows client applications to sub-
Here, we show the system being able to configure processing scribe to data streams. The subscription interface defines the in our testbed, and some experimental results from the refinery stream id, host and port used by MidSN-NC to publish sensed deployment. We first describe the refinery setup (Section V-A); data or processing results.
in Section V-B, we show how a driver should be developed; in Closed-loop control allows engineers to configure closed-
Section V-C, we show runtime configurations and results and in loop control in WSNs. It configures any node with MidSN-NC Section V-D, we show an example of performance results from to collect data from sensors; any node in the system to collect the refinery deployment, to complement the experiments.
data from other nodes and apply a condition or controller, re-sulting in an actuation value; any node in the system to receive A. Setup Description actuation values and to actuate.
Within the context of the FP7 Ginseng project, we have de- The network adapter (NA) is an interface between the ployed an industrial testbed. The testbed is a totally planned net- MidSN-RConfig component and the network communication work (Ginseng focuses on totally planned networks with perfor- infrastructure, which allows communicating with the embedded mance guarantees). The network includes 26 embedded devices devices. This module implements and abstracts network pro- (TelosB nodes) organized hierarchically in two tree and two tocols needed to be able to communicate with all nodes in the sink nodes (PC). The setup also includes a control station that receives the sensor samples, alarm messages and allows con- Lastly, the Catalog (XML-based stored in a control station) figuring the network. All PC nodes (sinks and control station) stores information about configuration requests, subscriptions, are connected with Ethernet cable and GigaBit network adapter.
and node status. It is responsible for indexing the requests, net- Fig. 9 shows a sketch of the node placement in our setup, while work configuration, and other shared resources in the system Fig. 10 shows the real deployment.
in order to enable applications to discover what is available for We have applied GinMAC [15] over Contiki in the WSN nodes. GinMac (a schedule-based MAC) was configured with10-ms slots and one retransmission slot per node. A statictopology was assumed with 1 s of epoch length. The epoch D. Node Referencing and Heterogeneity includes an upstream slot for each node and one broadcast To handle heterogeneity, MidSN defines a gateway compo- downstream slot per tree level (all nodes of the same tree-level nent to handle parts of the distributed system that might not sup- are awaken to receive a command at the same time). This scheme allows more than one node to be configured with The Catalog (extract in Fig. 8) includes information on IPs reduced latency.
that must be routed through gateways, and the gateway is anIP node itself which implements specific communication with a B. Driver Implementation for Heterogeneity Handling non-IP subnetwork of a specific type. Each gateway implements In order to demonstrate the heterogeneity support of MidSN, two interfaces: one used to establish communication through we develop a communication driver for ContikiOS.
IP networks and the other one used to establish communication Fig. 11 shows a flowchart of the mechanism used to imple- with embedded communication protocols such as Rime or uIP.
ment the reception of messages (command configurations or In the catalog extract of Fig. 8 each MidSN node is identi- data messages) and how to indicate to the MidSN that a new . Each node includes a node identifier message arrived. This is part of the communications driver that

CECILIO AND FURTADO: ARCHITECTURE FOR UNIFORM (RE)CONFIGURATION AND PROCESSING OVER WSANs Fig. 10. Node deployment. (a) Main office. (b) Location of WSN nodes.
Fig. 12. Sensor readings and reconfigure.
Fig. 13. Alarms (sensor and control station).
Fig. 11. Driver flow chart.
From the figure, it is also possible to see that pressure samples must be developed once for each operating system, as part of started to be collected at a rate of a sample every 3 seconds after the MidSN-NC component.
the command was received by the sensor.
As shown in the figure, the communication driver must be MidSN also provides functionalities to create and manage able to continuously listen to the connection, in order to receive alarms and actions. To test those functionalities, we configured messages. Upon reception, the driver must copy the data buffer an alarm on the control station when sensor stream data is above to internal memory and notify the MidSN-NC that a new mes- a certain threshold and another alarm on a sensor node for the sage is available. After MidSN-NC receives the notification, the same effect, but with a different threshold.
I/O adapter (a module of MidSN-NC described before) uses the The fact that both parts of the system contain the same function midsn get received packet() offered by the driver to re- configuration and processing component and are directly refer- ceive the message and further analyse it.
enced by an address variable allows uniform configuration. Weprogrammed the network to sample pressure every 3 seconds C. Runtime Configurations (in order to more easily exercise the alarm thresholds, wegenerated simulated pressure values instead of reading the In order to test MidSN we have written a simple web ser- actual values).
vice client to submit commands at specific time instants and we collected data logs in the control station to analyze the modifi- cations to sampled data. With this data, we have built timeline {(PRESSURE, VALUE)}); charts to show the results.
The other command raises an alarm on the control station The following code extracts show the calls to web-service when pressure is above 9 bars: API methods issued by the configuration software to start a sensor collection stream with a 3-s sampling rate.
// create stream for reading from sensor (a) Node.createStream(AllNodes, "pressure- An alarm is also to be raised on the sensor node every time pressure goes above a value of 7 bars: 3s, {(PRESSURE, VALUE)}); // forward the stream to the control station The test ran for 30 min, and we logged all alarm occurrences Fig. 12 shows the results of these commands (only command and sample readings. After the test, we collected those alarms (a) is shown for enhanced readability).
and samples from the log and created the chart shown in Fig. 13 Line (1) represents submission of command (a) through the (we show only 2 min). The chart shows that the configura- MidSN-RConfig component, which is running in a PC. Line (2) tion worked well and the alarms are raised when the thresh- represents reception at the sensor node—the command took 400 olds are passed: above 7 bars the sensor node alarm was trig- ms to arrive at the target node. Line (3) represents processing of gered—shown in the figure by line (1)—and above 9 bars the the command to create the stream—this processing took 7 ms.
control station alarm was also raised [line (2)].
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 [6] WirelessHART Data Sheet. HART Commun. Foundation, Dec. 2011.
[Online]. Available: http://www.hartcomm.org/ [7] K. Aberer, M. Hauswirth, and A. Salehi, "The global sensor networks middleware for efficient and flexible deployment and interconnectionof sensor networks," EPFL, Tech. Rep. LSIR-REPORT-2006-006,2006.
[8] M. Rossi, N. Bui, G. Zanca, L. Stabellini, R. Crepaldi, and M. Zorzi, "SYNAPSE++: Code dissemination in wireless sensor networks usingfountain codes," IEEE Transactions on Mobile Computing, vol. 9, no.
12, pp. 1749–1765, Dec. 2010.
[9] M. Rossi, G. Zanca, L. Stabellini, R. Crepaldi, A. F. Harris, and M.
Zorzi, "Synapse: A network reprogramming protocol for wireless Fig. 14. Latencies on each part of the WSN (closed loop).
sensor networks using fountain codes," in Proc. 5th Annu. IEEECommun. Soc. Conf., 2008, pp. 188–196.
[10] N. Tsiftes, A. Dunkels, and T. Voigt, "Efficient sensor network repro- D. Example of Testbed Run Performance gramming through compression of executable modules," in Proc. 5thAnnu. IEEE Commun. Soc. Conf., 2008, pp. 359–367.
As a complement to the results shown in this section, we [11] P. B. Gibbons, B. Karp, Y. Ke, S. Nath, and S. Seshan, "IrisNet: An collected performance results from the refinery testbed. We architecture for a world-wide sensorweb," IEEE Pervasive Computing,vol. 2, no. 4, pp. 22–33, Oct. 2003.
show latency results from applying a simple closed loop (a [12] P. Wyckoff, S. W. McLaughry, T. J. Lehman, and D. A. Ford, "T sensor node in one WSN sends acquired data to the control spaces," IBM Syst. J., pp. 454–474, 1998.
station, the control station verifies a threshold periodically and [13] P. Levis and D. E. Culler, "Maté: A tiny virtual machine for sensor net- works," Architectural Support for Programming Languages and Oper- issues an actuation command into an actuation node in the ating Systems 2002.
other WSN). Fig. 14 shows the closed loop partial and total [14] P. Costa, L. Mottola, A. L. Murphy, and G. P. Picco, "Programming latencies, which includes WSN(up)—latency from sensor node wireless sensor networks with the TeenyLime middleware," in Proc. —latency from gateway to ACM/IFIP/USENIX Int. Conf. Middleware, 2007, pp. 429–449.
[15] P. Suriyachai, J. Brown, and U. Roedig, "Time-critical data delivery in control station and back to gateway and sink node, WSN(down) wireless sensor networks," in Proc. DCOSS, 2010, pp. 216–229.
to Actuator—latency to wait for down slot and to send the com- [16] E. Monmasson and M. N. Cirstea, "FPGA design methodology for in- mand through the WSN to the actuator node.
dustrial control systems—A review," IEEE Trans. Ind. Electron., vol.
54, no. 4, pp. 1824–1842, Aug. 2007.
[17] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, "TinyDB: An acquisitional query processing system for sensor net- In this paper, we proposed an architecture for easy and uni- works," ACM Trans. Database Syst., vol. 30, pp. 122–173, 2005.
[18] S. Brown and C. J. Sreenan, Updating Software in Wireless Sensor form configuration and operation over heterogeneous networks Networks: A Survey Tech. Rep. UCC-CS-2006-13-07, 2006.
comprising embedded devices and nodes such as PCs or con- [19] C.-C. Han, R. Kumar, R. Shea, and M. Srivastava, "Sensor network trol stations. The model advances the state of the art since it software update management: A survey," Int. J. Network Manag., vol.
15, pp. 283–294, 2005.
views the whole system as a distributed system and any com-puting device as a node (inside or outside of the WSN, regard-less of hardware or operating system). We have described the José Cecilio received the B.S. and M.Sc. degrees in
components and details of the architecture. Then, we used an electrical and computer engineering and the Ph.D.
degree in computer science from the University of industrial experimental testbed to show that the system is able Coimbra, Coimbra, Portugal, in 2006, 2008, and to configure both embedded devices and control stations very 2013, respectively.
easily and using exactly the same calls. From our test runs, we He is a Senior Researcher with the Centre for Informatics and Systems, University of Coimbra, extracted logs and displayed a timeline that proves correct con- Coimbra, Portugal. His main research interests are figuration of both embedded nodes and control station using the in the areas of internet of things, embedded systems, distributed systems and communication systems,with focus on embedded devices for health care, wireless networks, and vehicular networks. He actively participated in several industrial projects related with automation and robotics.
[1] A. Hagedorn, D. Starobinski, and A. Trachtenberg, "Rateless deluge: Dr. Cecilio is a licensed Professional Engineer.
Over-the-air programming of wireless sensor networks using randomlinear codes," in Proc. IEEE Int. Conf. Inf. Process. Sensor Networks,Apr. 2008, pp. 477–466.
[2] A. Rowe, M. Berges, G. Bhatia, E. Goldman, R. Rajkumar, L.
Pedro Furtado received the B.S. and M.Sc. de-
Soibelman, J. Garrett, and J. Moura, "Sensor Andrew: Large-scale grees in computer engineering, the Ph.D. degree in campus-wide sensing and actuation," IBM J. Res. Develop., vol. 1, pp.
computer science from the University of Coimbra, 1–6, 2010.
Coimbra, Portugal, in 1991, 1995, and 2000, re- [3] A. Tavakoli, A. Kansal, and S. Nath, "On-line sensing task optimization spectively, and the MBA degree from the University for shared sensors," in Proc. 9th ACM/IEEE Int. Conf. Inf. Process. in Católica Portuguesa, Lisbon, Portugal, in 2003.
Sensor Networks, Stockholm, Sweden, 2010, pp. 47–57.
He is an Assistant Professor with the University [4] C.-L. Fok, G.-C. Roman, and C. Lu, "Agilla: A mobile agent middle- of Coimbra. He has authored and coauthored more ware for self-adaptive wireless sensor networks," ACM Trans. Auton. than 100 papers published in international venues Adaptive Syst., vol. 4, no. 3, pp. 1–26, 2009, Art. 16.
and several research collaborations in both industry [5] H. Hinkelmann, P. Zipf, and M. Glesner, "Design concepts for and academia. His main research interests are mid- a dynamically reconfigurable wireless sensor node," in Proc. 1st dleware and data management in parallel and distributed systems, real-time NASA/ESA Conf. Adaptive Hardware Syst., Jun. 2006, pp. 436–441.
systems, data warehousing, and mining.

Source: http://pervasivecomputing.se/M7012E_2014/papers/P17-S04-Nyman-Architecture%20for%20Uniform%20(Re)Configuration%20and%20Processing%20Over%20Embedded%20Sensor%20and%20Actuator%20Networks.pdf