# An Open and Modular Hardware Node for Wireless Sensor and Body Area Networks

Authors: L. Ciabattoni; A. Freddi; S. Longhi; A. Monteriù; L. Pepa; M. Prist
Journal: Journal of Sensors
 (2016)

---

## Abstract

Health monitoring is nowadays one of the hottest markets due to the increasing interest in prevention and treatment of physical problems. In this context the development of wearable, wireless, open-source, and nonintrusive sensing solutions is still an open problem. Indeed, most of the existing commercial architectures are closed and provide little flexibility. In this paper, an open hardware architecture for designing a modular wireless sensor node for health monitoring is proposed. By separating the connection and sensing functions in two separate boards, compliant with the IEEE1451 standard, we add plug and play capabilities to analog transducers, while granting at the same time a high level of customization. As an additional contribution of the work, we developed a cosimulation tool which simplifies the physical connection with the hardware devices and provides support for complex systems. Finally, a wireless body area network for fall detection and health monitoring, based on wireless node prototypes realized according to the proposed architecture, is presented as an application scenario.


---

## Body

## 1. Introduction

The application of Wireless Sensor Network (WSN) technology in different scenarios rapidly increased in the past few years [1–3]. The recent interest in this topic can be attributed to several factors:(i)
The growing availability on the market of small and inexpensive sensors and devices easy to embed.(ii)
The worldwide diffusion of networking technologies, such as Wi-Fi, Ethernet, and Bluetooth which makes the communication between devices easier.(iii)
The presence of small computing devices (such as smartphones, tablets, and netbooks) in daily living.As reported in [4, 5], one of its innovative deployments relates to biomedical sensor networks to monitor human vital signals. The most important change in demographic situation in the European Union is the transition towards a much older population. In this context a technology that promises to bring elderly people health care to a higher level of personalization is the Wireless Body Area Network (WBAN) [6, 7]. WBAN and Wireless Body Sensor Network (WBSN) are terms used to describe the application of wearable computing devices in Ambient Assisted Living (AAL). Patient monitoring systems can be used to collect patient physical status related data at home, and in some cases outdoors, to facilitate disease management, diagnosis, prediction, and follow-up [8, 9].A Body Sensor Network (BSN) consists of a number of smart sensors with limited computing, storage, communication, and energy resources. These sensors are placed around the human body in order to collect various vital parameters related to the patient’s health status. In this domain, due to the unacceptability of wired technologies over the human body, the wireless approach is the only solution; see, for example, [10–12]. However, WBSN technology still poses many challenges.WSNs are composed of sensor nodes that autonomously operate by gathering sensors information and combining both communication and computational capabilities in a small form factor. These nodes, establishing a wireless link, collaborate with each other to execute application tasks. The main obstacles to the spread diffusion of this technology are mainly represented by communication issues (in terms of reliability and latency), power supply issues, and flexibility [13, 14]. Indeed, most of the existing commercial node architectures provide little flexibility, configurability, and the absence of interoperability among them. Daughter boards provide sensing capabilities, but the processing and communication modules are fixed and cannot be often extended. These limitations constrain the cross-usability of the same node in different applications and the use of different branded nodes in the same application.In this paper we face the flexibility and customization problem in Wireless Sensor Networks, and in particular in Wireless Body Area Networks, presenting a novel architecture of an open hardware wireless modular sensor node. By separating the connection and sensing functions into two separate boards, the new architecture adds plug and play capabilities to analog transducers, while providing at the same time a higher level of customization for the whole network. The node hardware designer can thus exploit the modular architecture to implement different features, such as occupancy reduction, improved energy management, and increased power transmission, while always remaining compliant with the IEEE1451 standard. An additional contribution of the work regards the development of a cosimulation tool which simplifies the physical connection with the hardware devices and provides support for complex systems. We finally present prototypes of the wireless nodes and use them to build a wireless body area network for fall detection and health monitoring.The paper is organized as follows. In Section2 we review the state of the art in WSNs. The innovative design of the proposed node and a brief introduction to the IEEE standards are discussed in Section 3, while the hardware, chosen for the prototype, is reported in Section 4. In Section 5, a brief description of the developed cosimulation tool is reported. The proposed WBAN application is described in Section 6 where the modular node has been configured to monitor different vital parameters. Some remarks conclude the paper.


## 2. WSNs State of the Art

WSNs are generally composed of a large number of nodes which operate in a specific configuration. Typically, the sensor nodes are autonomous and spatially distributed and cooperate to monitor and to gather environmental conditions. Data processing can be done either in a centralized/decentralized mode or by sending data to a sink which sends them to other networks (e.g., through a gateway). Project, design, prototyping, and utilization of a WSN include a wide range of application-specific constraints. Even if WSNs are application dependent, it is possible to classify them in relation to common features:(1)
self-organization capabilities;(2)
short-range communication and/or star/multihop routing;(3)
centralized or decentralized cooperation of sensor nodes;(4)
capability to modify topology in runtime;(5)
constrains in energy consumption, transmission range, memory, computing power, and security.The sensor nodes of a WSN, typically, are made up of three basic building blocks: sensing unit, computational unit, and communication unit. In order for a WSN to operate properly, the sensor nodes require an operating system, a routing protocol, and eventually a simulator. In the following, we provide an overview of the state of the art of operating systems, routing protocols, and simulators for WSNs, together with a short list of commercially available wireless sensor nodes.


### 2.1. Operating Systems

The most critical problems which can affect a WSN are the absence of hardware nodes standardization (the architectures provide little flexibility and configurability), energy consumption (typically provided by a small capacity battery), quality of service (communication delay, packets loss, and the out-of-order packets), scalability, distributed reconfiguration, programmability, and memory, which often allows only a few kilobytes of storage. In this context the Operating System (OS) becomes the manager for allocating the limited resources in a correctly and controlled manner. The main OSs for WSNs are presented in the following.


#### 2.1.1. TinyOS

TinyOS is open source, flexible, based on component and module, and designed specifically for wireless sensor networks [15]. TinyOS supports concurrent programs with very low memory requirements and it includes many libraries to manage network protocols, distributed services, transducer drivers, and data gathering tools. The runtime of this OS is based on a monolithic architecture class and it uses the component model to compose a static image that runs on the node. From version 2.1, TinyOS provides support for multithreading, called TOS Threads, which uses a cooperative threading approach.


#### 2.1.2. Contiki

This OS, developed by the Swedish Institute of Computer Science, is a lightweight, open-source OS written in C for WSNs [16]. It is a highly portable OS and it is based on an event-driven kernel. Contiki provides multitasking, so called Protothreads, that can be used at the individual process level. Contiki project includes many features to support an application-specific scenario, like multitasking kernel, preemptive multithreading, Protothreads, TCP/IP protocol, IPv6 protocol, a simple web server, a light telnet client, and so forth. Although Contiki supports dynamic memory management, it does not provide any support for real-time applications.


#### 2.1.3. MANTIS

The MultimodAl system for NeTworks of In Situ Wireless Sensors (MANTIS) [17] is an operating system for WSNs based on multithreaded approach. MANTIS is a lightweight and energy efficient OS which includes kernel, scheduler, and network stack and, in addition, it is portable across multiple platforms, that is, PDA or a PC.


#### 2.1.4. Nano-RK

Nano-RK is a real-time OS for WSNs based on multitasking [18]. The design goals for Nano-RK are the multihop networking, efficient power management to extend WSN lifetime, light applications with limited resources, and priority-based scheduling.


#### 2.1.5. LiteOS

LiteOS is a Unix-like OS developed by the University of Illinois at Urbana-Champaign to support WSNs programming [19]. LiteOS provides a familiar programming environment based on Unix, threads, and C. It follows a hybrid programming model that allows both event-driven and thread-driven programming.


### 2.2. Routing Protocols

Routing is the key process for data transmission within a WSN. It consists in determining a path between the source node and the sink (destination) node. The routing protocols can be mainly classified into different ways as follows.


#### 2.2.1. Path Establishment Based Routing Protocols

