-
1
A Framework for Measurement Anomaly Detection in Sensor
Networks
By Kartik Nathan ([email protected] )
Project Report
Submitted to the Faculty
Of the
ROCHESTER INSTITUTE OF TECHNOLOGY
In partial fulfillment of the requirements for the
Degree of Master of Science
In
Computer Science
March, 2009
______________________
Professor Leon Reznik, Chair _________________
Professor Manjeet Rege, Reader _________________
Professor Roxanne Canosa, Observer _________________
-
2
Acknowledgements
I would like to thank my Chair, Prof. Leon Reznik for his
valuable inputs during the
conceptualization and implementation of the project. Prof.
Rezniks advice and feedback was
critical to the successful culmination of this project and I am
very thankful to him for his
guidance. I would also like to thank the members of my defense
committee, Prof. Manjeet Rege,
for his role as the Reader for my project and Prof. Roxanne
Canosa for her role as the Observer
for my project. The C.S Faculty has played a critical role in
giving me the right perspective and
improving my understanding of the subject and I greatly
appreciate their efforts in making this
possible. I would like to thank my Graduate Coordinator Prof.
Hans-Peter Bischof for his timely
advice and for motivating me to do my best.
I am grateful to the CS department for encouraging scholarly
endeavors and providing excellent
infrastructure to facilitate it. I would also like to take this
opportunity to thank my parents and
family, who have been instrumental in their encouragement of my
pursuit of the Masters Degree
in Computer Science at this Institute.
Kartik Nathan
R.I.T, M.S. C.S 09
-
3
Contents Acknowledgement
......................................................................................................................2
1. Abstract
...................................................................................................................................5
2. Introduction
.............................................................................................................................5
3. Literature Review
....................................................................................................................8
4. Tools Review
........................................................................................................................
11
5. Problem Statement
................................................................................................................
12
6. Goals
.....................................................................................................................................
12
7. Proposed Solution
.................................................................................................................
13
8. Design
...................................................................................................................................
14
8.1 Platform Capabilities
.......................................................................................................
14
8.1.1
Hardware...................................................................................................................
14
8.1.2 Memory Usage
..........................................................................................................
15
8.1.3 Networking
...............................................................................................................
16
8.2 Design Goals
...................................................................................................................
18
8.2.1 Concurrency
..............................................................................................................
18
8.2.2 Asynchronous Inter-service Communication
.............................................................
18
8.2.3 Real Time Data Processing
........................................................................................
18
8.2.4 Data Aggregation
......................................................................................................
18
8.3 Design Assumptions
........................................................................................................
18
8.3.1 Client Server Architecture
.........................................................................................
18
8.3.2 Distribution of Functionality between Host and Sensor Node
.................................... 19
8.3.3 Use of Generic Connection Framework
.....................................................................
19
8.3.4 Datagram based communication
................................................................................
19
8.3.5 Standard Deployment Process
...................................................................................
19
8.4 High Level Design
...........................................................................................................
20
8.4.1 Network Architecture
................................................................................................
20
8.4.2 Messaging Architecture
.............................................................................................
22
8.4.3 Publisher Subscriber Model
.......................................................................................
22
8.4.4 Multi Level Message Queuing
...................................................................................
24
8.4.5 Detection Algorithm
..................................................................................................
24
-
4
8.5 Low Level
Design............................................................................................................
24
8.5.1 IDaemon
...................................................................................................................
25
8.5.2 ISubscriber and IPublisher
.........................................................................................
26
8.5.3 Message Format
........................................................................................................
26
8.5.4 Detection
...................................................................................................................
29
8.5.5 SPOT Context
...........................................................................................................
32
9. Implementation
.....................................................................................................................
33
10. Tests and Results
.................................................................................................................
42
10.1 Test Setup
......................................................................................................................
42
10.2 Experiment 1: Single Sensor Anomaly Detection using Grid
Indexed Clustering ........... 45
10.2.1 Nature of Simulated Inputs
......................................................................................
46
10.2.2 Experiment 1 Part A
................................................................................................
49
10.2.3 Experiment 1 Part B
................................................................................................
53
10.2.4 Experiment 1 Part C
................................................................................................
59
10.2.5 Results
Summary.....................................................................................................
64
10.3 Experiment 2: Multi-sensor Anomaly Detection using K-means
Clustering ................... 65
10.3.1 Nature of Simulated Inputs
......................................................................................
65
10.3.2 Experiment 2 Part A
................................................................................................
66
10.3.3 Experiment 2 Part B
................................................................................................
68
10.3.4 Result Summary
......................................................................................................
69
11. Conclusion
..........................................................................................................................
70
12. Future Work
........................................................................................................................
70
References
................................................................................................................................
71
-
5
1. Abstract
Sensor nodes are being widely deployed across various domains,
for the purpose of measurement
and data collection. With the increasing trend of sensor
deployment, there is also a growing
emphasis on the security aspects in such networks. One
particular method of security
enhancement is detecting anomalies in the sensor measurements.
In traditional approaches to
anomaly detection, the sensor nodes are responsible only for
retrieving sensor data and
transmitting it. A detection engine usually aggregates the
sensor information, to be able to
identify anomalies based on each sensor nodes profile. In recent
times, the idea of distributing
the responsibility of the detection engine onto the sensor nodes
is being actively explored.
Restrictions in terms of processing capabilities, power
consumption, network bandwidth and
storage limits dominate most sensor network platforms. A
framework that addresses these issues
and provides a way to embed intelligence in the sensor nodes for
the purpose of anomaly
detection is of great utility to the platform.
The primary goal of this project is to provide a framework that
facilitates the implementation of
an anomaly detection system on the Sun SPOT sensor network
platform. The services
implemented as part of the framework are used to develop
intelligent anomaly detection systems
based on clustering and their performance is evaluated using
simulated and real-life test
scenarios.
2. Introduction
The primary goal of sensor deployment is the ability to measure
environmental conditions in the
areas where they are deployed. A Sensor Network allows for
aggregation of sensor data obtained
from multiple sensor nodes and their analysis at the processing
node. The task of data collection
from sensor nodes in a network usually involves generation of a
stream of data from each of the
sensor nodes. The stream is eventually stored at a central
location, where a real-time analysis or
offline analysis is done. As the number of sensor nodes in the
network increases, so does the
effective bandwidth consumed by the network. In addition to
this, there is greater competition for
resources, as the sensor nodes send all the information to the
central node. To add to this
complexity sensor nodes are also able to utilize the
architecture of the sensor network and the
underlying platform, to route the messages from one node to
another, using intermediate nodes.
-
6
These complexities increase the power consumption of each sensor
node, and effectively reduce
the lifetime of the network. Given these drawbacks, the idea of
distributing the task of data
collection or the eventual internalization of detection within
the sensor nodes presents significant
benefits, both in terms of bandwidth consumed and in terms of
reduced load on the central
server. This form of optimization can be effectively achieved by
the embedding of intelligence
on the sensor nodes. This project builds on research in the area
to embed intelligence on sensor
nodes for the purpose of data anomaly detection.
The Sun Small Programmable Object Technology (SPOT) gives us the
bare-bones platform that
can be used to build the framework. The SPOT supports routing
and route discovery using the
AODV protocol. This allows for multi-hop communication. It
provides Object API to access the
various hardware components such as Sensors, Battery, Radio and
other external input and
output pins. The SPOT presents the various building blocks that
can be used to implement the
Framework. Currently, the SPOT does not comprise of an anomaly
detection module or a data
collection framework. This project aims to give SPOTs that
capability. In addition to anomaly
detection, the project also implicitly provides methods by which
data collection can be carried
out over the network.
The definition and the focus of intrusion detection vary based
of the domain to which it is
applied. In the network security domain, intrusion detection is
used to cover the methods that are
used to detect abnormal network activity, payload abnormality,
authorization and authentication
flaws. In addition, it is also used to identify traffic based
attacks that are performed on the nodes
of the system. Unlike the all encompassing view of intrusion
detection, the intrusion detection
that I wish to address, is data anomaly based attacks. Intrusion
detection is broadly categorized
into misuse detection and anomaly detection.
Misuse detection is generally associated with rule based
engines. Features of network traffic are
compared with significantly large database of attack signatures.
Most anti-virus applications
predominantly incorporate this form of intrusion detection. The
greatest advantage of using this
technique is the speed with which the attack can be detected.
Another advantage of using misuse
detection models is the accuracy of detection. The attack either
follows a particular pattern or
does not. This dichotomy yields precise results. Effective
performance of this method is deterred
by the fact that misuse detection is based on a priori knowledge
of the domain, and cannot be
-
7
applied to a network one knows nothing about. Since it is a
classification based method, one
must also have all possible misuse classes defined. In other
words, misuse detection cannot be
used to infer unknown attacks. This may lead to serious issues
with false negatives.
To overcome the shortcomings of misuse detection, it is
complemented by anomaly detection.
Anomaly detection is a technique that is used to identify
anomalies in traffic or measured
quantities based on historical information. Unlike misuse
detection, data is not compared to pre-
defined signatures, instead they are compared to dynamically
generated historical indicators of
correct behavior, and this is usually referred to as a Profile.
Anomaly detection techniques
usually measure the deviation of a current measure from the
normal. The deviation is usually
based on statistical analysis of measurement data. One of the
biggest advantages of Anomaly
Detection is the ability to detect attacks without signature
databases. In contrast to misuse
detection, the detection in this case is more probabilistic. As
it appears, the measures of accuracy
like False Positives and False Negatives play a larger role in
this perspective. Improvement of
performance in perspective of False Positives and False
Negatives presents interesting research
challenges.
While simpler forms of anomaly detection are based on static
profiles, the strength of this
approach is enhanced with adaptive and self-learning techniques.
For instance, most anomaly
detection routines involve building a model that is then used to
evaluate the data in real time. The
model is built from the profile. This profile consists of
measurements taken for a specific time
period, when the behavior of the sensor and the environment is
considered normal. The data that
is used to construct the profile and hence the model, is called
the training data. Learning is
further divided into a dichotomy of Supervised and Unsupervised
learning. In Supervised
learning, the data is labeled indicating the expected
classification for a particular input. In
unsupervised learning, the classification is implicitly
determined using the regression based
predictive function. In supervised learning, one assumes to know
about the environment and
parameters of normalcy. In unsupervised learning, while data is
automatically classified based
on the predictive function, the eventual labeling and hence its
interpretation is open.
Unsupervised learning enables detection of previously
undiscovered attacks.
Several methods that realize the concepts of supervised and
unsupervised learning algorithms
exist. These methods are also called classification methods.
Neural Networks (Multi-layer
-
8
Perceptron), Support Vector Methods, k-Nearest Neighbors,
Gaussian Mixture Model, Gaussian,
Nave Bayes, Decision Tree and RBF Classifiers are the various
methods used for classification
The following section describes how some of these
classifications have been applied to sensor
networks with varying degrees of success and their applicability
to the current project.
3. Literature Review
Approaches to intrusion detection, more specifically anomaly
detection, have been usually split
evenly between network anomaly detection and host based anomaly
detection. Numerous
approaches that address the network based anomaly detection
exist. This project focuses on Host
based anomaly detection.
Rajasegarar et al [1] discuss a method of anomaly detection that
performs on par with centralized
techniques of data collection, using clustering techniques. The
goal of the project is to reduce
the communication overhead. The basic assumption in this
regards, is that the sensors have been
deployed in a hierarchical topology and in a homogenous
environment, and thus the
measurements follow the same unknown distribution. The
measurements are time synchronized
and a window of measurements is used as the benchmark for
detecting outliers. A fixed width
based algorithm used in their approach. They compare their
approach with a centralized
clustering approach. In the centralized approach, the sensor
nodes, at the end of each window,
send their entire data to the gateway node that in turn combines
its data with the received data
and then runs the clustering algorithm on the combined data. In
the proposed Distributed
approach, the volume of data is significantly reduced by moving
the clustering logic to each of
the sensor nodes. The minimal amount of information that needs
to be sent through the various
hierarchical levels is the centroids of the clusters and the
number of nodes within each of the
clusters. Based on these arguments, a similar approach to
clustering could be used to test the
proposed anomaly detection framework. One of the challenges in
implementing the clustering
based methods is that, clustering is usually static in nature
hence is not able to re-capture normal
behavior, once the sensors are deployed in disparate
environments. One of the strongest
arguments for using clustering based approaches is the ability
to optimize many operations to
linear time, with cluster merge accounting for quadratic
complexity.
-
9
Data mining approaches have been proposed for inferring features
and intrusions from data in
several research articles. One of the earliest works that
suggested these ideas was by Wenke Lee
et al [2]. In the paper, the authors suggest two mining methods
that could be applied to mine
intrusion data, one, an association rule based algorithm and the
second a frequent episode based
algorithm. It is important to note that while rule based
identification is extremely accurate, it is
most frequently used as a method of offline detection. In a
succeeding work, they qualify their
work by suggesting the application of data mining in real time
for detection of Intrusions. The
approach suggested by them is based on the building a Decision
Tree Model that can be
effectively trained based on labeled data. This model is
referred to as the RIPPER algorithm [3].
In the suggested method, features are extracted from the Network
Traffic data. In order to extract
the correct features, the network data is first categorized
under discrete chunks under fields that
are applicable to network traffic. The data is categorized by
timestamp, duration, source and
destination IP addresses and ports, and error condition flags
[4]. Correlations between the data is
measured and a pattern of the form A, B -> C, D [confidence,
support] [4] is obtained. A and B
are events that lead to events C and D. They also suggest that
this form of empirical learning was
most effective when evaluating the 1998 DARPA Intrusion
Detection Evaluation [5]. Rule based
learning engines have been found to perform the best when
considering the various learning
techniques applied on the data. Similar Decision based/ Rule
based Learning engines have also
been used to filter anomalous real time intrusion alerts from
selective sensors based on historical
information and the formation of the model by the rule engine
[6].
In addition to the application of Data Mining based algorithms,
there have been proposals to
apply intelligent methods to effectively detect anomalies. One
of the methods proposed, is the
usage of Instance Based Learning [7]. Instance based learning
involves finding instances from
the data that closely classify the incoming data. The incoming
data is classified based on the
instance dictionary of the system. The K-Nearest Neighbors
algorithm is an example of Instance
Based Learning. Each new instance is classified based on its
proximity among the k neighbors.
The measure of proximity is usually based on Euclidean distance
or a comparable value based on
the measurement domain. One of the biggest drawbacks of using
Instance Based Learning is that
there could be infinite number of abnormality classes. In such
cases, the instance dictionary can
expand boundlessly. Lane et al [7] recognize this shortcoming
and suggest data-reduction to
reduce the size of the Instance Dictionary. Two methods of Data
Reduction are contrasted,
-
10
Instance Selection, incorporating algorithms like FIFO, LRU and
LFU and Clustering
algorithms, incorporating K-Means Clustering and Greedy
Clustering System. The Clustering
techniques were found to gracefully degrade in performance based
on the reduction of profile
information in contrast to the Instance Selection Algorithms,
which degraded more rapidly.
In addition to Instance based algorithms, Neural Network based
learning has also been gaining
traction as an effective method of anomaly detection [8]. Neural
Networks present a powerful
method that can be used to overcome the shortcomings of Rule
based learning engines. However,
in order for the Neural Network based model to be effective, it
is necessary to train the model
with both normal and abnormal data sets, in other words, Neural
Networks perform optimally
when considered for Supervised Learning. In the paper [8] , the
approach adopted by the authors
differs from the usually approaches to intrusion detection, in
the following ways. The training
data set is optimized by reduction of repeated elements. Normal
behavior composes 50% of the
actual training data set, while the remaining is uniformly
distributed across various other attacks.
Another significant diversion that was proposed was the
classification of each individual attack
as opposed to a broad classification of attacks into different
groups. Doing so reduces the number
of misclassifications and improves detection reliability. The
neural network approach
successfully detected unknown attacks, using RBF (Radial Basis
Function) Neural Networks. In
various tests, the RBF based classifier was found to be much
more effective at detecting
intrusions than Multilayer Perceptron based Neural Networks. In
context to this project, the
implementation of Neural Nets on the sensor nodes introduces
additional complexity, both in
terms of processing power required and the amount of storage
needed to support the neural
networks. This complexity makes it infeasible for a full scale
implementation on the Sun SPOT
Sensor Network Platform.
The generic problem of Anomaly Detection has been addressed by
various researchers using
techniques like Decision Trees, Data Mining algorithms like K
Means, Instance based Learning
in the form of K Nearest Neighbors and Artificial Intelligence
approaches like Neural Networks.
Many of the methods are self sufficient, and address both Misuse
and Anomaly Detection. Each
method varies in the amount of processing power expended and the
storage required for effective
operation. Supervised Learning methods have been found to be
more effective in detecting
attacks. A common practice in measuring performance of network
intrusion detection is to use a
-
11
portion of KDD cup [2] data as training data, currently, no such
benchmarks exist for Sensor
Networks. The scope of supervised learning in the area of sensor
measurement anomaly
detection is very limited, since there is no concept of known
attacks in context to sensor
measurement. Supervised learning in context to Sensor Networks
is most applicable when
considering Network Anomaly Detection. In context to data
anomaly in Sensor Networks,
unsupervised learning that performs efficiently with memory
constraints, and requires minimal
resources for retraining, is most desired. The proposed
framework aims to address these goals.
4. Tools Review
Suns Small Programmable Object Technologies, is a set of Java
enabled sensor nodes coupled
with a transceiver known as a base station. The Sensor devices
run the Java based Squawk
Virtual Machine [9]. Using the Sun SPOT SDK and the Java API, we
can embed java programs
on the sensor devices. In addition to this, the SDK also
provides for interaction between the
sensor devices and the host computer using the base station. A
detailed list of available APIs can
be found on the SunSpotWorld website [10]. The Netbeans IDE
provides built in support for
SPOT Host and Client applications using a plugin which is
downloaded via the Update Center.
When applications are created using the Netbeans IDE, the
appropriate runtime environments are
automatically configured and the jar files that are available
for that particular environment are
automatically brought into the class path. This enables us to
develop applications that follow the
restrictions imposed by the run time environment of the target
platform. The applications are
deployed onto the SPOTs using ant build scripts. The ant scripts
use the SDK to compile, build
and transfer the jar files onto the SPOT application space. The
SDK also provides ways in which
the base station can be used to remotely deploy applications
onto different SPOTs. A detailed
explanation of the deployment procedure can be found in the SPOT
Developers guide [11].
Starting from the Purple SDK, the Solarium [12] tool (formerly
SunSpotWorld), has been made
available to the general public. The tool is used for the
discovery and management of SPOTs. In
context of this project, the Solarium tool is used to emulate
virtual SPOTs, which can be used to
test the functionality of the SPOT based application, before
deployment to actual SPOTs. The
emulator provides us the capability to create a SPOT deployment
configuration, loading and
execution of applications, manipulation of sensor and other I/O
data and monitoring of execution
-
12
by redirecting the standard output to the user interface. Using
the SPOT Emulator in
SPOTWorld [13] describes these capabilities in greater
detail.
5. Problem Statement
Solutions for measurement anomaly detection in sensor networks
have usually been custom
built, depending on the nature of the underlying platform and
the approach that is used to detect
the anomaly. While building a customized solution has its
benefits, there is significant effort
expended in handling common tasks on both sensor nodes as well
as data collection nodes. Most
sensor network platforms provide methods to perform basic
networking and handle the
scheduling of the various processes spawned by the embedded
application. In addition to this, the
object level access to hardware enables applications to access
the sensor data. Each of these
services is decoupled from the other, with the application
programmer having to pass
information between the different services running on the sensor
and performing rudimentary
inter-service communication. To build powerful applications that
utilize these services, it is
necessary to build high level components that handle the
primitive operations and provide a
better abstraction to the programmers. Apart from the
extensibility of the underlying framework,
the anomaly detection algorithm utilizing the framework must
address challenges such as Real
time processing of sensor data, near linear time detection,
efficient storage of information and
efficient network utilization. The implementation of a local
intelligent anomaly detection method
also obviates the need for sending all sensor data to the data
acquisition server. Each sensor node
can independently detect anomalies and decide to send only the
alerts to the central server, thus
avoiding excessive utilization of battery power for continuous
transmission of data to the server.
Currently, no single framework built for the sensor networks
addresses all these issues to
facilitate the easy deployment of generic anomaly detection
algorithms.
6. Goals
The project aims at building a generic framework that abstracts
the complexity of the frequently
used components in a network based anomaly detection system and
allows the embedding of
intelligent anomaly detection algorithms.
-
13
The primary goal of the project is to provide components that
handle tasks such as network
communication, server discovery, data retrieval, messaging and
event handling. Using these
components, the developer of the anomaly detection algorithm can
build a fully functional
anomaly detection system on sensor networks. Suns Small
Programmable Object Technologies
(SPOT) is the platform used to realize the framework design. The
framework addresses the
following requirements.
The administrator must be able to determine sensors running the
anomaly detection
application.
The administrator must be able to communicate over network to
control the data flow as
well as control the internal state of the sensor nodes.
The administrator must be able to initiate the appropriate
anomaly detection algorithm on
each of the sensor nodes.
The administration console must be capable of receiving sensor
data from each of the
sensors, over the network.
Depending on the implementation of anomaly detection algorithm,
the administrator may
choose to be notified on an as needed basis, i.e. the
administrator may subscribe to only
alerts, or only data, or both.
The framework must be able to support different types of Anomaly
detection algorithms,
running simultaneously, and independently of each other.
7. Proposed Solution
This project aims to provide a framework that could be used to
embed intelligence in the sensor
nodes for the purpose of anomaly detection. The framework seeks
to simplify the inherent
complexities of accessing sensor data and communicating with the
server. The project facilitates
the generation of messages and their interpretation on both the
client and the server. The
framework is implemented as Host based and SPOT based parts. The
SPOT framework is used
to handle data collection, network based messaging and message
handling. The Host framework
is used to discover nearby SPOTs, broadcast messaging, message
handling and support for
multiple views.
-
14
The framework is used to support the functionality of clustering
based intelligent anomaly
detection algorithms in this project. The strategy of the
algorithm is encapsulated as a state
machine implementing the anomaly detection strategy. The data is
read and processed in a real
time manner. Based on the algorithmic parameters, the algorithm
seamlessly transitions from the
training phase to the detection phase. Data is aggregated and
stored in the main memory to
ensure efficient retrieval. Traditional cluster based approaches
have an O(n) algorithmic
complexity for identifying the closest cluster. Using a grid
based approach [14]; the lookup time
can be further reduced. This idea is explored as part of the
implementation of the algorithm for
single sensor anomaly detection. A grid based algorithm does not
scale well for multi sensor
anomaly detection; hence we pursue the traditional k-means
approach for detecting multi-sensor
anomalies. The algorithm uses the underlying messaging
capabilities to notify the server of the
generated alerts as well as cluster updates. The alerts and the
cluster updates are viewed in real
time at the host using the host part of the framework.
8. Design
To design a framework that addresses the project goals, it is
necessary to understand the
limitations and idiosyncrasies of the underlying Sun SPOT
platform. While general networking
is socket based and provides for connection oriented
communication, Sun SPOTs provide
rudimentary support for sockets, primarily using datagrams and
radiograms for connectionless
connection. In addition to these factors, the target platform
supports programming using only a
subset of the Java programming language. The limitations and
features provided by the SPOTs
play a major role in determining how we go about in addressing
the project goals. The
capabilities of Sun SPOTs and their applicability to the project
are discussed as part of section
8.1.
8.1 Platform Capabilities
8.1.1 Hardware
Suns Small Programmable Object Technologies are battery powered
sensor devices running the
Squawk JVM [9]. The SPOT comes equipped with a 32 bit 180 MHz
ARM920T processor, with
512K of RAM and 4MB of Flash memory [15]. It also comes equipped
with support for radio
communication over 802.15.4 with a range of 80 meters. In
addition to the main processor, the
-
15
eDEMO board [16] also features I/O interfaces for USB, SPI and
Programmable I/O based
communication. The SPOT is powered by an internal 3.7V 720maH
rechargeable lithium ion
prismatic cell, which can be charged either using the USB type
mini-B device or from an
external source with a 5V10% supply [16].
The eDEMO board contains a row of 8 tri-color LEDs, and two push
buttons that operate in
parallel. Another device that is of primary importance to the
project is the Analog to Digital
Converter embedded in the eDEMO Board. The analog inputs accept
a voltage of 0-3V in analog
voltage, with the resolution of 1.024mV/count. In other words,
ADC = 1024
is 3.0 V
[16]. In other words, the digitized output of each of the
sensors is in the range 0-1024. These
values are normalized using default and reference values of the
corresponding inputs.
The accelerometer reading in terms of g-force is calculated
using the formula 465 .5
186.2 [16].
The output range of the Luminosity sensor is 0.1V to 4.3V, with
the former indicating dark and
latter indicating light.
The various hardware components and their operational parameters
are covered in greater detail
in the Sun SPOT Theory of Operation Document [16] that
accompanies the standard
documentation of the Sun SPOT SDK.
The use of raw digitized output in the range of 0-1.024 mV for
each of the sensor readings
enables us to build a sensor independent anomaly detection
technique. Operating on quantized
sensor measurements also significantly reduces the eventual cost
of storing and transmitting data
across the network.
8.1.2 Memory Usage
Squawk VM runs from the 4MB Flash memory, taking up 1/3 of the
storage for system code and
leaving 2/3 of the space for application code and data [9]. The
memory map of the Flash memory
is described using the following Pie Chart.
-
16
Figure 1 Memory Consumption of Flash Memory (in KB)
Based on these specifications, the framework must be designed so
as to not physically exceed
384 KB.
On the SRAM, the approximately 20% of the memory is consumed for
system memory while,
the remaining, forms the Java Heap (459KB) [9]. This entails
that the run time memory
consumption by the various objects created by the application
must not exceed 459 KB of
memory.
8.1.3 Networking
The SPOTs support radio communication over the 802.15.4 and
operates in the 2.4GHz to
2.4835 GHz band. It has an output power setting in the range
-24dbM to 0dbM, with an effective
transmission rate of 250 kbps. It consumes 20ma during receive
and 18ma for 0dBm
transmission [16].
SPOTs support a multilayer radio communication stack as shown in
the figure below
VM Binaries
Utilization, 149VM Binaries
Reserved, 107
VM Suite
Utilized, 363
VM Suite
Reserved, 149
Loader, 64
Application
Slot 1, 384
Application Slot 2,
384
Data Space, 2040
-
17
The lowest two layers implement the 802.15.4 specification
partially with maximum data rate
being 32kBps. The third layer (lowpan) is used to multiplex
communication over 255 different
protocols over the radio connection. The goal of the lowpan
layer is to allow developers to build
suitable protocol handlers on top of the layer. Two protocols
that have been implemented using
the lowpan layer on the SPOTs are the radio and radiogram
protocols. These protocols are part of
the Generic Connection Framework. This project utilizes the
Generic Connection Framework
(GCF) for datagram based network communication.
Communication using the GCF is based on using URLs to indicate
connection. The generic
format of a GCF connection string is ://:.The
radio protocol allows for stream based communication while the
radiogram protocol allows for
datagram based communication. Radiogram protocol can also be
used for broadcasting messages
over the network. Broadcast messages are extremely useful in
discovering SPOTs prior to
establishing a peer to peer connection, and this capability is
put to use in the framework.
The hardware capabilities, nature of sensor data, communication
stack and the physical storage
limitations play a critical role in the design of an efficient
anomaly detection system. The project
goals together with the knowledge of platform capabilities
enable us to formalize the design
goals of the project.
radio: protocol radiogram: protocol
lowpan
802.15.4 MAC
802.15.4 Physical
Figure 2 Sun SPOT Communication Stack
-
18
8.2 Design Goals
8.2.1 Concurrency
The system must support concurrent operation of the various
services supported by the
framework. For instance, the network communication, data
collection and the data processing
must take place independent of the execution schedule of the
other. In other words, no service
may act as a bottleneck for the other.
8.2.2 Asynchronous Inter-service Communication
The system must support seamless message passing between the
various components of the
framework. There is a need for greater flexibility than making a
function call and waiting for the
execution to complete.
8.2.3 Real Time Data Processing
The sensors generate data at a continuous rate, to make the most
efficient use of the storage
available in the platform; we must ensure that the data is
processed in real time. The real time
processing requirement entails that the processing must not be
computationally intensive. The
desired algorithmic complexity for all operations is linear time
or lower.
8.2.4 Data Aggregation
Unlike traditional sensor networks, where all the data is sent
to the server, embedding
intelligence on the sensor nodes entails that data can now be
sent on an as needed basis.
Communication with the server is usually critical as soon as an
alarm is generated on the sensor
nodes or an anomaly is found. Alternately, the sensor node may
also opt to aggregate
information over a period of time before sending the information
to the Server, this reducing the
bottleneck at the server. The framework must provide the
programming constructs that allow for
this form of transmission.
8.3 Design Assumptions
8.3.1 Client Server Architecture
The project explores the network communication in context of
client server based architecture as
opposed to peer to peer communication. Hierarchical approaches
to anomaly detection in sensor
networks [1] are usually supported by heterogeneous sensor
nodes, with the aggregate node
-
19
being slightly better capable in terms of radio communication or
processing capabilities. Sun
SPOTs comprise of homogenous nodes, with the exception of the
base station, which is
essentially a transceiver attached to the host computer. As the
only heterogeneous node in the
sensor network is the host computer, client server based
architecture is the logical choice for
implementation.
8.3.2 Distribution of Functionality between Host and Sensor
Node
SPOT API allows for two different types of applications to be
created, the SPOT application
utilizes the run time libraries that are embedded on the
sensors; the host application on the other
hand is given access to the fully functional Java API. The Host
uses the base station as a
transceiver to communicate with the sensor nodes. Taking this
fact into consideration, the
framework is divided into the Host Part and the SPOT part. Both
parts are synchronized to
ensure seamless interaction between the two entities.
8.3.3 Use of Generic Connection Framework
The SPOT API provides a generic connection framework for network
communication. The
SPOT networking stack allows developers to build protocols on
top of the lowpan layer,
however, the radiogram protocol presents a robust datagram based
protocol that could be re-used
for the purpose of network communication between the host and
sensor node. Hence the
framework uses the GCF for network based communication.
8.3.4 Datagram based communication
The nature of the sensor network traffic is continuous or
intermittent, based on how much
information the anomaly detection system decides to send the
server. In most cases, we would
like to avoid the overhead that occurs in connection oriented
communication. By choosing the
datagram based radiogram protocol, we choose to forego the
reliability features provided by the
connection based approach. For purpose of the implementation,
packet loss is not considered a
significant factor in network communication. Real time data
delivery is a prominent factor that
leads us to choose connectionless datagram based
communication.
8.3.5 Standard Deployment Process
Deployment of an application to a Sun SPOT involves loading of
the application on the host and
transferring the application over an USB interface onto the
SPOT. In addition, the SPOT SDK
-
20
also supports the remote deployment of applications using the
over the air (OTA) interface. This
form of deployment presents the most flexibility, and hence the
design does not explicitly need
to provide user interfaces for the purpose of deployment of
anomaly detection algorithms. The
implementation of anomaly detection, control of execution flow
as well as the retrieval of
application specific data is the main focus of the system
design, hence for all practical purposes
the standard methods of application deployment are used.
8.4 High Level Design
As discussed previously, the framework design is split into the
host and the sensor components.
The primary focus of the sensor component is to act as the
client to the server which is powered
by the host component. In addition to the client server
functionality, the client concurrently
subscribes to the sensor data and runs the appropriate anomaly
detection algorithm, while the
host handles the discovery of SPOTs, control messaging and data
handling and internal storage.
8.4.1 Network Architecture
The Sensor network consists of homogenous sensor nodes that are
identified and controlled from
the central server. Support for 802.15.4 protocol, ensures that
medium access and packet
buffering and acknowledgement are taken care of by the
components of the radio stack. The host
starts two network daemons. The beacon daemon is used to
discover the nearby SPOTs and
hence it operates in the broadcast mode. The daemon is reused
for transmission of control signals
to SPOTs. The network daemon on the host operates in the server
mode and handles incoming
datagram messaging.
-
21
The above figure describes the network architecture of the
system. The beacon channel is
primarily used to indicate the availability of the Host Server.
The standard response to the
beacon is the beacon response. In addition to the beacon, the
channel is also used to broadcast
control messages to the connected SPOTs. The SPOT network daemon
responds to the received
beacon and control requests using a client connection to the
network daemon of the host. A full
duplex mode of operation is avoided as the SPOT API specifies
that a broadcast connection may
not be used to receive incoming connections. We thus opt for
operation over two network
interfaces instead of one, to avoid the complexity of having to
multiplex receiving and
transmitting data. This is especially desirable when we are not
sure the frequency of transmission
or receipt. We also choose to broadcast messages to the SPOTs as
broadcast is the most scalable
form of communication with SPOTs. Issues due to power
consumption during broadcast
communication are not applicable to the host application, as it
is assumed to have an unlimited
source of power. The SPOTs on the other hand establish peer to
peer connections with the server
to conserve the battery power.
BeaconDaemon
Network Daemon
Port 55
Port 58
Beacon Channel
HOST SPOT
N/W
Daemon
SPOT
N/W
Daemon
SPOT
N/W
Daemon
Beacon Beacon
Beacon
Response & Data
Response & Data
Response & Data
Figure 3: Network Architecture
-
22
8.4.2 Messaging Architecture
The datagram based radiogram protocol is used to transport
information between the host and the
SPOT. While the protocol supports the delivery of primitive data
types over the network, the
transmission of objects is not supported by the SPOT API. The
framework is a purely object
oriented framework; hence the messages received over the network
are transferred between the
various services as objects. This means that the responsibility
of serialization and de-serialization
lies with the message object. In addition to holding the data
structures that describe the message
format, the message objects also encapsulate the methods that
are used to create the appropriate
datagram (serialization) and load the data, given the datagram
(de-serialization).
Figure 4: Generic Message Object Structure
The above figure describes the generic structure of a generic
message object. This functionality
is abstracted onto a generic (abstract) message object, which is
then extended by each of the
messages. The generic message is passed as parameter to most
services that handle and interpret
the messages, in order to provide a uniform interface for the
serialization and de-serialization of
messages.
The network daemons on the SPOT and the Host route and handle
the messages based on the
first byte of the incoming datagram, which indicates the message
type. In most messages, the
message type byte is usually followed by 8 bytes indicating the
destination address. For
undirected control messages, this value is set to 0. A detailed
list of messages and their formats is
covered under low level design.
8.4.3 Publisher Subscriber Model
The design makes extensive use of the observer pattern. In the
Observer pattern, Observers
subscribe to changes in an Observable quantity. When the
contents of the Observable quantity
changes, the Observers are notified of the change. The Observers
may choose to access the
msgType | Message Data
createDatagram
loadDatagram
-
23
observable quantity regarding the change or may handle the
change as a parameter in their
callback function. The Observer pattern is inherently supported
as part of the standard Java
utility libraries. However, the SPOT API does not support this
pattern. This pattern is adapted in
the form of a Publisher Subscriber Model to implement the
underlying message bus that enables
the functionality of the framework.
In this model, the message bus is the designated publisher of
information. When a new message
arrives on the message bus, it is added to the queue and the
function returns, allowing the calling
function to continue with execution. The message bus thread then
pops the message from its
queue and notifies the subscribers in a sequential order. In
order to ensure asynchronous
execution, we ensure that the notification routines on the
subscribers return from the function
call as soon as possible. This is done to avoid blocking during
notification. On the Host part, the
Observable and Observer objects are used to achieve similar
functionality.
In context to the system design, the message bus is considered a
publisher, while the original
publisher could subscribe to the acknowledgements through the
message bus, if required. Using
this model, it is possible to implement callbacks for the
publishers using acknowledgements.
N/W
daemon
Data daemon
Message Bus
Controller
Enqueue
Return;
Detector
Enqueue
Return;
Figure 5: Publisher Subscriber Model in Message Bus on the
SPOT
-
24
8.4.4 Multi Level Message Queuing
Asynchronous communication enhances the publisher subscriber
model by ensuring that the
message bus architecture does not make any blocking calls while
notifying its subscribers. To
achieve this, in most cases, the subscribers are run as threads
that service their internal queues. In
this way, if a computationally intensive task is to be performed
at the receipt of the message, the
task is handled as a separate thread of execution. The network
daemon creates the appropriate
message and adds the message onto the message queue of the
message bus and returns. The
message bus thread removes the message from the queue and
notifies the corresponding
subscribers. Each of the subscribers maintains an internal
queue, which stores the new
notifications. The message is added to the internal queue if the
message is relevant to the
subscriber context. If it is not then it is discarded. While
servicing the request, the subscriber
may choose to generate a new message; this message is again
added to the message bus, where
the above process repeats.
8.4.5 Detection Algorithm
Most anomaly detection algorithms follow a common workflow. They
initialize the internal data-
structures and the internal model, train the internal model,
pass the sensor measurements as input
to the model and take the appropriate action based on the output
of the model. At the end of the
process, the algorithm de-allocates the memory that was
allocated to the model. The life cycle of
the algorithm is encapsulated into an AbstractDetector object.
This object is inherited by the
anomaly detection algorithms, to handle each of the events that
occur during the life cycle. In
order to initiate the appropriate action at a given instance of
time, the detector maintains internal
states that are manipulated by the active handlers. This
behavior is akin to a State Machine. The
design of the detection algorithm is based on a blend of the
strategy pattern and the state machine
patterns.
8.5 Low Level Design
The following section discusses the recurrent object oriented
patterns in the framework. These
design elements are used to implement most of the functionality
of the system.
-
25
8.5.1 IDaemon
The IDaemon pattern is a frequently occurring pattern on both
the host and the sensor node. It is
the primary interface implemented by all the services of the
system. The IDaemon interface
implements the Runnable interface and uses internal states to
control the execution.
Figure 6: IDaemon Interface on the SPOT
Figure 6 shows how the main components of the framework
implement the IDaemon interface.
The SPOT API provides supports threading. This feature is
employed extensively to achieve a
high level of concurrency on the SPOT. The IDaemon is also
implemented by the services on the
host, to give us the ability to control the execution of the
services.
The run methods of most of all the services run a particular
task in a continuous loop. The
continuous execution is manipulated by the status of the
service.
-
26
8.5.2 ISubscriber and IPublisher
Figure 7: ISubscriber and IPublisher interfaces
The IPublisher and ISubscriber interfaces are used to implement
the publisher subscriber system
on the SPOTs. This implementation replaces the Observer pattern
which is predominantly used
on the host. The NotifierDaemon is intended for use by the
anomaly detection routine to
communicate alerts and notification to the server, the SPOT
Controller uses the subscriber
interface to subscribe to the message bus. The publisher in this
design is the message bus, which
is run by the messaging daemon.
8.5.3 Message Format
Network communication in the system is carried out using
connectionless datagrams being sent
over the radio using the 802.15.4 specification. At the
application level, the datagrams need to be
-
27
interpreted at both ends. While it would be possible to build a
component whose responsibility is
to translate the datagram packets to the internal object
representation, maintaining this messaging
architecture would be complex with the addition of new messages
into the system. In order to
solve this, the Message Objects encapsulate the methods that
enable them to populate the
datagrams and also populate their internal data structures from
the data in the datagrams. When a
new message is introduced, it extends the SPOTMessageFactory
class, which is the abstract class
specifying the methods that a new message format must support.
In addition to this, the message
type is added to the SPOTMessageType class. For compatibility
purposes, the implementation on
SPOT is kept synchronized with the corresponding implementation
on the host and vice versa.
The figure below describes the SPOTMesssageFactory design.
Figure 8: SPOTMessageFactory and Messages
The main advantage of using the SPOTMessageFactory is that most
consumers of the messages
can use the standard interfaces for their functionality,
irrespective of what the actual message is.
On the SPOT and the host, the incoming message is loaded onto
the message object, without the
need for any explicit down-casting based on the message
type.
The following table represents the message structure of the
common messages used in the system
-
28
Message Type Message Components
Beacon Request Byte: Message Type
Integer : Server Port of the Host
Long: IEEE Address of the Host to connect to
Beacon Response Byte : Message Type
Long: IEEE Address of the SPOT
Data Request Message Byte: Message Type
Long: Address to which the request is directed. 0 for
broadcast.
Data Message Byte: Message Type
Integer: Temperature
Integer: Luminosity
Integer: Acceleration X
Integer: Acceleration Y
Integer: Acceleration Z
(Note: This message is used internally)
Alert Message Byte: Message Type
Long: Address
ClusterFeature: Composite object, which is serialized by the
internal
routines
Cluster Information Response Byte: Message Type
Long: Address
ClusterFeature: The updated cluster feature
Data Stop Message Byte: Message Type
Long: Address
Shut Down Message Byte: Message Type
(this message is sent over broadcast channel to indicate that
the host is
shutting down)
GI Alert Message Byte: Message Type
Long: Address
Instance : Integer
Attribute Type : Byte
-
29
GI Clustering Info Response Message Type : Byte
Address: Long
GI_ClusterFeature : composite object that is serialized
during
transmission
Table 1: Message Types and their internal structures
On the SPOT, the SPOTController is the primary consumer of the
network based messages. The
SPOTController contains a list of message handlers that are
responsible for the appropriate
incoming message. The message handlers implement the IHandler
interface, thus providing a
uniform interface for the SPOTController to use to handle the
incoming messages.
8.5.4 Detection
In order to support the requirement of real time processing, the
data is stored in the main memory
(RAM) as opposed to being stored in the Flash memory. The SPOT
API does not currently
support the Java Collection Framework; hence most of the storage
is done using primitives,
Vectors and Hashtables. The constructor of the detector takes in
parameters that are used to
initialize the internal structures. Single sensor anomaly
detection assumes that each sensor
reading is independent of the other sensor readings at that
point of time. For instance, the
clustering for temperature is carried out independent of the
clustering for luminosity. In multi-
sensor anomaly detection, an anomaly in one physical quantity,
invalidates all other sensor
readings at that time. For purpose of the implementation, I
choose to implement a grid based
clustering algorithm for single sensor anomaly detection and the
k-means clustering algorithm
for multi-sensor anomaly detection.
Concept
The grid based clustering algorithm is loosely based on the
clustering concepts used in Anomaly
Detection with Incremental Clustering (ADWICE) [14]. Although
ADWICE was built on a
BIRCH [17] tree implementation, the idea of using cluster
features which are organized and
navigated in a pre-specified order to identify the appropriate
cluster is of relevance with respect
to this implementation. In the grid indexed clustering method,
the input domain is divided into
homogenous grids. The grids contain references to clusters. The
main motivation of using grids
is to be able to map a particular input to its appropriate
cluster without having to navigate all the
candidate clusters in the sample space. The grid based approach
does not scale well for multi-
-
30
sensor anomaly detection, requiring multi-dimensional grid
support. As the sensor nodes have
not been designed to store large quantities of data in the main
memory, we decide to approach
the problem of multi-sensor anomaly detection using k-means
based clustering algorithm.
The k-means approach to clustering makes use of the following
strategy.
1. Choose K random points from the sample space
2. Group each of the points in the sample space into k clusters
based on their proximity to
the K points
3. Alter the centroid to reflect the contents of the cluster
4. If the point does not meet the proximity criteria
(diameter/threshold) of any of the
clusters, flag it as an outlier and an anomaly.
The k-means strategy is a simplistic yet powerful clustering
approach which can be used to
identify outliers. This method is inefficient, if we consider
storing the data before we apply the
clustering algorithm on the data. In addition to this, a
significant amount of computation is
expended in identifying the appropriate cluster. This method
usually involves calculating the
Euclidean distance of the new point with the centroids of the
clusters. To enable greater
sensitivity and a more accurate classification, the numbers of
clusters need to be kept as high as
possible. The k-means can be used to effectively identify
multi-sensor anomalies. One can avoid
the complexities of the k-means clustering approach if one needs
to only identify single sensor
anomalies.
Using a grid based approach, it is possible to have a large
number of target clusters, and the most
suitable clusters are identified using a much smaller search
space. The strategy is based on the
assumption that all similar measurements are designated to the
same cluster. For instance, if a
value of 30 belongs to a cluster indicating normal behavior, all
measurements of the same
quantity that bear the value 30 usually belong to the same
cluster. The sensor measurements
considered for the current implementation are integers and hence
values like 30.2 and 30.432 do
not occur. If the readings are floating point numbers, we can
choose to modify the definition of
the grid to incorporate floating point thresholds (i.e. each
grid could indicate increments of 0.2 in
the measurement)
The design is represented by the following figure.
-
31
Once a value (23) is generated, it is indexed to the possible
target clusters that a similar value is
placed under. Each index in the grid points to a ClusterFeature
vector. This vector is navigated
linearly to identify the closest cluster centroid. Once the
closest centroid has been found, it is
added to the appropriate cluster. The addition of the point to
the target cluster involves updating
the centroid, the linear sum and the quadratic sum. In addition
to this the threshold may be
updated. In an adaptive implementation, it could also update the
diameter. In this
implementation, we define the cluster threshold as the maximum
number of points that the
cluster can hold this number is checked before the addition of a
new point into the cluster.
As explained previously, the functionality of the detector is
similar to a state machine. The
following are the phases that occur during the execution of the
detector code.
Initialization
The grid based clustering algorithm is initialized with
parameters indicating the cluster threshold
and the size of the training sample. The clustering width is
assumed to be fixed at 1. This
Figure 9: Grid Indexing for Clustering
23
0 1 1023 22 23 . ..
23.5
23.7
23.06
ClusterFeature id: 102
ClusterFeature id: 145
ClusterFeature id: 239
Temperature
Temperature Grid
Grid Vector
Cluster Centroids
-
32
coincides with the fact that the default width of each grid is
1. A training data store of dimension
(number of attributes x sample size) is initialized.
Training
The Detector subscribes to the DataMessage in the message bus.
In the training mode, the data is
stored in the appropriate cell based on which type of physical
quantity it is, and what the current
count of the training data is.
Training Completed
In this phase, the training data is navigated and inserted into
the appropriate grid as a cluster
feature. If a ClusterFeature already exists for that value, its
appropriateness is determined using
the isFit() method of the ClusterFeature. If the target value is
found to be a fit, the cluster feature
is updated, if no matches are found a new cluster feature is
created in that index of the grid and
added to the cluster feature vector at that index.
Algorithm Start
In this state, the incoming data is placed into the appropriate
cluster using the process described
in the Training Completed phase. Any new clusters are marked as
anomalies, as all the normal
clusters are marked in the Training phase. The new clusters are
then sent as alerts to the host
server for processing.
Algorithm Stop
This state is used to indicate that the detection algorithm has
ended. All the memory allocated to
the data structures used to maintain the model and the training
data are de-allocated in this phase.
8.5.5 SPOT Context
The SPOT Context is used to provide the different components of
the system ready access to the
running daemons in the system. The SPOT context specifically
contains references to the
message bus, network daemon and the data daemon. A similar
context exists on the host part of
the framework. This context is implemented as a class with
static references to the necessary
data, in order to provide simple access to the necessary daemons
for common tasks.
-
33
9. Implementation
In this section the implementation of the various design
elements mentioned in the previous
sections is described in the context of the anomaly detection
system. The anomaly detection
system comprises the host server and the sensor nodes. The host
server application is instantiates
the NetworkDaemon in the server mode and the BeaconDaemon in the
broadcast mode. The
responsibility of the NetworkDaemon is the handling of incoming
connections and the incoming
datagrams. The BeaconDaemon broadcasts the BeaconRequestMessage
at periodic intervals to
announce the availability of the Server to the nearby SPOTs.
Meanwhile, the SPOT applicat ion
is activated. The LEDs on the SPOTs indicate the internal state
of the SPOT. The first LED is
used to indicate the connectivity status of the SPOT. Initially
this LED is red, once a
BeaconRequestMessage is received by the NetworkDaemon on the
SPOT, the message type; the
source server port and the source address are extracted. This
information is used to construct the
BeaconResponseMessage. This message is sent by creating a client
connection to the specified
host and port (from the BeaconRequestMessage). The
BeaconResponseMessage is received by
the NetworkDaemon on the host. The message type is extracted.
The SPOTMessageFactory is
used to create the appropriate message. The message is then
decoded from the datagram and
added onto the message bus. In this case, the
BeaconResponseMessage contains the IEEE
Address of the SPOTs. This information is used to populate the
list box in the user interface.
Once all the SPOTs are discovered, we can initiate the detection
algorithm. The
DataRequestMessage is broadcast using the BeaconDaemon. This
message is received by the
NetworkDaemon on the SPOT. The NetworkDaemon extracts the
message and invokes the
SPOTMessageFactory with the message type. The message object is
then loaded with the
datagram and added to the message bus. The SPOTController
receives the message from the
message bus. It checks its internal IHandler table to see if the
message has a specified handler. If
the handler exists, the message is passed to the appropriate
handler from the IHandler table. The
handler then interprets the message to perform the necessary
actions. In this case, the Data
Request Message is used to initialize the DataDaemon and the
Default Detector. The Data
Daemon and Detectors are run as threads. As always, all the
daemons are added to the
SPOTContext to enable easy access. On the SPOT, the Data Daemon
accesses the sensor data at
frequent intervals. This information is used to populate a
DataMessage. The DataMessage is
then added to the message bus. The Detector receives the
DataMessage via the message bus and
-
34
adds it to an internal queue. In the training mode, the detector
stores data onto the internal
training date storage. Once the training is complete, it creates
the necessary cluster features and
adds them at the appropriate locations in the grid. This process
is repeated for each of the
attributes. At the end of the training mode, a list of all the
clusters is sent to the host as a
ClusterInfoResponse message and the detection algorithm is
started. The DataMessage is used to
identify nearby clusters and calculate the best fit. If any
alerts are to be generated, the
AlertMessage is generated and the network daemon is used to send
this information to the host.
In this implementation, we also choose to send all updates in
the normal clusters to the host using
the ClusterInfoResponse. How much information needs to be sent
to the host is entirely up to the
implementation of the algorithm. On the host, the messages are
received and populated into the
internal message objects, the message objects are added to the
message queue. The message
queue is subscribed to by each of the designated views. Note we
have a view to indicate the
alerts as well as a view to indicate all the cluster updates.
The two views are notified of every
new message in the message bus. This message is then translated
to a corresponding change in
the JTable in each of the views. Once the detection phase is
completed on the host, the
DataStopMessage is sent to the SPOT using the BeaconDaemon, this
is handled by the
DataStopHandler and the DataDaemon and the Detector are stopped.
Once the host application
is closed, the ShutDownMessage is broadcast by the BeaconDaemon.
This message makes its
way to the ShutDownHandler through the SPOTController. At the
receipt of this message, all
daemons are requested to stop executing by changing their
internal states to STOPPED. Once the
daemons complete executing, the application exits.
The following paragraphs describe the internal functioning of
the core components in the
application.
NetworkDaemon
The Network Daemon on both the host and the SPOT are opened in
the server mode. Their
primary responsibility is to receive datagrams and interpret
them, and add them to the message
bus. The implementation follows the following pseudo code.
1. Listen for incoming messages
2. Read the first byte of the datagram as the message type
byte
-
35
3. Create a SPOTMessageFactory using the message type byte.
4. Access the message bus using the context object
5. Add the message onto the message bus
6. Go to step 1 while internal state!= STOPPED.
7. Exit
Beacon Daemon
The Beacon Daemon is used to identify nearby SPOTS by
periodically broadcasting the beacon
signal. The Beacon Daemon is also used by the host to send the
control signals to the SPOTs.
The implementation of the Beacon Daemon follows the following
pseudo code
1. Create the broadcast connection on the standard listen port
of the SPOTs
2. Create a datagram and populate it with the
BeaconRequestMessage.
3. Send the datagram over the broadcast channel
4. Sleep for the pre-determined amount.
5. Repeat step 3 while internal state != STOPPED
6. Stop
Messaging Daemon
The Messaging Daemon is used to implement the functionality of
the Message Bus on both the
SPOT and on the host. The Messaging Daemon primarily notifies
the subscribers of new
additions in its internal message queue. The execution follows
the following lifecycle.
1. Initialize internal queue
2. If the queue is empty
a. Yield the thread
3. If the queue is not empty
a. Pop the first element from the queue
b. Notify each observer with the element as parameter
c. Remove the element from the queue
4. Go to step 1 while internal state != STOPPED.
-
36
The following is the list of the messages supported in this
implementation of the message bus
and their purpose
Message Name Purpose
BeaconRequestMessage This message is used by the host framework
to indicate that it is
operational
BeaconResponseMessage This message is used by the SPOTs to
indicate their acknowledgment to
the BeaconRequestMessage and to connect to the host
DataMessage This message is used internally by the DataDaemon to
indicate the
availability of new sensor data
DataRequestMessage This message is used by the host in this
implementation to request the
SPOT to start the anomaly detection application and send the
information to the host.
DataStopMessage This message is used by the host to indicate to
the SPOT that it must stop
transmitting data to the host
ClusterInfoMessage
GI_ClusterInfoMessage
These messages are used by the SPOT to send cluster information
of
data that is classified to be normal
AlertMessage
GI_AlertMessage
These messages are used by the SPOT to indicate an anomaly to
the host
ShutDownMessage This message is used by the host to shut down
the application on the
SPOT.
Table 2. Messages supported by Message bus and their
purposes
SPOT Controller
The SPOTController is the primary subscriber to the message bus
on the SPOT. It subscribes to
all the messages directed to the SPOT, with the exception of
BeaconRequest. The
BeaconRequest is directly handled by the NetworkDaemon. Once a
message is received, it is
added to the internal message queue. In the run method, the
element is extracted and the
appropriate handler is looked up for the message type of the
object. Once an appropriate handler
is found, the handle routine is called on the appropriate
handler. This operation can be described
using the following pseudo code.
1. Initialize the internal handler table, with the appropriate
default handlers
2. If the queue is empty
-
37
a. Yield the queue
3. If the queue is not empty
a. Pop the first element as spotMessage.
b. Read the message type from the element.
c. Use message type as index in IHandler table
d. If IHandler[messageType] == null
i. Do nothing
e. Id IHandler[messageType] !=null
i. IHandler[messageType].handle(spotMessage)
f. Remove element from queue.
4. While internal state != STOPPED go to step 2
5. Stop
Abstract Detector
The AbstractDetector is used to specify the state machine based
functionality of the Detector.
The AbstractDetector specifies what function is called during
each internal state. This behavior is
captured by the following pseudo code
1. If state == RUNNING
a. Set state = ALGO_INIT
2. If state == ALGO_INIT
a. Call handle_init()
3. If state = ALGO_START
a. Call handle_train()
4. If state == ALGO_TRAIN_DONE
a. Call handle_train_done()
5. If state == ALGO_START
a. Call handle_start()
6. If state == ALGO_STOP
a. Call handle_stop()
-
38
The implementations of the anomaly detection algorithms extend
the AbstractDetector class,
hence they implement the handle_* methods and also handle the
internal state transition. For
instance, some algorithms may choose to forego the training
phase in which case they may
directly transition to the start phase within their
handle_train. Another advantage of using this
method is, some algorithms may be trained based on time while
others may be trained based on
the number of training samples recorded, as the state transition
is entirely controlled by the
handle_* methods of the algorithm, alternate methods of training
can be seamlessly integrated.
GI_ClusteringDetector
In the implementation of the anomaly detection algorithm, this
object is of primary importance.
The object encapsulates the functionality of the proposed Grid
Indexed Clustering Algorithm. As
the Detector extends the Abstract Detector, the algorithm
implementation is split into the
handle_* methods. This is described by the following
pseudocode.
handle_init()
1. Initialize current number of samples to 0, i.e. currentIndex
=0
2. Initialize samples[5][max_sample_size]
3. Initialize clustergrid[5][1024]
4. Register with the message bus
5. Set state to ALGO_TRAIN
handle_train()
1. If message queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Extract the first element from the queue
b. Populate samples[0..4][currentIndex] with the contents of the
data message
c. If currentIndex == max_sample_size
i. Set state = ALGO_TRAIN_DONE
d. Remove the element from the queue
-
39
handle_train_done()
1. For each attribute do
a. For each entry in samples[attribute] do
i. For range = attribute width /2 to attribute + width/2
1. Add all clusters at clusterGrid[attribute][range] to
candidateCluster
ii. If candidateCluster is not empty then For cluster in
candidateCluster
1. Find the closest cluster
iii. Update closest cluster with entry
iv. If candidateCluster does not exist create a
GI_ClusterFeature with entry
and parameter and set its attribute.
2. Send all clusters to host using GI_ClusterInfoResponse
messages
3. Set state to ALGO_START
handle_start()
1. If queue is empty
a. Yield the thread
2. If the message queue is not empty
a. For each attribute do
i. For range = value[attribute] width/2 to
value[attribute]+width/2 do
1. If clusterGrid[attribute][range] exists
a. Add clusters to candidateCluster
2. If candidateCluster exists then for each cluster in
candidateCluster
a. Find the closest cluster as targetCluster
3. If value[attribute] fits the targetCluster
a. Add the value to targetCluster
b. Add targetCluster to current grid index if not already
present
4. If candidateCluster does not exist, then raise alarm
3. End
-
40
handle_stop()
0. De-register from the message queue
1. De allocate the cluster grid
2. Remove all pending messages from internal message queue
3. Set state = STOPPED
KMeansDetector
This class encapsulates the functionality of the K Means
clustering algorithm. The Detector
extends the Abstract Detector, and hence the algorithm
implementation is split into the handle_*
methods. This is described by the following pseudocode.
handle_init()
1. Initialize current number of samples to 0, i.e. currentIndex
=0
2. Initialize samples[max_sample_size][5]
3. Initialize clusterList
4. Register with the message bus
5. Set state to ALGO_TRAIN
handle_train()
1. If message queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Extract the first element from the queue
b. Populate samples[currentIndex][0..4] with the contents of the
data message
c. If currentIndex == max_sample_size
i. Set state = ALGO_TRAIN_DONE
d. Remove the element from the queue
-
41
handle_train_done()
1. Choose K random points from samples
2. Create K ClusterFeatures and add the clusterList
a. For value[0..4] in samples do
i. Find the closest cluster from clusterList as targetCluster
and add to it
3. End.
handle_start()
1. If queue is empty
a. Yield the thread
2. If the message queue is not empty
a. Read values into values[]
b. For clusters in clusterList do
i. Find the closest cluster as targetCluster
c. If targetCluster is null then raise AlertMessage
d. If targetCluster is not null and if values fits
targetCluster
i. Add values to targetCluster
e. If values do not fit targetCluster then raise
AlertMessage
3. End
handle_stop()
1. De-register from the message queue
2. De allocate the cluster grid
3. Remove all pending messages from internal message queue
4. Set state = STOPPED
-
42
10. Tests and Results
The anomaly detection system is built using the framework and
deployed to SPOTs. The tests
primarily focus on the accuracy of detection of anomalies. Two
anomaly detection methods are
tested in this project. The grid indexed clustering method is
used to identify single sensor
anomalies and the k-means method is used to identify
multi-sensor anomalies. The tests are
divided into simulated and real-world tests. In the simulation
experiments, the DataDaemon in
the SPOTs is modified to generate inputs following a pre-defined
function. In addition to this,
random noise is added to the function. This input is used to
train the model. After the training is
complete, we monitor the number of alerts generated and the
number of correct classifications.
These numbers are compared over variable parameters. In the real
world tests, the internal model
is trained based on the actual environmental conditions. After
the training, the number of alerts
and the number of correct classifications are calculated. The
physical quantities that are
measured are Temperature, Luminosity, and Acceleration along the
X, Y and Z axes. These tests
are covered in greater detail in the succeeding sections.
10.1 Test Setup
Suns Solarium [12] tool is used to simulate the tests on the
virtual SPOTs. The Virtual SPOTs
are assumed to run the same version of the anomaly detection
system. All SPOTs are upgraded
to the purple version of the SPOT SDK.
Experiment 1 is used to test the grid indexing clustering
algorithm. It is divided into four parts.
In the first part (part A), simulated modified sinusoidal waves
and simulated modified saw-tooth
waves are used to test the algorithm. In the second part (part
B) we test the variation of false
positive rate and the accuracy of classification, using a
simulated wave with varying Signal to
Noise Ratios. The algorithm is tested on actual SPOTs in the
third part of the experiment.
Experiment 2 is used to test the k-means based approach. It is
divided into two parts. In the
simulated part, a modified saw-tooth wave is used to test the
algorithm at varying signal to noise
levels. In this part, the variation of the false positive and
false negative rates is observed. We
calculate the false negatives, by simulating anomalies and
recording the number of true
anomalies. In the second part, the algorithm is deployed on
actual SPOTs and the performance is
measured.
-
43
In the simulated tests a random noise is added to the waves to
yield the resultant input. The input
is used by the anomaly detector for training as well as
detection. We measure the number of false
alarms that are raised for the input in experiment 1. The
default width in experiment 1 is fixed at
1. This reduces the number of false negatives (at 100%
classification accuracy) to 0. With the
default width set to 1, once an input is classified as an
anomaly, the classification does not
change over time. Hence, in experiment 1 we specifically
calculate the number of instances that
have been wrongly classified as abnormal, since the training
sample is assumed to contain only
normality information. In experiment 2 we measure both false
alarms and false negatives. We
do this by setting thresholds of each physical quantity during
training. The following paragraphs
describe the tests and their results in greater detail. The data
obtained from each of the tests have
been recorded in spreadsheets which will be part of the final
submission. The file naming
convention for the data files is experiment__.xls
Number Part No. of SPOTs
(excluding the
base station)
Type of Algorithm Input Type Experiment
Name
1 A 1 Grid indexed
Clustering
Simulated, Modified
Sinusoid Wave
1_A_1
1 A 2 Grid indexed
Clustering
Simulated, Modified
Sinusoid Wave
1_A_2
1 A 1 Grid indexed
Clustering
Simulated, Modified
Saw-tooth Wave
1_A_3
1 A 2 Grid indexed
Clustering
Simulated, Modified
Saw-tooth Wave
1_A_4
1 B 1 Grid indexed
Clustering
Simulated Sinusoidal
wave at different S/N
levels
1_B_1
1 B 1 Grid indexed
Clustering
Simulated Saw-tooth
wave at different S/N
levels
1_B_2
1 C 1 Grid indexed
Clustering
Real-world test 1_C_1
-
44
Number Part No. of SPOTs
(excluding the
base station)
Type of Algorithm Input Type Experiment
Name
1 C 2 Grid Indexed
Clustering
Real-world test 1_C_2
2 A 1 K-means Simulated Saw-to