Table of ContentsBUILDING MANAGEMENT FRAMEWORK4Section 1: INTRODUCTION41.1The purpose41.2 Motivation41.3 Wireless sensor network61.4 Jade Agent10Section 2: REQUIREMENTS AND DESIGN122.1 The Building Management Framework Communication Protocol122.1.1 BMF122.1.2 Specific Requirements192.1.3 Design192.2 Gateway between BMF and Spine framework272.2.1 Spine272.2.2 Specific Requirements272.2.3 Design28Section 3: IMPLEMENTATION DETAILS433.1 BMF433.2 Spine45Section 4: EXPERIMENTS AND TEST464.1. Communication Protocol464.2 Gateway between and BMF and Spine51Conclusions56References57A Annex: BMF Class diagram58B Annex Source code for Communication between basestation and node69C Annex Source Code for gateway between BMF and Spine79

Content of figure:Figure 1 WSN Topology7Figure 2 WSN8Figure 4 WSN components9Figure 3 WSN9Figure 5 The BMF Groups13Figure 6 The basestation configuration14Figure 7 The HLP configuration15Figure 8 The basestation16Figure 9 LLP configuration17Figure 10 Sensor nodes18Figure 11 The communication between the LLP components19Figure 12 The communication diagram between basestation and node20Figure 13 Class diagram for Acknowledge Packet23Figure 14 Class diagram for Configuration Packet24Figure 15 Class diagram for Data Packet25Figure 16 Class diagram for Membership Packet25Figure 17 Gateway between BMF and Spine28Figure 18 Communication design29Figure 19 The communication diagram between basestation, BMF Agent and Spine Agent with actors29Figure 20 The communication diagram between basestation, BMF Agent and Spine Agent30Figure 21 The communication diagram for One Shot behavior31Figure 22 The communication diagram for Periodical Behavior34Figure 23 BMF Class diagram36Figure 24 The communication diagram for ContractNet-Protocol38Figure 25 The communication diagram for Iterated ContractNet-Protocol39Figure 26 Types of sensors43Figure 27 The office node distribution48Figure 28 The basestation connection49Figure 29 Sensor connection49Figure 30 Waist sensor position51Figure 31 Leg sensor position51Figure 32 Waist and leg sensors position52 Content of Table:Table 1 Type of packages23Table 2 Methods description and parameters26Table 3 Software and Hardware configuration for sensor nodes45Table 4 Group configuration49

BUILDING MANAGEMENT FRAMEWORK Section 1: INTRODUCTION1.1 The purpose

Nowadays, as buildings inhabitants are growing their awareness about technology, they expect that future buildings will be smart" in supporting their need. In particular, the inhabitants of a building want to be sure about the structural health of their buildings, they would require the presence of mechanisms supporting building automation for increasing the comfort levels and monitoring of the building energy usage to automatically actuate energy saving strategies. This types of requirements be possible only with the pervasive and intelligent control of all the spaces in a building carried out through sensors and actuators deployed inside buildings and on the building structure. We propose one framework named: Building Management Framework (BMF) that provides powerful abstractions by capture the morphology of buildings for allowing the rapid development and flexible management of pervasive building monitoring applications.1.2 Motivation

Future buildings will be constantly monitored and managed through intelligent systems that allow having information about the building health, keeping a good comfort level for the building inhabitants and optimizing the energy spent.Making this possible, we will use wireless sensor and actuator networks (WSANs) to audit buildings and control equipment that represents a viable and more flexible solution to traditional building monitoring and actuating systems (BMAS), which require retrofitting the whole building and therefore are difficult to implement in existing structures.BMF, Building Management Framework (first version released in 2011),which is a domain-specific framework based on WSANs (Wireless Sensor and Actuator Networks) for enabling proactive monitoring of spaces and control of devices/equipments.WSAN-based solutions for monitoring buildings and controlling equipment, such as electrical devices, heating, ventilation and cooling (HVAC), can be installed in existing structures with minimal efforts. This should enable a more effective monitoring of building structure condition, and building space and energy (electricity, gas, water) usage while facilitating the design of techniques for intelligent actuation of devices in buildings. In order to achieve this, WSAN-based building auditing necessitates devising a dedicated management framework for:1. The management of a range of cooperating networked entities in the different parts of the structure;2. The capture of the morphology of the buildings to correlate sensed data to a portion of the building; 3. The adaptive management of sensing and actuation;4. The management of networks communication to allow different duty cycle for nodes powered through the mains; 5. The low and high level programmability of the network; 6. The fast deployment of concurrent applications at runtime.

The aim of the BMF is to overcome the limits of existing, by using the WSANs, frameworks by providing:1. Flexible and efficient management of large sets of cooperating networked sensors and actuators; 2. Abstractions for logical and physical node group organization to specifically capture the morphology of buildings; 3. Intelligent sensing and actuation techniques;4. Integration of heterogeneous WSANs; 5. Flexible system programming at low- and high-level;6. Fast deployment of different applications through message exchange.

There are some framework that can be used to monitor buildings, provide a simplified way to query data from the nodes, use in-network processing, and multi-hop support for large networks: TinyDB, SwissQM, Abstract Regions (AR) and FiGaRo. Existing frameworks have significant drawbacks and miss key features that hinder the applicability in a smart building context. In particular, they do not implement methods to capture the morphology of buildings, do not provide multi-platform support, and do not allow using actuators. In addition, they provide users with features like SQL-like query interpreters, in-network data fusion, and shared variables that in a Building Management domain could be unnecessary and charge the nodes with complex and onerous algorithms.We will talk about the BMF, Building Management Framework ,which is a domain-specific framework based on WSANs (Wireless Sensor and Actuator Networks) for enabling proactive monitoring of spaces.BMF is organized in two processing layers: Low-Level Processing (LLP) and High-Level Processing (HLP). LLP resides at sensor node level and provides sensor-based services, while HLP resides at the basestation level and provides application based services.The contribution of the framework is twofold: through the HLP the BMF assists the application developer with an extensible set of OSGi Bundle that facilitates the management of a heterogeneous WSAN spanned in buildings and the collection of data from the network. Through the LLP the BMF is a network practitioner in the sense that facilitates the deployment of heterogeneous nodes, management of network operations, and network maintenance. This is achieved by providing a set of embedded functionalities and a corresponding API at PC side, namely high-level processing. At the LLP side, BMF is currently implemented in TinyOS specifically supporting the interoperation of several types of TelosB (Crossbow, Moteiv, KMotes Tyndall and Epic) platforms with heterogeneous sensing capabilities, and in Java for the SunSPOT platform. The use of BMF is demonstrated through SmartEnLab, a BMF-based application for energy monitoring in computer laboratory environments. SmartEnLab is useful not only to highlight the advantages provided by BMF in terms of application programming effectiveness, deployment flexibility, run-time reconfiguration and system performance, but also shows the usefulness of WSAN in the context of energy profiling in office environments.1.3 Wireless sensor network

A sensor network is composed of a large number of sensor nodes, which are densely deployed either inside the phenomenon or very close to it. These sensors are small, with limited processing and computing resources, and they are inexpensive compared to traditional sensors. These sensor nodes can sense, measure, and gather information from the environment and, based on some local decision process, they can transmit the sensed data to the user.A WSN typically has little or no infrastructure. It consists of a number of sensor nodes (few tens to thousands) working together to monitor a region to obtain data about the environment. An example of a WSN is in the next figure (infrastructure of a network).

Figure 1 WSN Topology

Unlike traditional networks, a WSN has its own design and resource constraints. Resource constraints include a limited amount of energy, short communication range, low bandwidth, and limited processing and storage in each node. Design constraints are application dependent and are based on the monitored environment. The environment plays a key role in determining the size of the network, the deployment scheme, and the network topology. The sensor position need not be engineered or pre-determined. This allows random deployment in inaccessible terrains or disaster relief operations. On the other hand, this also means that sensor network protocols and algorithms must possess self-organizing capabilities. Another unique feature of sensor networks is the cooperative effort of sensor nodes. Sensor nodes are fitted with an on-board processor. The size of the network varies with the monitored environment. For indoor environments, fewer nodes are required to form a network in a limited space whereas outdoor environments may require more nodes to cover a larger area. An ad hoc deployment is preferred over pre-planned deployment when the environment is inaccessible by humans or when the network is composed of hundreds to thousands of nodes. Obstructions in the environment can also limit communication between nodes, which in turn affects the network connectivity (or topology).A sensor network design is influenced by many factors, which include fault tolerance; scalability; production costs; operating environment; sensor network topology; hardware constraints; transmission media; and power consumption.These factors are important because they serve as a guideline to design a protocol or an algorithm for sensor networks. In addition, these influencing factors can be used to compare different schemes. We will discuss about the most important facts that influence a WSN.Fault tolerance is the ability to sustain sensor network functionalities without any interruption due to sensor node failures. If the environment where the sensor nodes are deployed has little interference, then the protocols can be more relaxed. For example, if sensor nodes are being deployed in a house to keep track of humidity and temperature levels, the fault tolerance requirement may be low since this kind of sensor networks is not easily damaged or interfered by environmental noise. On the other hand, if sensor nodes are being deployed in a battlefield for surveillance and detection, then the fault tolerance has to be high because the sensed data are critical and sensor nodes can be destroyed by hostile actions. As a result, the fault tolerance level depends on the application of the sensor networks, and the schemes must be developed with this in mind.Scalability depends of the number of sensor nodes deployed in studying a phenomenon may be in the order of hundreds or thousands. Depending on the application, the number may reach an extreme value of millions. The new schemes must be able to work with this number of nodes. They must also utilize the high density nature of the sensor networks.Hardware constraintsA sensor node is made up of four basic components as shown in the Figure 4: a sensing unit, a processing unit, a transceiver unit and a power unit and the real sensor is shown in the Figure 2. They may also have application dependent additional components such as a location finding system, a power generator and a mobilize.

