Computer Communications and Networks José Cecílio Pedro Furtado Wireless Sensors in Heterogeneous Networked Systems Configuration and Operation Middleware Computer Communications and Networks Editor A.J Sammes Centre for Forensic Computing Cranfield University Shrivenham Campus Swindon, UK www.Technicalbookspdf.com The Computer Communications and Networks series is a range of textbooks, monographs and handbooks It sets out to provide students, researchers, and nonspecialists alike with a sure grounding in current knowledge, together with comprehensible access to the latest developments in computer communications and networking Emphasis is placed on clear and explanatory styles that support a tutorial approach, so that even the most complex of topics is presented in a lucid and intelligible manner More information about this series at http://www.springer.com/series/4198 www.Technicalbookspdf.com José Cecílio • Pedro Furtado Wireless Sensors in Heterogeneous Networked Systems Configuration and Operation Middleware www.Technicalbookspdf.com José Cecílio Pedro Furtado University of Coimbra Coimbra, Portugal ISSN 1617-7975 ISBN 978-3-319-09279-9 ISBN 978-3-319-09280-5 (eBook) DOI 10.1007/978-3-319-09280-5 Springer Cham Heidelberg New York Dordrecht London Library of Congress Control Number: 2014948173 © Springer International Publishing Switzerland 2014 This work is subject to copyright All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer Permissions for use may be obtained through RightsLink at the Copyright Clearance Center Violations are liable to prosecution under the respective Copyright Law The use of general descriptive names, registered names, trademarks, service marks, etc in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made The publisher makes no warranty, express or implied, with respect to the material contained herein Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com) www.Technicalbookspdf.com Preface We live in an exciting time for lovers of lego-like sensing devices and remote operation The availability, interoperability, and price of off-the-shelf sensors and wireless sensor nodes have increased dramatically over the last years Today, anyone with a reasonable expertise in C++ and a love for lego-like technology can buy an Arduino and some sensors, go to the Internet to learn how to build and configure them, and put them to work in some simple application Wireless sensing has also been popularized in those platforms and systems More professional applications in commercial and industrial settings deploy a possibly very large number of wired and/or wireless sensors and actuators, integrate them into some information system or at least data collection computation device, configure everything to work together by extensive programming and testing, and, finally, deploy the system for operation over the years Although wired sensors form the core of many deployments in industrial settings, the use of wireless sensor devices has increased both in industrial and nonindustrial applications due to advantages concerning portability, price, and deployment ease An important future trend for the increased adoption of wireless sensor devices is the ease of deployment, configuration, and operation In the future, a distributed sensing system should be developed and deployed without programming The future should also see an increase in the number of deployments of wireless sensors, and heterogeneity is one of the characteristics of the resulting sensor networks since they will have wireless and wired components that should work together as a single entity, be configurable, and operate as a single homogeneous system This book is about middleware architectures for configuring and operating heterogeneous node platforms and whole sensor networks It reviews existing middleware proposals, advantages, and disadvantages; defines the middleware architecture that should be used to configure and operate those systems; and reports on practical prototypes and experimental results applying the best solutions for the issues that were raised Besides discussing how wireless sensors and wireless sensor networks work, some of the subjects that are thoroughly reviewed in this book and for which the v www.Technicalbookspdf.com vi Preface book is a good reference include what different solutions exist in terms of operating software, network layout and routing, application scenarios, middleware solutions, solutions for platform and communication protocol independence, and programming paradigms But the book also proposes solutions for generic middleware architecture that configures and operates sensor networks on any combination of hardware, software, platform, and communication protocols The book can be used as a reference in both introductory and advanced courses in embedded devices, and it is also very useful as a reference work for researchers and scholars alike Finally, it provides in-depth knowledge for practitioners willing to learn more about how these systems work Coimbra, Portugal José Cecílio Pedro Furtado www.Technicalbookspdf.com Contents Introduction Wireless Sensor Networks: Concepts and Components 2.1 Network Components 2.2 Hardware Platforms 2.3 Wireless Sensor Operating Software 2.3.1 TinyOS 2.3.2 SOS 2.3.3 Contiki 2.3.4 MANTIS 2.3.5 SensorOS 2.3.6 MagnetOS 2.3.7 Nano-RK 2.3.8 ERIKA 2.3.9 RETOS 2.3.10 LiteOS 2.4 Network Topologies 2.4.1 Star Topology 2.4.2 Tree Topology 2.4.3 Mesh Topology 2.4.4 Hybrid Topology 2.5 Data Models 2.6 Routing Techniques References 5 8 9 9 10 10 10 11 11 12 13 13 14 15 15 23 Application Scenarios 3.1 Industrial Monitoring and Control 3.2 Environmental Monitoring 3.3 Agriculture Applications 3.4 Smart Buildings 3.5 Warehouse Tracking 27 28 29 30 31 32 vii www.Technicalbookspdf.com viii Contents 3.6 Transport Logistics 3.7 Surveillance 3.8 Health Care References 32 33 35 36 Existing Middleware Solutions for Wireless Sensor Networks 4.1 Taxonomy of Operating Software for Wireless Sensor Data 4.2 Remote (Re)configuration Approaches 4.3 Middleware Architectures Inside the WSN 4.3.1 Database Abstractions 4.3.2 Mobile Agents 4.3.3 Virtual Machines 4.3.4 Application-Driven and Message-Oriented Middleware 4.4 Internet-Based Integration of Sensor Data 4.5 IP-Based Homogeneous Middleware References 39 40 42 47 47 48 50 Middleware Mechanisms for Heterogeneous Wireless Sensor Networks 5.1 Middleware Requirements 5.2 Architecture 5.3 Platform and Communication Protocol Independency (Drivers) 5.4 The Catalog 5.5 Node Referencing and Heterogeneity 5.6 Publish/Subscribe External Interface 5.7 Data and Processing Model 5.8 Operations 5.9 User API Middleware Implementation Details: A Case Study 6.1 Node Component Architecture 6.2 NC-Kernel 6.2.1 Communication (I/O Adapter) 6.2.2 Agent Manager (NC-Kernel-AM) 6.3 SOMApp 6.3.1 Acquisition and Actuation (NC-SOMApp-AA) 6.3.2 Configuration Management (NC-SOMApp-CM) 6.3.3 Data Collector (NC-SOMApp-DC) 6.3.4 SOM Processor (NC-SOMApp-GP) 6.3.5 Extensibility of SOMApp 6.4 Remote Configuration Component (RConfig) 6.5 Custom Code Agents Reference www.Technicalbookspdf.com 50 52 53 55 61 61 62 65 68 68 69 72 74 75 77 77 79 80 80 80 80 81 82 82 84 85 86 87 Contents ix Programming Paradigms and Stream Processing for WSN 7.1 Programming Abstractions for WSNs 7.2 Basics of High-Level Stream Processing 7.3 Language and Architectural Features 7.4 A Stream Processing Language for Heterogeneous Networks with Wireless Sensors 7.5 The Per-Node Database Management System 7.5.1 Data Storage Organization 7.5.2 Stream Relational Algebra and Algorithm 7.5.3 Constrained Group By 7.5.4 Join Algorithm References Experimental Validation of Middleware: Platforms, Performance and Related Issues 8.1 Evaluation of NC for Multiple Platforms 8.1.1 Development and Porting Between Platforms 8.1.2 Memory and Performance 8.2 Operation Processing in Constrained Devices 8.2.1 Memory Footprint 8.2.2 Performance and Energy Consumption: RAM Versus Flash 8.2.3 Data Processing Versus Lifetime 8.3 Networked Execution and Performance Evaluation 8.3.1 Experimental Setup 8.3.2 Command Configuration and Latency 8.3.3 Monitoring Operation 8.3.4 Closed Loop over Heterogeneous Devices References Appendices Appendix 1: Communication Driver: Code Example Appendix 2: User API A.2.1 Node A.2.2 Operations and Filters A.2.3 Alarms A.2.4 Actions A.2.5 Actuations A.2.6 Publish/Subscribe A.2.7 Agents 89 89 90 91 94 100 100 101 103 105 106 107 108 108 109 112 112 114 116 118 119 119 121 123 126 127 127 128 129 130 133 134 135 135 136 Index 139 www.Technicalbookspdf.com 128 Appendices Fig A.1 Implementation of the communication driver using Contiki-OS Appendix 2: User API In this appendix, we describe a specification for the user API As discussed before, this API is extensible and can include features to fit different application contexts The functionalities of the NC API described here are divided into seven categories Next, we describe each category and its calls Appendices 129 Fig A.2 Implementation of the communication driver using Java for Linux A.2.1 Node The API has a set of functionalities that allows controlling the nodes It includes primitives to activate/deactivate nodes, i.e all executions inside a node are suspended if the deactivate node call is issued to the node Besides activate/deactivate nodes, there are also primitives to activate/deactivate sensors, request node status, reset a node and ping a node 130 Appendices Table A.1 Node primitives Function Activate/deactivate nodes Activate/deactivate sensors and actuators connected to each node Request node status Reset a node Ping a node Primitive Node.run([NODE,], TRUE or FALSE); Node.Sensors.run (([NODE,], [SENSOR,], TRUE or FALSE); Node.status([NODE,]); Node.reset([NODE,]); Node.ping([NODE,]); Activate/deactivate sensors allows controlling which sensors are able to sample This allows, for instance, to save energy by switching on and off the sensors The request node status primitive allows collecting information about nodes (e.g battery, messages losses, and latencies), while the reset function resets a node and starts NC with default configurations The ping command is used to verify that a node is live and that it can communicate with another Table A.1 shows the default node primitives included in NC API All of these primitives use a list of nodes ([NODE]) as argument to identify the nodes where the operation is applied This list of nodes can include WSN nodes and/or PCs A.2.2 Operations and Filters Operations and filters functionalities allow creating operations and filters to be processed in nodes This category of API functionalities includes primitives to create operations (periodical or one time operations), activate/deactivate their execution, change the execution periodicity or delete them from nodes Each operation corresponds to data collection, processing and sending tasks according to the operation configurations It allows, for instance, collecting sensor readings, computing an average and sending the output result to other node The activate/deactivate operation execution primitives are used to suspend the execution of a stream For instance, we can use these primitives to suspend execution of an operation during maintenance and resume execution afterwards The change execution periodicity primitive allows changing the rate of an operation It is useful to allow changing only the rate instead of changing all operation configurations This category of API functionalities also includes primitives to create smoothing filters over measures, which are associated to operations Assuming an industrial environment where noise is an important issue and appears coupled to the measures, this filter allows, for instance, to reduce the influence of noise by always averaging over a set of sensed values 131 Appendices Table A.2 Operations and filters primitives Function Create operation Delete operation from node Start and stop operation execution Change operation periodicity Create data filter (where) Drop data filter Primitive Operation.create([NODE,], OP_NAME, ACQUISITION_RATE, SEND_RATE, WINDOW_SIZE, MEASURE (source, metric), CLIENT (address, port) ); Operation.drop(([NODE,], OP_NAME ); Operation.run(OP_NAME, TRUE or FALSE ); Operation.setPeriodicity( OP_NAME, NEW_RATE ); Filter.create([NODE,], FILTER_NAME, OP_NAME, CONDITION (MEASURE, operator, MEASURE) ); Filter.drop([NODE,], FILTER_NAME ); Table A.2 shows the NC API primitives concerning operations and filters Depending on the functionality, some arguments are needed to manage operations and filters For instance, the create operations call creates a stream that is processed and sent to another node or control station This primitive needs arguments such as a unique identifier, an acquisition rate, an execution rate, a list of measures that must be included into the stream and a list of client (other nodes) that will receive the stream output Each operation can be executed periodically (with a period defined through the SEND_RATE field) or one time (SEND_RATE = 0) It is also possible to create operations that only collect data and store it in the node (SEND_RATE = −1) In this case, data received by a node is stored inside it without any processing Moreover, operations have a window size parameter associated to them This value is used to limit data values used to process computations and/or to limit the number of tuple stored in the corresponding stream The stream output will be constructed based on the configured measures Each measure has a measure name (e.g temperature, humidity, light) and a metric 132 Appendices Fig A.3 Piece of code to create periodic operation and send data to the control station Fig A.4 Piece of code to collect sensor reading in control station (e.g average, maximum, minimum, percentile) Figure A.3 shows the calls to configuration web service API methods that were issued by the configuration software to start a sensor collection operation in nodes 1.1, 1.2, 1.3 with s of acquisition and sending rates Besides configuring nodes to send data readings, it is needed to configure the control station to collect it Figure A.4 shows how to configure the control station to collect the sensor readings This configuration is done automatically by the RConfig component when the configuration of Fig A.4 is called However, its configurations can be changed by the user In the example of Fig A.4, we create an operation with the identifier “pressureStreamCS” that will receive values from the stream “pressureStream” and store them until reaching the maximum number of samples, in this case 10,000 samples The fields ACQUISITION_RATE, SEND_RATE and CLIENT are filled with −1 to indicate that it is not a periodic operation with acquisition or sending parts and the values are not sent to other nodes During the lifetime of the network, we can change its configuration In the next example (Fig A.5), we will use the API to change the rate from to s, and after that, we stop the operation The following code extracts are used to perform this In some applications, the readings gathered from physical sensors may need to be filtered For instance, to reduce the influence of noise, it is possible to apply averaging over some values which is a smoothing filter over the measures Figure A.6 shows another example of how to create a filter over the pressure values In this example, we removed all values that were above bars 133 Appendices Fig A.5 Piece of code to change operation rate, stop and start the execution Fig A.6 Piece of code to create a filter Table A.3 Alarm primitives Function Create alarm Delete alarm from node Start and stop alarm verification Primitive Alarm.create ([NODE,], ALARM_NAME, OP_NAME, CONDITION (MEASURE, operator, MEASURE), CLIENT (address, port) ); Alarm.drop(ALARM_NAME); Alarm.run(ALARM_NAME, TRUE or FALSE ); A.2.3 Alarms In some applications, alarms are needed to inform a user of an imminent or occurring emergency The alarm API functionalities presented here were created to establish a configuration interface for those applications, where functionalities to create, drop, start and stop alarms were included Those alarms are based on conditions that are submitted by users Alarms are used to specify an operation that is sent each time a specific condition occurs in node(s) The condition is defined by a set of parameters such as an identifier, a condition and a list of clients that will receive the alarm values The alarm configuration includes a condition that needs to be true to send data to the clients (other nodes) Each condition is defined by two measures and one operator, where the operator can assume one of the following symbols: = It allows, for instance, creating conditions similar to avg(temperature) >30 °C Table A.3 shows the API primitives concerning alarms 134 Appendices Fig A.7 Piece of code to create an alarm Table A.4 Action primitives Function Create action Drop action Primitive Action.create([NODE,], ACTION_NAME, OP_NAME, CONDITION (MEASURE, operator, threshold), ACTUATION ( ACTUATOR_NAME, value, TARGET_NODE ) ); Action.drop(ACTION_NAME); In the next example (Fig A.7), we configure an alarm in the control station when pressure sensor data is above a certain threshold (3 bars) We also create another alarm on a sensor node 1.1 for the same effect, but with a different threshold (2 bars) A.2.4 Actions NC also provides functionalities to create and manage actions Actions are used to actuate in nodes when a specific condition occurs Each action is associated to an operation and includes a condition and an actuation The condition is defined the same way as creating an alarm The actuation is defined through the indication of an actuator, the value that the node must write to the actuator and the node address where the actuator is connected If the actuation is done in the same node, this field is filled with −1 Table A.4 shows the syntax of these functionalities Appendices 135 Fig A.8 Piece of code to create an action Table A.5 Actuation primitives Function Send and apply actuation value Primitive Actuate([NODE,], ACTUATION (ACTUATOR_NAME, ) ); Actions can be configured to prevent accidents Assuming that pressure above bars can explode a pipe, for example, we can specify an action inside a node to switch on a valve when pressure goes above bars Each action is executed every time that the corresponding operation is executed Figure A.8 shows how to configure an action to handle those specifications This example consists of evaluating (inside node 1.1) the condition over each pressure value of the stream “pressureStream” and actuating over the PIPE_VALVE (connected to the same node) if the condition is true A.2.5 Actuations NC allow users to submit actuation commands directly to each node Table A.5 shows the primitive used to submit actuation commands directly to nodes This primitive receives as arguments a list of nodes where the actuation will be performed and the actuation parameters Each actuation is defined by the actuator identifier and the value that we want to apply to the actuator A.2.6 Publish/Subscribe To interface NC with external applications, the proposed architecture includes a publish/subscribe mechanism Table A.6 shows the API primitives that allow subscribing and unsubscribing stream data The subscribe stream data function allows to subscribe stream data To a subscription, external applications need to call this function with the network address, a port where data will be received, the stream data name and the timeout used to close connection between the publisher (NC) and the external application that wants to receive stream data This function must be called for each stream data subscription Figure A.9 shows an example of using the subscription functionality Appendices 136 Table A.6 Publish/ subscribe primitives Function Subscribe data Unsubscribe data Primitive PS.subscribe(SUBSCRIBER_ADDRESS, SUBSCRIBER_RECEPTION_PORT, OP_NAME, CONNECTION_TIMEOUT ); PS.subscribe(SUBSCRIBER_ADDRESS, OP_NAME ); Fig A.9 Piece of code to subscribe stream data The example consists of a subscription to the “pressureStream” configured in Fig A.9 Upon receiving stream data, the publisher will send it to the address and port specified in the call, 10.3.1.132 and 5,000, respectively Lastly, the timeout value (60,000) is used to close the connection with the client For instance, if the connection of the nodes 1.1, 1.2, 1.3 is lost, the stream “pressureStream” will never arrive at the publish/subscribe After this timeout, the publisher will close the connection to the external application, because it is not needed Meanwhile, a new connection is opened if the stream “pressureStream” arrives at the publish/subscribe A.2.7 Agents NC also provides functionalities to receive agents over the air from users It offers functions to dynamically send agents to nodes, load an agent from flash memory and prepare it to run with default values, start/stop agents, drop an agent or change parameters used by the agent Table A.7 shows the primitives developed to manage agents in nodes Users who want to add functionalities dynamically to a node should use this set of primitives It allows, for instance, sending an agent to a node To this, users need to develop the agent code, compile it and call the “Agent.create” method This method will receive as argument the target node(s), an agent id to identify the agent and the path to the binary image code Figure A.10 shows an example of using this functionality After the binary image is loaded by nodes, the user needs to call the load and stats functions to execute the agent in the node Figure A.11 shows how to this Since we are assuming that our controller doesn’t need initial parameters, we use −1 in the field Appendices Table A.7 Agent primitives 137 Functionality Send an agent Drop agent Load agent Unload agent Start and stop agents Send parameters to agents Fig A.10 Piece of code to send an agent Fig A.11 Piece of code to load and run an agent inside a node Primitive Agent.create ([NODE,], AGENT_ID, AGENT_CODE_PATH ); Agent.drop ([NODE,], AGENT_ID ); Agent.load([NODE,], AGENT_ID ); Agent.unload([NODE,], AGENT_ID ); Agent.start([NODE,], AGENT_ID, , TRUE or FALSE ); Agent setParameters([NODE,], AGENT_ID, VALUES ); Index A Abstract, 2, 3, 11, 39, 41, 47–48, 51, 52, 54, 66, 77, 79, 85, 89–94, 108, 118 Acknowledgement, 63, 64, 85, 86 Acquisition, 47, 66, 74, 79–81, 83, 94, 101, 103, 113, 125, 131, 132 Actuation, 1, 7, 35, 54, 62, 63, 76–82, 98, 124, 125, 134, 135 Actuator, 5, 6, 28, 31, 53, 63, 68, 74, 78–81, 98, 124, 125, 130, 134, 135 Adaptable, 40, 51 Address, 16, 28, 29, 64, 68–71, 81, 86, 96, 119, 123, 127, 131, 133–136 Agent, 40, 41, 46–51, 76–81, 86–87, 113, 136–137 Aggregation, 6, 16–18, 20, 22, 30, 48–50, 53, 83, 95, 96, 102–105, 111, 112, 115 Alarm, 15, 28, 29, 31, 34, 62, 63, 73–78, 80–83, 86, 90, 91, 98, 119, 133–134 Algorithm, 7, 10, 15–21, 23, 40, 46, 52, 77, 86, 100–105, 112 Amount of memory, 102, 109, 112, 113 Analog, 6, 79 Answer, 66, 72, 91 API commands, 77, 85 Application, 1–3, 5–17, 20, 22, 27–35, 39–42, 47–54, 61–64, 68–70, 72–77, 80, 83, 85, 87, 89, 90, 92, 94, 97–99, 101, 102, 107, 108, 114, 128, 132, 133, 135, 136 adaptation, 48 level, 2, 49, 52, 53, 68, 78, 90, 93, 94 scenario, 1–3, 27–35, 61, 62, 80 Application programming interfaces (APIs), 10, 49, 50, 54, 62, 64, 65, 67, 75–76, 79, 85–87, 94–98, 113, 128–133, 135 Approach, 2, 3, 8, 10, 16, 17, 22, 39–48, 50–54, 65, 73, 80, 86, 87, 89, 90, 92, 94, 103 Architecture, 2, 3, 16, 39, 40, 47–52, 54, 61–66, 68, 69, 72, 77–79, 84–86, 107–109, 135 Asynchronous, 9, 48, 50, 51 Automatically, 10, 15, 32, 48, 51, 54, 97, 132 B Bandwidth, 7, 10, 15–17, 19, 21, 22, 30, 46 Battery, 7, 12, 14, 21, 32, 68, 103, 107, 118, 130 Behaviour, 10, 11, 27, 33, 48, 51, 62, 89, 90 Byte, 9, 50, 101, 102, 112, 114, 115 C Clauses, 73, 82, 95–98, 101, 103–105 Closed-loop, 29, 79, 81, 98, 119, 123–125 Clustering, 16–19, 21, 22, 47, 48 Code fragment, 47 Code size, 48, 52, 107, 109 Command, 2, 6, 11, 12, 15, 49, 51, 63, 64, 66, 68, 69, 72, 75, 77–82, 84–87, 91, 94–98, 100, 119–121, 124, 125, 127, 130, 135 Command message, 63, 80, 81, 86 Communication driver, 65–67, 127–129 Communication protocol, 3, 16, 46, 54, 65–69, 86, 127 Component, 1, 5–23, 33, 49–52, 54, 62–70, 77–79, 85–87, 91, 96, 107, 109, 110, 112, 114, 123, 132 © Springer International Publishing Switzerland 2014 J Cecílio, P Furtado, Wireless Sensors in Heterogeneous Networked Systems, Computer Communications and Networks, DOI 10.1007/978-3-319-09280-5 139 140 Compression algorithm, 46 Computation capabilities, 112, 118 Computation device, Computed incrementally, 112 Computer, 1, 6–8, 12, 31, 35, 39, 40, 46, 51–54, 61–64, 73, 85, 103, 108–112, 118, 119, 122 Computing layer, 77 Conditional actuation, 81, 82 Configurable, 31, 32, 42–45, 62, 68, 69, 78 Configuration, 1–3, 7, 11–13, 29, 32, 33, 40, 42–48, 54, 61–64, 66, 68, 72, 73, 75, 77, 79–82, 84–87, 96–101, 109, 115, 123, 124, 130, 132, 133 Configuration command, 63, 64, 66, 72, 75, 77, 79, 81, 84, 85, 100, 119–121 Constrained device, 2, 11, 53, 107, 109, 112–118 Contiki, 8, 9, 11, 41, 54, 68, 89, 90, 92–94, 108–110, 112–114, 116, 119, 127 Control, 1–3, 6, 11, 15, 20, 22, 28–35, 42, 45, 48, 49, 79, 81, 92, 98, 119, 123, 124 Control station, 30, 68, 69, 74, 75, 117–119, 121–125, 131, 132, 134 Critical, 9, 28, 30–32 Custom code, 77, 79, 86–87 Custom programming, D Daemon, 66, 86 Data acquisition, 7, 50, 61–62 aggregation, 17, 18, 49, 50 delivery, 16, 18 model, 15 path, processing, 1, 7, 50, 53, 61, 73, 74, 80, 82, 90, 116–118 streams, 52, 64, 69, 71, 79–81 Database, 2, 40, 41, 47–48, 51, 52, 90–93, 96, 100–105 Data-centric, 16, 48 Deadline, 10, 19, 21, 22 Debugging, 11, 46, 87 Delay, 17, 20–22, 32 Deployment, 1, 2, 16, 29, 46, 49, 51–53, 65, 89 Destination, 5, 16, 20, 46, 68, 69, 74, 79–81, 83, 85, 103 Index Developed by hand, 40, 87 Device, 1, 2, 5–7, 9, 11, 12, 32, 35, 39, 42, 49, 50, 52–54, 61–63, 65, 68, 81, 82, 85, 86, 89, 96, 107–109, 112–118, 123–125 Different hardware, 1, 3, 62, 65, 77, 107 Digital, Discover, 15, 53, 68, 86 Dissemination, 46, 50 Distributed sensing, 1, 39, 63 Distributed system, 1, 7, 47, 51, 61, 62, 64, 68, 101, 118 Driver, 3, 54, 62, 65–67, 80, 86, 108, 109, 112–114 Dynamic software updating, 46 E Easy-to-use interface, 47 Efficiency, 15, 28, 31, 46, 55 Embedded device, 7, 9, 12, 35, 52, 54, 61, 63, 65, 68, 82, 85, 86, 109 End-to-end connection, 66 End-to-end delay, 28–35 End-user level, 94 Energy, 16–23, 30, 31, 33, 41, 46–48, 107, 117, 118, 130 Energy consumption, 10, 17, 20, 32, 41, 46, 47, 50, 54, 114–117 Engine, 42, 45, 50, 54, 61, 89–91 Environment, 1, 2, 8, 10, 22, 23, 28–30, 32, 33, 39, 49, 52, 63, 100, 107, 130 Event, 8, 9, 15, 28–31, 33–35, 48–51, 54, 65, 66, 74, 81–84, 89–91, 93, 94, 98, 99, 109, 112–114 Event-driven, 8, 9, 15, 33, 50, 89, 90, 92 Exchange information, Executable, 8, 86 Extensibility, 79, 84 External applications, 64, 69, 70, 75, 83, 85, 135, 136 External client applications, 75, 85 F Fault tolerance, 14, 18–22, 27–31, 48 Features, 9, 10, 32, 76, 78–94, 128 Field, 28, 30, 73, 74, 79, 81, 82, 102, 131, 132, 134, 136 Firmware, 46, 49 Flexibility, 42, 47–49, 62, 72, 79, 93, 114 141 Index Flexible, 7, 52, 54, 62, 77, 79, 89, 90 Flow, 12, 15, 16, 18, 64, 79, 80, 83, 86, 90, 92 Footprint, 9, 50, 107, 112–114 Format, 6, 52, 61, 65, 73, 95, 96, 103 G Gateway, 3, 5, 6, 12–16, 20, 22, 49, 52, 65, 68–70, 86, 96, 108, 119, 121, 122 Guaranties, 18–20, 22 H Hand-programmed, 53, 55, 84 Hardware, 1–3, 7–8, 10, 27, 39, 42, 46, 47, 52, 54, 55, 62, 65, 67, 74, 77, 78, 80, 81, 86, 91, 107, 108 Harsh, 29 Heterogeneity, 1–3, 27–35, 39, 40, 43–46, 48, 51–53, 62, 68–69 Hierarchical, 12, 16–19, 22, 48, 49, 52, 53 Hierarchy, 13, 20 High-level, 11, 72, 89–91, 98 Homogeneous, 2, 3, 47, 52–55, 62 HTTP, 53, 54, 75, 85 I Image, 8, 9, 46, 47, 86, 87, 105, 136 Implementations, 3, 46, 49, 52–55, 66, 73, 77–87, 101, 108–110, 113, 127–129 Incoming message, 79 Independency, 3, 39, 40, 65–67 Information, 2, 5, 6, 16–18, 21, 23, 27–30, 35, 46, 47, 51–54, 68, 70, 72, 73, 80, 81, 85–87, 90, 92, 96, 99, 101, 117, 130 Information system, 1, Infrastructure, 2, 28, 33, 51–55, 63, 85 Interaction, 2, 6, 15, 51, 55, 63, 64, 79, 87, 89, 93, 94 Interface, 6, 8, 10, 13, 47–48, 51, 52, 62, 64, 67, 69–72, 75, 78, 80, 85–87, 91, 119, 121, 133, 135 Internal memory, 66 Internet, 2, 3, 7, 12, 39, 40, 42, 44, 45, 52–53, 68 Interoperability, 1, 52, 55, 61, 62, 65 J Java, 7, 50, 66, 89, 101, 108, 109, 127, 129 Java virtual machine, 50, 108 K Kernel, 8–11, 47, 78–80, 113 L Language, 2, 7, 8, 11, 47, 49, 51, 53, 66, 89–100, 108, 127 Latency, 32, 119–122, 124, 125 Leaf, 5, 6, 13, 117 Lifetime, 18–22, 27–35, 51, 62, 77, 107, 116–118, 132 Lightweight, 9, 10, 42, 45, 48, 54 Link, 5, 13, 14, 16, 17, 28, 32, 50, 80 Loadable module, Localization, 27–35 Location-based, 16, 17, 22, 30, 31, 34, 53 M Macro-programming, 40, 41, 46, 51, 89 Main memory, 80, 87, 112–116 Management, 7, 8, 16, 28, 32, 35, 40, 42, 48–50, 52, 53, 61, 81–82, 100–105 Measures, 73, 77, 78, 84, 112, 121, 130–133 Mechanism, 2, 3, 9, 11, 16, 17, 27, 40, 42, 46, 48, 50, 52, 53, 61–77, 82, 100, 107, 116, 119, 135 Memory, 7–9, 11, 46, 65–67, 71, 78, 80, 82, 87, 90, 96, 100–103, 105, 107–118, 136 Memory allocation, 8, 67 Message, 8, 9, 18, 20, 21, 50, 51, 53, 54, 63, 66, 68, 69, 73, 78–82, 85, 86, 90, 93, 94, 103, 119, 127, 130 Middleware, 1–3, 27, 39–55, 61–87, 107–127 Mobility, 1, 17, 18, 23 Modular, 10, 48, 62, 80 Monitoring, 1, 6, 15, 22, 28–31, 33–35, 39, 48, 49, 62, 98, 119, 121–122 Multi-hop, 5, 10, 14, 92, 93 N Network delay, 20, 22 layout, 3, traffic, 80 Node, 1, 5, 27, 39, 61, 77, 89, 107, 127 Notification, 50, 63, 66, 91 142 O Object-oriented language, 66, 127 Open source, 8, 9, 90 Operating software, 3, 8–11, 40–42 Operating systems, 2, 7–11, 39, 40, 43–45, 50, 51, 62, 65–68, 77, 86, 93, 108–110, 113, 114 Operation, 1, 2, 10, 12, 13, 15, 17, 22, 29, 40, 42, 49, 51–55, 61, 62, 64–66, 72, 74–84, 87, 89, 91, 97, 98, 102, 104, 107, 111–119, 121–123, 130–135 Overhead, 2, 22, 23, 47, 48, 50, 52, 54, 55, 115 Over-the-air, 40, 41, 46, 47, 49, 80, 113, 136 P Packet, 5–7, 10, 15, 21, 28, 46, 49, 64, 66, 80, 97, 102–105, 116, 127 Packet loss, 28–31 Paradigm, 3, 22, 50, 52, 70, 87, 89–105 Parameter, 29, 35, 48, 62, 65, 73, 80, 82, 101, 102, 131, 133, 135–137 Parser, 81 Performance, 15, 20, 22, 35, 47, 48, 52, 61, 62, 107–125 Period, 15, 29, 30, 46, 51, 67, 73, 74, 99, 117, 131 Periodic, 28, 30, 31, 33, 34, 74, 81, 82, 93, 94, 98, 113 Periodically, 9, 31, 51, 74, 79–82, 94, 98, 103 Periodical operations, 75, 81, 132 Periodic events, 82, 113 Persistent memory, 80 Platform, 2, 3, 5–10, 39, 42, 47, 48, 50–52, 55, 62, 65–68, 86, 89, 90, 107–125 Portability, Power, 2, 7, 9, 10, 14–18, 20, 30, 43–46, 48, 54, 55, 107, 116 Power consumption, 12, 13, 15, 54, 55 Powerful node, 63, 108 Primitive, 49, 50, 54, 63, 65–67, 109, 130, 131, 133–137 Processing, 1, 7, 15, 16, 33, 35, 46, 47, 50, 51, 53, 54, 61, 72–74, 77, 79–83, 87, 89–105, 112–118, 123, 125, 130, 131 Program, 6, 8, 9, 46–50, 61, 86, 87, 89, 108, 112, 113, 123 Programming, 1–3, 7, 8, 10, 11, 29, 40, 41, 46–52, 54, 62, 66, 85, 89–105, 110, 114, 118 Protocol, 2, 3, 6, 7, 10, 15–18, 20–23, 46–48, 50, 51, 53–55, 65–69, 85, 86, 90, 108, 127 Proxy, 53 Index Publish, 42, 49, 51, 53, 64, 69–73, 76, 80, 97, 98, 135–136 Q QoS, 16, 17, 19, 22, 51 Query, 2, 16–18, 20, 22, 47, 51–53, 72, 73, 90–92, 101–103 Query processor, 72, 90, 92, 100 R Radio link, 13, 14, 16, 50 Raise alarms, 31, 78, 83 RConfig See Remote configuration (RConfig) Reading, 3, 8, 29, 30, 65, 72, 82, 94–96, 116, 123, 130, 132 Real-time, 10, 11, 19–22, 28, 31–35, 48–51, 62 Reboot, Redundancy, 16 Relay, 5, 6, 13, 16, 22 Remote configuration (RConfig), 33, 64, 65, 70, 77, 80, 85–87, 96, 124, 132 Remotely, 31, 75, 77, 81, 85 Remote operation, 77 Reprogramming, 7, 8, 40, 46, 47, 49 Request type, 71 Requirement, 2, 3, 15, 16, 20, 22, 27–35, 47, 49, 61–62, 64, 65, 77, 78, 84, 103, 107, 114 Resource, 2, 7, 9–11, 16, 46, 48, 52, 54, 55, 67, 109, 111, 112 REST, 40, 42, 45, 53–55, 75, 85 Result, 14, 22, 48, 50, 54, 72–74, 79, 83, 84, 96, 101–103, 107, 113, 115–118, 121, 124, 125, 130 Review, 3, 27, 39, 40, 46 Route, 6, 15, 16, 20, 21, 47, 79, 97 Routing, 3, 10, 15–23, 49, 89, 93 S Scalability, 27–35, 47, 48, 54 Scarceness, 42, 111 Scheduling, 7, 9, 10, 20, 30, 48, 109 Security, 27–35 Self, 8, 14, 16, 50 Self-organization, 48 Sensing, 1–3, 7, 40, 48, 52, 66, 78–80, 108, 121, 124, 125 Sensor network, 1–3, 5–23, 27, 29, 30, 33, 39–55, 61–76, 85, 90, 92, 101, 108, 116 Service, 2, 39, 40, 48–55, 62, 64, 75, 85, 132 143 Index Sharing, 40, 42, 44, 45, 49, 53, 90, 92, 93 Single-hop, 5, 12, 93, 119 SOAP, 40, 42, 45, 53, 54 Software, 3, 4, 7–11, 27, 39–42, 46–49, 53–55, 62, 67, 78, 86, 90, 107, 132 Software reconfiguration, 40, 42 Specific platforms, 42, 52, 86 SQL, 47, 91, 92, 94–98 SQL statement, 82 Stack, 2, 9, 10, 22, 51, 53–55, 78, 87, 93, 94 Statistic results, 72 Storage, 7, 16, 32, 35, 48, 81, 82, 96, 99–101, 116 Stream operating machine, 80 processing model, 74 Structure, 50, 54, 63, 71, 73, 78, 81, 82, 94, 100, 102, 103, 108, 109 Subscribe, 49, 51, 53, 64, 69–73, 75, 76, 85, 98, 135–136 Subscriber, 50, 70, 71, 73 Synchronization, 11, 13, 27–30, 32–35, 49, 109 Synchronous, 9, 51 T Target agent, 79, 80 Taxonomy, 3, 39–42, 90 Technology, 9, 12, 33, 35, 50, 53 Template, 49, 51 Thread, 9, 11, 66, 109 Threshold, 8, 82, 134 Time critical, synchronization, 11, 13, 27–31 Tool, 8, 10, 39, 49, 116 Topology, 11–15, 23, 46, 49, 50 Translate, 3, 50, 53, 64, 68, 85 Transparently, 10, 40, 62 Trigger, 73, 74, 83, 89 Tuple, 49, 73, 82, 92, 94, 95, 97, 98, 101–105, 111, 114–117, 121, 123, 131 U Underlying, 3, 42, 52 Uniform, 47, 61, 62, 68, 77, 123 Usability, 48, 108 V Virtual machine, 10, 40, 41, 46, 47, 50, 52, 108, 109 W Web service, 2, 52–55, 75, 85, 132 Wide-span, 61, 73 Wired, 1, 3, 6, 23, 31, 33, 39, 68, 78, 79 Wired sensor, 1, 63 Wrapper, 52, 53 ... wired and wireless nodes and need to be integrated into backbone information systems The architecture and mechanisms proposed were integrated in a middleware approach demonstrated live in an oil and. .. nodes and the rest of the networked control system One involves programming every detail of processing © Springer International Publishing Switzerland 2014 J Cecílio, P Furtado, Wireless Sensors in. .. scenarios and requirements After reviewing and analysing existing middleware solutions, we define generic middleware architecture for configuration and operation The middleware architecture proposed