The routing paths can be calculated in three different ways: proactive, reactive, or hybrid. The proactive protocols develop all the possible routes before they are needed and then create a routing table in each node. Reactive protocols use a dynamic research techniques based on the request to send message. The hybrid routing strategies, instead, use clustering techniques to stabilize and scale the network and thus are generally applicable to networks of larger size and contain both strategies.


#### 2.2.2. Network-Based Routing Protocols

Protocols included into this family are further classified into three classes in relation to their functionalities.Flat-Based Routing. Flat-based routing is used when a WSN is composed of a large amount of sensor nodes and the gateway sends a request to a group of specific motes in a bounded area and waits for response.Hierarchical-Based Routing. Hierarchical-based routing is used when within a WSN scalability and efficient communications are needed. This protocol is based on an energy efficient method in which nodes with high batteries are randomly selected for data analysis and sending data, while nodes with low battery are used for sensing and send data to the master. This increases the network scalability, lifetime, and energy usage.Location-Based Routing. In this routing architecture, motes are distributed randomly, with a geographic position known in a specific region and the distance between nodes is calculated using the signal strength received from those nodes.


#### 2.2.3. Operation-Based Routing Protocols

WSNs applications as well as routing protocols can be classified according to their operations.Multipath Routing Protocols. These protocols provide multiple path selection in order to decrease delay and increase network performance, but they consume a great amount of energy.Query-Based Routing Protocols. This type of protocols is based on distributed data queries using high level languages.Negotiation-Based Routing Protocols. These protocols use intelligent algorithm for communication based on network available resources.


#### 2.2.4. Next-Hop Selection-Based Routing Protocols

These protocols determine the next hop on the route. The decision can be based on(i)
the query content;(ii)
probabilistic approach and random selection of the next-hop neighbor;(iii)
the known position of the neighbors and the destination.Alternatively, each mote in the network can decide individually whether to forward a message or not.


### 2.3. Commercial Solutions

Due to a wide range of application areas, a great number of solutions for wireless sensor nodes have been designed and commercialized. Nowadays there are mainly two kinds of nodes used in WSNs. The first one is the normal sensor node deployed to sense the phenomena and gather data, while the second is the gateway node that interfaces sensor networks to the external world. Commercial solutions, research prototypes of wireless sensor nodes, and their main features are illustrated in Table1, and some samples are depicted in Figures 1 and 2. About sensor nodes for WBANs, different commercial solutions exist and some of them are shown in Figure 3.Table 1
Commercial nodes.
Node Name
Micro
Transceiver
Remarks
Maker
COOKIES [20]
ADUC841, MSP430
ETRX2 TELEGESIS, and ZigBit 868/915
Platform with hardware reconfigurability (Spartan 3FPGA based or Actel Igloo)
Centro de Electronica Industrial, Universidad Politécnica de Madrid
BTnode [21]
Atmel ATmega 128L (8 MHz @ 8 MIPS)
Chipcon CC1000 (433–915 MHz) and Bluetooth (2.4 GHz)
BTnut and TinyOS support
Computer Engineering and Networks Laboratory, ETH Zurich
EPIC mote [22]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
TinyOS
University of California at Berkeley
Eyes [23]
MSP430F149
TR1001
PeerOS Support
TU Berlin, Germany
FlatMesh FM1 [24]
16 MHz
802.15.4 compliant
Commercial system, for digital sensors. Second generation with built-in tilt sensor
Senceive Ltd., London, UK
IMote [25]
ARM core 12 MHz
Bluetooth with the range of 30 m
TinyOS Support
Intel Research, USA
IMote 2.0 [25]
Marvell PXA271 ARM 11–400 MHz
TI CC2420 802.15.4/ZigBee compliant radio
Microsoft.NET Micro, Linux, and TinyOS Support
Intel Research, USA
T-Mote Sky [26]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
Contiki, TinyOS, SOS, and MantisOS Support
Advantic Sistemas y Servicios S.L., Madrid, Spain
Waspmote [27]
Atmel ATmega 1281
ZigBee/802.15.4/DigiMesh/RF,2.4 GHz/868/900 MHz
GPRS, Bluetooth, and GPS modules, sensor boards
Libelium Comunicaciones Distribuidas S.L., Zaragoza, Spain
INDriya [28]
Atmel ATmega 128L
IEEE802.15.4 compliant XBee radios
Comprehensive sensor mote with ambient light, temperature, accelerometer, JPEG camera, PIR, sound sensor, TinyOS, TinyOS compliant, and IPv6 network supportive stacks for internetworking
Indrion Technologies Ltd., Bangalore, India
Iris Mote [29]
ATmega 1281
Atmel AT86RF230 802.15.4/ZigBee compliant radio
Mote Runner, TinyOS, and MoteWorks Support
MEMSIC Inc., Andover, MA, USA
Mica2 [30]
ATMEGA 128L
Chipcon 868/916 MHz
TinyOS, SOS, and MantisOS Support
University of California at Berkeley, USA
MicaZ [30]
ATMEGA 128
TI CC2420 802.15.4/ZigBee compliant radio
TinyOS, SOS, MantisOS, and Nano-RK Support
University of California at Berkeley, USA
Mulle [31]
Renesas M16C
Atmel AT86RF230 802.15.4/Bluetooth 2.0
Contiki, TinyOS, lwIP: TCP/IP and Bluetooth Profiles: LAP, DUN, PAN, and SPP Support
Eishtec AB, Sweden
PowWow [32]
MSP430F1612
TI CC2420 802.15.4/ZigBee compliant radio
Open source; open hardware; and research platform
INRIA CAIRN, Université de Rennes
Preon32 [33]
ARM Cortex M3
Atmel AT86RF231 (2.4 GHz)
Virtual machine, Contiki and 6LoWPan supported
Virtenio GmbH, Berlin, Germany
Shimmer [34]
MSP430F1611
802.15.4 Shimmer SR7 (TI CC2420)
TinyOS Support. Built-In 3-Axis Accel., Tilt/Vib Sensor. Full range of expansion modules
Shimmer Sensing, Dublin, Ireland
TelosB [26]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
Contiki, TinyOS, SOS, and MantisOS Support
Advantic Sistemas y Servicios S.L., Madrid, SpainFigure 1
Intel family motes.
(a)
Intel Mote
(b)
Intel Mote 2Figure 2
Samples of commercial sensor nodes.
(a)
Smart Dust Mote conceptual diagram
(b)
Mica Mote
(c)
Tmote Sky Mote
(d)
BTnode MoteFigure 3
Samples of WBAN sensor nodes.
(a)
Limb mobility—EXLs1 [35]
(b)
SuWBAN Platform [36]
(c)
BSN Development Kit [37]


### 2.4. WSN Simulators