Figure 2 WSN Sensing units are usually composed of two subunits: sensors and analog to digital converters (ADCs). The analog signals produced by the sensors based on he observed phenomenon are converted to digital signals by the ADC, and then fed into the processing unit. The processing unit, which is generally associated with a small storage unit, manages the procedures that make the sensor node collaborate with the other nodes to carry out the assigned sensing tasks. A transceiver unit connects the node to the network. One of the most important components of a sensor node is the power unit. Figure 3 WSN Power units may be supported by a power scavenging unit such as solar cells. There are also other subunits, which are application dependent.

Figure 4 WSN components

It is very important to be care four about the network security. A WSN is vulnerable to threats and risks. An adversary can compromise a sensor node, alter the integrity of the data, eavesdrop on messages, inject fake messages, and waste network resource. Unlike wired networks, wireless nodes broadcast their messages to the medium. Hence, the issue of security must be addressed in WSNs.There are constraints in incorporating security into a WSN such as limitations in storage, communication, computation, and processing capabilities. Designing security protocols requires understanding of these limitations and achieving acceptable performance with security measures to meet the needs of an application. We designed some protocols but we will discuss it in the implementation side.

We have to analyses all the requirements of a Building Management System (BMS) based on WSANs and used as comparison parameters:1. Fast Reconfiguration. While some frameworks allow to quickly configuring nodes in a WSN through packets sent over the air, some other works require the user to write embedded code for sensors that is difficult to realize and requires an expensive and slow deployment phase. We believe that a dynamic network requires tools for a fast (re)configuration to switch over different applications at runtime. Moreover, the packets sent to configure the nodes have to be optimized to save communication bandwidth and carry out a fast reconfiguration. Moreover, an effective query language for node programming has to be defined for WSAN programming at run-time.2. In-node Processing. Performing in-node processing allows computing and sending synthetic data on the network giving the opportunity to send less raw data packets so saving both bandwidth and energy on the nodes (as the radio is the sensor component that wastes more energy) and also allowing more nodes to join the network. In a Building WSAN, the in-node processing is more useful than the in-network processing (data fusion, shared variables, and so forth) which provides functionalities that are most of the time useless in a Building Management domain, charges the nodes with onerous algorithms and increases configuration data exchange among nodes.3. Multi-hop Support. To cover whole buildings, a framework must provide support for multi-hop networks4. Multi-platform Support. Using different platforms together in a network allows to take advantage of different types of sensor nodes with different and more suitable features.5. Methods to dynamically capture the morphology of buildings (Building Programming Abstraction). In a building, the nodes of a WSAN can be deployed everywhere. It is very important to design a Building Programming Abstraction that allows to store where the nodes are placed in a building in terms of room (e.g. kitchen, sitting room, and bathroom) and function (e.g.: ambient temperature, lighting system, and radiator monitoring). A Building Programming Abstraction allows capturing the morphology of a building at basestation side and allows making a node conscious about its position in the building.6. Support for actuators. In order to apply policies to achieve some goals like comfort or energy saving in a building, it's of primary importance for some nodes of the network the control of actuators. Through actuators, a user can remotely send commands to objects (appliances, lights, radiators) or software can intelligently apply some rules.7. Deploy management through Human Computer Interface (HCI). A user- friendly graphical interface to easily configure the network is fundamental. In particular, it allows saving programming time and effectively visualizing data from the WSANs. Moreover, the interface has to be extensible to allow users to add high-level functionalities without programming a new interface or re-implementing the one provided.1.4 Jade AgentThe term agent is essentially a special software component that has autonomy that provides an interoperable interface to an arbitrary system and/or behaves like a human agent, working for some clients in pursuit of its own agenda. Even if an agent system can be based on a solitary agent working within an environment and if necessary interacting with its users, usually they consist of multiple agents. These multi-agent systems (MAS) can model complex systems and introduce the possibility of agents having common or conflicting goals. These agents may interact with each other both indirectly (by acting on the environment) or directly (via communication and negotiation). Agents may decide to cooperate for mutual benefit or may compete to serve their own interests.One of the key components of multi-agent systems is communication. In fact, agents need to be able to communicate with users, with system resources, and with each other if they need to cooperate, collaborate, and negotiate and so on. In particular, agents interact with each other by using some special communication languages, currently the most used and studied agent communication language is the FIPA ACL. A FIPA-ACL message contains a set of one or more message parameters. Precisely which parameters are needed for effective agent communication will vary according to the situation; we will discos about each parameter when we will use the agent.

Section 2: REQUIREMENTS AND DESIGN 2.1 The Building Management Framework Communication Protocol2.1.1 BMF

BMF supports a Building Programming Abstraction to explicitly capture the morphology of a building based on high-level dynamic groups. Groups can be used to address the nodes through their logical or physical characteristics (place in which the node is positioned, type of sensor available on the node, appliance which the node is monitoring, and so forth). In such a way, many nodes can be simply addressed by the same packet and, consequently, there is no need to explicitly send the same request to many addressees. If this type of aggregation is dynamic and the network changes, a request will be transparently sent to the updated group of nodes. Moreover, BMF is the only work that allows controlling actuators such as ACme actuator nodes or Tyndall REAM nodes.The BMF dynamically organizes the nodes in groups. Formally, a group is defined as a non-empty set of nodes, as highlighted in Equation 1.= { } Equation 1 Groups equationIn particular, a group formalizes either logical or physical properties of nodes. Examples of properties are: location (e.g. dining room, bedroom, and kitchen), monitoring activity (e.g. heater monitoring), the presence of a specific sensing device onboard (e.g. all the nodes with passive infrared detector). Indeed, a node can belong to more than one group. Each node knows its group member- ship through the reception of configuration packets sent by the user through the BS. This allows a group membership be dynamically changed at any time.In particular, BMF uses dynamic node addressing scheme to send packets to a specific node, a group of nodes or a compound group. We will see the packets transmission in the next section. The next figure represents an example of group and compounds groups.

Figure 5 The BMF Groups

The Building Management Framework (BMF) is a domain-specific framework implemented for both WSAN nodes and more capable devices at basestation side such as PC, plug computer, smart phone, PDA. It allows flexible and efficient distributed sensing and actuation in buildings. BMF fully addresses all the requirements, which are not comprehensively addressed in currently available general-purpose application frameworks for WSNs. In particular, BMF provides fast reconfiguration, in-node processing algorithms, multi hop networks and multi-platform support, a building programming abstraction to dynamically catch the morphology of buildings, actuators support and an extensible interface.

The Node-side part of the BMF is designed around the following layers: Hardware Sensor Platform layer allows to access the hardware sensor/actuator platform. In particular, this layer facilitates the configuration of the platform specific drivers and the use of the radio. WSAN Management layer manages the communication between the node and the reference BS according to the BMF application-level protocol and among the nodes in the neighborhoods through the multi-hop network protocol provided by the node sensor platform. Sensing and Actuation Management layer allows acquiring data from sensors and executing on actuators. In particular, this layer allows to control and plugin sensors/actuators from different vendors. Node Management layer is the core of the Node-side BMF and allows to coordinate all the layers for task execution. In particular, on one side it handles events from the lower layers every time that a network packet arrives or data from sensor/actuator are available, and on the other side it manages events from the upper layers every time that data are processed or a stored request has to be executed. Dynamic Group Management layer provides node grouping functionalities. A node can belong to several groups at the same time and its membership can be dynamically updated on the basis of requests from the user. In-node Signal Processing layer allows the node to execute signal processing functions on data acquired from sensors. It can compute simple aggregation functions (e.g. mean, min, max, variance, RMS) and more complex user-defined functions on buffers of acquired data. Multi Request Scheduling layer allows the scheduling of sensing and actuation requests. In particular, it stores the requests from the user and schedules them according to their execution rate.. Figure 6 The basestation configurationBMF is organized into two levels of processing logics: Low-Level Processing (LLP) and High-Level Processing (HLP). While the LLP resides on sensor nodes, HLP resides at the BS side, which is usually a laptop, a workstation, a PDA, a plug computer or a smart-phone. LLP and HLP communicate according to an application-level Building Management Framework Communication Protocol (BMFCP), it will be discuss later on. The HLP has a strong modularity that permits to implement all the services needed in different bundles that communicate through the OSGi Framework. This allows changing functions or part of them just stopping a bundle and starting a new one implementing the same services of the former. As shown in Figure 7 the defined core bundles are:

