One document matched: draft-manner-roll-shm-requirements-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-manner-roll-shm-requirements-00"
     ipr="full3978">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>

  <front>
    <title abbrev="SHM Requirements">Sensor Network Routing Requirements of Structural Health Monitoring</title>

<author initials='J.' surname="Hollmén" fullname='Jaakko Hollmén'>
<organization abbrev='TKK'>Helsinki University of Technology
(TKK)</organization>
<address>
<postal>
<street>P.O. Box 5400</street>
<city>Espoo</city> <code>FI-02015 TKK</code>
<country>Finland</country>
</postal>
<phone>+358 9 451 5290</phone>
<email>jaakko.hollmen@tkk.fi</email>
</address>
</author>

        <author initials='J.' surname="Manner" fullname='Jukka Manner'>
	<organization abbrev='TKK'>Helsinki University of Technology (TKK)</organization>
	<address>
	<postal>
	<street>P.O. Box 3000</street>
	<city>Espoo</city> <code>FI-02015 TKK</code>
	<country>Finland</country>
	</postal>
	<phone>+358 9 451 2481</phone>
	<email>jukka.manner@tkk.fi</email>
	</address>
        </author>


    <date month="July" year="2008" />

    <abstract>

      <t>This document discusses monitoring the status of constructions,
      structural health monitoring, using sensor networks, and the
      requirements such a system puts on routing. </t>

    </abstract>

  </front>

  <middle>

    <section title="Introduction">

<t>

Structural health monitoring (SHM) aims at defining an abstract
condition for a physical structure, such as a bridge, crane, tower or
other physical object, even heavy machinery. Measurement data is used to
measure and monitor physical quantities and computer models are used to
analyze the data and classify the current state of the structure to give
alerts if necessary. Structural health monitoring systems typically
become a part of the structure for its entire lifetime, and the
structure's condition will be inferred from the physical measurements.
Due to the lifetime requirements and physical size of the objects,
wiring of the sensors recording physical quantities is not a preferred
solution. Wireless sensor networks are a solution that avoids costly and
error-prone wiring within the structure.

</t>

<t>

This draft presents the concept of structural health monitoring using
sensor networks, and identifies requirements on the routing due to the
task and the operating environment.

</t>

</section>

    <section title="Structural Health Monitoring (SHM)">

<t>

The challenge with monitoring the status and health of structures is
that there does not exist a sensor that can tell directly the answer,
e.g., is a bridge going to crash. The only mechanism we have is to
periodically measure physical quantities and then use various data
mining techniques to analyze the data and find irregularities that could
be a sign of an emerging problem.

</t>

<t>

The structure's condition must be described by the physical quantities
measured from the structure. Typical physical quantities used are
accelerations, strains, pressure, temperature, wind speed, flow,
position, orientation, chemical quantities and wave propagation
quantities. Timely availability of the measurements have a large effect
on the delay of detection and therefore typically close to real-time
measurements are used. This also sets requirements on the transmission
bandwidths of the network.

</t>

<t>

While measuring the structure, typically only the output measurements
are availables, without the knowledge of the state (or condition) of the
structure nor the input that caused, for instance, the structure to
vibrate. Usually, in the subsequent analysis phase, it is assumed that
these measurements are representative for the normal condition of the
structure.

</t>

<t>

In civil engineering studies, a typical sampling frequency is often less
than or equal to 100 Hz (Nyqvist theorem states that in order to be able
to detect signal frequencies up to a frequency f, the sampling frequency
has to be double that frequency (2*f) ). A typical SHM application
includes vibration measurements (accelerometer), sampled at 100 Hz for
10 minutes at a time. With some available hardware, it is possible to
sample at up to 8 kHz, but then the memory constraints become an issue.
The data needs to be stored in an external flash memory. With 100 Hz, it
is possible to measure for 30 s, but to reach 10 minutes some further
development needs to be done. The node can not sample, process, transmit
and receive simultaneously; rather, it can execute one of these
functions at a time. 

</t>

<t>

