Irrigation Software Commissioning: Test Commands, Timestamps, and Missing Data

Irrigation software commissioning should prove that an agreed field action and its supporting data survive the complete path through the system. A working login or changing dashboard is only part of that evidence. Test the requested command, the identified equipment, the execution record, the observation timestamp and the history that an operator will later use.

Black elbow fittings for irrigation pipework. This photograph shows physical pipe components, not evidence of the software acceptance tests described in this guide. Photo: IrriNex.

This guide builds an original acceptance set for one representative irrigation zone and its monitoring points. The test cases, identifiers and outcomes are fictional. They illustrate how to document acceptance; they are not results from an IrriNex installation or claims that a particular platform provides every feature described.

1. Turn the operating requirement into a testable record

Begin with the farm's required behavior and the supplier's supported functions. Identify the controller, field zone, sensor points, application, integration and report included in the trial. Record their configuration versions and assign a person to approve the test procedure.

Choose a representative path that can be observed safely. A controlled test may use a non-operating simulator for abnormal data and an authorized, supervised water-only procedure for equipment behavior. Do not disconnect energized equipment, obstruct a live valve or defeat a protective condition to manufacture a software fault.

Define expected outcomes before running the cases. Include project-specific response limits only when the farm and supplier have agreed how they will be measured. A generic requirement for real-time data is too vague to decide whether a delayed observation passes.

Keep a configuration snapshot and a restoration plan. Test evidence is meaningful only for the identified configuration and conditions; a result from one trial does not automatically cover every controller model, field route or later software version.

2. Follow a command beyond its initial acceptance

Give each trial a test identifier and retain the platform's request identifier where available. Follow the request through the supported status record to its documented terminal outcome. Compare the named asset with what a field observer or suitable instrumentation actually confirms.

For systems using HTTP, RFC 9110, HTTP Semantics, distinguishes a request accepted for later processing from completed processing. Its 202 status does not promise that the requested operation will eventually occur. A supplier should explain what its application-level statuses mean beyond that transport response.

A record that says a command was created can establish that software stored a request. It does not independently prove that a field controller received it, that the intended output operated or that the relevant branch delivered water. Match each claimed outcome to the evidence required by the farm's acceptance condition.

Also test a documented rejected request in a non-operating environment. Confirm that the rejection remains visible and that no unintended configuration or operation follows. Select the test input with the supplier so that the test exercises supported validation without introducing an unsafe operating demand.

For flow evidence, record the meter boundary and observation interval. The flow-meter pulse and reporting guide explains why a count, cumulative total and interval flow answer different questions. Software acceptance should use the correct reported quantity rather than infer delivery from an unrelated changing number.

3. Verify timestamps before interpreting sequence or delay

Identify which time belongs to the field observation, which to its reception and which to its display or report generation. Record the time basis and resolution for the relevant devices. A recently generated report can contain old measurements, and a fresh connection can deliver buffered history.

NIST's September 2023 Guide to Operational Technology Security discusses time synchronization for correlating events and logs. Its OT guidance supports checking the timing basis across the system. It does not prescribe an irrigation-specific delay limit or require a farm to adopt a particular synchronization technology.

Use the agreed reference to establish whether differences between timestamps represent actual delay or clock disagreement. Keep the result with the test. If timing uncertainty is large enough to change a pass into a fail, record the test as inconclusive and improve the measurement before judging performance.

Inspect the operator's normal view as well as an export. The displayed time should identify the observation consistently with the underlying record, even when the user chooses another supported time zone. Preserve the original measurement time when delayed data is placed into history.

Do not repair apparent timing problems by relabeling the received time as the measurement time. Establish the source and meaning of each field with the supplier. If the platform cannot preserve the required distinction, document that limitation as an acceptance issue.

4. Test valid, missing and delayed data separately

Prepare a small set of approved simulated observations with known identities, values, units, quality states and measurement times. Trace a valid observation from its source through ingestion, the current display and the retrieved historical record. Compare the actual record, not only the shape of a chart.

