| TOC |
|
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.
This document discusses monitoring the status of constructions, structural health monitoring, using sensor networks, and the requirements such a system puts on routing.
1.
Introduction
2.
Structural Health Monitoring (SHM)
3.
Requirements on Sensor Network Routing
3.1.
Non-goals
3.2.
Requirements for the routing system
4.
Security Considerations
5.
Acknowledgements
6.
Normative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
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.
| TOC |
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 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.
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.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
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.
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
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/
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
| Jaakko Hollmén | |
| 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 |
| TOC |
Copyright © 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.
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.