📌 Key Takeaways
Strong lift station requirements link every station condition to a clear response, adjustable setting, needed signal, exception, and verification method.
Start With Station Facts: Teams should document actual pumps, operating states, signals, limits, and future needs before comparing controller features.
Define Every Operating Case: Each requirement should name the trigger, available equipment, controller response, release condition, and fallback for failures.
Control Every Setpoint: Teams should record units, direction, reset rules, timing, ownership, approval status, and verification for each setting.
Trace Logic to Signals: Engineers should connect each required response to its signal source, type, valid range, failure behavior, and purpose.
Test Normal and Abnormal: Reviewers should verify normal sequencing, pump failures, bad signals, power restoration, manual modes, alarms, and future expansion.
Clear decisions prevent costly field surprises.
Municipal engineers, operators, and panel builders can align station decisions by using the requirements framework that follows.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
"Alternate pumps as required" may sound clear until operations, engineering, the panel builder, and the commissioning team each interpret it differently. One assumes runtime-based rotation. Another assumes event-based rotation. Nobody has documented what happens when the assigned lead pump isn't available.
Useful requirements don't start with that kind of shorthand. They connect a station condition to a required controller response, the values that must be adjustable, the inputs and outputs the response depends on, the exceptions that need a defined answer, and how the requirement will be verified. This isn't a sequence of operations you can copy from one station to the next, and it isn't a substitute for engineering judgment. It's a framework for documenting what your team already knows about the station, before a controller, panel, or programming approach is chosen.
Start With the Station Basis, Not the Controller Catalog
Sequencing requirements written around a specific controller's feature list tend to miss station-specific realities — a pump reserved for future capacity, a maintenance bypass mode, or a signal type the original panel designer never assumed. Documenting the station basis first gives every reviewer the same starting point.
Treat the following as a review checklist, not a set of universal requirements:
Pump arrangement and duty: the number of pumps, intended lead/lag/standby duty, and whether any pump is reserved for future use
Equipment type: fixed-speed, variable-speed, or mixed, confirmed against actual equipment documentation rather than assumed
Operating states: normal duty, manual override, hand/off/auto position, maintenance lockout, and faulted states
Wet-well objectives and constraints: what the station needs to accomplish and any known site limitations
Available signals: level, pump-status, power, flow, and auxiliary inputs already in place, and what device type produces each
Existing versus future equipment: what's installed today versus what capacity should be reserved
Local criteria: any owner standard, utility specification, or jurisdictional requirement that may affect the design
Don't assume a duplex architecture, identical pumps, or a single level-sensing method just because it's common. The point of this checklist is to surface what's actually true about the station before anyone writes a sequence.
Turning that checklist into requirements means asking the right questions of each wet-well condition. What actually creates a request for another pump? In which direction must the level indication move before that request is valid? Which equipment states are allowed to respond? What condition resets or releases the response? And does an alarm threshold rely on the same indication as the operating threshold, or a separate one? The station's operating objectives should drive those answers, but no article can supply the values — only the review process that gets them documented.
Write Each Sequence as Condition, State, Response, and Exception
A sequence becomes reviewable — and testable — when it's written as a relationship rather than a procedure. For each triggering condition, the requirement should identify which pumps are available, which one holds lead or lag duty, what response is required, and what condition ends or changes that response. It should also state how alternation is initiated, suspended, or restored, and specifically what should happen when the assigned pump is unavailable. Manual, automatic, local, remote, and maintenance permissives belong in the requirement wherever they apply, along with any interlock that prevents one pump state from conflicting with another.
In practice, this means documenting four connected elements for every operating case: the condition that calls for action, the state of pump assignment and availability that permits a response, the response itself along with what ends it, and the exception — what happens when an assumed pump, signal, power source, or operating mode isn't available when the condition occurs.
Staging and de-staging deserve the same discipline as alternation. A complete requirement identifies the condition that calls for another pump to stage on, which equipment is eligible to answer that call, and — just as importantly — the condition that releases or de-stages a pump once it's no longer needed. Minimum-run and minimum-stop considerations often belong here as controlled fields in their own right, not as assumed durations: the requirement should let reviewers decide whether such a timer applies, who approves its value, and how it interacts with other pending requests, rather than having a generic duration inserted by default.
Behavior after a power or communication interruption needs the same treatment: document that a restart requirement exists, without prescribing whether restart is simultaneous or staged. That decision depends on station-specific electrical and hydraulic factors that only your engineering team can evaluate.
A compact matrix keeps these fields traceable. The rows below are hypothetical examples meant to illustrate the format — not values to reuse.
Operating Condition / Trigger | Pump Availability / System State | Required Controller Response | Adjustable Parameter / Setpoint | Required I/O | Alarm, Exception, or Fallback | Acceptance Criterion / Approving Role |
|---|---|---|---|---|---|---|
Wet-well level reaches a documented call-out point | Lead pump available | Start assigned lead pump | Lead-pump call-out level | Level input; pump-start output | If lead pump unavailable, promote lag pump and alarm | Confirm start output energizes at documented condition; operations lead approves |
Level continues rising after lead pump starts | Additional pump available | Stage next pump per documented logic | Staging condition and time basis, if used | Level input; second pump-start output | If staged pump unavailable, alarm without automatic substitution unless approved | Confirm staging occurs only under documented condition; engineer of record approves |
Primary level signal reads out of expected range | Signal status unknown | Flag signal fault; do not act on an invalid reading | Signal-validity criteria | Level input; fault/alarm output | Escalate to operations; document backup indication if one exists | Confirm fault detection and alarm; controls engineer approves |
Power is restored after an outage with multiple pumps requested | Multiple pumps eligible | Execute documented restart behavior | Restart sequencing basis | Power-status input; pump-start outputs | If restart condition can't be confirmed, hold in a safe default state and alarm | Confirm restart matches documented sequence; operations and engineering jointly approve |
Every field in an actual project document needs a station-specific answer where this table shows a placeholder or a description of what must be decided.
Treat Setpoints as Controlled Requirements, Not Isolated Numbers
A setpoint is more than a number typed into a controller screen. Listing "high level alarm" without units, a reset condition, or an owner leaves the requirement incomplete — and leaves the actual value looking more final than it is. A controlled setpoint record should carry:
A unique tag or identifier
Its operational purpose
Engineering units
Trigger direction (rising or falling)
The reset or release condition
Deadband or hysteresis, where applicable
Any time qualification or delay, where applicable
Dependencies on or priority relative to other setpoints
Who is permitted to adjust it after commissioning
An approved initial value or a clearly labeled commissioning placeholder
An allowed range, only when supported by equipment documentation and engineering review
Source, owning stakeholder, and revision
The acceptance criterion used to verify it
No setpoint is meaningfully reviewed in isolation." OR "No setpoint is meaningful when reviewed in isolation. For example, comparing control logic to standard cloud monitoring platforms highlights this distinction. A start threshold needs to be checked against its stop or release condition, its timing, which equipment is eligible to respond, and how it relates to alarm behavior — not confirmed as a single standalone value. An alarm threshold carries the same obligation: it needs its own trigger and reset behavior defined, along with how it relates to the operating threshold it monitors, since the two don't always share the same indication or the same timing.
If someone tells you the programmer can work out the details later, or that exact setpoints aren't known yet, that's a reason to document the fields above — not a reason to skip the setpoint requirement entirely. Implementation can stay flexible. The required behavior, ownership, and acceptance criteria still need to be approved before anyone can evaluate whether a controller or program meets them.
Trace Every Required Response to I/O and Sensor Behavior
A sequence narrative and an I/O schedule that evolve separately are a common source of field surprises. Each required response should trace to a signal's purpose and source, whether it's analog or discrete, its scaling and valid range where verified, and what it reports — run status, availability, fault, mode, or command state. Analog and discrete indications aren't interchangeable in a requirement: an analog signal typically carries a measured value along with its own quality information, while a discrete signal represents a defined state. A broad label like "pump status" glosses over that distinction — the requirement should specify whether it means run, availability, fault, mode, or command state, since each implies a different response.
The requirement should also state what happens on loss of signal or a bad-quality reading, whether an independent backup indication exists, and whether spare I/O capacity is available for anticipated future needs.
It's worth being precise about what a monitoring signal proves. OmniSite's Station Utilization documentation describes analog level, pump-current, pump-runtime, and digital input and output information as data categories its equipment can report — useful for confirming after the fact that a sequence behaved as documented, but not the same as the closed-loop control logic inside the controller itself. OmniSite separately describes how its cloud-based lift-station monitoring works, covering alerts, runtime data, and reporting. A reported value shouldn't be treated as authority to start or stop a pump unless that function is separately documented and verified.
OmniSite also states that GuardDog permits alarm triggers to be configured for equipment input channels, with callout lists using email, text, or phone notifications. If your requirements package includes alarm notification behavior, that's a useful category to define — separately from, and not in place of, the sequencing logic itself. You can review GuardDog's alarm configuration and reporting options if notification requirements are part of your scope.
Document Abnormal Conditions Before They Become Field Decisions
A sequence description that only covers normal operation leaves the harder work undone. Documented requirements should also address: a pump that's unavailable, failed, or removed from service; conflicting or invalid level indications; loss of the primary level signal; power loss and restoration; communication loss where it affects required functions; manual override or maintenance states; demand that exceeds the normal duty arrangement; and alarm escalation or acknowledgment expectations where they apply.
Communication loss deserves a specific distinction: losing remote visibility into a station is not the same condition as losing a signal the local control logic actually depends on, and the requirement should make clear which one it's addressing before assigning a response.
For each condition, the requirement needs a defined response, a permitted fallback, an alarm expectation, operator visibility, and a way to verify it. None of these situations has one correct answer that applies to every station — the goal is making sure someone with the authority to decide has actually made that decision, rather than leaving it to whatever the controller happens to do by default.
Close the Loop With Traceability, Acceptance, and Expansion
A useful requirements package can be traced end to end: requirement ID → source or approving stakeholder → related I/O → configurable setpoint → verification method → approver. A requirement that can't be followed through each of those links usually means the condition wasn't fully described, the I/O wasn't confirmed, or nobody has actually approved the value.
The same discipline applies to future expansion. Calling a station "expandable" without defining capacity turns the word into an untestable claim. A better requirement states the anticipated future function and identifies the specific interface or capacity that needs to be reserved for it. Where the sequence narrative, setpoint schedule, I/O list, drawings, and equipment submittals disagree, resolve the conflict before it reaches commissioning — that's a far cheaper place to catch it.
If you're preparing a specification or reviewing an existing controls package, bring the requirements matrix above into a joint operations-and-engineering workshop before comparing controller features against each other. It's the fastest way to find out which decisions are still missing.
Frequently Asked Questions
Should a controller specification include exact lift-station setpoints?Â
Include approved project values where they're available. Where a value is still unresolved, document the setpoint's identifier, units, purpose, dependencies, owner, and approval status rather than substituting a generic number.
What should the sequence require when the lead pump is unavailable?Â
The requirement should define how unavailability is detected, which equipment remains eligible for lead or lag duty, what response and alarm are required, and how that state gets verified. The actual response still depends on the station's design.
Does sensor compatibility belong in the sequence requirements?Â
The sequence should identify which signals each required behavior depends on. Confirming signal type, scaling, range, failure indication, and electrical and controller compatibility belongs in the supporting I/O and equipment documentation.
Transitioning to Procurement
None of this replaces engineering judgment, and it isn't meant to. By codifying the station's functional needs independently of any specific hardware platform, the engineering team establishes a vendor-neutral standard. This ensures the eventual procurement process evaluates how well a proposed solution meets the site's operating realities, rather than forcing the site to adapt to a vendor's default logic.
Disclaimer: This article is for general informational purposes only and does not constitute compliance, safety, technical, or professional advice. Requirements, risks, and best practices may vary by context, jurisdiction, system, provider, or use case. Confirm important decisions with the appropriate qualified professional, authority, or technical expert.
Our Editorial Process:
OmniSite content is drafted from approved OmniSite source materials, reviewed for factual accuracy against product documentation and current website pages, checked for unsupported technical or quantitative claims, and edited for clarity for municipal wastewater and public works readers. Any claim involving safety, cybersecurity, reliability, warranty, pricing, reporting cadence, or technical specifications is traced to an approved OmniSite document or an authoritative external source.
By the OmniSite Insights Team
OmniSite manufactures control systems that help protect people and the planet by supporting municipal infrastructure monitoring for lift stations, water systems, wastewater systems, and airfield lighting, with a mission centered on protecting waterways, drinking water, and public safety through early warning of equipment issues.