Sensor Management Tracking and Documentation

back to EnviroSensing Cluster main page

Overview

Automated observation systems need to be managed for optimal performance. Maintenance of the overall sensor system include anything from repairs, replacements, changes to the general infrastructure, to deployment and operation of individual sensors, and seasonal or event driven site clean up activities. Any of these activities in the field may affect the data being collected. Therefore, consistent and uniform records of maintenance, service, and changes to field instrumentation and supporting infrastructure serve as metadata for long term quality control and evaluation of the sensor data.

In this chapter, we describe the types of management records that should be kept and the various methods for collecting, maintaining, communicating, and connecting this information to the data. It is important to create tracking and documentation protocols early on because these protocols will support and guide communications and work between field and data management personnel.

Real time monitoring of system health and alerting systems are discussed in the middleware, quality control, and transmission sections of this document. Although some of these parameters do not affect the actual data quality, tracking of these system performance diagnostic data may be helpful to detect patterns and prevent future data loss, intervene remotely, and schedule site visits more effectively. Calibration procedures and schedules, maintenance activities, and replacement schedules are hardware specific and will not be covered here in detail.

Introduction

Data are collected to detect changes in the environment, effects of treatments, disturbances etc., and in all data collection great care is taken to not mask the signature of events of interest with impacts from unavoidable, sampling related disturbances. Field notes are usually associated with the raw data to be able to discern a natural event of interest from a management event. Data collection approaches using automated sensing networks are becoming more complex with many people involved in the data gathering, management, and interpretation activities, and communication among all involved parties is becoming more important and more challenging. Field notes can be a useful vehicle for this communication. Everyone using older long-term data knows the value of field note books to help understand and interpret a dataset. Field notes are equally valuable to future users for a sensor data stream, particularly if the notes are interpreted such that information is integrated with the data via data qualifying flags and method description codes.

Currently there are no standards for flag code sets or for defining which events should be flagged and how to efficiently communicate with data users. Here we attempt to present a list of events that are useful to track and that have been helpful in the past to guide data users in the interpretation and evaluation of the data. To manage this information the concepts of a ‘logical sensor’, a ‘physical sensor’, a ‘method’ and ‘event codes’ have proven useful.

A ‘logical sensor’ or a sensor data stream can be defined by a location, height/depth, and measurement parameter, regardless of what exact physical sensor or hardware is used to log measurements. An example would be ‘air temperature at 3 m above the ground at site A’. However, over time the ‘physical sensor’ will have to be calibrated, eventually replaced, and a new type of sensor may be chosen to provide more accurate measurements. If hardware is swapped out for technical reasons, the data stream still represents the site location for that measurement, and the notion of a ‘logical sensor’ allows identification of a consistent data stream over time.

Changes in the type of sensor or ‘method’ might be tracked with a method code associated with the logical sensor. Of course should a replacement sensor be significantly different such that the past and new data stream are not comparable, then a new logical sensor stream should be initiated. Events such as routine calibration might be flagged with an ‘event code’ rather than a change in ‘method’, even if this event has lasting effects on the data, i.e., more accurate data. An event code may serve as a means to link to individual field notes for the event. ‘Physical sensors’ should also be individually identifiable by location and tracked through a calibration or replacement schedule.

• Sensor Identification and Tracking
  • Location Information (Spatial-Temporal)
  • Service History
  • Tracking Options
    • Bar Codes
    • Geo-Location Tags
    • Microchip Encoded Sensors (NEON 'Grape')
• Maintenance & Tracking of Sensor Events
  • Deployments (Spatial-Temporal)
  • Methodology: Frequency, Calibration, Quality Filters, Sampling Program, Equipment Change
  • Calibrations
  • Other Service Actions
  • Failures
  • Replacement
• Middleware Capabilities
  • Workflow Management
  • Proprietary Software
• Geo-Location Referencing
  • Geo-Referenced Data Stream
  • Photo Documentation
    • Hemispheric photos
    • Time-Series Image Collections
• Data Stream Processing
  • System Configuration (Hardware/Software/History/Legacy)
    • Datalogger Program Archive
    • Sensor Wiring Diagrams
  • Data Workflow
    • Processing Procedures: Current Protocol, Legacy Operations
    • Quality Filters: Application/Log
    • Quality Flags: Application/Log
      • Quality Control Actions
        • Automated
        • Human-Reviewed
        • Log