For many applications of the measured data (e.g. data analysis), time
synchronization is required. The accuracy of timing after
synchronization is in the scale of microseconds, but due to clock
drifts, the synchronization needs to be done regularly (maybe every half
a minute). Due to local processing of data, the sampling is done in an
asynchronous way (no continuous sampling), but at least the neighbor
nodes should measure at same time instants. This can be achieved by
running a time synchronization algorithm in the network requiring
communication from sensors/cluster heads to sensors.

</t>

<t>

The are two distinct methods for analyzing the sensor data, online and
offline applications, where the data is either processed at the scene or
offline (later on). The choice of mode greatly affects the networking
solutions. There is also an obvious trade-off in local data processing
vs. data transmission. A rule of thumb is that energy-wise transmitting
one byte is as expensive as running 8000 CPU cycles. This means that
computation should be done as close as possible to the measurement
point, i.e. locally on the nodes. Only the fused information should be
transmitted to those nodes that need the information (e.g. certain
covariance information might be needed in another node to be able to
perform Kalman-filtering etc.). The computing capabilities of the nodes
are very constrained. The microprocessor in many sensor products is TI
MSP430 with 10 kB of RAM and 256 KB flash memory running at 8 MHz. The
node also has a 4 Mbit serial data flash memory. The nodes are typically
equiped with a 6LowPAN protocol stack.

</t>

<t>

Often the positions of sensors need to be known. Sometimes these need to
be very accurately fixed in advance, and sometimes the sensors need to
be installed exactly on the same locations as in the previous time.
Location is not only important for data analysis, but also for
networking. Hence there might be needs for localization support, meaning
that the nodes would have to be equipped with GPS or ultrasound sensors,
because the radio signal strength based localization results in low
accuracy.

</t>

<t>

The sensors used to measure the physical quantities are located in
different physical locations in the structure. In order to have a
holistic view on the entire structure, the detector must have access to
all of the data. Two alternative architectures are possible: centralized
architecture, where the data is mediated through the wireless sensor
network to a central node, where the detector analyzes the data and
assesses the structure's condition. In a de-centralized architecture,
there is more analysis local to the sensors.

</t>

<t>

Two modes of measurement can be differentiated: in a periodic batch type
of a measurement, a fixed period of time (for instance, 10 minutes) is
dedicated to the measurements, after which the data is mediated and
analyzed without little real-time constraints on these activities. In a
continuous measurement mode, the condition of the structure is
continually measured, parallel to the data mediation and its analysis.
This sets stringent requirements on the throughput of the network and
well as the response time for the detector.

</t>

<t>

Two modes of analysis can be used. The data based mode uses measurement
data in order to estimate a model of the normal behavior and use it in
assessing the condition of the structure. Statistical time-series models
are well suited for this task. Model-based approach relies on a
computer-based model of the physical structure and finite element method
derived results on the behavior of the structure.

</t>

    </section>

<section title="Requirements on Sensor Network Routing">

<t> 
Based on the previous description of the functionality of a system
to monitor the health of structures, this section highlights functional
requirements of a sensor network and how the routing should perform. The
terminology used follows <xref target="RFC2119" />.
</t>

<t>

There are two fundamental properties of the SHM that put pressure on how
the routing should function. First, sensor networks for SHM produce
large amounts of data at various intervals. Typical applications do not,
e.g., produce some small amount of continuous data, or frequent small
bursts. Rather, e.g., every 8 hours a relatively big chunk of data must
be transfered from the sources to one or more sinks. This does not
happen all over the network at one time, but rather a certain section of
the network needs to transfer the data at a given time. Secondly, SHM is
used in many areas where lives could be lost. Thus, once a section of
the sensor network starts to transfer data, the data must get to its
destination with a high reliability. </t>

<t> 

A SHM sensor network is not only about periodic one-way transmission of
measurement data. If the data mining reveals a possible problem in the
structure, advanced applications would control the sensors to continue
measuring the structure at a redefined frequency and data delivery
interval. Additional functionality of an SHM sensor network include
service discovery, sensors need to find sinks, or nodes performing data
fusion, and the sinks must be able to find the sensors.

</t>

<t>