In order to realize a real scenario or a test bench which provides realistic results, the physical architecture and the hardware development require a lot of resources, and the WSN programming and debug become extremely complex. In this context, wireless sensor network simulation becomes a very important and essential tool which provides good results in a cost effective way. The WSN simulators can be divided into different categories in relation to their features and applications:(i)
code level simulators;(ii)
topology control simulators;(iii)
environment and wireless medium simulators.Due to the ability to increase the real WSN prototyping, the Cross Levels Simulators, like COOJA, have become an important class of simulators. This kind of simulators operates at three abstraction levels: the network level, the operating system level, and the machine code instruction set level. Although they are open source, flexible, and extensible at all levels, the test interface, the external connection at a physical level and the direct interaction with the process control via the WSN are very poor [38]. In recent years, to solve these problems, a few numbers of cosimulators have been developed which integrate WSN simulators and MATLAB/Simulink tools. The Simulink tool provides a wide range of library and simulation model blocks but does not provide an adequate physical connection with the hardware devices used in a Cyber-Physical System (CPS), and it is not possible to simulate complex systems like WBAN or IEEE1451 standard architecture.The mainsimulators for WSNs are the following.(1) Avrora. Avrora is an emulator and a code level simulator [39]. It is used to emulate the sensor hardware or to process the program code as it would be on a real hardware device. Avrora is a command-line framework compatible with MEMSIC Mica2 and MicaZ sensor platforms.(2) TOSSIM. It is an emulator for WSNs running TinyOS [40]. The simulation environment permits creating a common topology which runs exactly the same TinyOS applications.(3) COOJA. COOJA Simulator, by Swedish Institute of Computer Science, is an open-source simulator for the Contiki sensor node operating system [41]. The simulator operates at three abstraction levels, the code level, the topology control level, and the environment and wireless medium level.(4) Atarraya. Atarraya is a simulator for topology construction and topology maintenance in WSNs [42].The maincosimulators for WSNs are the following.(5) WCPS. In [43] an open-source simulation environment for wireless control systems, namely, Wireless Cyber-Physical Simulator (WCPS), has been proposed. This solution integrates Simulink and the TOSSIM wireless sensor simulator [40]. WCPS has been used to manage the physical systems and the wireless sensor-actuator networks used for control. Unfortunately, TOSSIM simulator supports only TinyOS Operating System and the MICAZ hardware platform [44].(6) NCSWT. The Networked Control Systems Wind Tunnel (NCSWT), a new integrated modeling and simulation tool for the evaluation of networked control systems, has been proposed in [45]. NCSWT integrates MATLAB/Simulink and ns-2 simulator using the High Level Architecture for an accurate time synchronization and data communication in heterogenous simulations [45].(7) PiccSIM. In [46] the authors proposed a new Platform for Integrated Communications and Control design, Simulation, Implementation and Modeling (PiccSIM) composed of Simulink and ns-2. The communication between the two frameworks, for sending and receiving sensor data, time synchronization, and node position, is network-based with UDP packets.(8) GISOO. A new virtual testbed for simulation of wireless cyberphysical systems that integrates two state-of-the art simulators, Simulink and COOJA, namely, GISOO, has been developed by the Swedish KTH Royal Institute of Technology [47]. The main base is the cross-level simulator COOJA, that permits to manage(i)
the code level simulators which emulate the sensor hardware, the process and, simultaneously, permit executing the program code directly on a real device;(ii)
the topology control level simulators which are used to study topology construction mechanisms;(iii)
the environment and wireless medium level simulators which offer the opportunity to simulate physical phenomena [48].In addition to the COOJA features, GISOO integrates the Simulink advantages, thus allowing to extend the three levels with a new one for the cyberphysical modeling [49].


## 2.1. Operating Systems

The most critical problems which can affect a WSN are the absence of hardware nodes standardization (the architectures provide little flexibility and configurability), energy consumption (typically provided by a small capacity battery), quality of service (communication delay, packets loss, and the out-of-order packets), scalability, distributed reconfiguration, programmability, and memory, which often allows only a few kilobytes of storage. In this context the Operating System (OS) becomes the manager for allocating the limited resources in a correctly and controlled manner. The main OSs for WSNs are presented in the following.


### 2.1.1. TinyOS

TinyOS is open source, flexible, based on component and module, and designed specifically for wireless sensor networks [15]. TinyOS supports concurrent programs with very low memory requirements and it includes many libraries to manage network protocols, distributed services, transducer drivers, and data gathering tools. The runtime of this OS is based on a monolithic architecture class and it uses the component model to compose a static image that runs on the node. From version 2.1, TinyOS provides support for multithreading, called TOS Threads, which uses a cooperative threading approach.


### 2.1.2. Contiki

This OS, developed by the Swedish Institute of Computer Science, is a lightweight, open-source OS written in C for WSNs [16]. It is a highly portable OS and it is based on an event-driven kernel. Contiki provides multitasking, so called Protothreads, that can be used at the individual process level. Contiki project includes many features to support an application-specific scenario, like multitasking kernel, preemptive multithreading, Protothreads, TCP/IP protocol, IPv6 protocol, a simple web server, a light telnet client, and so forth. Although Contiki supports dynamic memory management, it does not provide any support for real-time applications.


### 2.1.3. MANTIS

The MultimodAl system for NeTworks of In Situ Wireless Sensors (MANTIS) [17] is an operating system for WSNs based on multithreaded approach. MANTIS is a lightweight and energy efficient OS which includes kernel, scheduler, and network stack and, in addition, it is portable across multiple platforms, that is, PDA or a PC.


### 2.1.4. Nano-RK

Nano-RK is a real-time OS for WSNs based on multitasking [18]. The design goals for Nano-RK are the multihop networking, efficient power management to extend WSN lifetime, light applications with limited resources, and priority-based scheduling.


### 2.1.5. LiteOS

LiteOS is a Unix-like OS developed by the University of Illinois at Urbana-Champaign to support WSNs programming [19]. LiteOS provides a familiar programming environment based on Unix, threads, and C. It follows a hybrid programming model that allows both event-driven and thread-driven programming.


## 2.1.1. TinyOS

TinyOS is open source, flexible, based on component and module, and designed specifically for wireless sensor networks [15]. TinyOS supports concurrent programs with very low memory requirements and it includes many libraries to manage network protocols, distributed services, transducer drivers, and data gathering tools. The runtime of this OS is based on a monolithic architecture class and it uses the component model to compose a static image that runs on the node. From version 2.1, TinyOS provides support for multithreading, called TOS Threads, which uses a cooperative threading approach.


## 2.1.2. Contiki

This OS, developed by the Swedish Institute of Computer Science, is a lightweight, open-source OS written in C for WSNs [16]. It is a highly portable OS and it is based on an event-driven kernel. Contiki provides multitasking, so called Protothreads, that can be used at the individual process level. Contiki project includes many features to support an application-specific scenario, like multitasking kernel, preemptive multithreading, Protothreads, TCP/IP protocol, IPv6 protocol, a simple web server, a light telnet client, and so forth. Although Contiki supports dynamic memory management, it does not provide any support for real-time applications.


## 2.1.3. MANTIS

The MultimodAl system for NeTworks of In Situ Wireless Sensors (MANTIS) [17] is an operating system for WSNs based on multithreaded approach. MANTIS is a lightweight and energy efficient OS which includes kernel, scheduler, and network stack and, in addition, it is portable across multiple platforms, that is, PDA or a PC.


## 2.1.4. Nano-RK

Nano-RK is a real-time OS for WSNs based on multitasking [18]. The design goals for Nano-RK are the multihop networking, efficient power management to extend WSN lifetime, light applications with limited resources, and priority-based scheduling.


## 2.1.5. LiteOS

LiteOS is a Unix-like OS developed by the University of Illinois at Urbana-Champaign to support WSNs programming [19]. LiteOS provides a familiar programming environment based on Unix, threads, and C. It follows a hybrid programming model that allows both event-driven and thread-driven programming.


## 2.2. Routing Protocols

Routing is the key process for data transmission within a WSN. It consists in determining a path between the source node and the sink (destination) node. The routing protocols can be mainly classified into different ways as follows.


### 2.2.1. Path Establishment Based Routing Protocols

The routing paths can be calculated in three different ways: proactive, reactive, or hybrid. The proactive protocols develop all the possible routes before they are needed and then create a routing table in each node. Reactive protocols use a dynamic research techniques based on the request to send message. The hybrid routing strategies, instead, use clustering techniques to stabilize and scale the network and thus are generally applicable to networks of larger size and contain both strategies.


### 2.2.2. Network-Based Routing Protocols

Protocols included into this family are further classified into three classes in relation to their functionalities.Flat-Based Routing. Flat-based routing is used when a WSN is composed of a large amount of sensor nodes and the gateway sends a request to a group of specific motes in a bounded area and waits for response.Hierarchical-Based Routing. Hierarchical-based routing is used when within a WSN scalability and efficient communications are needed. This protocol is based on an energy efficient method in which nodes with high batteries are randomly selected for data analysis and sending data, while nodes with low battery are used for sensing and send data to the master. This increases the network scalability, lifetime, and energy usage.Location-Based Routing. In this routing architecture, motes are distributed randomly, with a geographic position known in a specific region and the distance between nodes is calculated using the signal strength received from those nodes.


### 2.2.3. Operation-Based Routing Protocols