Figure 7 The HLP configuration The Platform Bundle (PB) represents a set of bundles that allow interfacing the system with different types of platforms. Every PB is linked to a hardware component so to communicate with a specific WSAN platform. For example, in a building WSAN consisting of TinyOS and Sun SPOT nodes there will be two PBs to communicate with TinyOS and Sun SPOT platforms. The Communication Bundle (CB) uses specific platform services published by the PBs, to allow sending and receiving packets and enabling communication between bundles and a WSAN. The Groups and Nodes Management Bundle (GNMB) keeps track of nodes and groups in a WSAN and stores nodes configurations and groups compositions. GNMB is useful to save in one place data about a WSAN and share it among several bundles. The Packet Manager Bundle (PMB) allows the creation and the interpretation of low-level packets according to the Building Management Framework Communication Protocol (BMFCP) introduced and described in detail in the next sections. The Network Manager Bundle (NMB) allows to fully managing a WSAN through the use of CB, GNMB, and PMB. NMB can build, send, receive and interpret packets to/from a WSAN, manage the status of nodes and the membership of groups as requested by the high level bundles. The Data Saving Bundle (DSB) listens to all the data forwarded by the NMB from the network. The DSB is designed to save data to les or a database in order to track the evolution of a WSAN and to store data for future requests. The Aggregation Bundle (AB) is responsible for executing aggregations on data from the network. AB is useful to calculate, on the base station side, aggregated synthetic data on sensor values from different nodes of a WSAN. The BMF Management GUI Bundle (MGUIB) is a graphical user interface to allow the user to manage a WSAN, submitting requests, waiting for and visualizing data from the network and displaying charts about sensing operations. The basestation used in our application is:

Figure 8 The basestation

LLP is the node-level part of BMF and is implemented both in TinyOS 2.1, for TinyOS-based nodes, and in Java, for SunSPOT nodes. For space reason this paper focuses on the LLP for TinyOS, while the SunSPOT implementation has similar functionalities and components. LLP supports two types of logics: Node Logic, which provides acquisition of data from sensors, control of actuators, in-node signal processing; store and scheduling of requests; Network Logic, which provides downstream and upstream communication, packet parsing, packet formation, transmission handling, dynamic node addressing; group management.In the Figure 9 the components of LLP are shown according to a layered architectural style. The modular structure of LLP allows separating all key functions. This is useful in case of improvements of a single component, which would solely involve the replacement of the structure independently from other components.

Figure 9 LLP configurationIn particular: The PacketManager (PaM) handles packets of the BMF application level protocol, parses downstream packets and builds upstream packets to the BS. The GroupManager (GM) manages the group membership of a node. As a node can belong to several groups simultaneously, its membership can be dynamically updated on the basis of downstream packets sent. The CommunicationManager (CM) manages node's communication through downstream and upstream routing protocols. The BMFManager (BMFM) is the broker component of the framework. BMFM receives events every time a packet arrives from the network and every time some data to be sent is ready. In the first case, it interprets the packet by means of PaM and dispatches the packet to the handling component (GM or PM); in the latter case, it builds the packet through PaM and dispatches it to CM to send it to the BS. The RequestManager (RM) stores the BS requests and schedules them according to their execution rate and lifetime. The Sensing&ActuatingManager (SAM) is a dispatcher that forwards sensor reading and actuation requests to the right sensor/actuator driver. It addresses sensors and actuators in a generic way, as it communicates with a generic platform version of the drivers. The Sensor, Actuator & Platform Abstraction (SAPA) is a layer that allows addressing different types of sensors/actuators in a platform independent way. SAPA guarantees interoperability between TinyOS-based platforms and sensing/actuation devices by creating a common API used to abstract from different low-level hardware sensor and actuator drivers. SAM exploits SAPA when a sensor is to be addressed. Thus, SAM only needs to request for a generic sensor, which is linked to the platform specific one at compilation time. The ProcessingManager (PM) manages all the requests for sensing and/or actuation coming from the network or from internal components. In particular, PM handles an internal queue of one-shot requests. According to the request type, PM can interact with RM to schedule the request if it is periodical; interact with SAM to read a sensor or actuate a command; compute some function on the acquired data; check the sampled values to re an alarm if set. Moreover, when data is ready to be sent to the BS, PM forwards them to the BMFM through an event.The nodes used in our application are:

Figure 10 Sensor nodes

It is worth noting that only RM, SAPA and CM are based on TinyOS components while SAM, PaM, PM, GM and BMFM are built on top of the other components. This means that the higher layers are also independent of the TinyOS components so that they can be easily ported to non-TinyOS platforms. The Figure 11 shows the connections between the components of the LLP.

Figure 11 The communication between the LLP components

2.1.2 Specific Requirements Making possible the interaction between basestation and the nodes it should be designed, created and implemented a communication protocol, as we talk before, the protocols name will be Building Management Framework Communication Protocol (BMFCP) BMFCP should support the communication between HLP and LLP to configure and monitor the building sensor network in an effective manner. The packets that will be exchanged are called BMFPackets that can be formed, depending on the specific request sent from the BS or the specific data sent from the sensor nodes, by different fields having a different amount of bytes. The BMFCP is developed to transmit variable length packets containing only the meaningful bits of the significant fields. By doing so, the BMFCP optimizes transmissions saving battery of nodes and network bandwidth so allowing an improved sharing of the radio channel.2.1.3 Design

LLP and HLP interact through an application level communication protocol, namely Building Management Framework Communication Protocol (BMFCP).In order to understand how will be the flow of the interchanged packages between the basestation and the nodes, through that protocol the next figure will presents the communication protocol:

Figure 12 The communication diagram between basestation and nodeAs we can see form that diagram the framework implements eight different packets:

The Advertisement Packet (AD-PKT) is a Node-to-BS packet with variable length that will be sent when nodes are switched on. The AD-PKT is sent several times at random intervals until a packet from the BS is received so to ensure that the BS is online and received an AD-PKT from the current node. The purpose of this packet is to inform the BS about the presence of node in the network, the sensing/actuating abilities of the node itself and the analytic available at the node in the case sensing devices are provided. The AD-PKT should send some information to BS some of them are: packet type (in our case the advertisement packet), the id of the sender, it should sent information about the sensor / actuator type (light, temperature, humidity) and the nodes functions. The Sensor Schedule Packet (SS-PKT) is a BS-to-Node packet with variable length that will be sent to configure the available sensing devices. The packet should presents a field indicating the id of the request, namely the code of the request, and two couples of fields, PERIOD TIMESCALE and PERIOD VALUE, LIFETIME TIMESCALE and LIFETIME VALUE. These indicate timescale/value of the period at which a data is requested and the timescale/value of the duration of the current request respectively. The packet should sent a SENSOR TYPE with the code of the sensor required and a DATA TYPE, indicating if the packet is asking for all the sensed (and eventually calculated) data or only for data that verifies a threshold. The THRESHOLD TYPE field indicates if the packet requests for values over or under a THRESHOLD VALUE or for all the times the THRESHOLD VALUE is passed from up to down or vice versa.

The Actuator Schedule Packet (AS-PKT) is a BS-to-Node packet of variable length, should be sent to configure actuation on them. In this packet there should be the same timing fields as in the SS-PKT. Afterwards, there should be an ACTUATOR TYPE field with the code of the actuator and an ACTUATOR PARAM which is filled with a value linked to the actuator type.

The Unschedule Packet (U-PKT) is a BS-to-Node packet of variable length that will be sent to unscheduled an active sensing or actuation request on them. Apart from the header, the only field that this packet should have is the REQUEST ID to request an uscheduling.

The Group Management Packet (GM-PKT) is a BS-to-Node packet with variable length that will be sent to set the groups to which the addressees have to belong to. In the packet, there should be a MEMBERSHIP TYPE field which indicates if the groups in the following have to be added to the actual membership, if the membership has to be completely updated, if some groups have to be deleted or if the group membership has to be reset. The other field that will be necessary is the MEMBERSHIP COUNT that represents the counter of the GM-PKTs sent. MEMBERSHIP GROUPS will be a list of nodes which is present in the packet if the MEMBERSHIP TYPE is different from \reset".

The Reset Packet (R-PKT) is a BS-to-Node packet with variable length, this packet will be sent to restore addressees' initial state. This packet will have no fields apart from the header because it is not necessary.

The Data Packet (D-PKT) is a Node-to-BS packet with variable length, that will be sent when some sensed and elaborated or just sensed data is ready. We need the SENDER ID field because it reports the producer of the following data, the TIMESTAMP that should be a progressive number saying the amount of data sent from the SENDER ID, the REQUEST ID that should indicates what is the request the RESULT data refers to.

The Ack Packet (A-PKT) is a Node-to-BS packet, which should be sent when nodes need to confirm the reception and elaboration of a packet from the BS. Besides the PKT TYPE and the SENDER ID fields, this packet should contains a field, PKT TYPE TO ACK, which will report the packet type that is acknowledged and an ACK PARAM that reports a field of the acknowledged packet (e.g. in the case of acknowledging a SS-PKT, the REQUEST ID is provided).

