Borehole Telemetry, Remote Control and Pump Protection

Use the working record

Download the editable worksheet. Record the actual evidence and responsible reviewer against each relevant row. The empty results are inputs for your project, not completed tests. Add the equipment identity, operating period and reference method before assigning an outcome. Retain unsuccessful checks and the evidence from any repeat after correction.

Define the function before selecting a signal

State whether the project needs reporting, operator notification, authorised remote control or a protective action. A level trend can inform a water-management decision without controlling the pump. Adding a remote start function changes the operating responsibilities and acceptance tests. Keep that change explicit in the scope rather than treating it as a dashboard option.

Identify the pump, borehole, storage and delivery route. The responsible water and electrical specialists should agree which conditions matter to the actual installation. A shared tank, multiple pumps or a changed valve arrangement can affect what a command or measurement means.

Separate the observations available to the operator

A start command, contactor state, motor current and delivered flow are different observations. Verify each signal against the physical equipment and retain its identity. A running indication can help establish that a motor was energised; confirmation of water delivery requires the relevant flow, pressure or local inspection evidence.

Borehole level needs a stable reference and a suitable installation. The water specialist interprets drawdown and recovery for the actual source. A remote value should retain its unit, timestamp and quality, particularly when the displayed observation is old or the instrument is under maintenance.

Give local protection its own design authority

The electrical and pump-control designer specifies the local protective functions appropriate to the equipment and installation. The design identifies the relevant inputs, interlocks, reset behaviour and authorised settings. The monitoring project should obtain that information so its display and command interface represent the real control arrangement accurately.

A cloud connection should not become the sole path for a protective action that must remain available locally. The responsible engineer determines the required independence and failure behaviour. Record what the controller does during loss of a remote measurement, gateway power or backhaul, and verify those conditions through an approved test method.

Define an explicit command lifecycle

Record who may issue a command, the intended asset, request time and required permission. Distinguish request creation, transmission, controller acceptance, physical state change and confirmed operating outcome. A successful network response at one stage does not establish completion of every later stage.

Specify command expiry and the handling of duplicates or delayed delivery. A request issued before an interruption should not unexpectedly become a fresh operating instruction after the connection returns. The control designer and operating owner should agree how the supplied system deals with those situations and how the evidence is retained.

Agree the operating mode and local priority

Document local, remote and maintenance modes as they actually exist. A local technician should be able to identify which source has authority and what the remote interface displays during isolation or maintenance. The application must not suggest that a command is available when the local arrangement intentionally prevents it.

Record the procedure for returning equipment to service. Restoring communication and restoring operating permission are separate steps. The authorised site team should confirm the intended mode, open work and relevant protections before routine remote operation resumes.

Test loss of information separately from loss of control

Use safe simulations or controlled tests approved by the responsible team. Exercise unavailable level information, lost backhaul, gateway restart and a rejected command as distinct conditions. The expected outcome should specify the displayed state, local control behaviour, retained record and operator action for each scenario.

Label simulated evidence clearly and verify restoration after the exercise. A test that leaves a bypass, temporary configuration or disabled notification in place is not a completed handover. Retain the restoration witness and any unresolved item with the original test result.

Preserve the actual timing of delayed records

Local storage can help reconstruct an interruption when the supplied architecture supports it. Retain acquisition time separately from arrival time. A recovered low-level observation may explain an earlier event without proving that a live warning reached the operator during that period.

The response procedure should identify what staff do when current information is unavailable. A stale reading should remain visibly stale, even if it is the last plausible value. The operating owner decides the local checks and permitted actions under that condition.

Hand over a responsibility matrix that can be maintained

Record who owns protection settings, command permissions, water-level interpretation, communication service and routine instrument checks. The same company may supply several functions, but the responsibilities should remain identifiable. Include the evidence required before a replacement device or changed controller mapping returns to service.

Review the matrix when the source, pump, storage route or operating requirement changes. A telemetry expansion should trigger a review of the affected functions rather than silently inherit the original control assumptions. The final acceptance pack should make clear what was observed, what was commanded and what was independently protected.

Connect the decision to the project

Use Automated irrigation, Remote water monitoring, Agriculture to place this task within the wider installation. Bring a recent operating record and identify the decision that the proposed measurement should support. A focused discussion should establish the first boundary, the responsible site participants and the evidence needed before expanding the scope.

Agree who maintains the point register and who can change interpretation rules. Preserve the previous version when a device, product, reporting period or responsibility changes. During handover, demonstrate an export that another authorised person can reconcile without relying on the dashboard operator to explain missing fields.

Discuss the scope with addanode using the actual site information, available interfaces and proposed acceptance record.

Sources and method

NIST SP 800-82 Revision 3 provides OT dependency background. USGS technical procedures support water-level reference practice. The responsibility and failure matrix is a proposed project tool, not a certified protective-system design.

Frequently asked questions