WSNs applications as well as routing protocols can be classified according to their operations.Multipath Routing Protocols. These protocols provide multiple path selection in order to decrease delay and increase network performance, but they consume a great amount of energy.Query-Based Routing Protocols. This type of protocols is based on distributed data queries using high level languages.Negotiation-Based Routing Protocols. These protocols use intelligent algorithm for communication based on network available resources.


### 2.2.4. Next-Hop Selection-Based Routing Protocols

These protocols determine the next hop on the route. The decision can be based on(i)
the query content;(ii)
probabilistic approach and random selection of the next-hop neighbor;(iii)
the known position of the neighbors and the destination.Alternatively, each mote in the network can decide individually whether to forward a message or not.


## 2.2.1. Path Establishment Based Routing Protocols

The routing paths can be calculated in three different ways: proactive, reactive, or hybrid. The proactive protocols develop all the possible routes before they are needed and then create a routing table in each node. Reactive protocols use a dynamic research techniques based on the request to send message. The hybrid routing strategies, instead, use clustering techniques to stabilize and scale the network and thus are generally applicable to networks of larger size and contain both strategies.


## 2.2.2. Network-Based Routing Protocols

Protocols included into this family are further classified into three classes in relation to their functionalities.Flat-Based Routing. Flat-based routing is used when a WSN is composed of a large amount of sensor nodes and the gateway sends a request to a group of specific motes in a bounded area and waits for response.Hierarchical-Based Routing. Hierarchical-based routing is used when within a WSN scalability and efficient communications are needed. This protocol is based on an energy efficient method in which nodes with high batteries are randomly selected for data analysis and sending data, while nodes with low battery are used for sensing and send data to the master. This increases the network scalability, lifetime, and energy usage.Location-Based Routing. In this routing architecture, motes are distributed randomly, with a geographic position known in a specific region and the distance between nodes is calculated using the signal strength received from those nodes.


## 2.2.3. Operation-Based Routing Protocols

WSNs applications as well as routing protocols can be classified according to their operations.Multipath Routing Protocols. These protocols provide multiple path selection in order to decrease delay and increase network performance, but they consume a great amount of energy.Query-Based Routing Protocols. This type of protocols is based on distributed data queries using high level languages.Negotiation-Based Routing Protocols. These protocols use intelligent algorithm for communication based on network available resources.


## 2.2.4. Next-Hop Selection-Based Routing Protocols

These protocols determine the next hop on the route. The decision can be based on(i)
the query content;(ii)
probabilistic approach and random selection of the next-hop neighbor;(iii)
the known position of the neighbors and the destination.Alternatively, each mote in the network can decide individually whether to forward a message or not.


## 2.3. Commercial Solutions

Due to a wide range of application areas, a great number of solutions for wireless sensor nodes have been designed and commercialized. Nowadays there are mainly two kinds of nodes used in WSNs. The first one is the normal sensor node deployed to sense the phenomena and gather data, while the second is the gateway node that interfaces sensor networks to the external world. Commercial solutions, research prototypes of wireless sensor nodes, and their main features are illustrated in Table1, and some samples are depicted in Figures 1 and 2. About sensor nodes for WBANs, different commercial solutions exist and some of them are shown in Figure 3.Table 1
Commercial nodes.
Node Name
Micro
Transceiver
Remarks
Maker
COOKIES [20]
ADUC841, MSP430
ETRX2 TELEGESIS, and ZigBit 868/915
Platform with hardware reconfigurability (Spartan 3FPGA based or Actel Igloo)
Centro de Electronica Industrial, Universidad Politécnica de Madrid
BTnode [21]
Atmel ATmega 128L (8 MHz @ 8 MIPS)
Chipcon CC1000 (433–915 MHz) and Bluetooth (2.4 GHz)
BTnut and TinyOS support
Computer Engineering and Networks Laboratory, ETH Zurich
EPIC mote [22]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
TinyOS
University of California at Berkeley
Eyes [23]
MSP430F149
TR1001
PeerOS Support
TU Berlin, Germany
FlatMesh FM1 [24]
16 MHz
802.15.4 compliant
Commercial system, for digital sensors. Second generation with built-in tilt sensor
Senceive Ltd., London, UK
IMote [25]
ARM core 12 MHz
Bluetooth with the range of 30 m
TinyOS Support
Intel Research, USA
IMote 2.0 [25]
Marvell PXA271 ARM 11–400 MHz
TI CC2420 802.15.4/ZigBee compliant radio
Microsoft.NET Micro, Linux, and TinyOS Support
Intel Research, USA
T-Mote Sky [26]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
Contiki, TinyOS, SOS, and MantisOS Support
Advantic Sistemas y Servicios S.L., Madrid, Spain
Waspmote [27]
Atmel ATmega 1281
ZigBee/802.15.4/DigiMesh/RF,2.4 GHz/868/900 MHz
GPRS, Bluetooth, and GPS modules, sensor boards
Libelium Comunicaciones Distribuidas S.L., Zaragoza, Spain
INDriya [28]
Atmel ATmega 128L
IEEE802.15.4 compliant XBee radios
Comprehensive sensor mote with ambient light, temperature, accelerometer, JPEG camera, PIR, sound sensor, TinyOS, TinyOS compliant, and IPv6 network supportive stacks for internetworking
Indrion Technologies Ltd., Bangalore, India
Iris Mote [29]
ATmega 1281
Atmel AT86RF230 802.15.4/ZigBee compliant radio
Mote Runner, TinyOS, and MoteWorks Support
MEMSIC Inc., Andover, MA, USA
Mica2 [30]
ATMEGA 128L
Chipcon 868/916 MHz
TinyOS, SOS, and MantisOS Support
University of California at Berkeley, USA
MicaZ [30]
ATMEGA 128
TI CC2420 802.15.4/ZigBee compliant radio
TinyOS, SOS, MantisOS, and Nano-RK Support
University of California at Berkeley, USA
Mulle [31]
Renesas M16C
Atmel AT86RF230 802.15.4/Bluetooth 2.0
Contiki, TinyOS, lwIP: TCP/IP and Bluetooth Profiles: LAP, DUN, PAN, and SPP Support
Eishtec AB, Sweden
PowWow [32]
MSP430F1612
TI CC2420 802.15.4/ZigBee compliant radio
Open source; open hardware; and research platform
INRIA CAIRN, Université de Rennes
Preon32 [33]
ARM Cortex M3
Atmel AT86RF231 (2.4 GHz)
Virtual machine, Contiki and 6LoWPan supported
Virtenio GmbH, Berlin, Germany
Shimmer [34]
MSP430F1611
802.15.4 Shimmer SR7 (TI CC2420)
TinyOS Support. Built-In 3-Axis Accel., Tilt/Vib Sensor. Full range of expansion modules
Shimmer Sensing, Dublin, Ireland
TelosB [26]
TI MSP430
250 kbit/s 2.4 GHz IEEE802.15.4 Chipcon Wireless Transceiver
Contiki, TinyOS, SOS, and MantisOS Support
Advantic Sistemas y Servicios S.L., Madrid, SpainFigure 1
Intel family motes.
(a)
Intel Mote
(b)
Intel Mote 2Figure 2
Samples of commercial sensor nodes.
(a)
Smart Dust Mote conceptual diagram
(b)
Mica Mote
(c)
Tmote Sky Mote
(d)
BTnode MoteFigure 3
Samples of WBAN sensor nodes.
(a)
Limb mobility—EXLs1 [35]
(b)
SuWBAN Platform [36]
(c)
BSN Development Kit [37]


## 2.4. WSN Simulators