In order to understand the interactions between BS and sensor nodes through the BMFCP, as shows in the figure a sequence diagram we will discuss in the next example. Once a node is started, it periodically emits AD-PKTs until the BS sends a configuration packet (group management or request scheduling).The BS could send even a GM-PKT, through this type of message, the BS could manages the membership of target nodes (a node can belongs in the same time to more than one group). After the node processes the received packet by interpreting the fields, it sends the A PKT to acknowledge the packet received to the BS, in that way the basestation can be sure that the configuration packet was correctly received. The SS-PKT (or AS-PKT) allows requesting a specific sensing (or actuation) operation to target nodes. The node transmits sensed (processed) data to the BS through the D-PKT. The BS can unschedule previously scheduled requests through the U-PKT. Finally the BS sends out the R-PKT to reset target nodes that start again to send AD-PKTs. After receiving an U-PKT the nodes wont be able to restart the communication with the basestation because its wont be able to send back to BS the ADPKT, in the other point of view if the communication is ended through a R-PKT the communication will restart, because the node is able to sent back to basestation AD-PKT.For better understanding the communication protocol and the packets fields I will present the next table:Crt.Nr. Packet NameDescriptionParameters

1.Advertisement Packet(AD-PKT).Node-to-BSPKT_TYPE, AD-PKT>

**if exists(*)*

2.Sensor Schedule Packet(SS-PKT).BS-to-Node

if DATA_TYPE.VALUE == THRESHOLD_NOTIFICATION

3.Actuator Schedule Packet(AS-PKT).BS-to-Node

*

4.Unschedule Packet(U-PKT)BS-to-Node

5.Group ManagementPacket(GM-PKT)BS-to-Node

If MEMBERSHIP_TYPE.VALUE != RESET endIf

6.Reset Packet(R-PKT)BS-to-Node

7.Data Packet(D-PKT)Node-to-BS

8.Ack Packet (A-PKT)Node-to-BS

Table 1 Type of packagesIn order to create an Ack-Pkt I created a class with the next class diagram:

Figure 13 Class diagram for Acknowledge Packetfor better encapsulated, I created an interface and when we want to create an object Ack-Pkt we will use that interface (IAckPacket). This type of message is sent only when a Configuration Packet was sent. The class diagram for the Configuration Packet is the presented in the next figure:As it is writhed in the row 2, table 1, the class presented in the next diagram, ConfigurationPacket has the same fields as it is writhed. I created an interface only for better encapsulated. One configuration packet (schedule packet) is send from BS to Node side so in order to create the node side we create the Destination class.

Figure 14 Class diagram for Configuration PacketFor the data packet we need the id of the sender, because we should know how sent to the basestation that packet, the request id because we should validate the request, the data received from the node (sensor). All the data type received form node side (sensor side) are long integer or unsigned integer, I choose to use the unsigned integer because is mode appropriate. The class diagram for a data packet is shown in the next figure.

Figure 15 Class diagram for Data Packet

As we saw in the introduction a node can belong to more than one group. Each node knows its group member- ship through the reception of configuration packets sent by the user through the BS. This allows a group membership be dynamically changed at any time.In order to dynamically change the group membership for a node we should set some methods that update the group membership, those methods should add the node in another group or should delete the node from a group. That is shown in the next class diagram:

Figure 16 Class diagram for Membership PacketWhen I created the packets parameters exchanged between the basestation and the nodes (sensors) through Building Management Framework Communication Protocol, I predefined values of those and those are showed in the next table.

Additional Parameter

DescriptionPREDEFINED VALUEs

ADDRESSEE_TYPEThe type of addressee in the followingNode, List of Nodes, GROUP, GROUP_COMPOSITION

ADDRESSEEThe addressee of the packetN+ | ([NOT] G [STO [NOT] G]*)

REQUEST_IDThe unique identifier of a requestNo predefined value. Eight bit Integer

PERIOD_TIMESCALEThe timescale of the periodMSEC, SEC, MIN, HOUR, DAY

PERIOD_VALUEThe period of the request executionNo predefined value. Six bit Integer

LIFETIME_TIMESCALEThe lifetime of the requestMSEC, SEC, MIN, HOUR, DAY

LIFETIME_VALUEThe timescale of the requestNo predefined value. Six bit Integer

SENSOR_TYPEThe specific sensor typeACC_X, ACC_Y, ACC_Z, HUMIDITY, IR, LIGHT, MAGNETIC_X, MAGNETIC_Y, SOUND, TEMPERATURE,ELECTRICITY,INTERNAL_VOLTAGE

ACTUATOR_TYPEThe specific actuator typeLED

ACTUATOR_PARAM

An actuator parameterIf ACTUATOR_TYPE == LEDLED_0_TOGGLE,LED_1_TOGGLE,LED_2_TOGGLE

DATA_TYPEThe data type of sensorreadingsSENSED_DATA, THRESHOLD_NOTIFICATION

SYNTHETIC_DATA_TYPEThe synthetic data type of sensor readings. Data aggregation can be set.NO_SYNTHETIC (RAW DATA), AVERAGE

THRESHOLD_TYPEThe threshold type appliedon sensor readingLOWER, BIGGER, TRANSITION

MEMBERSHIP_TYPEThe type of membershipoperationUPDATE, ADD, DELETE, RESET

MEMBERSHIP_COUNTThe counter of themembership configuration sentNo predefined value. Eight bit Integer

FUNCTIONThe type of in-nodefunction computed on thesampled dataELABORATION_AND_THRESHOLD_STANDAD, ELABORATION_STANDARD, THRESHOLD_STANDARD,AVERAGE, MIN, MAX, THRESHOLD_TYPE_LOWER,THRESHOLD_TYPE_BIGGER,THRESHOLD_TYPE_TRANSITION

TIMESTAMPTimestamp of the transmitted dataNo predefined value. Eight bit Integer

RESULTTransmitted dataNo predefined value. Variable length 8, 16 or 32 bitInteger

PKT_TYPE_TO_ACKThe packet type to ack SS-PKT, AS-PKT, U-PKT, GM

ACK_PARAMType of ackif PKT_TYPE_TO_ACK == SS-PKT || AS-PKT || U-PKTREQUEST_ID.VALUEif PKT_TYPE_TO_ACK == GM-PKTMEMBERSHIP_COUNT.VALUE

Table 2 Methods description and parameters2.2 Gateway between BMF and Spine framework2.2.1 Spine

When applied to the monitoring of human body parameters, WSNs are usually called Wireless Body Sensor Networks (WBSNs)or just BSNs and can significantly improve the quality of life by enabling continuous and real-time medical assistance at low cost. Health-care applications based on BSNs include early detection or prevention of diseases, heart beatings elderly person assistance at home, e-fitness, rehabilitation after surgeries, motion and gestures detection, cognitive and emotional recognition, medical assistance in disaster events, etc. To support the design of optimized BSN applications while minimizing the design time and effort, a domain-specific open source framework, called SPINE (signal processing in-node environment), has been developed. SPINE offers service architecture and a set of libraries that are common to most BSN applications and at the same time makes it easy to customize or extend the given libraries to meet the particular needs of specific applications. SPINE provides libraries of protocols, utilities and processing functions and a lightweight Java API that can be used by local and remote applications to manage the sensor nodes or issue service requests. By providing these abstractions and libraries, that are common to most signal processing algorithms used in WSNs for sensor data analysis and classification, SPINE also provides flexibility in the allocation of tasks among the WSN nodes and allows the exploitation of implementation tradeoffs. For example, SPINE supports distributed implementations of classification systems where signal processing functions are computed on the sensor nodes and the result sent to the BSN coordinator (called SPINE coordinator) running on a PC or PDA. This allows reducing the amount of data exchanged between the BSN coordinator and the sensor nodes with respect to applications where sensor nodes transmit raw sensor data.

2.2.2 Specific Requirements

As we could see the Building monitoring framework monitors the ambient sensors through wireless sensor network and the Spine monitors the body sensors through body sensor network so we should do a gateway between those two frameworks.We need that gateway for monitoring the body sensor network through the BMF, when a person who is wearing body sensors enter in a building that has monitoring the ambient sensor through BMF should be able to send data to BMF when it request for that.

Body DataRequest

Figure 17 Gateway between BMF and Spine

2.2.3 Design

The SPINE framework has been used to design a human activity monitoring system prototype. This application is able to recognize postures (e.g. lying, sitting or standing still) and a few movements (e.g. walking and jumping) of a person; furthermore, it can detect if the monitored person has fallen and unable to stand up.As we can see in the above image from the BMF side it is sent a request to the Spine side for asking the date from the body sensor network, Spine responds with the afferent data. We have to design and implement 3 types of requests: One shut request: when the BMF wants the current activity; Periodical request: when the BMF wants the current activity every x milliseconds; Threshold request there are 3 types of threshold requests Bigger than a given value; Less than a given value; Between two values.Figure 18 Communication designFor making the communication easier we propose to introduce to this environment a special Jade agent responsible for each framework (one for BMF called BMFAgent and the other for Spine called SpineAgent), so we will have 3 actors: the BMF witch communicate with the BMFAgent through packages according to Building Management Framework Communication Protocol, the BMFAgent witch communicate with the SpineAgent through ACLMessages and the last one the SpineAgent witch continuously collect data from BSN(as we can see in the next figure).

Figure 19 The communication diagram between basestation, BMF Agent and Spine Agent with actorsThe packages that can be exchanged between the basestation (bmf in the next figure) and the BMFAgent are: AD-PKT (BMF Agent to BS): the purpose of this packet is to inform the BS about the presence of node in the network. It is sent several times at random intervals until a configuration packet from the BS is received. D-PKT (BMF Agent to BS): this type of packet is sent when some sensed and elaborated or just sensed data is ready. R-PKT (BS to BMF Agent): this type of message is sent to restore addressees' initial state. A-PKT (BMF Agent to BS): packet sent when nodes have to confirm the reception and elaboration of a packet from the BS.

