Continuous Monitoring Station Operations and Quality Assurance
Operate a lake or reservoir monitoring station through named ownership, remote review, alarm and stale-data triage, evidence-based service, controlled configuration changes, field reconciliation, explicit data states, seasonal planning, and bounded return to service.
What to do first
A continuous station is operational only when people, equipment, data, and decisions are managed as one controlled system. Name owners and backups; review telemetry and diagnostics against the station's expected behavior; triage stale data and alarms without confusing them with environmental conclusions; schedule service from project requirements and accumulated field evidence; preserve as-found, cleaned, and as-left records; reconcile logger, telemetry, calibration, configuration, and maintenance evidence; and require an authorized return-to-service decision. Hardware working again does not make an affected data interval accepted, released, or fit for every use.
- Assign accountable owners and backups for station health, field work, data review, configuration, escalation, and return to service
- Distinguish stale telemetry, instrument faults, provisional alarms, and plausible environmental change before mobilizing or communicating
- Set and revise service timing from approved requirements, site risk, diagnostics, fouling and drift evidence, access constraints, and data consequences
- Control firmware, configuration, credentials, consumables, and spares without losing the as-deployed baseline or rollback path
- Reconcile local logger, transmitted, calibration, service, alarm, and configuration records while preserving immutable raw evidence
- Keep station operating states separate from data review and release states
- Apply explicit safety and evidence gates before seasonal redeployment or return to service
Field route
Use an authored handoff; this is not an automatic recommendation or approval.
Open Station service and calibration log Use the governed record after reviewing Continuous Monitoring Station Operations and Quality Assurance.
1. Establish station ownership and operational control
Every observation, alarm, service decision, and configuration change needs an accountable owner.
Create a station responsibility matrix before routine operation. The program owner defines purpose and resources; the station custodian monitors equipment health; the data reviewer evaluates records; the field lead controls work at the site; the configuration approver authorizes system changes; and the decision or release authority controls operational or public use of the data. Name backups and after-hours routing where the monitoring objective requires it.
Define who may declare the station degraded, take it out of service, silence an alarm, approve remote changes, dispatch a crew, return hardware to service, qualify an affected interval, and release a dataset. One person may hold several roles, but the record should still show which authority they exercised and whether independent review is required.
| Function | Owner must control | Evidence to retain |
|---|---|---|
| Program and decision | Intended uses, priorities, funding, and external authority | Approved plan, contacts, escalation and release authority |
| Station health | Remote review, open issues, dispatch recommendation, and service history | Review log, issue tickets, state changes, and handoffs |
| Field service | Site safety, approved work scope, as-found evidence, and stop-work decisions | Service log, calibration records, parts, photographs, and deviations |
| Configuration | Firmware, logger program, sensor map, clocks, telemetry, QC, alerts, and access | Approved change, baseline, test result, implementation, and rollback record |
| Data review and release | Flags, findings, corrections, fitness for use, release, and revision | Immutable raw IDs, review history, release version, and limitations |
2. Publish operational states before the first failure
A dashboard labeled online can still represent a degraded or unverified station.
Use a small, controlled set of station states and define who can assign each one. A useful project vocabulary may distinguish commissioning, in service, degraded, out of service, under service, verification pending, and retired. The project can use different terms, but each state needs entry evidence, permitted actions, user-facing display behavior, an owner, and an exit rule.
Station state is not data quality. A station may be in service while recent observations remain provisional, or it may be out of service while an earlier interval is accepted and released. Store the two histories separately so a return-to-service timestamp cannot silently approve data.
| Station state | Operational meaning | Required control |
|---|---|---|
| In service | Approved operating configuration and required checks are current | Named health reviewer and documented monitoring scope |
| Degraded | A known limitation affects part of the station but bounded operation continues | Displayed limitation, affected functions, review frequency, and expiry/escalation rule |
| Out of service | Required capability or safety condition is not available | Start time, reason, affected products, notification, and recovery owner |
| Under service | Physical or configuration work is in progress | Maintenance flag, protected raw interval, authorized work scope, and field lead |
| Verification pending | Work is complete but required functional and data checks are unresolved | Open gate list, evidence owner, and no premature return declaration |
3. Review station health remotely with context
Remote review should detect loss of evidence, not merely values outside a chart range.
Define a remote-review package for each station: time of last local observation, last transmission, expected measurement and upload cadence, clock status, logger and sensor diagnostics, supply and charging measurements, memory, wiper or actuator evidence, QC-test results, alert state, recent maintenance, and companion parameters. Show the observation timestamp separately from receipt and dashboard-render times.
Set review timing from the consequence of delayed detection, expected environmental and station variability, communications resilience, staffing, and the approved monitoring objective. A daily, weekly, or event-triggered pattern can be appropriate in different projects; this guide does not assign a universal review frequency.
- Observation, transmission, ingestion, and display times are separately visible with time-zone basis
- Last successful local write and last received transmission are distinguishable
- Power, charging, internal temperature, memory, modem, and sensor diagnostics are retained where available
- Automated QC results retain test name, version, threshold source, result, and execution time
- Maintenance, calibration, deployment, ice, storm, treatment, and known disturbance windows are annotated
- Neighboring stations and related parameters are used as context, not as permission to overwrite or delete
- Reviewer, review time, finding, action, and next check are recorded
4. Triage stale records and alarms before diagnosing
A missing update, flat line, QC failure, and environmental excursion are different findings.
Classify the signal
Determine whether the event is late or missing transmission, a local logging gap, repeated or flat values, a diagnostic fault, a QC-test result, an environmental alert, a security or access event, or an unknown condition. Preserve the original alert and timestamps.
Check the data path
Trace sensor, logger, clock, storage, power, communications, ingestion, QC, dashboard, and notification delivery. Do not label water conditions stable because the dashboard stopped changing.
Inspect scientific context
Compare related parameters, depth, weather, hydrology, treatment or operational events, nearby observations, and recent service without using correlation as proof of cause.
Assign a bounded disposition
Record whether to continue remote observation, increase review, request a safe field check, collect confirmation evidence, mark the station degraded, take it out of service, or notify a responsible authority. State what remains unknown.
| Finding | Evidence to inspect | Do not conclude from it alone |
|---|---|---|
| No recent dashboard update | Observation and receipt times, local logger heartbeat, modem, power, ingestion, and status page | Water quality remained unchanged or the sensor failed |
| Long flat line | Sensor resolution, raw sequence, companion variables, ice, fouling, logger state, and repeated payloads | Stable environmental conditions or invalid data |
| Abrupt environmental alarm | Raw values, QC tests, rate and persistence, related parameters, disturbance, second method, and field context | Cause, compliance, public safety, or treatment need |
| Diagnostic or battery alarm | Trend, charging conditions, load, connections, recent changes, and vendor diagnostics | A fixed remaining run time or immediate safe site access |
5. Schedule service from risk and accumulated evidence
The correct interval is demonstrated at the station, not copied from a generic calendar.
Start with approved method and manufacturer requirements, anticipated fouling and drift, seasonal access, power and communications risk, redundancy, safety, intended data use, and the consequence of an undetected failure. Use a conservative initial plan where site behavior is unknown, then revise it through controlled review rather than habit.
After each visit, compare as-found fouling, calibration checks, drift, battery and charging behavior, physical wear, moisture intrusion, clock error, communications gaps, QC findings, missed events, data loss, and time since prior service. Shorten, lengthen, or change the work scope only when the project owner documents evidence, uncertainty, new controls, and the effect on data-quality objectives.
| Evidence class | Examples | Planning use |
|---|---|---|
| Method and manufacturer | Calibration, consumable, storage, cleaning, inspection, and environmental limits | Establish mandatory constraints and initial work scope |
| As-found condition | Biofouling, debris, corrosion, moisture, damage, mounting, wiper and optics condition | Test whether the previous interval protected measurement and equipment |
| Measurement evidence | Pre/post checks, drift direction, duplicate or reference comparison, QC findings, affected interval | Assess whether quality goals were sustained between visits |
| Operations evidence | Power margin, communications loss, memory, clock, alarm performance, access delay, and repair time | Change redundancy, spares, remote review, or service trigger |
| Season and events | Ice, storms, blooms, high flow, treatment, vandalism, drawdown, and debris periods | Use condition-based or event-triggered visits where planned and safe |
6. Clear safety and access gates before dispatch
Data recovery never outranks a stop-work condition.
Use the approved site-specific hazard analysis, field plan, training requirements, permissions, communications plan, and emergency procedures for every visit. Confirm the work scope and hazards before mobilization, then repeat the go/no-go check at the launch, shoreline, structure, or station because conditions can change en route.
Consider weather and lightning, darkness, wind and waves, current and water level, cold water and ice, boat and PFD requirements, crew and check-in rules, traffic, steep or unstable banks, wildlife, public interaction, contamination or bloom exposure, lifting and pinch points, mooring tension, solar and battery circuits, tools, calibration chemicals, and confined or restricted structures. Only trained and authorized personnel should perform work within their scope.
- Approved work order, site hazard analysis, access permission, permits, crew roles, and shore contact are current
- Weather, lightning, wind/waves, water level/current, ice, visibility, and return window meet project go/no-go rules
- Boat, vehicle, PFD, rescue, first aid, communications, and task-specific equipment checks are complete
- Electrical, battery, solar, chemical, biological, lifting, pressure, stored-energy, and mooring hazards are controlled
- Sensitive locations, credentials, and public-health or infrastructure information are handled under approved access rules
- Stop-work authority, missed check-in response, emergency contacts, and safe retreat are understood
- Unplanned work is deferred unless separately assessed and authorized
7. Control configuration, firmware, credentials, and spares
A successful repair can still create an undocumented method change.
Maintain a versioned as-deployed baseline that identifies station and sensor IDs, hardware revisions, firmware, logger program, channel and unit map, measurement and transmission behavior, clock basis, calibration coefficients, wiper actions, telemetry routing, QC rules, alerts, dashboards, and user-access roles. Store protected backups and enough metadata to recreate or compare the configuration without placing secrets in a public field record.
Authorize changes through a ticket or equivalent record that states purpose, affected requirements and data, compatibility review, bench or staging test, implementation owner, planned maintenance window, verification, rollback, and communication. Preserve the prior version. Do not combine an urgent repair with an untested firmware or QC-rule upgrade merely because a crew is on site.
Manage spares by exact compatibility, stable asset ID, storage and expiration requirements, calibration or acceptance status, firmware and configuration readiness, custody, and reorder point. A spare sensor is not interchangeable evidence until its identity, preparation, checks, and deployment are recorded.
- Current and prior configuration packages are versioned, backed up, access-controlled, and attributable
- Release notes, compatibility, security, method impact, and data-schema impact are reviewed before change approval
- Bench test and rollback evidence exist before field implementation when the project requires them
- Credentials and recovery procedures are controlled separately from shareable service records
- Spare sensors, cables, connectors, power components, modem/antenna parts, wipers, seals, standards, and tools match the approved system
- Lot, expiration, storage, preparation, calibration, and acceptance status are visible for consumables and standards
- Configuration changes create an annotation and review boundary in the time series
8. Execute field service as a controlled evidence workflow
Capture as-found evidence before cleaning, resetting, replacing, or updating anything.
Open the visit
Confirm authorization and safety gates; synchronize the work record; identify station state, open alarms, planned scope, applicable methods, configuration baseline, standards, spares, and expected data window. Mark the maintenance interval before disturbing the station.
Document as found
Record time, clock basis, physical condition, sensor position and depth reference, fouling, debris, moisture, damage, power, communications, diagnostics, display or raw readings, photographs, and pre-cleaning checks required by the method. Do not clean first and reconstruct later.
Preserve local evidence
Secure the native logger download, diagnostic and event logs, configuration snapshot, calibration information, and relevant device files under stable IDs. Do not overwrite source files with a processed export.
Clean, inspect, and verify
Follow current manufacturer and project procedures for cleaning, consumables, inspection, verification, and calibration. Record standards, lots, expiration, temperatures or other required context, initial and final results, stabilization, adjustments, failures, and deviations.
Perform only approved changes
Record every part, sensor, cable, seal, mounting, power, firmware, logger, QC, alarm, telemetry, or access change with old/new identity and the approved change reference. Open a deviation rather than silently expanding the visit.
Document as left
Repeat physical, depth, time, logging, transmission, diagnostic, QC, and alert-path checks required by the project. Save the as-left configuration and photographs, record unresolved findings, and assign an operational disposition without approving the data interval.
9. Keep data-state transitions separate and reversible
Automated screening, human review, correction, and release are different events.
Preserve observations exactly as acquired and store automated QC test results alongside them. Real-time flags should remain historical evidence even when later review reaches a different conclusion; post-processing should add a separate flag or decision rather than rewrite the original test history.
Define the project's data states and allowed transitions. An illustrative flow is received raw, automated-screened, pending review, accepted or qualified or rejected for a named use, and released as a versioned product. Corrections and derived values must point to source records, rule and version, reason, reviewer, and date. Reopening a released interval creates a new review and release version rather than invisible editing.
| History | Question answered | Examples |
|---|---|---|
| Station operational state | What functions and controls were available at this time? | In service, degraded, out of service, under service, verification pending |
| Automated QC state | Which documented tests ran and what did each return? | Not evaluated, pass, suspect, fail, missing; with test and threshold versions |
| Human review state | What finding and fitness-for-use decision did an authorized reviewer make? | Pending, accepted, qualified, rejected for named use |
| Release state | Which approved version may a named audience use? | Provisional display, release version, superseded, withdrawn, revised |
10. Reconcile station, service, and data records
The service narrative and time series must describe the same event without forcing false agreement.
After the visit, compare the local logger record with transmitted and ingested records by station, sensor, channel, unit, timestamp, sequence, and value. Identify buffered backfill, duplicates, missing records, repeated payloads, clock offset or jumps, parsing or unit changes, and the precise maintenance interval. Keep each original file and document every transformation.
Reconcile the service log, calibration and verification records, standards, parts and sensor identities, configuration before and after, change approvals, photographs, alarm and issue history, data annotations, and operational-state transition. Open a finding for conflicts or missing evidence; do not repair metadata from memory without attributable support.
- Local logger, telemetry transport, ingestion, dashboard, and export record counts and time bases are compared
- Station, sensor, channel, parameter, unit, depth, and configuration identities cross-walk correctly
- Maintenance, calibration, cleaning, disturbance, outage, and configuration-change windows are marked
- Backfilled, duplicate, missing, shifted, parsed, normalized, or derived records remain traceable to raw inputs
- Pre/post checks and fouling or drift findings are linked to the affected interval without an unsupported correction
- Open deviations, unresolved safety or hardware issues, and required data review have owners and due dates
- Operational return, data acceptance, and release approvals are recorded as separate decisions
11. Require evidence before return to service
Completing field work is not the same as restoring an approved monitoring capability.
Define return-to-service gates in the project plan before a failure. Apply the gates appropriate to the affected functions and intended use: safe physical installation, correct sensor identity and placement, required verification or calibration results, approved configuration, stable clock and local logging, successful communications and ingest, valid QC execution, alert delivery and acknowledgment, documented limitations, record reconciliation, and authorized sign-off.
If a requirement is unresolved, keep the station in verification pending, out of service, or a documented degraded state with bounded scope, visible limitation, owner, next action, and expiration or escalation rule. Do not invent an acceptance threshold during the incident or hide a failed gate behind an online indicator.
| Decision | Minimum record | Does not establish |
|---|---|---|
| Return in service | Satisfied project gates, evidence links, configuration, effective time, approver, and notifications | Acceptance or release of data collected before, during, or after service |
| Return degraded | Available and unavailable functions, affected users/data, compensating controls, owner, review and expiry | Fitness for an unlisted use |
| Remain verification pending | Open gate, evidence needed, responsible person, safe station condition, and next review | Permission to display data as reviewed |
| Remain out of service | Reason, protected condition, affected products, notification, recovery plan, and reassessment trigger | Failure of every historical observation |
12. Plan seasonal transitions and audit the whole system
Seasonal readiness and annual audit test whether the program can still meet its stated purpose.
Before ice, storms, drawdown, low-light periods, high fouling, high use, or other site-specific transitions, decide whether to continue, harden, relocate, change depth under an approved plan, reduce scope, retrieve, or suspend the station. Base the decision on the monitoring objective, physical and access hazards, power and communications, expected water conditions, permits, equipment limits, staffing, and consequences of loss. Record removal, storage, sensor protection, clocks, configuration, raw data, asset custody, and the redeployment acceptance plan.
At the program's defined audit interval, evaluate station-state history, data completeness by intended use, false and missed alarms, stale-data time, confirmation and repair performance, service evidence, fouling and drift, calibration and consumable failures, safety stops and near misses, configuration changes, access reviews, cybersecurity and credential ownership, spare availability, vendor support and obsolescence, costs, open findings, data releases and revisions, and user decisions. Revise requirements, review and service timing, architecture, training, spares, or the monitoring objective through controlled approval.
- Season-specific hazards, access, water level/depth, ice, storm, fouling, power, and communications assumptions were compared with evidence
- Retrieval, storage, winterization, redeployment, recommissioning, and permit responsibilities are assigned
- Station-state, alert, issue, safety, service, configuration, calibration, spare, data-review, release, and revision histories are complete
- False alarms, missed events, silent failures, stale-data duration, gaps, confirmation time, repair time, and repeat findings are evaluated with documented definitions
- Users confirm which observations supported decisions and which requirements no longer add value
- Corrective and preventive actions have owners, target dates, verification, and closure evidence
- The next operating plan records changed assumptions, requirements, risks, and review dates
Sources and review notes
Educational operations and quality-assurance guidance only. This guide does not approve a station, QAPP, safety plan, calibration, firmware change, data correction, regulatory submission, public-health action, or return to service. The current project plan, approved methods, manufacturer instructions, permits, site-specific hazard controls, data-quality objectives, contracts, and responsible authorities govern. Service intervals, alarm rules, acceptance criteria, and return-to-service evidence must be established for the site and intended use; this guide does not supply universal values.
- Guidelines and Standard Procedures for Continuous Water-Quality MonitorsU.S. Geological Survey · field protocol
- National Field Manual for the Collection of Water-Quality DataU.S. Geological Survey · field protocol
- National Field Manual, Chapter A1: Preparations for Water SamplingU.S. Geological Survey · field protocol
- Quality Assurance Project Plan StandardU.S. Environmental Protection Agency · agency guidance
- Quality Assurance Project Plan GuidanceU.S. Environmental Protection Agency · agency guidance
- Manual for Real-Time Oceanographic Data Quality Control Flags, Version 1.2U.S. Integrated Ocean Observing System · agency guidance
- Procedures for Processing, Approving, Publishing, and Auditing Time-Series Records for Water DataU.S. Geological Survey · agency guidance