In order to realize a real scenario or a test bench which provides realistic results, the physical architecture and the hardware development require a lot of resources, and the WSN programming and debug become extremely complex. In this context, wireless sensor network simulation becomes a very important and essential tool which provides good results in a cost effective way. The WSN simulators can be divided into different categories in relation to their features and applications:(i)
code level simulators;(ii)
topology control simulators;(iii)
environment and wireless medium simulators.Due to the ability to increase the real WSN prototyping, the Cross Levels Simulators, like COOJA, have become an important class of simulators. This kind of simulators operates at three abstraction levels: the network level, the operating system level, and the machine code instruction set level. Although they are open source, flexible, and extensible at all levels, the test interface, the external connection at a physical level and the direct interaction with the process control via the WSN are very poor [38]. In recent years, to solve these problems, a few numbers of cosimulators have been developed which integrate WSN simulators and MATLAB/Simulink tools. The Simulink tool provides a wide range of library and simulation model blocks but does not provide an adequate physical connection with the hardware devices used in a Cyber-Physical System (CPS), and it is not possible to simulate complex systems like WBAN or IEEE1451 standard architecture.The mainsimulators for WSNs are the following.(1) Avrora. Avrora is an emulator and a code level simulator [39]. It is used to emulate the sensor hardware or to process the program code as it would be on a real hardware device. Avrora is a command-line framework compatible with MEMSIC Mica2 and MicaZ sensor platforms.(2) TOSSIM. It is an emulator for WSNs running TinyOS [40]. The simulation environment permits creating a common topology which runs exactly the same TinyOS applications.(3) COOJA. COOJA Simulator, by Swedish Institute of Computer Science, is an open-source simulator for the Contiki sensor node operating system [41]. The simulator operates at three abstraction levels, the code level, the topology control level, and the environment and wireless medium level.(4) Atarraya. Atarraya is a simulator for topology construction and topology maintenance in WSNs [42].The maincosimulators for WSNs are the following.(5) WCPS. In [43] an open-source simulation environment for wireless control systems, namely, Wireless Cyber-Physical Simulator (WCPS), has been proposed. This solution integrates Simulink and the TOSSIM wireless sensor simulator [40]. WCPS has been used to manage the physical systems and the wireless sensor-actuator networks used for control. Unfortunately, TOSSIM simulator supports only TinyOS Operating System and the MICAZ hardware platform [44].(6) NCSWT. The Networked Control Systems Wind Tunnel (NCSWT), a new integrated modeling and simulation tool for the evaluation of networked control systems, has been proposed in [45]. NCSWT integrates MATLAB/Simulink and ns-2 simulator using the High Level Architecture for an accurate time synchronization and data communication in heterogenous simulations [45].(7) PiccSIM. In [46] the authors proposed a new Platform for Integrated Communications and Control design, Simulation, Implementation and Modeling (PiccSIM) composed of Simulink and ns-2. The communication between the two frameworks, for sending and receiving sensor data, time synchronization, and node position, is network-based with UDP packets.(8) GISOO. A new virtual testbed for simulation of wireless cyberphysical systems that integrates two state-of-the art simulators, Simulink and COOJA, namely, GISOO, has been developed by the Swedish KTH Royal Institute of Technology [47]. The main base is the cross-level simulator COOJA, that permits to manage(i)
the code level simulators which emulate the sensor hardware, the process and, simultaneously, permit executing the program code directly on a real device;(ii)
the topology control level simulators which are used to study topology construction mechanisms;(iii)
the environment and wireless medium level simulators which offer the opportunity to simulate physical phenomena [48].In addition to the COOJA features, GISOO integrates the Simulink advantages, thus allowing to extend the three levels with a new one for the cyberphysical modeling [49].


## 3. Design of the Proposed Wireless Sensor Node

It is recognized that standardization of wireless nodes will have a great impact on WSNs market expansion. In effect, it will help to decrease the cost of the system industrialization, reducing at the same time the development cycle. Among the existing and emerging standards for WSN, IEEE1451 has been used for the design of the proposed node. IEEE1451 is a family of standards introduced to add plug and play capabilities to smart transducers.As defined in IEEE standard 1451.5 [50], a Wireless Transducer Interface Module (WTIM) is a device connected to transducers and, via Dot5AR protocol, to the Network Capable Application Processors (NCAPs). A WTIM differs from the standard TIM (Transducer Interface Module), as defined in IEEE Std 1451.0-2007, only for the wireless communication to the NCAP and provides two different functions. On one side, it allows the connection with the NCAP node while, on the other, makes possible the sensors interfacing.The main design novelty presented in this paper is the separation of the WTIM into two independent boards to perform in a separate way the connection with the NCAP and the sensor interfacing functions, while always respecting IEEE1451 standards, as shown in Figure4.Figure 4
New network architecture and IEEE1451 standard division.The connection board performs only actions involved in the wireless connection process with the NCAP node, maintaining in memory only the wireless related PHY TEDS (Transducer Electronic Data Sheets) and communication module commands. About the aspect of the transducers related commands, it acts as a gateway for the sensor board.The sensor board has another microcontroller to perform the remaining functions: transducers interfacing, signal acquisition, and conditioning. In this board TEDS are stored, and all the information coming from the network, through the communication board, is processed. Since the IEEE1451 standards do not provide a specific hardware communication protocol between the two boards, the Universal Asynchronous Receiver-Transmitter (UART) protocol with a3.3 V line has been adopted.


## 4. Hardware of the Proposed Wireless Sensor Node Prototype

The proposed hardware demo-board, called Argosd II, mainly developed for biometric data acquisition, is based on Argosd I, the previous version of the wireless sensor node which is briefly recalled in the following subsection.


### 4.1. Argosd I

Argos I is a Sky Mote based node, hardware designed by UC Berkeley [51] and produced by Crossbow [52]. Argosd I has the same Sky microcontroller and radio chip, but with a different architecture, and it was developed for reducing the amount of components on board, the node size, and the power consumption, to increase the flexibility, and to reduce the current loss due to leakage that happens when the chip is pulling electrical current, even when powered down.The core element of Argosd I is a Texas Instruments MSP430 MCU [53] which has been widely used in wireless sensors networks [54]. The main advantages of the MCU are the extremely low power during periods of Sleep Mode and the massive use in the WSN nodes. The MSP430 microcontroller has a 16-bit RISC CPU, connected via a data bus (MDB), and a 16-bit address bus (MAB) with memories (RAM and Flash/ROM) and peripheral I/O. In addition, it has a 8-MBit Serial Flash Memory Chip, the M25P80 by STMicroelectronics, with advanced write protection mechanisms and access via a high speed SPI-compatible bus. Moreover, an electronic registration number with external power supply, the low-cost DS2411 silicon serial number by Maxim Integrated, has been used in order to provide an absolutely unique identity that can be determined with a minimal electronic interface and associated with the network address (see Figures 5 and 6).Figure 5
Argosd I Platfom.Figure 6
Connection board architecture.The low power techniques used to design the Argosd I platform are detailed in the following.(i)
Reduction of the components on board and the utilization of low power chips.(ii)
Switching off External Circuits Duty Cycle. All the low power modes are ineffective in the reduction of power consumption if the system is unable to control the power used by external circuits to the microcontroller. It is therefore crucial to analyse what physical modes or states are required and to partition the electronics in order to shut down unneeded circuitry. In the standard WSN platforms the flash, the sensors (temperature, battery voltage, humidity, etc.), the unique ID, and its bias circuit are energized at all times. To get the minimum current draw, Argosd I shuts down these circuits when they are not required.(iii)
Utilization of High-Value Pull-Up Resistors. It is more power efficient to use larger pull-up resistors on I/O pins, such as MCLR, I2C signals, and switches, and also resistor dividers.(iv)
Reduction of Operating Voltage. Reducing the operating voltage of the device (Vdd) is a useful step in the reduction of the overall power consumption. When running, power consumption is mainly influenced by the clock speed. When sleeping, the most significant factor is leakage in the transistors. At lower voltages, less charge is required to switch the system clocks and transistors leak less current.


### 4.2. Argosd II