Figure 20 The communication diagram between basestation, BMF Agent and Spine AgentBMF Agent

It is quite clear, however, that when an agent is dealing with complex tasks that involve several computational steps, possibly mixed with conversations with other agents and so on, it is not convenient to implement the complete task logic within more than one behavior. Depending on each type of request the BMFAgent should add a behavior, so we will deal with 3 types of behavior (one shot behavior, periodical behavior and threshold behavior).The communication between BMF and Spine stats according to the communication diagram with an ACLMessage sent by BMFAgent to SpineAgent asking it what are the available Spine functions (in our case only human activity) in order to know what the it can do.

The Spine Agent replies with an ACLMessage, which performativ is INFORM, for returning the services that it can provide (in our case only activity witch internal virtual code is 25).Once the BMFAgent receives that ACLMessage is able to sent to basestation its presents in the network through an AD-PKT. Once the basestation receives an AD-PKT, it can send a configuration packet to the BMF Agent. When the BMF Agent receives the configuration packet, it sends back an A-PKT and interprets the configuration packet. Depending on the packets parameters, the BMF Agent could initialize 2 types of behaviors:

1. One Shot BehaviorThe communication diagram of this behavior is:

Figure 21 The communication diagram for One Shot behaviorThe packet sent in order to initialize that type of behavior has the next structure:pkt=getConfigurationPacket(1,Constants.TIMESCALE_SEC,1,Constants.TIMESCALE_SEC,0, Constants.ACTION_SENSING,Constants.SENSOR_TYPE_ACTIVITY, Constants.DATA_TYPE_SENSED_DATA);Where: 1 is the period timescale Constants.TIMESCALE_SEC is the type of the Timescale 0 is the period life time Constants.ACTION_SENSING is the type of the activity that the basestation wants to do Constants.SENSOR_TYPE_ACTIVITY is the sensors destionation typeOnce that type of packet is received by the BMFAgent from basestation it should be sure witch behavior should initialize, however we want to initialize an OneShotBehaviour we should check the period life time value, if that value is 0 that behavior id added.

After the node processes the received packet, it sends back to basestation the A-PKT to acknowledge the packet received to the BS, in other case the basestation thinks that the configuration packet wasnt reach the destination and it try to send it again. The BMF Agent sends a request for the activity to Spine Agent (through ACLMessage.REQUEST) as we can see in the communication diagram:

The Spine Agent creates an ACLMessage.INFORM with the data received from the virtual sensor network and sends it to the BMF Agent.The message that SpineAgent sends back has the next format:idNode:activity|idNode:activity| idNode:activity|Where: The idNode is the Spines node id. That id is an integer value The activity is the current activity of the node witch id is idNode, is an integer value. According to an Spine protocol the activity value represents a human real activity, each activity has an integer value:

For better understanding the content of the received ACLMessage.INFORM in the BMFAgent side we create a method that parse that ACLMessage :

Where: SpineData is a class that we created for better dealing with the data received from Spine Agent. The structure of that class is:

}Where: The requested is the number of the received request,that value is incremented every time when we receive data from SpineAgent. The activityVal is the integer value of the Spines node activity. According with the activityVal we create the String activity. This is useful because it is not a better thing to deal with the virtual code it is better to know (in real language) what means a value. aclMessage: is the ACLMessage received from SpineAgent with the collected data.

Once the message is parsed the BMFAgent must send it to basestation through a data packet (D-Pkt).We create that packet and foreword it to BMF.Every time we initialize a one-shot behavior, we check if the threshold fields are set up (in the request).If they are, we check if the threshold value is equals to (or greater, or smaller depending on the threshold request) the value received from Spine Agent and eventually we send a data packet back to the basestation.If we want to initialize an one shot behavior with threshold function the packet send by basestation to BMFAgent should has the next format and the next parameters value:pkt = getConfigurationPacket(1, Constants.TIMESCALE_SEC, 1,Constants.TIMESCALE_SEC, 0,Constants.ACTION_SENSING,Constants.SENSOR_ACTIVITY,Constants.DATA_TYPE_SENSED_DATA,1,1,Constants.THRESHOLD_TYPE_EQUALS,1,listInt,value,listInt);Where: The Constants.THRESHOLD_TYPE_EQUALS is the threshold type. The value is a vector of integer. That vectors size depends on the threshold type, if we have an greater than or less than threshold the size is 1 and if we deal with an between threshold type we should have 2 values in the vector, because we should know the limits. If it the threshold value isnt initialized we make a one-shot behavior like we saw before.2. Periodical BehaviorThe communication diagram is sown in the next figure:

Figure 22 The communication diagram for Periodical Behavior

The BMF sends a configuration packet to the BMF Agent.pkt = getConfigurationPacket(1,Constants.TIMESCALE_SEC,1,Constants.TIMESCALE_SEC,60, Constants.ACTION_SENSING, Constants. SENSOR_TYPE_ACTIVITY Constants.DATA_TYPE_SENSED_DATA)Where the parameters signification are the same like in One Shut Behavior.In order to initialize this type of behavior we should check the life time value, if this value is greater than 1, we have to act in a periodical way.

As we can see in the communication diagram after receiving the configuration packet the BMF Agent should send back to basestation an A-PKT, for informing the basestation that it received the packet. Once sending that packet, the BMF Agent should send to Spine Agent a Request to see which the current activities are.The periodic behavior is different opposite the one shut behavior because between two requests sent by BMF Agent to Spine Agent we should wait some seconds, this time is given in the configuration packet and it is called periodValue. So between two requests we should wait getPeriodValue( ),that thing we will implement with a Java Thread that sleeps for getPeriodValue( ) milliseconds.

The BMF Agent will periodically sent this request until the lifetime value is reached, when it is the communication will stop. Every time the BMF Agent send the request with current activity we should increment a variable, that variable is useful when we check if the lifetime value is reached.

The ACLMessage.INFORM received by the BMF Agent form the Spine Agent (with the data collected from sensor nodes) is interpreted like in One Shut Behavior, every time when BMF Agent receives a message from spine, it parse that message and create an data packet that is forwarded to the basesation. If we choose to initialize a periodical behavior with threshold functionality, we have to set the threshold number and the threshold value.Every time the BMF Agent receives data from the Spine side, it verifies if those two values are initialized. If the received data are equal to (or greater, or smaller depending on the threshold request) the threshold value, we eventually create a data packet and forward it to the basestation.For better understanding the methods and the communication between classes and methods I will present you the BMF side class diagram:

Figure 23 BMF Class diagram

Spine Agent

Spine Agent has two functions, one of them is to continuously monitor the body sensor network in order to be always ready to respond to the bmf request and the other one is to be able to responds to the bmf requests. There are three type of requests send by the BMF Agent to Spine Agent: What can you do? asking what are the available functions that spine is able to do, in our case only activity.When it receives an ACLMessage.Request with the content "What can you do? it should return the services provided (in our case only the activity) and create an ACLMessage.INFORM with the sensor code (activity code is 25). Give me the activity in that case the Spine Agent should send back the last node activity. When it receives an ACLMessage.Request with the content "Give me the activity, it answers with the last activity known.We use a method createMessageOneShot() that returns a string value, that is the last activity.

Stop, when it receives that type of message the Spine behavior should be stopped. When it receives ACLMessage.Request with the content Stop it ends the communication between the BMF Agent and the Spine Agent. We can stop a behavior by setting the done data with the value true.

We are able to do those things with specific FIPA Protocol; we consider that the communication protocol will be Contract Net for the initial behavior and the one shut behavior and for Periodical behavior we will use Iterated Contact Net.Explanation of the Contract Net Protocol Flow:First of all the communication protocol is:

Figure 24 The communication diagram for ContractNet-Protocol

The Initiator solicitsmproposals from other agents by issuing a call for proposals (cfp) act, which specifies the task, as well any conditions the Initiator is placing upon the execution of the task. Participants receiving the call for proposals are viewed as potential contractors and are able to generatenresponses. Of these,jare proposals to perform the task, specified aspropose.The Participants proposal includes the preconditions that the Participant is setting out for the task, which may be the price, time when the task will be done, etc. Alternatively, thei=n-jParticipants mayrefuseto propose. Once the deadline passes, the Initiator evaluates the receivedjproposals and selects agents to perform the task; one, several or no agents may be chosen. Thelagents of the selected proposal(s) will be sent anaccept-proposalact and the remainingkagents will receive areject-proposalact. The proposals are binding on the Participant, so that once the Initiator accepts the proposal; the Participant acquires a commitment to perform the task. Once the Participant has completed the task, it sends a completion message to the Initiator in the form of aninform-doneor a more explanatory version in the form of aninform-result.However, if the Participant fails to complete the task, afailuremessage is sent.Note that this IP requires the Initiator to know when it has received all replies. In the case that a Participant fails to reply with either aproposeor arefuseact, the Initiator may potentially be left waiting indefinitely. To guard against this, thecfpact includes a deadline by which replies should be received by the Initiator. Proposals received after the deadline is automatically rejected with the given reason that the proposal was late. The deadline is specified by thereply-byparameter in the ACL message.Any interaction using this interaction protocol is identified by a globally unique, non-nullconversation-idparameter, assigned by the Initiator. The agents involved in the interaction must tag all of its ACL messages with this conversation identifier. This enables each agent to manage its communication strategies and activities, for example, it allows an agent to identify individual conversations and to reason across historical records of conversations.In the case of 1: N interaction protocols or sub-protocols the Initiator is free to decide if the sameconversation-idparameter should be used or a new one should be issued. Additionally, the messages may specify other interaction-related information such as a timeout in thereply-byparameter that denotes the latest time by which the sending agent would like to have received the next message in the protocol flow.In our case Initiator: is the BMF Agent; Participant: is the Spine Agent.Explanation of the Protocol Flow for Iterated Contract Net: First of all we need the communication diagram that is presented in the nest figure:

