Automation · Water & pump controls
Water and pump visibility where intent never overrules an interlock.
GA Applications designs the software layer for water and pump systems: levels, flow, pressure, pump state and runtime with trends, alarms by consequence, and an honest display of operator intent versus specialist-owned safety interlocks. Remote command is never assumed, and manual controls stay manual.
Who this is for
Know what the water system is doing — before the phone call
Water systems fail quietly: a pump short-cycling for weeks, a tank overflowing at night, a pressure drift that becomes a burst. This service designs the visibility and coordination layer for tanks, pumps, lines and bores — levels, flow, pressure, pump state and runtime, alarms by consequence, and manual controls that remain firmly in human hands.
Right fit
- Rural properties, irrigation schemes, facilities and small utilities with tanks and pumps
- Operators tired of driving out to check a level
- Teams who want runtime and start-count trends to catch wear early
- Organisations with qualified pump and electrical providers who need a better software layer
Wrong fit
- Anyone seeking hydraulic design, pump sizing or electrical installation — qualified specialists own that
- Safety-critical control where software must guarantee an action — we design visibility and logged intent, not certified control
- Buyers wanting fully autonomous pump control with no human authority model
What the system shows and does
States, trends, interlocks and consequence-based alarms
The operating picture
Levels, flow, pressure, pump state and runtime are presented as one picture with freshness and quality on every value. Trends matter as much as states: rising start counts, lengthening runtimes for the same volume, and slow pressure declines are the early warnings a daily glance cannot catch. History is kept so “has it always done that?” has an evidence-based answer.
Operator intent versus safety interlock
This distinction is the heart of the design. An operator's request — start the pump, open a path — is intent. Whether the equipment may act is decided by safety interlocks that qualified specialists own and validate: low suction pressure, dry-run protection, over-level, electrical faults. Our software displays both sides honestly: the intent, the interlock state, the reason for any block, and the log entry. It never overrides an interlock, and it never hides one.
Alarms by consequence
An overflowing tank at 02:00 and a slow pressure drift do not deserve the same noise. Alarm severity follows consequence — what happens if nobody responds — and routes through acknowledgement and escalation exactly as in the wider monitoring and alerts design. Trend-based early warnings are informational; imminent damage is not.
Manual controls stay manual
Physical controls at the pump remain available and authoritative. Where remote commands are designed at all, they require supported equipment, explicit authority, confirmation, logging and a tested fallback — the same bar as every page in this section — and field response connects through field technology so the person driving out knows what the system saw.
Delivery
Interface review, witnessed testing, operations pack
Delivery starts with an interface review alongside your pump and electrical providers: what signals exist, what the controllers support, where the interlocks live. Testing is witnessed — states forced and observed, alarms triggered and acknowledged, interlock blocks demonstrated — before handover. You receive an operations pack: the state dictionary, alarm classes and escalation chain, responsibility matrix, and the manual fallback procedure. How we run projects
System contract
Inputs, outputs and interfaces
| Kind | Examples | Authority / owner |
|---|---|---|
| Inputs | Level, flow, pressure and pump-state signals; interlock states; operator intent | Controllers and interlocks are authoritative; the software displays, never overrides |
| Outputs | Operating picture, trends, consequence-based alarms, intent/interlock log, field-response tasks | Your operators own response; specialists own safety logic |
| Interfaces | Pump controllers, level/pressure/flow instruments, alerting channels, field technology | Confirmed in the interface review with your pump and electrical providers |
Delivery sequence: interface review with your providers → state and alarm design → witnessed testing of states, alarms and interlock blocks → handover with the operations pack and manual fallback procedure.
Questions buyers actually ask
Frequently asked questions
Can the software start and stop my pump?
Only where the equipment supports it, you grant explicit authority, confirmation and logging are in place, and a tested fallback exists — and never against a safety interlock. Interlocks are owned and validated by your qualified specialists; the software displays intent and interlock state honestly and logs every action. Monitoring-only is the default starting point.
Do you design or install the pumps and pipework?
No. Hydraulic design, pump selection, electrical work and commissioning stay with qualified pump and electrical providers. We design the software layer: states, trends, alarms, intent-versus-interlock display and records — alongside those providers, with the responsibility matrix agreed up front.
What alarms will we get?
Alarm classes are designed by consequence: informational trend warnings (rising start counts, runtime drift), actionable warnings (level approaching limits, pressure outside band), and high-severity conditions (overflow risk, dry-run risk indicated by interlocks) that escalate until acknowledged. Thresholds are tuned during the pilot so every alarm means something.
What happens if communications to the site drop?
The interface shows last-known state with its timestamp and raises a lost-contact alert through the severity chain. Local controllers and manual controls at the equipment continue to operate as your specialists configured them — our software layer never stands between the equipment and its safety logic.
What do we receive at handover?
An operations pack: the state dictionary, alarm classes and escalation chain, the responsibility matrix showing which party owns interlocks and safety logic, witnessed test records, and the manual fallback procedure. Your team should be able to read every state and own every alarm without us.
Scope my water system
Tell us about the task, site or signal you want to automate. We will come back with a scoped pilot path — model, test, controlled commissioning, handover.