One document matched: draft-manner-roll-shm-requirements-00.txt
Network Working Group J. Hollmen
Internet-Draft J. Manner
Intended status: Standards Track TKK
Expires: January 8, 2009 July 7, 2008
Sensor Network Routing Requirements of Structural Health Monitoring
draft-manner-roll-shm-requirements-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document discusses monitoring the status of constructions,
structural health monitoring, using sensor networks, and the
requirements such a system puts on routing.
Hollmen & Manner Expires January 8, 2009 [Page 1]
Internet-Draft SHM Requirements July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Structural Health Monitoring (SHM) . . . . . . . . . . . . . . 3
3. Requirements on Sensor Network Routing . . . . . . . . . . . . 5
3.1. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Requirements for the routing system . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hollmen & Manner Expires January 8, 2009 [Page 2]
Internet-Draft SHM Requirements July 2008
1. Introduction
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.
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.
2. Structural Health Monitoring (SHM)
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.
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.
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.
In civil engineering studies, a typical sampling frequency is often
less than or equal to 100 Hz (Nyqvist theorem states that in order to
Hollmen & Manner Expires January 8, 2009 [Page 3]
Internet-Draft SHM Requirements July 2008
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.
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.
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.
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.
Hollmen & Manner Expires January 8, 2009 [Page 4]
Internet-Draft SHM Requirements July 2008
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.
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.
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.
3. Requirements on Sensor Network Routing
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 [RFC2119].
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.
Hollmen & Manner Expires January 8, 2009 [Page 5]
Internet-Draft SHM Requirements July 2008
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.
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.
3.1. Non-goals
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.
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.
3.2. Requirements for the routing system
This section highlights some aspects that the SHM application would
need from the underlying routing system.
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.
o Multicast support: in order to make the bootstrapping function, and
also save energy, the routing SHOULD support multicast. This is
Hollmen & Manner Expires January 8, 2009 [Page 6]
Internet-Draft SHM Requirements July 2008
needed especially for the service/node discovery.
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.
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.
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.
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.
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.
4. Security Considerations
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
Hollmen & Manner Expires January 8, 2009 [Page 7]
Internet-Draft SHM Requirements July 2008
not a primary concern. The sensor data is mostly public information.
5. Acknowledgements
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/
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Jaakko Hollmen
Helsinki University of Technology (TKK)
P.O. Box 5400
Espoo FI-02015 TKK
Finland
Phone: +358 9 451 5290
Email: jaakko.hollmen@tkk.fi
Jukka Manner
Helsinki University of Technology (TKK)
P.O. Box 3000
Espoo FI-02015 TKK
Finland
Phone: +358 9 451 2481
Email: jukka.manner@tkk.fi
Hollmen & Manner Expires January 8, 2009 [Page 8]
Internet-Draft SHM Requirements July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hollmen & Manner Expires January 8, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 15:05:49 |