Starting from these considerations and following the IEEE1451 standard guidelines, the Argosd I has been divided into two parts.(i)
The Wireless Transducer Interface Module (WTIM). The WTIM, namely Argosd II, which is used to manage the network policy, IEEE1451 commands, and the radio chip.(ii)
The Transducer Electronic Data Sheets (TEDS). This module is used to manage the intelligent transducers. It contains the critical information needed by an instrument or measurement system to identify, to characterize, to interface, and to properly use the signal from analog sensors. It provides physical units to use (e.g., pressure in Pascal, temperature in K), sensors accuracy and their resolution, calibration information, and so forth.The first prototype has been designed with the aim of testing the new architecture and the internal bus communication, and the developed 4-layer Printed Circuit Board (PCB) has a size of 35 mm× 60 mm. However a reduction in the size of the board to 20 mm × 20 mm is possible in order to optimize the usability and the free space of the PCB. The wireless module interface is a modular board with a single serial bus used to communicate and to exchange data with the TEDS. Its modular nature lends itself to the development of numerous TEDS for use in different application scenarios. The TEDS can be attached in an innovative plug and play way and includes communication, processing, and sensing. The differences in the radio chip and the sensors within the new developed architecture are highlighted in Figure 6. The hardware design principles are(i)
separation between intelligence transmission and intelligence transduction, in compliance with the IEEE1451 standard;(ii)
optimal energy management in both of the connected devices, TEDS and WTIM, as a result of the use of the MOSFET power switches;(iii)
increasing power transmission to reduce the influence of unintentional disturbance sources caused by coexistent radio systems, nonideal operation of communication devices and, in industrial environments, electric machines, welders, and so forth;(iv)
space reduction.According to the standard, the first developed module must only execute the actions to process the wireless communication with the NCAP devices and, therefore, it is composed using a limited number of components. In particular, as highlighted in Figure7, the architecture comprises a radio chip, a processing unit, and other components like the unique serial number chip, the external flash memory, the three-state LEDs, the temperature sensor, and the battery charge sensor.Figure 7
Argosd II blocks schema.The Argosd II printed circuit board, shown in Figure8, contains(i)
an ultralow power MSP430 16-bit RISC microcontroller by Texas Instruments, with five low power modes to achieve extended battery life in portable measurement applications;(ii)
a ChipCon CC2520 IEEE802.15.4 compliant radio transceiver with a programmable Output Power ranging from −20 to 5 dB and two power mode states;(iii)
an external flash memory due to the limited Random Access Memory (RAM) by MCUs;(iv)
simple wire antenna.Figure 8
Argosd II printed circuit board.The Argosd II board does not include sensors but has only a serial bus interface and the power supply port to connect the intelligent transducers. A MOSFET is used to manage the power supply port in order to turn off/on the TEDS, controlling its power consumption, as shown in Figure9. The batteries charge state is monitored by the internal ADC port with a specific AVcc reference.Figure 9
TEDS power management.


## 4.1. Argosd I

Argos I is a Sky Mote based node, hardware designed by UC Berkeley [51] and produced by Crossbow [52]. Argosd I has the same Sky microcontroller and radio chip, but with a different architecture, and it was developed for reducing the amount of components on board, the node size, and the power consumption, to increase the flexibility, and to reduce the current loss due to leakage that happens when the chip is pulling electrical current, even when powered down.The core element of Argosd I is a Texas Instruments MSP430 MCU [53] which has been widely used in wireless sensors networks [54]. The main advantages of the MCU are the extremely low power during periods of Sleep Mode and the massive use in the WSN nodes. The MSP430 microcontroller has a 16-bit RISC CPU, connected via a data bus (MDB), and a 16-bit address bus (MAB) with memories (RAM and Flash/ROM) and peripheral I/O. In addition, it has a 8-MBit Serial Flash Memory Chip, the M25P80 by STMicroelectronics, with advanced write protection mechanisms and access via a high speed SPI-compatible bus. Moreover, an electronic registration number with external power supply, the low-cost DS2411 silicon serial number by Maxim Integrated, has been used in order to provide an absolutely unique identity that can be determined with a minimal electronic interface and associated with the network address (see Figures 5 and 6).Figure 5
Argosd I Platfom.Figure 6
Connection board architecture.The low power techniques used to design the Argosd I platform are detailed in the following.(i)
Reduction of the components on board and the utilization of low power chips.(ii)
Switching off External Circuits Duty Cycle. All the low power modes are ineffective in the reduction of power consumption if the system is unable to control the power used by external circuits to the microcontroller. It is therefore crucial to analyse what physical modes or states are required and to partition the electronics in order to shut down unneeded circuitry. In the standard WSN platforms the flash, the sensors (temperature, battery voltage, humidity, etc.), the unique ID, and its bias circuit are energized at all times. To get the minimum current draw, Argosd I shuts down these circuits when they are not required.(iii)
Utilization of High-Value Pull-Up Resistors. It is more power efficient to use larger pull-up resistors on I/O pins, such as MCLR, I2C signals, and switches, and also resistor dividers.(iv)
Reduction of Operating Voltage. Reducing the operating voltage of the device (Vdd) is a useful step in the reduction of the overall power consumption. When running, power consumption is mainly influenced by the clock speed. When sleeping, the most significant factor is leakage in the transistors. At lower voltages, less charge is required to switch the system clocks and transistors leak less current.


## 4.2. Argosd II

Starting from these considerations and following the IEEE1451 standard guidelines, the Argosd I has been divided into two parts.(i)
The Wireless Transducer Interface Module (WTIM). The WTIM, namely Argosd II, which is used to manage the network policy, IEEE1451 commands, and the radio chip.(ii)
The Transducer Electronic Data Sheets (TEDS). This module is used to manage the intelligent transducers. It contains the critical information needed by an instrument or measurement system to identify, to characterize, to interface, and to properly use the signal from analog sensors. It provides physical units to use (e.g., pressure in Pascal, temperature in K), sensors accuracy and their resolution, calibration information, and so forth.The first prototype has been designed with the aim of testing the new architecture and the internal bus communication, and the developed 4-layer Printed Circuit Board (PCB) has a size of 35 mm× 60 mm. However a reduction in the size of the board to 20 mm × 20 mm is possible in order to optimize the usability and the free space of the PCB. The wireless module interface is a modular board with a single serial bus used to communicate and to exchange data with the TEDS. Its modular nature lends itself to the development of numerous TEDS for use in different application scenarios. The TEDS can be attached in an innovative plug and play way and includes communication, processing, and sensing. The differences in the radio chip and the sensors within the new developed architecture are highlighted in Figure 6. The hardware design principles are(i)
separation between intelligence transmission and intelligence transduction, in compliance with the IEEE1451 standard;(ii)
optimal energy management in both of the connected devices, TEDS and WTIM, as a result of the use of the MOSFET power switches;(iii)
increasing power transmission to reduce the influence of unintentional disturbance sources caused by coexistent radio systems, nonideal operation of communication devices and, in industrial environments, electric machines, welders, and so forth;(iv)
space reduction.According to the standard, the first developed module must only execute the actions to process the wireless communication with the NCAP devices and, therefore, it is composed using a limited number of components. In particular, as highlighted in Figure7, the architecture comprises a radio chip, a processing unit, and other components like the unique serial number chip, the external flash memory, the three-state LEDs, the temperature sensor, and the battery charge sensor.Figure 7
Argosd II blocks schema.The Argosd II printed circuit board, shown in Figure8, contains(i)
an ultralow power MSP430 16-bit RISC microcontroller by Texas Instruments, with five low power modes to achieve extended battery life in portable measurement applications;(ii)
a ChipCon CC2520 IEEE802.15.4 compliant radio transceiver with a programmable Output Power ranging from −20 to 5 dB and two power mode states;(iii)
an external flash memory due to the limited Random Access Memory (RAM) by MCUs;(iv)
simple wire antenna.Figure 8
Argosd II printed circuit board.The Argosd II board does not include sensors but has only a serial bus interface and the power supply port to connect the intelligent transducers. A MOSFET is used to manage the power supply port in order to turn off/on the TEDS, controlling its power consumption, as shown in Figure9. The batteries charge state is monitored by the internal ADC port with a specific AVcc reference.Figure 9
TEDS power management.


## 5. Cosimulator for CPSs and WBAN