Furthermore, as discussed in the previous section, we have two types of
modes for the data mining, offline and online. In the following
discussion on requirements, we mainly focus on the offline mode. Online
mode makes similar requirements on the data routing, i.e., large amounts
of data must be periodically sent to an entity, either a sink and
gateway to external networks, or a place for data fusion and online data
mining.

</t>

<section title="Non-goals">

<t> 

Designing a routing protocol is ultimately about choices, one
performance aspect rules out another one, all functional design
decisions affect performance in some way. SHM is about rather static
deployments and use cases. Thus, support for highly dynamic networks is
not needed. We can expect the network to bootstrap itself in matter of
hours or even days, rather than seconds. Also, once the network routing
has been put in place, the only changes are that some nodes may just die
out, and some are replaced, at a very modest frequency.

</t>

<t>

SHM applications do not require extremely large sensor networks. One
network might consist of tens up to couple hundred nodes. If larger
structures need to be monitored, multiple independent sensor networks
could be used.

</t>

</section>

<section title="Requirements for the routing system">

<t>
This section highlights some aspects that the SHM application would need from the 
underlying routing system.
</t>

<t>

o Autoconfiguration: the network MUST be able to automatically configure
itself and the routing paths. Yet, this does not have strict
requirements on timeliness. In order to make accurate measurements from
multiple sensors at the exact same instance in time, we need time
synchronization with an accuracy in the order of milliseconds, possibly
over multiple hops.

</t>

<t>
o Multicast support: in order to make the bootstrapping function, and also save energy, 
the routing SHOULD support multicast. This is needed especially for the service/node 
discovery.
</t>

<t> 
o Multiple routing paths: since SHM produces large amounts of data at one time, the 
routing system SHOULD be able to support more than one routing path between a data 
producer and the consumers. This requirement is not fully mandatory (MUST), since the use 
of multiple paths can be simulated on a higher layer, by a sensor sending its data to 
multiple sinks. 
</t>

<t>
o Reliability: when a group of sensors provide their data for further processing (data 
mining), this data MUST be routed/transported in a reliable way. If one part of the whole 
data is lost, the entire sampled data may be useless. This requirement is more important 
than real-time operation. Also, bandwidth problems can be partly solved by using multiple 
data sinks.
</t>

<t>
o Energy-awareness: obviously the routing protocol SHOULD be aware of the energy levels of 
the sensor nodes and seek to balance the energy consumption of the whole network.
</t>

<t> 

o Route repair: the routing protocol MUST be able to repair routes as nodes die out 
and news ones are put in place. New nodes may also be installed just to increase the 
reliability and performance of the network. The change SHOULD be localized, and not 
visible all around the sensor network. The time interval for repairing the network may be 
relatively long, as in the bootstrapping phase. </t>

<t>
o Coupling with RRM: since the sensor nodes need to save power, they will sleep most of 
their lifetime. Also, since the hardware typically only supports one function at a time 
(measuring or data transmission/reception), nodes are not always able to receive data. 
Thus, the routing protocol SHOULD consider the node availability with regard to the radio 
interface, and each nodes ability to further forward, route, packets. It is of little use 
to send data on a certain path if that path will be truncated as hops down the path will 
be sleeping.
</t>

</section>

    </section>


    <section title="Security Considerations">

      <t>Moniroting the health of structures enables saving lives, but
      also allows timely response to emerging problems. The data
      provided by sensors is thus of utmost importance. The whole
      transport and routing infrastructure must support a high level of
      reliability and the ability to verify the data source. When we get
      measurement data of a structure, we must be able to trust the
      data. Thus, data origin authentication is the primary security
      feature that must be available. Encryption of the transmitted data and eavesdropping
      is not a primary concern. The sensor data is mostly public information.</t>

    </section>

    <section title="Acknowledgements">
      	<t>
	This work is part of an ongoing project Intelligent Structural
Health Monitoring System (ISMO) funded by the Multidisciplinary
Institute of Digitalisation and Energy (MIDE), a technology initiative
by the Helsinki University of Technology (TKK). More information at:
http://mide.tkk.fi/en/

	</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

&rfc2119;

    </references>

  </back>
</rfc>