Figure 25 The communication diagram for Iterated ContractNet-Protocol

As with the FIPA Contract Net IP, the Initiator issuesminitial call for proposals with thecfpact. Of thenParticipants that respond,kisproposemessages from Participants that are willing and able to do the task under the proposed conditions and the remainingjare from Participants thatrefuse.Of thekproposals, the Initiator may decide this is the final iteration and acceptpof the bids(0 p k), and reject the others. Alternatively the Initiator may decide to iterate the process by issuingarevisedcfptol of the Participants and rejecting the remainingk-lParticipants. The intent is that the Initiator seeks to get better bids from the Participants by modifying the call and requesting new (equivalently, revised) bids. The process terminates when the Initiator refuses all proposals and does not issue a newcfp, the Initiator accepts one or more of the bids or the Participants all refuse to bid.Any interaction using this interaction protocol is identified by a globally unique, non-nullconversation-idparameter, assigned by the Initiator. The agents involved in the interaction must tag all of its ACL messages with this conversation identifier. This enables each agent to manage its communication strategies and activities, for example, it allows an agent to identify individual conversations and to reason across historical records of conversations.In the case of 1:N interaction protocols or sub-protocols the Initiator is free to decide if the sameconversation-idparameter should be used or a new one should be issued. Additionally, the messages may specify other interaction-related information such as a timeout in thereply-byparameter that denotes the latest time by which the sending agent would like to have received the next message in the protocol flow.

This type of behaviour should extend ContractNetInitiator.

Once the communication starts, we should sent an ACLMessage.CFP (call for propose) for asking the Spine Agent (Participant) what is can do (in our case only the activity).

The spine agent will respond with an ACLMessage.Propose witch content will be 25.When the Initiator (BMF Agent) will receive the propose, it should accept or refuse the propose (if the message content will be 25 the BMF will accept the propose).Once the accept for the propose is sent, BMF Agent starts to periodically sent AD_PKT to BS.Once the basestation(BMF interaction class) receives an AD-PKT, it can sent a configuration packet to the BMF Agent.When the BMF Agent receives the configuration packet, it sends back an A-PKT.

Depending on the packets parameters, the BMF Agent could initialize 2 types of behaviors; we should check the lifetime value, if that value is 0 we are able to initialize that type of behavior in other case we should initialize the periodical behavior. One shut

Periodical

First of all we will make some details about One Shut functionality, for this behavior we will need the communication diagram that is shown in Figure 23. This type of behaviour should extend ConstractNetInitiator.

Once the communication starts, we should send an ACLMessage.CFP (call for propose) for asking the Spine Agent (Participant) for the activity.When the Spine Agent (Participant) receive the cfp message, it creates an replay for that message and sends back its last activities through an ACLMessage.Propose., those are done in the method:protected ACLMessage handleCfp(ACLMessage cfp) {}

After BMF Agent receives the Propose it should accept or reject it, this is done in method:protected void handleAllResponses(Vector responses, Vector acceptances) {}

The communication is done after that step.When we want to talk about Periodical behavior we need to fallow the communication protocol that is shown in Figure 24.This type of behaviour should extends ContractNetInitiator

The communication protocol works like in the One shot one , but the only one difference is that the ACLMessge.CFP could be sent more than one time. This cfp message is sent in method:protected void handleAllResponses(Vector responses, Vector acceptances) {}

We made a method stopCondition in the BMF Agent periodical behavior that verify if the period lifetime value is reached , if it isnt we create and sent a new ACLMessage.CFP with the content Give me your last activity.

Section 3: IMPLEMENTATION DETAILS3.1 BMF

The BMF is implemented and tested on TelosB, Tyndall25, and Epic sensor platforms based on TinyOS and on the Java SunSPOT platforms.

Figure 26 Types of sensorsBMF is basically organized in two modular layers residing on the sensor nodes (sensor-based services) and at the BS side (system-wide services). While from one side, it facilitates the deployment of heterogeneous nodes, management and maintenance of the network operations, from the other side, it assists the application developer with an extensible set of OSGi Bundles to allow basic and advanced control of the building. BMF is currently implemented in Java following the OSGi paradigm on the BS side and in TinyOS, on the TelosB, Tyndall, and Epic platforms, and Java, on the SunSPOT platform, at sensor node side.At the LLP side, BMF is currently implemented in TinyOS (TinyOS, 2011) specifically supporting the interoperation of several types of TelosB such as Crossbow, Moteiv, KMotes , as well as Tyndall and Epic platforms with heterogeneous sensing capabilities, and in Java (J2ME) for the SunSPOT platform.The implementation of BMF has been carried out on the TinyOS (TinyOS,2011) operating system through the nesC language due to its availability for many sensor platforms and flexibility to meet specific application needs and on the SunSPOT (Oracle Corporation, 2011) sensor platform that allows the programming of a WSAN through the flexible and more user friendly Java language. The BS side of the framework is fully implemented in Java according to the OSGi Framework mainly due to its programming effectiveness, modularity and possibility to plug in applications at runtime. The OSGi Framework is a modular system and service platform for Java that implements a complete dynamic component model. Building application components, called bundles, can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot of the application. A service registry allows bundles to know other bundles and their state. Bundles can use services offered by other bundles and explicitly depend on them. To implement the OSGi framework means implementing a modularized environment. Some of the benefits that OSGi provides are: (i) Reuse: the OSGi component model makes it very easy to use many third party components in an application; (ii) Suitable for the Real World: the OSGi framework is dynamic. It can update bundles on the y and services can come and go; (iii) Dynamic Updates, the OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system;(iv) Secure, OSGi inherits Java security and makes it simpler to be used.In the next table are presented some software and hardware configuration for some existing sensors:Model Microcontroller Tranceiver Memory Programm + Data External memory Programm O.S.

BEAN MSP430F169 CC1000 (300-1000 MHz) with 78.6 kbit/s 4 Mbit YATOS

BTnode Atmel ATmega 128L (8 MHz @ 8 MIPS) Chipcon CC1000 (433-915 MHz) e Bluetooth (2.4 GHz) 64+180 K RAM 128K FLASH, 4K EEPROM C, nesC BTnut eTinyOS

COTS ATMEL Microcontroller 916 MHz

Dot ATMEGA163 1K RAM 8-16K Flash weC

Eyes MSP430F149 TR1001 8 Mbit PeerOS

IMote ARM core 12 MHz Bluetooth at range of 30 m 64K SRAM 512K Flash TinyOS

IMote 1.0 ARM 7TDMI 12-48 MHz Bluetooth at range of di 30 m 64K SRAM 512K Flash TinyOS

KMote TI MSP430 microcontroller 250 kbit/s 2.4 GHz IEEE 802.15.4 Chipcon Wireless Transceiver 10k RAM 48k Flash TinyOS eSOS

Mica Atmel ATMEGA103 4 MHz 8-bit CPU RFM TR1000 radio 50 kbit/s 128+4K RAM 512K Flash nesC TinyOS

Mica2 ATMEGA 128L Chipcon 868/916 MHz 4K RAM 128K Flash TinyOS,SOS eMantisOS

Mica2Dot ATMEGA 128 4K RAM 128K Flash

MicaZ ATMEGA 128 802.15.4/ZigBee compliant RF transceiver 4K RAM 128K Flash nesC TinyOS,SOS eMantisOS

Mulle Renesas M16C Bluetooth 2.0 31K RAM 256K Flash C Supporto TCP/IP

Nymph ATMEGA128L CC1000 64 kB EEPROM MantisOS

Rene ATMEL8535 916 MHz a 10 kbit/s 512 MB RAM 8K Flash TinyOS

SunSPOT ARM 920T 802.15.4 512K RAM 4 MB Flash Java SquawkVM

Telos Motorola HCS08 4K RAM

T-Mote Sky Texas Instruments MSP430 250 kbit/s 2.4 GHz IEEE 802.15.4. (Chipcon CC2420) 10k RAM 48k Flash TinyOS, SOS eMantisOS

weC Atmel AVR AT90S2313 RFM TR1000 RF

XYZ ML67 series ARM/THUMB microcontroller Chipcon CC2420 Zigbee compliant radio 32K RAM 256K Flash C SOS

Table 3 Software and Hardware configuration for sensor nodes

3.2 Spine