Next, omit a sample intentionally in the non-operating test. The absence should remain distinguishable from a valid reading of zero. A zero pressure reading, for example, describes a measurement; an absent pressure observation provides no such measurement. The agreed display and report behavior must preserve that difference.

If the application interpolates across missing observations, confirm that the interpolation is identifiable and that the original gap remains recoverable. A smooth line must not become the only record of a period when measurements were unavailable. Check totals or reports that could otherwise incorporate an invented value.

Then deliver an older valid observation after a newer one. Verify that the older point enters the appropriate place in history and does not appear to be a new measurement taken at arrival. The current-status indicator should follow its documented freshness rule rather than reset merely because some data arrived.

These tests verify software handling of observations. They do not establish sensor calibration or representativeness in soil. The soil-moisture sensor placement guide addresses that separate field requirement. Preserve both checks when the data will influence irrigation decisions.

5. Reconcile an uncertain command before retrying

Use an approved simulator or test harness to withhold an acknowledgement after a request is submitted. Observe whether the application distinguishes an unknown outcome from a confirmed rejection. The absence of a response does not establish that no execution occurred.

Ask the supplier to demonstrate its supported reconciliation process. Depending on the system, this may involve reading the original request's status, examining a controller execution record and checking the observed operation. Retain the relationship between the original request and any subsequent recovery action.

RFC 9110 also limits automatic retries of requests whose repeated effect is not known to be the same. The practical commissioning question is whether the platform can recover without creating another unintended irrigation event. Do not assume that clicking start again is a harmless acknowledgement check.

Distinguish lost remote visibility from interrupted local operation. The guide to irrigation with unreliable internet explains that operating dependency. During acceptance, document the installed controller's actual behavior and the approved operator response when the remote outcome remains uncertain.

Keep the test bounded and restore its normal communication conditions afterward. A trial of one recovery mechanism does not authorize disabling unrelated protections or experimenting with production retries. Unresolved uncertainty belongs in the defect record and operating handover.

6. Record the result of each case without hiding failures

The following fictional trial contains three command cases and three data cases. It assumes the test method, permitted operations and required display behavior were agreed in advance. Each result refers only to the case described.

Four cases pass and two fail. Those counts do not establish a reliability percentage for the software or justify accepting the whole installation. The two defects affect how an operator interprets missing and old data, so their consequences must be resolved before approving the relevant use.

Keep the input fixture, configuration version, expected result, actual result and evidence location for every case. A failed result should remain in the record after repair, linked to the corrective version and retest. Replacing the first report with an all-green screenshot loses useful commissioning evidence.

If a case cannot be observed because a status record or export is unavailable, mark it unverified rather than passed. Agree whether another supported evidence method can answer the requirement. The limitation should be visible to whoever accepts the installation.

7. Close defects and define the accepted scope

For the fictional S14 and S15 defects, request a documented correction and rerun the affected cases. Include related successful cases in the regression check where they share the changed handling of observations or status. The purpose is to verify the repaired behavior without losing behavior that previously worked.

Review any alarms produced by missing or stale data with the responsible operator. The remote irrigation alarm guide connects an indication with a response. Acceptance should establish that the tested condition reaches the intended view and that staff understand what the indication permits them to conclude.

Complete the trial by removing simulated inputs, restoring approved settings and confirming that the production view contains actual field data. Record who checked restoration and who accepted the stated scope. Repeat the relevant tests after a meaningful change to software, a gateway, an integration or the field mapping.

8. Frequently asked questions

Is a successful application command enough for commissioning?

It establishes only the outcome defined by that message. Follow the request to its documented execution status and the independent evidence required for the field action, then retain the result under the tested configuration.

Should missing irrigation sensor data appear as zero?

An absent observation and a valid zero measurement are different states. Verify that the application and historical report preserve the distinction, including any interpolation or quality indication.

Does one successful zone test accept every field controller?

No. Record the tested path and define additional coverage for materially different devices, routes and configurations. A representative case supports a commissioning plan but does not prove untested behavior.