Technical Report, IDE0502, January 2005
Open Secure Office Project
Wireless Sensor Network
Master’s Thesis in
†
Computer Systems Engineering and
‡Electrical Engineering
Rikard Andersson
‡, Martin Sandberg
‡, L´
aszl´
o Urszuly
†School of Information Science, Computer and Electrical Engineering Halmstad University
Open Secure Office Project
Wireless Sensor Network
Master’s Thesis in
Computer Systems Engineering and Electrical Engineering
School of Information Science, Computer and Electrical Engineering Halmstad University
Box 823, S-301 18 Halmstad, Sweden
January 2005
c 2005
Rikard Andersson, Martin Sandberg, L´aszl´o Urszuly All Rights Reserved
Description of cover page picture: Motekit 5040 from Crossbow [1] and a intended floor plan at Halmstad university.
Preface
The document in your hand is a master’s thesis entitled Open Secure Office Project -Wireless Sensor Network. It is one part of the project Open Secure Office initiated by Prof. Tony Larsson at the Computing and Communication laboratory at the school of Information Science, Computer an Electrical Engineering at Halmstad University, in the spring of 2004.
We would like to thank our supervisor Tony Larsson for his guidance throughout the project. We would also like to thank Latef Berzenji for his comments on the language of the work.
This document has been formatted using LATEX.
Rikard Andersson, Martin Sandberg, L´aszl´o Urszuly Halmstad University, 20th January 2005
Abstract
In recent years, the development of wireless sensor networks has made a great progress. Early projects focused on replacement of existing systems equipped with wires. These systems started out as simple static data collection networks with one smart central node that could decide further actions based on the content of the collected data. Through time, the intelligence has become more decentralized, which means the nodes now can cooperate in a more efficient and dynamic manner.
The task given is to evaluate TinyOS and NesC on specific hardware from Crossbow Technology Inc, applied on an application called the Open Secure Office Project. This application is designed to enhance the security without negative effects on comfort in a frequently visited open-plan office. Finally, a real world system demonstration should be performed.
We propose a solution where there is no urgent need to cover the entire office area with radio signals to maintain a secure sensor system. This is true as long as all entries and exits to the office area are “guarded” by some base station which has as main task to keep track of people and equipment entering or leaving the office.
Small scale tests have been performed which show that it is possible to easily develop and maintain a wireless sensor network security system, that could be coordinated by alternative systems.
CONTENTS
Contents
Preface iii Abstract v 1 Introduction 1 1.1 General Concept . . . 1 1.2 Related Work . . . 2 1.2.1 CodeBlue . . . 2 1.2.2 Wisenet . . . 2 1.2.3 Comparison . . . 3 2 Theoretical Background 5 2.1 Wireless Sensor Networks . . . 52.2 NesC . . . 6 2.3 TinyOS . . . 8 2.4 Power Management . . . 9 2.4.1 HPLPowerManagement . . . 10 2.4.2 Power Generation . . . 12 2.5 Network Design . . . 12 2.5.1 Single-hop Communication . . . 12 2.5.2 Multi-hop Communication . . . 13 3 Method 17 3.1 Problem Definition . . . 17 3.1.1 Project Frames . . . 17 3.2 Approach . . . 18 3.2.1 Investigation . . . 18 3.2.2 Implementation . . . 18 3.2.3 Evaluation . . . 19 3.2.4 Summarization . . . 19
4 Results and Discussion 21
4.1 System Architecture . . . 21
4.2 Sensor Network Components . . . 24
4.2.1 Mica2 Processing Element . . . 25
4.2.2 Mica2 Sensor Board . . . 26
4.2.3 Mica2dot Processing Element . . . 26
4.2.4 Mica2dot Sensor Board . . . 28
4.3 Hardware Specific Software . . . 28
4.3.1 Mica2RadioM . . . 29 4.3.2 Mica2UartM . . . 29 4.3.3 Mica2AccM . . . 30 4.3.4 Base Stations . . . 31 4.3.5 Identification Tags . . . 31 4.3.6 Accelerometer Nodes . . . 32
4.4 Software Development Environment and Debugging . . . 33
4.4.1 The Source Code Editor . . . 33
4.4.2 The Mote Communicator . . . 33
5 Conclusions 35 5.1 System Architecture . . . 35
5.2 Debug Application . . . 35
5.3 NesC and TinyOS . . . 35
5.4 Power Management . . . 36
5.5 Alternative Solutions . . . 36
5.6 Future Work . . . 37
Bibliography 39 A The combined project goal 41 A.1 Introduction . . . 41
A.2 Proposed Solution . . . 41
A.2.1 The Sensor Network . . . 41
A.2.2 Coordination . . . 42 B NesC Programs Structure 45
LIST OF FIGURES
List of Figures
1.1 A mote compared with a coin, Ø = 25mm [1] . . . 1
1.2 WISENET system block diagram. . . 3
2.1 Code example: Mica2dotPersonal.nc . . . 7
2.2 Code example: Mica2dotPersonalM.nc . . . 8
2.3 Single-hop communication, connections between CN and AP are wireless. The client (CN) only needs one hop to reach the access-point (AP). . . 13
2.4 Multi-hop communication, all connections are wireless. The sensor node A have to use 3 hops over B and C to reach the base-mote D . . . 14
2.5 Data centric: Trying to find routes from several sources to a single sink. At B data from Source 1 & 2 are aggregated. . . 14
2.6 Address centric: Finds the shortest path between pairs of addressable end-nodes. . . 14
3.1 Planning (organization) of the work . . . 18
4.1 The thief (filled circle) is trying to escape with the prey (outlined square) and he is detected by the general system only when positioned within the range of a base station (outlined white triangle), but before that, a picture might have been taken of him, and doors could have been locked or other actions taken within the particular office due to the settings of the local control station (outlined gray triangle), which also registers the alarm signals sent by the stolen but protected equipment. . . 22
4.2 The thief (filled circle) is trying to escape with the prey (outlined square) and is detected only when approaching a base station (outlined triangle) guarding an exit. . . 23
4.3 Alternative alarming method is an epidemic multi-hop protocol where each node (outlined circles and squares) forwards the alarm once. . . 23
4.4 The main components of the hardware platform for the Open Secure Office Environment. Top left: Mica2 processing element. Top right: Program-ming/docking board. Bottom left: Mica2 sensor board. Center: Mica2dot processing element. Bottom right: Mica2dot sensor board. . . 24
4.5 The Mica2 processing element attached to the programming/docking board. 25 4.6 The Mica2 sensor board attached to the programming/docking board. . . . 27
4.7 The Mica2dot processing element attached to the programming/docking board. 28 4.8 The Mica2dot sensor board attached to the programming/docking board. . . 29
4.9 Mica2RadioM module with interfaces. . . 29
4.10 Mica2UartM module connected via interfaces. . . 30
4.12 The module diagram shows the implementation on the base station mote. SingleTimer, Mica2UartM, Mica2RadioM and LedsC are low level mod-ules. They are hardware specific and are connected via interfaces to the
Mica2BaseM module. . . 32
4.13 The figure shows the module implementation in the personal mote. . . 32
4.14 The figure describes the structure of an accelerometer mote. The five mod-ules on right-hand-side are of lower level. . . 33
B.1 NesC programming code for the BlinkM module. . . 46
B.2 NesC programming code for the Blink configuration file. . . 47
LIST OF TABLES
List of Tables
2.1 Different kinds of motes . . . 6 2.2 Sleep Mode select . . . 11
CHAPTER 1. INTRODUCTION
1
Introduction
1.1
General Concept
Modern offices are nothing like they used to be twenty or thirty years ago. They are no longer closed environments for corporate employees while the ever growing need for personal contact with customers, business associates and suppliers has transformed them into something that sometimes could look like market places. This – of course – raises several security issues which as of today have been dealt with by using passwords and different kinds of identification methods like id-cards.
Too poorly designed security systems are (for reasons not needed to state) not desirable, while too rigorous systems are annoying when accessing frequently used resources. This dilemma creates a need for equipment which themselves can identify a foe and prevent in-trusion by locking doors and drawers, turning of monitors or locking computer keyboards. The idea is to develop the next generation of surveillance systems which can adapt them-selves to different scenarios and dynamically make correct decisions for that particular event, i.e. equipment that function more like people than static machinery.
This system can be achived by connecting wireless motes1 (see figure 1.1) in a sensor
network, controlled by a high level coordination language. This thesis primarily focuses on the hardware aspects of the problem; i.e. the sensor network and the low-level pro-gramming. The high-level programming and control, which is based on the coordination language STITCH, will be presented in a master’s-thesis entitled “Open Secure Office Project - Evaluating STITCH” [2].
Figure 1.1: A mote compared with a coin, Ø = 25mm [1]
1Motes are small electronic devices which include a microcontroller, a radio unit and one or several sensors
1.2
Related Work
This section describes a couple of projects associated with the Open secure office and points out the main differences between them.
1.2.1
CodeBlue
CodeBlue is a wireless infrastructure under development at Harvard University, USA [3] that is intended for critical health care environments both inside a hospital and on the field. CodeBlue is designed to work with several different types of devices containing PCs at a central level, iPAQ PDAs at a user interface level and low-power motes at the sensor level. The system architecture attaches great importance to the particular sturdiness and security demands of medical care settings.
CodeBlue has the capability to determine patients on the scene of the accident and guar-antee a data transfer from the victims to the paramedics without any loss of data. It also makes assignment of hospital resources more effective. The intention is that the sys-tem should be scalable from small static syssys-tems to very dense networks containing maybe thousands of devices and where the network conditions are very harsh. In order to achieve this, the infrastructure will support reliable, ad hoc data delivery, a flexible naming and discovery scheme, and a decentralized security model. Using an ad hoc network will give the possibility to extend the system over a building or between several different buildings close to each other. For increased coverage, if needed, extra fixed nodes could be placed in hallways or other areas. The network is self-organizing, which entail that data could be re-routed in a quick way, if a node is lost or a link is broken, independent of the network topology.
The system is built upon use of the Berkeley motes, Mica2 and Mica2dot series, which are available at Crossbow Technology Inc [1]. The motes are equipped with sensor boards that periodically transmit packets containing heart rate, SpO2 (blood oxygen saturation), and plethysmogram waveform data. Several patients could be monitored at the same time using a flexible, multi-hop routing strategy. The vital signs could be directed to the PDAs carried by personnel or to a base station (PC). As the network expands, the chance for information overload increases which may result in a network bottleneck. Therefore, CodeBlue supports filtration and aggregation of events continuously. For example, para-medics want to receive continuous data from one patient but only crucial data changes from other patients when they are on duty.
The project homepage is located at [4].
1.2.2
Wisenet
WISENET (WIreless SEnsor NETwork) is a wireless sensor network at Bradley University, Department of ECE [5]. The system monitors the environmental conditions of the labs and offices of the department. Things measured are for example, light, humidity and temperature.
CHAPTER 1. INTRODUCTION • The SENSOR MOTE NETWORK block contains several static sensor motes, which are equipped with sensor boards. Raw sensor data are transmitted from the sensor motes to a gateway mote, which is connected via RS232 to the SERVER block. When a sensor mote does not transmit any data, it enters a sleep mode in order to save energy but the gateway mote is always awake.
• The SERVER block contains a HTTP server and a mySQL database.
• The CLIENT block contains a computer with connection to Internet (HTTP) and a web browser user interface, which involves that a person can access the collected data via the Internet. The CLIENT could be developed outside of WISENET, however it is essential for the overall function.
Figure 1.2: WISENET system block diagram.
The connections between the SENSOR NET and the SERVER is a RS232 serial interface, and between the SERVER and the CLIENT is a regular TCP/IP.
Data Acquisition subsystem
This subsystem collects and stores data from the motes for later processing by the Data Analysis subsystem. This subsystem is the system part that contains all the hardware, i.e. the motes. It also includes TinyOS and WiseDB. WiseDB, which is a software component especially made for WISENET, is located on the server (see figure 1.2). This component is an interface that connects the hardware with the database.
Data Analysis subsystem
This subsystem could stand alone from WISENET, since it relies only on existing in-frastructures. It is built upon software only. The main issue of this subsystem is to present the collected data in an appropriate graphical way on a website.
1.2.3
Comparison
CodeBlue differs from WISENET in several ways. First of all CodeBlue is intended to work for much larger networks, and it is partially dynamic. WISENET, on the other hand, since its network is static, does not need to deal with the problem that is caused by the dynamic environment. Small static systems are also much easier to maintain.
When comparing The Open Secure Office with the projects above, some main differences and similarities could be identified.
In comparison to CodeBlue, both systems must be robust (no data could be lost). The systems also focus on a dynamic approach, which is not commonly the case in wireless sensor networks. CodeBlue supports a much more dense network, which entails more complex routing. It is; therefore larger compared to The Open Secure Office, which could be expanded in the future.
In comparison to WISENET, both systems are developed for indoor office environment, but WISENET focuses on many-to-one2communication instead of many-to-many. WISENET is fully static, that is, all motes are non-movable. Both systems are rather similar in size but the routing in WISENET is much easier.
Compared both to CodeBlue and WISENET the Open Secure Office solution is more event oriented.
CHAPTER 2. THEORETICAL BACKGROUND
2
Theoretical Background
This chapter presents a brief description of the theory which forms the basis of this thesis.
2.1
Wireless Sensor Networks
Since the late nineties, the interest in various kinds of wireless electronic equipment has emerged. In the commercial market, this has been seen particularly in wireless data networks such as Wireless Local Area Networks (WLAN: 802.11) and Bluetooth which are mostly known in connection with mobile telephones. Another part of the wireless area is wireless sensor networks which will be described briefly in this section.
Wireless sensor networks can be used to monitor temperature and humidity [5], industrial control [6] and intelligent agriculture and environmental sensing [6]. To be able to meet the requirements of these applications, some aspects of the sensor-networks are to be specified.
• Less maintenance than wired networks, for the simple reason that large systems include a large amount of wires which entail many possible sources of errors. • Easy to install and change the configuration. The comparison with a painting can
be done. One just attaches the sensor to a wall or an object, and it is ready to be used.
• Very small size (sometimes called smart dust[7]). There are sizes from a few square millimeters to the size of a coin (couple of centimeters).
• A sensor node is energy critical due to the battery power; therefore, one needs to save energy by turning off the unit to sleep mode when it is not needed. It also has a limited peak power.
• The sensor networks have low data throughputs compared to other wireless net-works. This implies that the overhead from addressing will be significant; therefore the communication effectiveness of the network will be very low.
• Security is an important issue in all kinds of wireless communication, where it is easier to intercept a message than with wired communication. The security could be obtained by message encryption, which, however, is not often the primary goal in a sensor network. The more important part to be seen is that the message has not been modified when it reaches the receiver.
Several sensors integrated into a mote have an event driven operational mode, that is, they react to changes in the environment and are not controlled by interaction with a user or another application in the same sense as an ordinary desktop computer is controlled. The fact that the motes get smaller and smaller makes it, however, harder to program their functionality. Increasing functional complexity and lower power consumption constraints due to market development add new dimensions to the programming intelligence.
Connecting several motes to a network of some kind introduces a new set of constraints to the application in terms of concurrency and real time requirements. A wireless net-work requires, besides the general considerations presented in the previous paragraph, an extensive survey in data encryption and secure wireless transmission. Additional con-straints to keep in mind, while implementing data integrity mechanisms, are the poor system hardware resources on motes, such as limited RAM and Flash memory.
A dynamic application also has heavy demands on power consumption and power man-agement to take into consideration. A static sensor network, which is only time triggered, like a humidity controlling system, which only measures some values at a given time inter-val and reports them back to a base station, can be tuned in for optimal signal strength in case of wireless data transmission. It can also use well defined sleeping modes to save battery power and make it last for months or even years. A dynamic application, such as an active security system, has to react on non-periodical events and send data and alarm signals at different signal strengths depending on present conditions. Planning and implementing an “intelligent” sleeping behavior on such systems are therefore much harder.
Table 2.1 shows the development trends of sensor motes in a short time period [8]. It is interesting to observe the fact that even though the physical size gets smaller, some parameters still keep growing, like the programming memory and random access memory, while the communication bit rate does not change to any appreciable extent.
weC ren´e ren´e2 dot mica mica2 Release Date 1998 1999 2000 2000 2001 2002 Microcontroller AT90LS8535 ATMega163 ATMega103 ATMega128L Prog.Mem (kB) 8 16 128
RAM (kB) 0.5 1 4
Radio RFM TR1000 Chipcon CC1000 Bit Rate (kbps) 10 40 38.4 Modulation type OOK ASK FSK
Table 2.1: Different kinds of motes
2.2
NesC
Recent advances in the topics of networking and hardware component integration have made it possible to develop smaller units at lower prices. While the main concept and functionality of a single unit stay the same, its technology will bring about the development of new programming languages and compilers.
As mentioned in section 2.1, there are several concerns in programming embedded sensor networks. The compiler must handle event-driven execution, data-race1 detection and
function in-lining2 in order to avoid conflicts at runtime and make optimal use of the
1Data race detection is a method to detect and prevent multiple threads from writing to and reading from the same shared resource at the same time [9].
2Function in-lining is used to improve performance in the program code itself. The idea is to replace all function calls by the actual function body. This way the time losses due to variable passing and context switches are eliminated [10], but the program code is increased, hence the desired performance regarding speed-up could instead be decreased while the entire program will not necessarily fit in the RAM memory.
CHAPTER 2. THEORETICAL BACKGROUND relatively poor hardware resources.
NesC is a static language, which means there is no possibility to dynamically allocate memory or in any other way alter the memory- or resource map during runtime. This makes the entire program definite at compile-time and the debugging processes are per-formed easily. The compiled software is thereby, theoretically at least, more reliable. As far as the lack of dynamic properties are concerned, there is no urgent need for them while the language itself is based on components that perform tasks rather than generate new data and the motes are seldom targets of data storage [8]. NesC is also the programming language used to develop TinyOS, see section 2.3.
A program in nesC is built out of Components, which can be divided into two parts, Modules and Configurations. Modules contain the code for the implementation and the configurations “wire” several components together.
NesC interfaces are bidirectional and could also be divided into two parts, Command and Event. Command is a call from one component to another that demands a specific service to be performed, while Event is a call which indicate that a service has been finalized. A component either provides an interface (for other components to use) or uses an interface (that other components provide). Interfaces are not dependent of a component implementation, which entails that changing parts of an application is simply to replace the component by another that provides the same interface. The words emphasized above are called restricted words in nesC. Figures 2.1 and 2.2 illustrate the use of these restricted words in a real nesC environment.
Figure 2.1: Code example: Mica2dotPersonal.nc
NesC used as a programming language for the application of current interest presents several favorable features besides those presented in the previous paragraphs, and the fact that it is an extension to C makes it suitable to be utilized while C produces an efficient code for all available hardware targets on the motes [8]. C is also known to most programmers and is, therefore, convenient to use.
Figure 2.2: Code example: Mica2dotPersonalM.nc
2.3
TinyOS
TinyOS, is a tiny microthreaded operating system originally developed at the University of California, Berkeley. It was developed especially for wireless embedded sensor networks, mainly because the existing embedded device operating systems did not meet up with the specific requirements, like small physical size, moderate active power load, concurrency intensive operation, limited resources, application-specific requirements etc.
TinyOS has an efficient foundation for modularity and also provides a resource-constrained event-driven concurrency model [11]. As the sensor nodes, which have limited RAM, primarily process several information flows rather than heavy computation, the demand for high concurrency is essential.
A complete system configuration can be divided into two parts; namely a tiny scheduler and a graph of components. The latter consists of four different parts: command handlers, event handlers, a stack of easy tasks and a condense fixed-size frame. The first three work within the fixed-size frame and operate on the current state of the frame. The frame is assigned a specific memory size at compile time, which prevents dynamic allocation overhead.
Many operations on TinyOS are called Split-Phase, which means that the commands are requests to start an operation, and an event signals completion of an operation. An exam-ple is: one component invokes send, another communication component signals sendDone when the packet is received.
TinyOS includes the essential things to support the design of a sensor network such as economize power, repeatedly gather data, do some simple calculation on the data and if necessary, pass it to an adjacent sensor node. TinyOS is an open-source operating system which can be downloaded at the TinyOS Community Forum [12]
CHAPTER 2. THEORETICAL BACKGROUND
2.4
Power Management
General wireless networks, like WLAN (802.11a-g), require high bandwidth which con-sumes a lot of power. This is, however, not a big problem because most devices that use these systems are either connected to power mains or use batteries with good capacities, for example portable computers. Portable devices with good battery capacity such as cellphones have an average energy consumption of tens to hundreds of milliamps which will give them a lifetime of approximately a couple of days. These lifetimes are accepted since it is easy to charge such systems.
Wireless sensor networks, on the other hand, require longer lifetimes, which demand components with very low average energy consumption (µA), because the majority of all “motes” used in wireless sensor networks are battery powered. Another reason is that these systems should be suited for the company’s or product’s maintenance period. The energy available normally has to last for years or at least months to be useful, which entails that the average power requirements need to be approximately 3 volts times a couple of hundred microamps (AA batteries, Mica2 mote) to last a year, and even less for cell batteries used at for example the Mica2dot mote.
Based on power supply and power consumption, the power management problem in wire-less sensor network nodes seems to be easy, since the battery delivers a specified amount of energy, and the node has to consume it during as long time as possible to maintain a long lifetime. However, since the energy form provided by the source is seldom optimal for the load, the problem becomes aggravated. One thing to consider is how to solve the problem with high power-peaks. Wireless sensor networks often have low average energy consumption but need to be able to handle high power-peaks every now and then during operation. For best performance, the hardware should be customized for the specific ap-plication. Off the shelf products, designed for multiple purposes, do not often completely reach the power requirements.
In order to save energy, one has to specify sources for energy consumption. The list below states a few examples to be considered:
• Radio transmission. • Transmission rate. • Time constraints. • Network topologies. • Routing protocols. • Operating system.
The major energy consumer in a wireless sensor network is the radio, which mainly has three states; idle listening, transmit and receive. Therefore, one needs to use the radio in a controlled way, to minimize the time the radio is active, which can be done in various ways. In this thesis, the approach is to use HPLPowerManagement, which is described in detail in section 2.4.1. Transmission rate, and time constraints are two sections in radio
communication which could be considered since they effect energy consumption. Higher transmission rate and wide time constraints result in higher energy consumption.
Being an essential part in wireless sensor networks and highly dependent of the appli-cation, network topologies are used to save energy. In the dissertation entitled “System Architecture for Wireless Sensor Networks” [13], Jason Hill states three classes of appli-cations:
Environmental data collection when one wants to assemble data from a great number of nodes (magnitude >100) and evaluate the data afterward.
Security monitoring differs from the former class in that no data are gathered for storage or further transmission. This forces the nodes to be awake more frequently (to read sensor values) but the radio is less active.
Sensor node tracking is a class often considered when one wants to track a moving object by the use of a sensor network. This scenario differs from the above two in several ways. First of all, this class exploits both dynamic and static nodes compared with only static ones. Secondly, these systems are designed to intercept radio messages from moving object rather than sensor reading.
The Open Secure Office does not fit into any of the classes mentioned above, because it is more or less a junction of security monitoring and sensor node tracking. The Open Secure Office, which uses, both dynamic and static nodes, focuses on sensor readings and tries to minimize radio traffic in order to save energy.
The network topologies suggested to save energy for each class are: Short and wide tree for Environmental data collection, linear topology for Security monitoring. The last class topology will change as the nodes advance in the network due to the dynamics.
As mentioned above, the radio use and network topology are essential in wireless sensor networks. However, in order to achieve a good performance of the network, one needs to consider routing protocols. One kind of the routing protocol is multi-hop communication, which gives the opportunity to reduce the transmission power of the radio (see section 2.5.2 for details).
A lot of power could be saved with an operating system that supports power management. TinyOS which is used in this project fits well this description. Section 2.4.1 presents the management of power in TinyOS.
2.4.1
HPLPowerManagement
By using Mica2 motes (containing the CC1000M radio), TinyOS provides 6 different power saving modes.
1. Idle mode basically halts the CPU- and FLASH clocks. Interrupt handlers, watch-dog and other clocks etc will be active. The start-up time is fast, but power reduction is not considerable.
CHAPTER 2. THEORETICAL BACKGROUND 2. ADC Noise Reduction mode differs essentially in one manner compared with the Idle mode, namely the I/O clock is disabled. This modification will make measurements more accurate since the noise level for the A/D converter is reduced. Power reduction in this mode is not considerable.
3. Power-down mode disables the external oscillator and the generated clocks but keeps the possibility for external interrupts to occur. Synchronous modules are not sup-ported due to the lack of clocks, which will save energy, but result in a delay, related to wake-up conditions.
4. Power-save mode differs from power-down mode in one aspect, namely it is possible to have Timer/Counter0 active during sleep. This requires that the AS0 bit in the Asynchronous Status Register (ASSR) is set (i.e. the Timer0 is clocked asynchro-nous). Compared to Power-down, this will give other possibilities for wake-up, as Timer overflow. Power-save mode is not recommended in favor of Power-down mode when the asynchronous timer is not clocked asynchronously.
5. Standby mode is identical to Power-down mode, with one modification, namely the oscillator is active. The wake-up time is 6 clock cycles.
6. Extended Standby mode is identical to Power-save mode, with one modification, namely the oscillator is active. The wake-up time is 6 clock cycles.
For even more detailed information regarding sleep-modes with the ATmega128(L) from the Atmel corporation, the reader is referred to Atmels website [14]. The sleep mode activation process in TinyOS includes 2 steps. First the hardware must be put in the desired state, which is done by:
1. Writing logic one to bit 5 in MCU Control Register (MCUCR) i.e. Sleep Enable. 2. Setting the appropriate mode according to table 2.2.
SM1 SM2 SM3 Sleep Mode 0 0 0 Idle
0 0 1 ADC Noise Reduction 0 1 0 Power-down 0 1 1 Power-save 1 1 0 Standby 1 1 1 Extended Standby
Table 2.2: Sleep Mode select
Second, when the hardware is set, the application has to shut down the radio in order for HPLPowerManagement to work. Then the HPLPowerManagement must be enabled, which will lead to that the mote automatically sleeps when the radio is off, all high speed interrupts and Serial Peripheral Interface interrupts (SPI) are disabled and the task queue is empty.
Summary
Set appropriate hardware state
call CC1000RadioC.StdControl.stop() call HPLPowerManagement.enable()
2.4.2
Power Generation
Alternative ways to generate power in this kind of systems could be to use ambient energy of some sort, like mechanical vibrations from the mote whenever it is moving, which is often called energy scavenging. However, when using energy scavenging, the benefits compared to the drawbacks of installation must be taken into consideration. One big problem is to multiply the collected energy to the source voltage level (e.g. 3.3V), because the multiplication process will obviously consume energy.
2.5
Network Design
When designing a wireless sensor network, it is interesting to look at the network topology and the routing algorithm(s). The first part contains for example tree-based structures and linear topologies. The second part is discussed below.
If it is possible for all hosts in a wireless sensor network to communicate with each other directly, the network is defined as single-hop; otherwise, it is defined as multi-hop. What is the pros and cons with the different algorithms? When is it appropriate to use a single-hop, and when is it better to use a multi-hop? Is it perhaps better to use a combination of both?
In wireless sensor networks where energy consumption is of great importance, it is inter-esting to evaluate single- and multi-hops to find out what alternative is best for a given application.
2.5.1
Single-hop Communication
Single-hop routing algorithms are widely used in wireless networks, for instance between an access-point (AP) and a client node (CN). WLAN, which is often used to replace an ordinary LAN, is mainly used to access the Internet. A client is then connected via an access-point, and other clients are connected in the same manner, which is illustrated in figure 2.3 where the connections between CN and AP are wireless. This is a form of single-hop routing since there is no connection between for instance Client → Client → Access-point, instead there is a direct connection between CN and AP.
In wireless sensor networks, single-hop may be a good choice when the transmission dis-tance is fairly short. As discussed before, the radio consumes a lot of power, and since the output power is decreased with the distance to the power of four owing to ground reflections from short antenna heights [15], long distances are not a suitable strategy to gain system efficiency. For short distances, single-hop communication is a good option be-cause it does not need the redundancy that is required by the multi-hop communication. Multi-hop compared to single-hop regarding energy consumption is described in [16]
CHAPTER 2. THEORETICAL BACKGROUND
Figure 2.3: Single-hop communication, connections between CN and AP are wireless. The client (CN) only needs one hop to reach the access-point (AP).
2.5.2
Multi-hop Communication
Multi-hop communications are often well suited to wireless sensor networks, because the sensor nodes are small sized with limited battery capacity and have a short transmission range, which sometimes means that the sensor nodes are not capable of reaching the base mote (BM in figure 2.4) in one single step. Instead, the transmission node must pass through several other nodes until it reaches the destination node, as illustrated in figure 2.4, where A has to pass through C and D in order to reach B. Moreover, when sending over long distances, single-hop is not appropriate (demands for high output power) because the energy loss will be noticeable. Power savings could be made by using several hops over short distances instead of one long hop, since output power then could be set to a minimum. According to [17], the transmit power scales as: Outputpowerhops2 for
each transmitter. For hops number of transmissions, the total power will be: Ptot =
hops · Outputpowerhops2 =
Outputpower
hops , which indicates that many relying nodes in the system
will reduce the total energy consumption since the nodes need less output power for radio transmission.
As discussed above, multi-hop will save energy when transmissions are over large distances. However, multi-hop will give rise to a delay problem [17] that has to be considered. The delay will increase with the number of hops. Nevertheless, the power savings are of a greater importance than the delay issue, but the delay must be considered in larger systems. Since single-hop is better for short distances and multi-hop is better over longer distances, a combination of both can thus be used.
Figure 2.4: Multi-hop communication, all connections are wireless. The sensor node A have to use 3 hops over B and C to reach the base-mote D
two main groups, namely data centric and address centric routing [18]. Data centric and address centric are terms used to characterize routing strategies. In the address centric approach, every source transmits their data in the shortest way to the sink (end-to-end routing). In the data centric approach, the sources transmit their data to the sink, but along the way, routing nodes aggregate data from the different sources in order to minimize radio traffic, which will result in saved energy. Figures 2.5 and 2.6 show a simplified model of the different approaches.
Figure 2.5: Data centric: Trying to find routes from several sources to a single sink. At B data from Source 1 & 2 are aggregated.
Figure 2.6: Address centric: Finds the short-est path between pairs of addressable end-nodes.
One drawback of the data centric approach is the latency affiliated with the aggregation. In the address centric approach, the data packets are routed through the system in a direct way, but in the data centric approach, the data from one source are sometimes detained at a midway node until data from another source have arrived. This delay is
CHAPTER 2. THEORETICAL BACKGROUND highly dependent on the aggregation function, and can sometimes be neglected. However, when the aggregation is complicated, the latency have to be considered. In [19], the conclusion drawn is that the main advantage of the data centric approach is that multiple sources are close to each other but at a great distance from the sink.
There are several different routing protocols that could be used [11]. Some main alterna-tives are described below.
Tree-Based Routing
The design is built on routing through the parents of the tree in both directions, hence nodes on the top of the system have to communicate more than those lower down in the network. Trees are constructed by a local broadcast from the root responded to by the child nodes sending a selective message back to the parents which finally ends in the root. There are two key features of the tree-based routing; first it is to always have an identifier on the root and second to know the number of underlying nodes. The design has two main complications, which concern the way the tree is built up and how it is going to keep its shape.
Maintenance problems have several lines of action. One solution is that a node selects a parent by overheard transmission and that the root then sends messages periodically that each underlying node transmits until it reaches the leaf nodes. The parent is selected by either the lowest hop-count or by evaluation of the link quality. A combined way is also possible, that is depending on link quality and hop-count.
Broadcast and Epidemic Protocols (Dissemination)
The network structure, which is designed to have a reliable data distribution to all nodes in the system, has two approaches.
1. The first one is that a base station broadcasts data, and all the nodes within a reachable distance receive the message and forward it once. The problem of this approach is to know when to stop sending data and that the signals interfere with each other. One way to avoid the first problem is to wait for retransmission or by using visual inspection. The second, interference problem can be solved by introducing a time delay before retransmission.
2. The other one is to have an epidemic algorithm which only sends data when it is needed. Periodically, nodes exchange instructions to know when it is time to distribute data over the network. When a new node enters the network, it gets all the information in a short period of time, hence this approach is preferable from an energy efficiency point of view.
One example of a dissemination protocol is flooding [20], which is a rather simple protocol used when data should be transmitted to every node in the system. Data are sent from one node to all its neighbors that send the data along to their neighbors and so forth. When a node has sent its message, it goes to sleep. Transmission interference is robust with nearly 100% redundancy, but it is highly sensitive between the different nodes. The
main drawback of flooding is its inefficiency, since nodes commonly recieve the same message several times. This problem is known as The broadcast storm problem, which is widely known and has resulted in several variations from the basic protocol to improve the efficiency of the system.
CHAPTER 3. METHOD
3
Method
In this chapter, the solution path of this project is discussed and the related problems are defined. Moreover, the operating circumstances and methods used to obtain the results are presented.
3.1
Problem Definition
For the achieving of the main goals, the obstacles defined below should be overcome;
• Build up and maintain communication in a dependable way. The first step in setting up the network is to send information between motes. A message can be considered as successfully sent when it has also successfully been received by the other party without information losses.
• Expand the network. The expansion must under no circumstances cause perfor-mance degradation in terms of data losses during send/receive operations, i.e. the communication must work properly also with the new motes.
• Implement some kind of multi-hop functionality. If one node physically can not reach the receiving node, the message should be sent either through other motes or through the base station. The main goal remains that the message must arrive at all costs.
• Data transmission security. This point has to be closely examined before it is stated fully, but it is conceivable to wish for some kind of data encryption or another method to protect the data that are sent, or at least detect if any changes have been made according to the parity model used in some early modems.
• Fault tolerance. The system must work as good as possible even if a hardware re-source is down or missing. This opens doors for the concept of graceful degradation and even though it falls a bit outside the frames of this thesis, the system soft-ware must be prepared for future upgrades and implementation of additional fault tolerance functionality.
3.1.1
Project Frames
The operational environment of the network system is only defined indoors. This means that tests on the network are made in a protected and controlled environment but there are no theoretical facts which indicate that this system will not work in an outdoor environment.
This project does neither include development of the rules by which the sensor network will work nor will the signals produced be used for further computation.
3.2
Approach
The project consists of four parts which are Investigation, Implementation, Evaluation and Summarization, whose work flow is described in figure 3.1
Figure 3.1: Planning (organization) of the work
3.2.1
Investigation
The background of the project is examined and the related projects are reviewed. The goal of this part of the project is to collect as much data as possible about the subject of wireless sensor networks. This is done partially to avoid reinventing the wheel but also to get a better understanding of the parts which generally tend to be harder to implement.
3.2.2
Implementation
This phase combines the knowledge gained in the previous phase and the application requirements. The result is program code used to control and run on the hardware. The programs written are specific for our application, which means that very few or no common functions or nesC components are used. Mainly the really hardware specific nesC components are used as they are, while they already are optimized for the hardware and there is no obvious need to rewrite the code that handles the individual pin data associations on the processor.
CHAPTER 3. METHOD
3.2.3
Evaluation
The implementation is evaluated and notes are made to be used in the final documentation. The complete functionality requirements are broken down to smaller parts which are implemented, tested and evaluated one by one. This reduces the complexity in getting it all working while there are fewer possible errors to commit with smaller modules. When a module is successfully implemented, it is easier to implement the rest knowing that the previously completed work is free from flaws and errors. A custom debugging program is also developed on the computer-side. This program is written in Java and is solely used to debug and verify the communication up to the PC. This program is also important because it contains the data transmission protocol between the standard TinyOS messages and the STITCH coordination language.
3.2.4
Summarization
The documentation phase comes into action when the Implementation/Evaluation loop reaches a final state. Then the results are analyzed, summarized and discussed.
CHAPTER 4. RESULTS AND DISCUSSION
4
Results and Discussion
In this chapter, the proposed sensor network architecture and the obtained results are presented and alternative additions, the tools and test environments used to obtain these results are discussed.
4.1
System Architecture
The functionality of the sensor network heavily depends on the overall system architecture. Not placing the base nodes strategically correct may influence the system stability or even reduce it completely.
We propose a solution where there is no urgent need to cover the entire office area with radio signals in order to maintain a secure sensor system. This is true as long as all exits and entries to the office area are “guarded” by some base station which has the main task of keeping track of people and equipment entering or leaving the office. If then someone is trying to steal a laptop it will start sending out alarm signals and the theft will be detected as soon as the thief approaches an exit. To achieve a higher efficiency and if the base station is out of range, the alarm signals can be forwarded to it by other sensor modules applying a multi-hop protocol. Such other sensor modules could in this case be other protected equipment or trusted persons with ID tags that are within the transmission range.
Perhaps the biggest problem of the proposed system architecture is the reduced possibility to expand it with new functions without affecting the entire system too much. If we, for example, introduce a new kind of sensor to alter a single office only and leave the rest of the floor unchanged, like a camera which takes a picture of the room when an alarm is detected, we have to implement a new sensor network locally in the particular office and then somehow incorporate it with the existing architecture. If there are any further “hardware upgrades” to the office, they will require a network of their own which in turn is to be integrated with the existing system. With no common base for these additional networks, it can get rather messy after some time. Therefore, it would be desirable if there would be some kind of access point or local control station present in each office that already has some kind of basic but still extendable intelligence; for example, keeping track of equipment and people in the room or telling the laptop to shutdown its screen and the drawers to lock themselves, but which is also easy to connect to other new sensors and actuators and thereby extend its intelligence. This would also be a neat property while the workload is then distributed down to the single office level and not all events need to be reported to the coordination environment, but they still might need to cause reaction somewhere in the system. This extension to the proposed sensor network architecture does not affect the overall security, but offer a possibility to office level customization of security rules. The local control station can be set to react in a certain way in my office without affecting or causing unnecessary load on the general coordination environment. Neither of the architectures presented so far are by any means optimized for power ef-ficiency while the single sensor module is forced to send alarm signals until it is reset. Alternatively, several sensor modules could be involved in the alarming process by utiliz-ing a multi-hop messagutiliz-ing structure. There would also be a problem with keeputiliz-ing track of
the stolen equipment on a “cross-office” level, if the alarm is reset as soon as it is detected by the first base station. There is an extension to the proposed solution that will solve the energy consumption problem and the alarm detection delay; if a larger part of the office area is covered and monitored by several base stations connected to the coordina-tion control system. Thus the messages and alarms would not have to travel considerable distances or through several other, perhaps sleeping, sensor nodes.
Figure 4.1: The thief (filled circle) is trying to escape with the prey (outlined square) and he is detected by the general system only when positioned within the range of a base station (outlined white triangle), but before that, a picture might have been taken of him, and doors could have been locked or other actions taken within the particular office due to the settings of the local control station (outlined gray triangle), which also registers the alarm signals sent by the stolen but protected equipment.
Figure 4.1 shows an office environment at Halmstad University where each room has its own local control station (gray-filled triangles), which is used to modify the particular office environment according to the devices that are present. For example, a camera can take a picture of the room when an alarm is detected or a light sensing device can turn on the lights, if it is too dark. These settings are not controlled by the general coordination environment but is still cooperating with the overall Open Secure Office environment. Figure 4.2 shows an office environment similar to that of figure 4.1. Here the owner (outlined circle) of a protected object (outlined square), like a laptop or a PDA, is not in the direct line of sight of his or her property. A non-trusted person (filled circle) is then trying to steal the equipment. Even though the protected equipment senses the unauthorized action and sends the movement signals continuously, the message itself is not detected until the thief is within the range of a base station (outlined triangle). Figure 4.3 also shows the same environment found in figure 4.1 but with a smaller mod-ification to the sensor network. In such a case the alarm messages can be sent through other optional sensor modules (pale outlined squares and circles), if a base station (out-lined triangle) is out of reach. Besides the neat property of instantly notifying the system of a theft, this solution also results in a higher security in terms of message redundancy.
CHAPTER 4. RESULTS AND DISCUSSION
Figure 4.2: The thief (filled circle) is trying to escape with the prey (outlined square) and is detected only when approaching a base station (outlined triangle) guarding an exit.
Figure 4.3: Alternative alarming method is an epidemic multi-hop protocol where each node (outlined circles and squares) forwards the alarm once.
Thus, there are several paths (thick bezier curves) the message can travel along, and if one is broken, there might be others that are not.
4.2
Sensor Network Components
The hardware platform for the Open Secure Office Project is proposed to be the “motes” from Crossbow Technology Inc. [1] (see figure 4.4). This platform is chosen mainly based on the fact that the components meet all the requirements stated in section 3.1 but also while it was the only platform available at project start and no time had to be waisted on waiting for new deliveries to arrive.
The hardware devices in the development kit are: • 4 × Mica2 processing elements (MPR400CB). • 4 × Mica2dot processing elements (MPR500CA).
• 3 × sensor boards for Mica2 processing elements (MTS310). • 2 × sensor boards for Mica2dot processing elements (MTS510). • 2 × prototype boards for Mica2dot processing elements (MDA500). • 1 × programming board (MIB510).
Besides the above presented list, an additional programming board was ordered to enable connecting yet another processing element to a PC. This way the coordination environ-ment could be tested for redundant information response, that is, how it reacts on multiple messages telling the same story.
As far as the choice of hardware is concerned, there are no further limitations or special criteria to take into consideration – more than those raised by performance issues – as long as the hardware modules can be programmed and the sensors can be easily changed. This means any hardware platform that can run programs developed for TinyOS is suited for this application.
Figure 4.4: The main components of the hardware platform for the Open Secure Office Environment. Top left: Mica2 processing element. Top right: Programming/docking board. Bottom left: Mica2 sensor board. Center: Mica2dot processing element. Bottom right: Mica2dot sensor board.
CHAPTER 4. RESULTS AND DISCUSSION
4.2.1
Mica2 Processing Element
The Mica2 processing element is a tiny system-on-a-chip architecture with a micro con-troller, digital and analogue input/output, SPI and I2C data protocol developed by Philips
and a multi channel radio. It has rather limited memory- and computation resources, for example, there is a 128 KB large/small program flash memory, a serial measurement flash memory of 512 KB size which is enough to store more than 100 000 measurements and an electrically erasable programmable read only memory (EEPROM) of 4KB size [21]. The default clocking crystal makes it possible to clock the Atmel ATmega 128L micro con-troller up to 8 MHz [14]. The Mica2 also has a reliable high-speed UART implemented which, in combination with a programming board (see figure 4.5), makes it suitable for use as a base station.
The Open Secure Office Project project basically relies on the functionality of the base stations. These base stations aggregate data from sub-nodes in the sensor network and forwards them to a coordination environment; hence, it is important that the base station can connect physically to a more powerful processor, like a PDA or a PC. The Mica2 processing element can in combination with the programming board be connected via an RS232 interface to a PC and is partly therefore chosen to be used as a base station. This decision was also more or less forced by the hardware architecture on the Mica2dot processing elements. Rather late in the development process and by unofficial sources1 it
came to our understanding that the Mica2dot does not have a reliable high speed UART, hence it is really unsuitable to be used as a base station. This is a bit of a drawback while there are not such extensive sensor board solutions for the Mica2dot as for the Mica2, thus it would be a better use of resources to utilize the Mica2dot as a base station and the technically more advanced Mica2 as sensing elements.
Figure 4.5: The Mica2 processing element attached to the programming/docking board.
1The unofficial sources consist of posted messages on the FAQ page of Crossbow Technology Inc [1]. While the credibility of FAQ pages are questionable after some time due to hardware upgrades and third party walk-arounds, et cetera, we choose not to reference the FAQ itself instead we feel satisfied by mentioning the key words used on the FAQ page in order to obtain the information; “Mica2dot” and “base station”.)
4.2.2
Mica2 Sensor Board
The Mica2 sensor board, which is a collection of sensors, is attachable to to the Mica2 processing element. The Mica2 operates independently of the sensor board, that is, it can send and receive messages via radio or to the on-board UART or light its LEDs even though there is not any sensor board attached to it. The sensor board on the other hand does not make any sense without the Mica2, while sensor readings are not useful unless operated on or in some other way worked upon. Each and every sensor has individual power control [22] which means they can be turned on and off independently of each other. This is really a smart design from an energy saving point of view while only those sensors in use consume battery power.
The sensor boards for the Mica2 in the development kit have a set of five sensors, which are [22]: • Accelerometer. • Acoustic sensor. • Light sensor. • Magnetometer. • Thermistor.
In the Open Secure Office Project, the accelerometer, which is the dominant sensor of use, can be used to detect when protected equipment is moved or perhaps a door is opened. The buzzer and microphone can be involved in the distance determination process between sensor nodes. This can be done by sending a high-frequency sound pulse just before sending a radio message. When a node receives the radio message, which travels much faster than sound, it activates its microphone and a timer. After some time, when the sound pulse is registered, the timer is stopped and by knowing the speed of sound in air, the time of flight of the sound pulse can be used to calculate the distance between the sending node and the receiving node. This feature has not been implemented in this application.
The sensor board is not only physically attachable to the Mica2 processing element but also to the programming board to be used in combination with a base station (see figure 4.6). Crossbow also grants an opportunity to order custom sensor boards for all processing elements they supply, if the standard equipment is not satisfactory for certain projects.
4.2.3
Mica2dot Processing Element
The Mica2dot processing element, which has mainly the same functionality as the Mica2, has the same hardware specification except for the data interfaces. The Mica2dot has only digital and analogue input/output, no SPI or I2C protocols are implemented [23]. The lack of a reliable high speed UART also differentiates the two platforms (see section 4.2.1). Even though there is a UART on the Mica2dot, it is not to be used to extract data directly from the Mica2dot as if it was a base station. Still the Mica2dot can be attached to the
CHAPTER 4. RESULTS AND DISCUSSION
Figure 4.6: The Mica2 sensor board attached to the programming/docking board.
programming board while downloading programs to it (see figure 4.7). Both Mica2 and Mica2dot are also re-programmable by radio, which means that the processing elements do not necessarily need to be attached to a programming board in order to be programmed. Possible reasons for why there are any differences might be the lack of physical size on the Mica2dot and the conceptual difference in operation. The Mica2dot has the size of a Swedish 5 kronor coin which has an approximate diameter of 25 millimeters (roughly an inch), and this leaves a very sparse collection of usable connectors. The Mica2dot only has a 19 pin connector as opposed to the 51 pin connector on the Mica2 and it is of very little interest that there is a rather advanced built in UART in the micro controller [14], if it can not be assigned any expansion pins. The Mica2dot is also intended to be used as a “smart ID tag” [23] and such equipment do not need to function as base stations, hence, there is no idea in increasing the hardware and software complexity by implementing unused technologies.
In the Open Secure Office Project, the Mica2dots are used as ID tags for authorized personnel even though they could be used to do other things as well. As an ID tag, the Mica2dot only has to listen for messages specifically sent to it or global messages meant for all the nodes in the sensor network. As of today, the only messages sent to an ID node in the Open Secure Office Project are identification requests, thus, the only thing an ID tag has to do is to return a message to the sender containing its identification code. The Mica2dot does not have to use a sensor board in this application, but it is possible to extend its functionality by adding one. Then, for example, the current state (moving or standing still) of the person wearing it could be determined and used in addition to other sensor values to exclude certain events. One example is when the office of an authorized person is upgraded with a motion detector: If the motion detector reports motion in the office and the owner’s ID node does report his presence, but also tells the system that he is not moving and, if the owner’s laptop, for example, then reports a movement, then the system can “guess” that it is not the owner who moves the protected equipment and, if an unauthorized person is in the office, an alarm might be appropriate to send.
Figure 4.7: The Mica2dot processing element attached to the programming/docking board.
4.2.4
Mica2dot Sensor Board
The Mica2dot sensor board is a condensed version of the Mica2 sensor board, which is developed for the Mica2dot processing element. It has a few but wisely chosen sensors implemented and all sensor circuits are processor controlled.
The sensors are: [24] • Accelerometer. • Acoustic sensor. • Light sensor.
As mentioned above; the sensor board for the Mica2dot is not as extensive as the one for the Mica2, but for the same reasons regarding physical size and operational mode as stated in section 4.2.1, there is no reason to implement more. The functionality is the same as for the sensor board for Mica2, and even though the Mica2dot can not be used as a base station, the sensor board can still be attached to the programming board and, thereby, tested and used (see figure 4.8).
4.3
Hardware Specific Software
NesC and TinyOS are based upon modularity. The Open secure office makes use of this functionality. Modules have been developed for radio and RS232 serial communication. For radio communication, the Mica2RadioM was implemented and Mica2UartM for RS232. These medium level modules take care of the low level interfaces and makes it easy and quick to set up a stable communication. Note that these modules are not the optimal solutions, because they involve more general nesC-code that is not optimized for this application. The Mica2UartM module, which is only used in the base station, is connected to STITCH, but it also serves as a debugger for the other modules during development.
CHAPTER 4. RESULTS AND DISCUSSION
Figure 4.8: The Mica2dot sensor board attached to the programming/docking board.
4.3.1
Mica2RadioM
A module for radio communication has been developed. This module makes it easier to setup a stable radio communication. Interfaces to the RadioCRCPacket module, of lower level, are of the types StdControl, BareSendMsg and ReceiveMsg.
Mica2RadioM, which provides and requires the interface BareSendMsg, also needs a StdControl interface. All received messages are forwarded to the Base module, that is connected via interfaces to Mica2RadioM, regardless of the containing information.
When messages are received, Mica2RadioM calls an event named RadioToBase.send in the base module, via the BareSendMsg (Number 3 in the figure 4.9). When a message is to be sent, the Base module calls the event BaseToRadio.send via the interface BareSendMsg (number 2 in the figure 4.9). The interface StdControl handles the init, start and stop functionality (number 1 in the figure 4.9).
Figure 4.9: Mica2RadioM module with interfaces.
4.3.2
Mica2UartM
Mica2UartM transfers messages from a module to a RS232 serial communication with no constraints regarding the information in the message. To use the module, the interfaces
1, 2 and 3 shown in the figure 4.10 must be implemented.
1. The interface StdControl, controls the init, start and stop functionality.
2. When a message is received on the uart, Mica2UartM calls an event UartToBase.send in the BaseM module via the BareSendMsg interface.
3. When the BaseM module sends a message on the RS232 line, it calls an event named BaseToUart.send in the Mica2UartM module via the BareSendMsg interface.
Figure 4.10: Mica2UartM module connected via interfaces.
4.3.3
Mica2AccM
The Mica2AccM module is written for extracting data from the accelerometer sensor on the sensor boards (see section 4.2.2 and section 4.2.4). Even though the nesC programming language and the TinyOS operating system support event driven functionality, there was no smart and easy solution to be found on how to automatically react on accelerations. Instead the Mica2AccM module asks for the current X- and Y-acceleration values 20 times a second, the answers then generate events from the sensor board. These requests are sent through the ADC interface. There is one separate instance of the ADC interface for the X-directional accelerations and one for the Y-directional accelerations.
The StdControl interface is used to prepare the accelerometer for usage, that is initialize, start or stop the component. The Mica2AccM is prepared in the same manner by the top-level module in the accelerometer application.
The ADC interface is built up by an asynchronous command called getData which initializes a single sensor reading. When there are data ready to use, the dataReady event is raised. There is also an asynchronous command called getContinuousData which automatically initializes a new request for sensor readings after the dataReady event has been raised. The communication between the Mica2AccM and the top level module is of a push-technology type, that is, messages are sent rather than requested. The interface used for this communication is the BareSendMsg interface which has a send command and a sendDone event. The send command is implemented in the receiver but called from the sender when it wants to send a message. The sendDone event is raised from the receiver when the message is received, and then used to notify the sender that the message is collected. The sendDone event has to be called manually.
Figure 4.11 describes how the Mica2AccM module is bound to the top level module and the hardware specific module.
CHAPTER 4. RESULTS AND DISCUSSION
Figure 4.11: Mica2AccM module with interfaces
4.3.4
Base Stations
The base station is an access point to the system that connects via an RS232 serial communication to the control node running STITCH. Basic functionality includes “check in” from motes in the radio communication area, transmission of “movement” messages from accelerometer motes to STITCH and send “alarm” messages over the radio that are received from STITCH.
This application is built up by linking the modules SingleTimer, Mica2UartM, Mica2RadioM and LedsC to Mica2BaseM, as shown in figure 4.12.
The base station mote sends out a message asking if some other mote receives the “Do You Sense Me” message. A received message containing the information “I Sense You” with the destination address that matches the base motes ID, results in a message to STITCH. The message contains a “check in” and the ID of the replaying mote. This procedure is done every fifth second, controlled by the SingleTimer module. SingleTimer activates an event named Timer.fired.
Motion messages from accelerometer motes received over the radio, regardless of group type, are transmitted to STITCH via the Mica2UartM module. The transmitted message encloses motion data and ID from the sender.
Alarm messages from STITCH are reorganized by setting the message address to the receiver’s ID, the message type to alarm and data to “Alarm”.
4.3.5
Identification Tags
The personal mote is programmed to do nothing unless it is spoken to (see figure 4.13). In order to save energy, a received “Do You Sense Me” message from a base station is replied to only once. To reply to the same base station again, it has to receive another “Do You Sense Me” message from another base station first. If the received message is from an accelerometer mote, which means the accelerometer mote is looking for its owner, it will reply with the “I Sense You” message, every time. The only difference in the “Do You Sense Me” message, regarding whether it is sent from a base station or an accelerometer mote, is the address in the message. Messages from base stations are sent with the address set to “all motes”, while messages from accelerometer motes are sent with the owners ID in the address field in the message.
The red LED is switched on, if the personal mote receives an alarm message, for illustration purpose only. If the alarm message is meant to another personal mote, the message will be forwarded once.
Figure 4.12: The module diagram shows the implementation on the base station mote. SingleTimer, Mica2UartM, Mica2RadioM and LedsC are low level modules. They are hardware specific and are connected via interfaces to the Mica2BaseM module.
Figure 4.13: The figure shows the module implementation in the personal mote.
4.3.6
Accelerometer Nodes
The Accelerometer mote (described in figure 4.14) is attached to the protected equipment. The mote is sensitive to movements in two directions. After a detected movement, the mote sends out a “Do You Sense Me” message to its owner and at the same time the yellow led is turned on. The message is sent five times in one second. A received “I Sense You” from the owner, results in that the yellow led is turned off and the green led is turned on for one second. If the mote does not receive a message, it will send a “movement” message to a base station and the red led is turned on for two seconds.
A received “Do You Sense Me” message from a base station is replied only once with the message “I Sense You”. To be able to answer the same base station again, the accelerometer mote has to receive another “Do You Sense Me” message from another base station first. Received alarm messages will be forwarded once. All LEDs are used for illustration purpose only.