The SPINE framework has been used to design a human activity monitoring system prototype. This application is able to recognize postures (e.g. lying, sitting or standing still) and a few movements (e.g. walking and jumping) of a person; furthermore, it can detect if the monitored person has fallen and unable to stand up.The wearable nodes are based on the Tmote Sky platform to which is attached a custom sensor board (SPINE sensor-board) including a 3-axis accelerometer and two 2-axis gyroscopes. The nodes are powered by a standard 3.7V, 600mAh Li-Ion camera battery. The user application is implemented in the Java language and runs on top of a SPINE coordinator laptop to which is attached a Tmote Sky, acting as a base-station bridge, connected via USB port. The activity recognition system prototype relies on a classifier that takes accelerometer data measured by sensors placed on the waist and on a leg of a person and recognizes the movements defined in a training phase. Among the classification algorithms available in the literature, a K-Nearest Neighbor (KNN)-based classifier was defined.The prototype provides a default training set and a graphical wizard to let the user build his own training set to enhance recognition accuracy. The significant features to be activated on the node to classify the movements are then selected using an offline sequential forward floating selection (SFFS) approach or the native sequential forward selection (SFS), embedded in the application prototype, running much faster but with worse results. The experimental results show that, given a certain training set, the classification accuracy is not much affected by the K value or the type of distance metric used by the classifier. This is because, in this specific example, classes (lying, sitting, standing and walking) are rather separate and not affected by noise. Therefore, K=1 and the Manhattan distance as parameters of the KNN-based classifier were set up. The experiments have been performed using two sensor nodes: one placed on the waist and the other on the thigh of the right leg.

Section 4: EXPERIMENTS AND TEST4.1. Communication Protocol

The BMF is specifically designed for dense WSANs based on a wide range of heterogeneous platforms with numerous application scenarios. Although the BMF is mainly targeted to building indoors, its versatility would allow the framework to be effectively reused in different contexts (e.g. building outdoor monitoring, area monitors, industrial monitoring, agriculture monitoring). In particular, the BMF has been used for:1. Energy monitoring, analyzing data coming from the sensors to understand the energy spent in a building;2. Behavioral monitoring, understanding the behavior of people in building;3. Space monitoring, understanding the use of the spaces in building;4. Intelligent actuation, using actuators to achieve specific aims (e.g. energy saving, maximization of the comfort in the building).There are several cases of energy monitoring through WSNs which can be more effectively reengineered through BMF. In particular, in low power cameras are used to monitor the occupancy of several rooms through the capture of small images that are elaborated on the node through processing algorithms. To allow controlling the HVAC (Heating, Ventilation and Air Conditioning) system for those rooms by using BMF, such cameras could be dynamically grouped and controlled so to seamlessly manage the application deployment in several building without the need to reprogram the nodes individually; similarly, the system to monitor, schedule, and manage energy in conference rooms could also be greatly enhanced through the BMF. In this case waste of energy is intended like the energy used to power on the lights if the ambient light from the windows was enough or if there are no people in the office. In the system all nodes were programmed to periodically send every few seconds the data of ambient lighting, lighting state and presence detection.The realization with the BMF of the cases exposed above would be effective and straightforward due to the flexibility of the framework that allows to set over the air the proper nodes to produce the data requested at the target rate. The BMF autonomously collects data from the WSAN, stores it in files or database and allows elaborating it in real time through a specifically created OSGi-Bundle which can be designed, for example, to process data and actuate actions on the network. The possibility to introduce new and dynamic OSGi- Bundles on the BS side is very important and represents a major improvement with respect to other existing frameworks which provide monolithic BSs that can be extended only stopping and restarting a network.To show the functionalities and the effectiveness of the BMF to support the monitoring of the inhabitants' behavior in a building and energy auditing, we created a test for our office. In this office the sensor nodes are distributed throughout the office space to collect the appropriate data while BMF is responsible for the management of the network and the configuration of the nodes.In the attempt to identify energy usage per workstation, lighting and humidity and temperature can be considered as shared entities while electrical sockets can be attributed to individual workstations. In fact, wall-mounted radiators provide heating while the office space is provided with a standard lighting array covering the whole space. Each monitored workstation was provided with a PC or a laptop and was occupied by a full time employee. The office and sensor layout is shown in the next figure (Figure 22). Each workstation is furnished with two types of sensor, an infra-red (IR) presence detector for the occupancy, and an electricity monitor to measure the electrical energy used by the workstation. Several light sensors placed above PVC ceiling panels determine the activity of the lighting array while avoiding exposure to ambient light in the laboratory. Each radiator is provided with two temperature sensors - one sensor on the inflow and one on the outflow pipe used to monitor the radiated energy. In particular, this test included: (1) ACme Electricity monitors used to measure the electricity at each workstation; (2) Wieye IR sensor board on top of Crossbow TelosB motes to measure occupancy and light utilization; (3) Tyndall 25mm motes equipped with temperature sensor for the radiator activity.

Figure 27 The office node distribution

We should create a separate group for each destination of use of the nodes and for each workstation. Nodes are joined to groups as soon as they are deployed in the laboratory and switched on. Here are the groups that are basically set: The workstation group consists of an electricity monitor and an occupancy monitor. A workstation group is set for each workstation. The light array group contains a single node to determine the state of the lighting array. To save on node transmissions, the BMF allows setting simple and yet effective aggregation mechanisms such as threshold-driven transmission used for the lighting array group to identify on/o_ lighting state. The ambient lighting and temperature group contains a number of nodes distributed throughout the office to measure the light level and the temperature. A task of average value on light and temperature sensors calculated over a minute was set for this group. The electricity group contains the ACme electricity monitors. A task of average value on electricity sensor calculated over a minute was set on the nodes of this group. The presence group contains the presence detectors for each workstation. The radiators group contains nodes equipped with temperature sensor to sample radiators activity.

The group configuration is shown in the next table:

Group#NodesSensing typeSamplingAggregationSelection

Light system1Light[x]1Threshold transition

Ambient2Light [x] & Temperature [ C] 1Average2/4

Presence40IR1Max

Electricity40Power[W]1Average

Radiators10Temperature[C]60None

Table 4 Group configuration For making the application running we have to plug the basesation on the User B computer like it is shown in the figure 23 and the node connection should be plugged in the User A and C computers like in Figure 24.

Figure 28 The basestation connection Figure 29 Sensor connection

If the basestation and the Sensor nodes are connected like in the above figures we are able to run the application for asking the nodes the humidity, temperature and the ambient light. The console results are:

Till now the basestation is seen by the application and it send the configuration packet to node, according to the Protocol described in section 2. As it is written in the Communication diagram after receiving the configuration packet the nodes should send back the ACK-packet:

In that moment the humidity, temperature and light nodes are able to send the current data to basestation.

4.2 Gateway between and BMF and Spine The experiments have been performed using two sensor nodes: one placed on the waist and the other on the thigh of the right leg.The resultant most significant features are: Waist node: mean on the accelerometer axes X Y Z, min value and max value on the accelerometer axis X;

Figure 30 Waist sensor position

Leg node: min value on the accelerometer axis X

Figure 31 Leg sensor position

Figure 32 Waist and leg sensors positionSPINE architecture consists of two entities, one on the sensor nodes and the other on a coordinator station. Such a coordinator can be a desktop computer, a laptop or even a PDA or a smart-phone. The coordinator provides the end-user application with an access point to the wireless BSN. Thus, its main tasks are controlling the remote nodes and capturing the various messages and events generated, according to the user-application needs.The BMF architecture is presented in the above section so in this point the basestation is able to collect the data from Spine nodes through the gateway that is presented in section 2.First of when the application is run both agents start to run and the communication between them are made according to the communication diagrams presented in the section 2.As we saw in Section 2 there are two types of requests: One shut: the BMF wants to know the current activity from Spine side. First the BMF Agent send to Spine Agent a request to ask it what can you do? in order to know what are the available functions that Spine can provide. In our case the gateway is able to collect only the activity data, so the Spine application will always respond with 25, which is a specific code for activity function.

Once the BMF Agent receives the code, it sends to basestation an A-PKT in order to advertise its availability. After that the basestation should sends the configuration packet in order to initialize one behavior, in our case One Shut Behavior. -----Behaviour One-Shot----BMF Agent: sent request to Spine Agent (one shot)Spine Agent: Received Give me the activity from:BMFAgent Message:20|Spine Agent: Sent data colected from virtual nodes to BMF Agent:20|BMF Agent:Received from SpineAgent message: activity 20The BS received data packet--------Communication ended-------- One Shut Behavior with threshold value: the basestation sends the configuration packet with the threshold value set to the equal threshold and the value will be 20 (lying).

BMF Agent runningBMF Agent: sent request to Spine Agent for see what it can doSpine Agent runningSpine Agent: Receive one request from:BMFAgent Spine Agent: Sent what can it do to BMF Agent:25BMFAgent: received from SpineAgent message 25Gateway BEHAVIOUR START.....The BS send the configuration packet......ACTIVITY ONE SHOT .....The BS: received the ack packet for the packet PKT_TYPE_CONFIGURATION_SCHEDULEGateway BEHAVIOUR REQUEST SENT .....lifetime:0-----Behaviour One-Shot----BMF Agent: sent request to Spine Agent (one shot)Spine Agent: Received Give me the activity from: BMFAgent Message:20|Spine Agent: Sent data collected from virtual nodes to BMF Agent:20|BMF Agent: Received from SpineAgent message: activity 20BMF Accepted 20The BS received data packet Periodical behavior: after receiving the virtual code for the activity, the basestation sends the configuration packet according to periodical behavior.