As already described in Section2, in recent years a few numbers of cosimulators have been developed, which integrate WSN simulators and MATLAB/Simulink tools. However, they do not typically provide an adequate support to physical hardware connections and complex WSN architectures simulation. For this reason we decided to develop a custom cosimulator, which integrates the LabVIEW, a system-design platform and development environment for a visual programming language from National Instruments, and COOJA, a cross-level wireless sensor network simulator. The developed software module, called “GILOO,” a Graphical Integration of LabVIEW and COOJA, enables to simultaneously develop and debug the control policy in a simulated or realistic scenario using or the virtual environment or the hardware modules, such as the National Instruments Data Acquisition, the FPGA platform for biometric data, and the CompactRio. Therefore, GILOO can be defined as an extension of COOJA, by which it becomes a four-level simulator, where the last level is the application connected directly to the physical reality [55].The proposed architecture, depicted in Figure10, integrates from one side the GISOO plugin implemented in COOJA (which monitors any call made by the native Analog-to-Digital Converter (ADC), Digital-to-Analog Converter (DAC), and serial port functions in the real wireless nodes), and from the other side it integrates the virtual instruments (VIs) (the building blocks of programs written in LabVIEW). Within a practical WBAN application, using Argosd II and two TEDs, the system can be decomposed into three subparts (see Figure 11):(i)
a physical process with sensors (e.g., a fall detection board and a blood pressure board, as in the example detailed in Section6);(ii)
a LabVIEW program that on the one hand interacts with the physical system through the communication modules of the National Instrument and that on the other communicates with COOJA through the LabVIEW block GILOO;(iii)
a wireless sensor network simulated in COOJA with an ad hoc communication protocol based on the IEEE802.15.4 standard and formed by a set of actors-sensors which acquire data from the physical world and a set of actors-actuators which interact with the control devices in LabVIEW.Figure 10
GILOO architecture.Figure 11
GILOO—WBAN architecture.COOJA simulates a wireless sensor network and, through the GILOO module, it interacts with the variables and the control unit in the LabVIEW program. The nodes used for sensory acquisition will read the field data and the nodes, dedicated to the control implementation, and act directly on the physical devices. The GILOO-LabVIEW library contains blocks to handle both the data communication and the time synchronization while the correct format of the serial messages and the relative bytes conversion have been implemented with a subVi routine.


## 6. Application Scenario: WBAN for Fall Detection and Health Monitoring

The proposed open hardware wireless modular node has been adopted to develop a body area network for fall detection and health monitoring. In the proposed scenario, modular nodes and a custom programmer are used to create a Low Power Area Networks (LowPans), as described in [50], adopting a Contiki operating system. Two main hardware categories are present:(i)
wireless sensor nodes, which acquire analog and digital inputs (depending on the sensors) and send measured values to the edge router every second using the 6LowPan standard;(ii)
wireless edge router, which opens the virtual channel to send data from WSN to the server and provides the communication between LowPans and Internet, implementing all the required features.We will focus our attention on the sensor boards, designed starting from our modular node Argosd II, and realized to be integrated in a wearable system.


### 6.1. Fall Detection Board

Falling is one of the leading causes of serious health problem or injury-related deaths in the elderly so it is extremely important to detect or estimate when a potential fall can happen; see, for example, [56, 57]. A fall can occur not only when a person is standing, but also while sitting on a chair or lying on a bed during sleep.In the design of our Fall Detection Board, as shown in Figure12, we included 3D accelerometers and environmental noise detectors.Figure 12
Fall detection board.(i) Motion Detector: Accelerometer. The key feature of the fall detection is the ability to detect a change in the patient position and the high accelerations. In order to acquire this information, the board is equipped with an acceleration sensor model MMA7455L which is a digital output (I2C and SPI) capacitive accelerometer (shown in Figure 13). The main features are built-in signal conditioning with a low pass filter, temperature compensation, self-test, and capability to detect 0g. The power consumption, one of the most important features of the sensor, is 400μA during the operation mode and 10μA in standby mode.Figure 13
Accelerometer schema.(ii) Acoustic Fall Detection: Noise Sensor. Most of the wearable devices used for this purpose are versatile and effective in indoor environments, but they often have maintenance problems like power management, high dimensions, and potential inconvenience for carrying them all the time during daily living activities. Detecting a fall with acoustic sensors is practical, reliable, and inexpensive and does not cause privacy issues [58]. This sensor is used in a more complex fall detection system where a motion detector sensor is integrated with an acoustic sensor for learning new sounds and, thus, studying the correlation between the fall and noise. In order to acquire this information, the board is also equipped with a noise sensor model CMC-5042PF-AC which is an omnidirectional noise sensor with a sensitivity of −42 dB (shown in Figure 14).Figure 14
Noise sensor schema.


### 6.2. Fall Detection Algorithm

The board presented in the previous section was used to detect fall. We select a sample frequency of 200 Hz for acceleration data and 2000 Hz for acoustic data. A sliding window of 1 s is applied to both signals. Window step is 0.4 s. Before starting feature extraction, acceleration is high pass filtered through a second-order, zero-lag Butterworth filter with 0.5 cutoff frequency, in order to remove gravitational component. On each window we compute four features, two from the acceleration signal and two from the acoustic signal. In detail, acceleration is used to compute the following features.(i) Mean Acceleration Magnitude (MAM). Consider(1)MAM=∑i=1NaiNai=ax2+ay2+az2,where N is the number of acceleration samples in the window and a(i) is the magnitude of the ith acceleration vector [59].(ii) Reference Velocity (RV) [59]. Consider(2)RV=∫t∈Watdt.Acceleration features are defined similarly to the ones proposed by Huang and Chan [59], but our approach does not require any particular sensor placement or alignment, since it takes into account the magnitude of acceleration vector rather than its components.From the acoustic signal we extract the following:(i)
the energy in the 0–200 Hz frequency band [60] is (3)E0–200=∫0200Afdf,where A(f) is the power spectrum of the acceleration;(ii)
the ratio betweenE0–200 and the energy in the 200–500 Hz frequency band is (4)ER=∫0200Afdf∫2001000Afdf.Features are sent as input of a fuzzy inference system which computes the warning level of the fall event. The goal of the integration of acoustic and motion features is the drastic reduction of false positives.


### 6.3. Fuzzy Logic Approach

Fuzzy rule-based systems (FRBS) have been successfully employed for system identification, control, and modeling in many areas [61, 62]. The approach considered in this work is the linguistic fuzzy modeling (LFM) with Mamdani rule structure due to its capability to model human knowledge in an explicit way. The membership functions of the variables involved in both of the fuzzy systems presented consist of triangular asymmetric and trapezoidal functions. The trapezoidal fuzzy set A in the universe of discourse U∈R with the membership function μA is parameterized by four real scalar parameters: (a,b,c,d) with a<b≤c<d. This representation can be interpreted as a mathematical membership function as described in [63](5)μAx=0,x<ax-ab-a,a<x<b1,b<x<cd-xd-c,c<x<d0,x>d.Whenb=c, the triangular function can be considered as a particular case of the trapezoidal one (a sample of the fuzzification of the variables is shown in Figures 15 and 16).Figure 15
Fuzzy sets for the input variable mean acceleration magnitude.Figure 16
Fuzzy sets for the input variable energy 0–200 Hz.Input values of acceleration features (MAM and RV) and noise ones are normalized over their thresholds, which are computed as mean plus one standard deviation from 10 s of normal activities. The fuzzy system is composed of four inputs and one output (the warning level) and the values of the fuzzy sets are reported in Table 2.Table 2
Fuzzy sets of the input and output variables: linguistic terms and their corresponding trapezoidal fuzzy sets parameters.
Input variables
Linguistic terms
Fuzzy sets (a, b, c, d)
E
0
–
200
Small
0, 0, 0.3, 0.7
Big
0.3, 0.7, +∞, +∞
MAM
Small
0, 0, 0.25, 0.45
Medium
0.25, 0.45, 0.7, 0.9
Big
0.7, 0.9, +∞, +∞
RV
Small
0, 0, 0.3, 0.7
Big
0.3, 0.7, +∞, +∞
E
R
Small
0, 0, 0.25, 0.45
Medium
0.25, 0.45, 0.7, 0.9
Big
0.7, 0.9, +∞, +∞
Output variable
Linguistic terms
Fuzzy sets (a, b, c, d)
Warning level
Zero
0, 0, 0.1, 0.2
Low
0.1, 0.2, 0.3, 0.4
Medium
0.3, 0.4, 0.6, 0.7
High
0.6, 0.7, 0.8, 0.9
Very high
0.8, 0.9, 1, 1In particular when the output is more than 0.75, we classify the event as a “falling event.” The fuzzy inference engine is composed of 36 rules chosen by examining the signals involved in the falling events.


