kartik nathan ms project report
DESCRIPTION
It is related to data mining and good materials for students.TRANSCRIPT
-
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