After that basestation sends the configuration packet to BMF Agent and the agent after receiving the packet it will send back ACK-Packet to basestation and after that will be tracked the communication diagram presented in Section 2.The BMF Agent will ask for the last activity till the lifetime value will be reached, when it will be reached the communication will be ended.

Periodical behavior with threshold: when the threshold value is set and the lifetime value is bigger than 1, the periodical behavior will act in this way.

Conclusions

We have described the Building Management Framework (BMF), a domain specific framework for effective management of WSAN, Wireless Sensor and Actuator Networks, which enables proactive monitoring of spaces and control of devices/equipments. BMF is specifically designed to provide flexible and efficient management of networked sensors and actuators and abstractions for logical and physical node grouping to expressively capture the morphology of buildings. The overall goal is to provide a versatile platform to allow intelligent sensing and actuation techniques, integration of heterogeneous WSANs, flexible system programming at low- and high-level, fast deployment of different applications through message-based programming.BMF is the only framework specifically conceived to address Building Management that fullest all the requirements identified by building applications which are lacking in frameworks for WSN-based monitoring (e.g. TinyDB, Swis-sQM, Abstract Regions and FiGaRo).BMF is basically organized in two modular layers residing on the sensor nodes (sensor-based services) and at the BS side (system-wide services). While from one side, it facilitates the deployment of heterogeneous nodes, management and maintenance of the network operations, from the other side, it assists the application developer with an extensible set of OSGi Bundles to allow basic and advanced control of the building. BMF is currently implemented in Java following the OSGi paradigm on the BS side and in TinyOS, on the TelosB, Tyndall, and Epic platforms, and Java, on the SunSPOT platform, at sensor node side.The effectiveness of BMF has been demonstrated through tests, a BMF-based application for energy monitoring in computer laboratory/office environments. The tests has shown not only flexibility in terms of monitoring(request schedule and data reception) and simplicity in the extraction of information, but also an interesting demonstrator of energy profiling application in building environments.Future work will investigate the coordination of multiple BS aiming to manage larger/a group of buildings. In fact, a limitation of the current implementation is the scalability to hundreds of nodes, which causes overloading with the loss of too many packets and significant delays of tens of seconds, which may prevent the implementation of real-time actuation of critical appliances. In this case, a multi-BS system can significantly reduce the packet transmission delay and would allow nodes to work on a lower duty cycle to reduce the energy spent in the network extending its lifetime. Future work will also design a high-level OSGi based architecture for Smart Buildings atop the proposed architecture to trade o_ inhabitants' personal comfort and building energy expenditure. In fact, while the proposed framework is effective to manage WSAN in buildings, it requires data mining techniques to infer information about habits and preferences of inhabitants of the building and merge them with energy saving techniques.References1. Akkaya, K., Younis, M., 5 2005. A survey on routing protocols for wireless sensor networks. Ad Hoc Networks 3.2. Fortino, G.,Gurriere, A.BMF, 20113. BMF, 2011. Building Management Framework.URL http://bmf.deis.unical.it/4. Doukas, H., Patlitzianas, K., Iatropoulos, K., Psarras, J., 2007. Intelligent building energy management system using rule sets. Building and Environment 42 (10).5. EpiSensor, 2011. EpiSensor SiCA for Building Management.URL http://episensor.com/solutions/building-management/6. I.F. Akyildiz, W. Su*, Y. Sankarasubramaniam, E. Cayirci Wireless sensor networks: a survey,2001

A Annex: BMF Class diagramPackets:1. ie.ucd.clarity.bmf.aggregator

2. ie.ucd.clarity.bmf.common;

3. ie.ucd.clarity.bmf.communication;

4. ie.ucd.clarity.bmf.configurationfile;

5. ie.ucd.clarity.bmf.data;

6. ie.ucd.clarity.bmf.data.file;

7. ie.ucd.clarity.bmf.network.manager;

8. ie.ucd.clarity.bmf.network.manager.configurationPackets;

9. ie.ucd.clarity.bmf.network.manager.nodesAndGroups;

10. ie.ucd.clarity.bmf.network.manager.nodesAndGroupsManager;

11. ie.ucd.clarity.bmf.network.platform;

12. ie.ucd.clarity.bmf.network.platform.tinyOS;

13. Main class

14. Communication between packets:

B Annex Source code for Communication between basestation and node1. Configuration Packetpackage ie.ucd.clarity.bmf.communication;

import ie.ucd.clarity.bmf.communication.IConfigurationPacket;

import ie.ucd.clarity.bmf.common.Constants;import ie.ucd.clarity.bmf.common.InvalidPacketParametersException;import ie.ucd.clarity.bmf.communication.IDestination;

/** * @author Angela */public class ConfigurationPacket implements IConfigurationPacket {private int configurationType;private IDestination dest;private int requestID;private int periodTimescale;private int periodValue;private int lifetimeTimescale;private int lifetimeValue;private int action;private int sensor_actuatorType;private int actuatorParams; // actuator caseprivate int dataType;private int syntheticData;private int thresholdNumber;private int sensorIfThreshold;private int[] thresholdType;private int[] thresholdValue;private int[] sensorTypeMoreThreshold;

public ConfigurationPacket() {dest = new Destination();}public ConfigurationPacket(int configurationType, int requestID,int periodTimescale, int periodValue, int lifetimeTimescale,int lifetimeValue, int action, int sensor_actuatorType,int actuatorParams) throws InvalidPacketParametersException {

dest = new Destination();

if (configurationType == Constants.PKT_TYPE_CONFIGURATION_SCHEDULE|| configurationType == Constants.PKT_TYPE_CONFIGURATION_UNSCHEDULE)this.configurationType = configurationType;elsethrow new InvalidPacketParametersException("WRONG CONFIGURATION TYPE!");

this.requestID = requestID;this.periodTimescale = periodTimescale;this.periodValue = periodValue;this.lifetimeTimescale = lifetimeTimescale;this.lifetimeValue = lifetimeValue;this.action = action;this.sensor_actuatorType = sensor_actuatorType;this.actuatorParams = actuatorParams;

}

public ConfigurationPacket(int configurationType,

int requestID, int periodTimescale, int periodValue,int lifetimeTimescale, int lifetimeValue, int action,int sensor_actuatorType,int dataType, int syntheticData

) throws InvalidPacketParametersException {

dest = new Destination();

if (configurationType == Constants.PKT_TYPE_CONFIGURATION_SCHEDULE|| configurationType == Constants.PKT_TYPE_CONFIGURATION_UNSCHEDULE)this.configurationType = configurationType;elsethrow new InvalidPacketParametersException("WRONG CONFIGURATION TYPE!");

this.requestID = requestID;this.periodTimescale = periodTimescale;this.periodValue = periodValue;this.lifetimeTimescale = lifetimeTimescale;this.lifetimeValue = lifetimeValue;this.action = action;this.sensor_actuatorType = sensor_actuatorType;this.dataType = dataType;this.syntheticData = syntheticData;

public ConfigurationPacket(int configurationType, int requestID, int periodTimescale,int periodValue, int lifetimeTimescale, int lifetimeValue,int action, int sensor_actuatorType,int dataType, int syntheticData,int thresholdNumber, int sensorIfThreshold, int[] thresholdType,int[] thresholdValue, int[] sensorTypeMoreThreshold)throws InvalidPacketParametersException {

if (configurationType == Constants.PKT_TYPE_CONFIGURATION_SCHEDULE|| configurationType == Constants.PKT_TYPE_CONFIGURATION_UNSCHEDULE)this.configurationType = configurationType;elsethrow new InvalidPacketParametersException("WRONG CONFIGURATION TYPE!");

if (!isThresholdNumberCompatibleWithPacket(thresholdNumber,thresholdType, thresholdValue, sensorTypeMoreThreshold)) {// ERROR: NO COMPATIBILITY among threshold notification parametersthrow new InvalidPacketParametersException("ConfigurationPacket: NO COMPATIBILITY AMONG THRESHOLD NOTIFICATION PARAMETERS!");}dest = new Destination();this.requestID = requestID;this.periodTimescale = periodTimescale;this.periodValue = periodValue;this.lifetimeTimescale = lifetimeTimescale;this.lifetimeValue = lifetimeValue;this.action = action;this.sensor_actuatorType = sensor_actuatorType;this.dataType = dataType;this.syntheticData = syntheticData;this.thresholdNumber = thresholdNumber;this.sensorIfThreshold = sensorIfThreshold;this.thresholdType = new int[thresholdType.length];System.arraycopy(thresholdType, 0, this.thresholdType, 0,thresholdType.length);this.thresholdValue = new int[thresholdValue.length];System.arraycopy(thresholdValue, 0, this.thresholdValue, 0,thresholdValue.length);this.sensorTypeMoreThreshold = new int[sensorTypeMoreThreshold.length];System.arraycopy(sensorTypeMoreThreshold, 0,this.sensorTypeMoreThreshold, 0,sensorTypeMoreThreshold.length);}

public boolean isThresholdNumberCompatibleWithPacket(int thresholdNumber,int[] thresholdType, int[] thresholdValue,int[] sensorTypeMoreThreshold) {return thresholdNumber == thresholdType.length&& thresholdNumber == thresholdValue.length&& thresholdNumber == (sensorTypeMoreThreshold.length + 1);}public void setDestinationNode(int destNodeID) {dest.setDestinationNode(destNodeID);}

public void