### 6.4. Experimental Evaluation

The proposed fall detection board was tested on 8 healthy subjects emulating falls. Each subject emulated 30 falls in his home while performing daily living activities (ADL). Subjects were asked to annotate the time of their falls in order to compare detected falls with real ones. On the same time they performed 30 daily living activities which can be similar to a falling event (e.g., sitting rapidly). A number of 240 falling events and 240 ADL were recorded.The system was able to detect as “true positive” 221 falling events with a success percentage of92%. On the same time 6% of ADL were wrongly recognized as “falls.”


## 6.1. Fall Detection Board

Falling is one of the leading causes of serious health problem or injury-related deaths in the elderly so it is extremely important to detect or estimate when a potential fall can happen; see, for example, [56, 57]. A fall can occur not only when a person is standing, but also while sitting on a chair or lying on a bed during sleep.In the design of our Fall Detection Board, as shown in Figure12, we included 3D accelerometers and environmental noise detectors.Figure 12
Fall detection board.(i) Motion Detector: Accelerometer. The key feature of the fall detection is the ability to detect a change in the patient position and the high accelerations. In order to acquire this information, the board is equipped with an acceleration sensor model MMA7455L which is a digital output (I2C and SPI) capacitive accelerometer (shown in Figure 13). The main features are built-in signal conditioning with a low pass filter, temperature compensation, self-test, and capability to detect 0g. The power consumption, one of the most important features of the sensor, is 400μA during the operation mode and 10μA in standby mode.Figure 13
Accelerometer schema.(ii) Acoustic Fall Detection: Noise Sensor. Most of the wearable devices used for this purpose are versatile and effective in indoor environments, but they often have maintenance problems like power management, high dimensions, and potential inconvenience for carrying them all the time during daily living activities. Detecting a fall with acoustic sensors is practical, reliable, and inexpensive and does not cause privacy issues [58]. This sensor is used in a more complex fall detection system where a motion detector sensor is integrated with an acoustic sensor for learning new sounds and, thus, studying the correlation between the fall and noise. In order to acquire this information, the board is also equipped with a noise sensor model CMC-5042PF-AC which is an omnidirectional noise sensor with a sensitivity of −42 dB (shown in Figure 14).Figure 14
Noise sensor schema.


## 6.2. Fall Detection Algorithm

The board presented in the previous section was used to detect fall. We select a sample frequency of 200 Hz for acceleration data and 2000 Hz for acoustic data. A sliding window of 1 s is applied to both signals. Window step is 0.4 s. Before starting feature extraction, acceleration is high pass filtered through a second-order, zero-lag Butterworth filter with 0.5 cutoff frequency, in order to remove gravitational component. On each window we compute four features, two from the acceleration signal and two from the acoustic signal. In detail, acceleration is used to compute the following features.(i) Mean Acceleration Magnitude (MAM). Consider(1)MAM=∑i=1NaiNai=ax2+ay2+az2,where N is the number of acceleration samples in the window and a(i) is the magnitude of the ith acceleration vector [59].(ii) Reference Velocity (RV) [59]. Consider(2)RV=∫t∈Watdt.Acceleration features are defined similarly to the ones proposed by Huang and Chan [59], but our approach does not require any particular sensor placement or alignment, since it takes into account the magnitude of acceleration vector rather than its components.From the acoustic signal we extract the following:(i)
the energy in the 0–200 Hz frequency band [60] is (3)E0–200=∫0200Afdf,where A(f) is the power spectrum of the acceleration;(ii)
the ratio betweenE0–200 and the energy in the 200–500 Hz frequency band is (4)ER=∫0200Afdf∫2001000Afdf.Features are sent as input of a fuzzy inference system which computes the warning level of the fall event. The goal of the integration of acoustic and motion features is the drastic reduction of false positives.


## 6.3. Fuzzy Logic Approach

Fuzzy rule-based systems (FRBS) have been successfully employed for system identification, control, and modeling in many areas [61, 62]. The approach considered in this work is the linguistic fuzzy modeling (LFM) with Mamdani rule structure due to its capability to model human knowledge in an explicit way. The membership functions of the variables involved in both of the fuzzy systems presented consist of triangular asymmetric and trapezoidal functions. The trapezoidal fuzzy set A in the universe of discourse U∈R with the membership function μA is parameterized by four real scalar parameters: (a,b,c,d) with a<b≤c<d. This representation can be interpreted as a mathematical membership function as described in [63](5)μAx=0,x<ax-ab-a,a<x<b1,b<x<cd-xd-c,c<x<d0,x>d.Whenb=c, the triangular function can be considered as a particular case of the trapezoidal one (a sample of the fuzzification of the variables is shown in Figures 15 and 16).Figure 15
Fuzzy sets for the input variable mean acceleration magnitude.Figure 16
Fuzzy sets for the input variable energy 0–200 Hz.Input values of acceleration features (MAM and RV) and noise ones are normalized over their thresholds, which are computed as mean plus one standard deviation from 10 s of normal activities. The fuzzy system is composed of four inputs and one output (the warning level) and the values of the fuzzy sets are reported in Table 2.Table 2
Fuzzy sets of the input and output variables: linguistic terms and their corresponding trapezoidal fuzzy sets parameters.
Input variables
Linguistic terms
Fuzzy sets (a, b, c, d)
E
0
–
200
Small
0, 0, 0.3, 0.7
Big
0.3, 0.7, +∞, +∞
MAM
Small
0, 0, 0.25, 0.45
Medium
0.25, 0.45, 0.7, 0.9
Big
0.7, 0.9, +∞, +∞
RV
Small
0, 0, 0.3, 0.7
Big
0.3, 0.7, +∞, +∞
E
R
Small
0, 0, 0.25, 0.45
Medium
0.25, 0.45, 0.7, 0.9
Big
0.7, 0.9, +∞, +∞
Output variable
Linguistic terms
Fuzzy sets (a, b, c, d)
Warning level
Zero
0, 0, 0.1, 0.2
Low
0.1, 0.2, 0.3, 0.4
Medium
0.3, 0.4, 0.6, 0.7
High
0.6, 0.7, 0.8, 0.9
Very high
0.8, 0.9, 1, 1In particular when the output is more than 0.75, we classify the event as a “falling event.” The fuzzy inference engine is composed of 36 rules chosen by examining the signals involved in the falling events.


## 6.4. Experimental Evaluation

The proposed fall detection board was tested on 8 healthy subjects emulating falls. Each subject emulated 30 falls in his home while performing daily living activities (ADL). Subjects were asked to annotate the time of their falls in order to compare detected falls with real ones. On the same time they performed 30 daily living activities which can be similar to a falling event (e.g., sitting rapidly). A number of 240 falling events and 240 ADL were recorded.The system was able to detect as “true positive” 221 falling events with a success percentage of92%. On the same time 6% of ADL were wrongly recognized as “falls.”


## 7. Conclusion

This paper presents an open hardware modular design of a wireless sensor node, which can be used for a wide range of applications and in particular for wireless body area networks. Following the IEEE1451 standard, the node has been designed by developing two main boards, related to the connection and the sensor interfaces, respectively. The main purpose of this design is to standardize the communication for the entire sensor network, thus giving the chance to use a wide range of sensors as plug and play devices, while granting at the same time a high level of customization. An additional contribution of the work is the development of a cosimulation tool which simplifies both hardware connection and software simulation. As an application scenario of the proposed modular node, we present a wireless body area network for fall detection and health monitoring.In order to compare the proposed node to other similar commercial solutions, a performance analysis is currently under investigation. In the future, the proposed prototypes will be improved and integrated in a more complex wireless body area network, in order to provide a continuous health monitoring for ambient assisted living applications in smart homes.



---

*Source: 2978073-2016-01-10.xml*