📌 Key Takeaways
Build lift station controller requirements from documented wet-well risks, then link each requirement to a clear, testable result.
Trace Every Risk: Link each station risk to an observation, response, alarm need, record, and clear acceptance test.
Separate Control and Monitoring: Keep immediate pump actions local, while remote systems handle notifications, history, and reports.
Define Every Pump State: Record what starts each step, confirms pump operation, handles unavailable pumps, and controls overrides or resets.
Test Inputs and Outputs: Tie each measurement and command to its purpose, failure response, visibility, owner, and acceptance method.
Keep Decisions Site-Specific: Qualified professionals must review final setpoints, sequences, safety measures, and local rules before the team relies on them.
Risks first. Testable requirements before vendor comparisons.
Municipal wastewater teams will build a review-ready requirements package, preparing them for the controller and panel comparisons below.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
A project team can usually name a long list of desirable controller features. What is harder is explaining which wet-well condition or pump-station risk each feature actually addresses.
Controller requirements should come from documented station conditions and risks, not from a feature list. The reliable way to get there is a five-part traceability method: start with the operating condition or risk, define what must be observed, state the controller function or response, identify the alarm and notification need, and set a documentation and acceptance criterion. Traceability, in this sense, is what connects an operating concern to its requirement, and an acceptance criterion is the observable result used to confirm that requirement has been met. Once that chain is in place for every material risk, the team has something reviewers can actually test.
Start With the Station, Not the Controller
Before anyone drafts a requirement, the project team needs an agreed picture of how the station actually behaves. That picture should cover more than routine operation, and it depends heavily on operator knowledge that may exist informally rather than in a reviewable document.
A practical way to build it is a short inventory, grouped by condition type:
Normal operation: typical wet-well level range, inflow variability, and the pumps expected to run under ordinary conditions.
Abnormal conditions: sensor loss, communication interruption, unexpected pump unavailability, or a level reading that no longer matches field observation.
Maintenance situations: a pump taken out of service, manual override, or bypass operation while work is underway.
Degraded operation: partial capacity, a single available pump, or reduced instrumentation while repairs are pending.
Record the pumps available, their intended duty arrangement, and the discrete statuses, alarms, and outputs already known to exist. Where drawings, I/O schedules, or operating narratives disagree with field observations, treat the field account as a trigger for confirmation. A cross-functional workshop, paired with a field walkdown where practical, is usually the fastest way to reconcile these gaps — operations can explain what the station actually does, while engineering and integration can identify what is documented, what is only assumed, and what remains unresolved. A specific technical threshold — a level, a delay, a signal range — belongs to project-specific engineering, not to this inventory stage.
Use a Risk-to-Requirement Traceability Matrix
Once the station conditions are documented, turn each one into a requirement that can be reviewed and tested. For example, stating 'The controller shall support lead/lag pump operation' is a feature request, not a requirement. It leaves reviewers guessing what physical condition triggers the transition, how failures are handled, and how the system confirms the transition was successful. A traceability matrix prevents this guesswork by walking a single condition through five columns: the condition or risk, what must be observed, the required controller function or response, the alarm and notification need, and the acceptance criterion that confirms the requirement is met.
Working through one condition at a time keeps the team from lumping unrelated concerns into a single vague requirement. The table below applies the method to four hypothetical conditions spanning normal, abnormal, maintenance, and degraded operation. None of the responses or acceptance methods shown here are recommended values; they illustrate the method, not a design.
Station Condition or Risk | Required Observation | Controller Function or Response | Alarm, Notification, and Documentation Need | Verification or Acceptance Criterion |
|---|---|---|---|---|
Normal alternation between lead and lag pumps under typical inflow | Run-confirmation status for each pump in turn | Local logic confirming alternation occurs as intended | Routine status logged; no alarm expected | Documented test confirming alternation and logging under normal conditions |
Wet-well level rising while the expected pump is not confirmed operating | Level trend and pump-run confirmation status | Local logic to detect the mismatch between rising level and absent run confirmation | Local alarm plus a remote notification to the designated on-call contact | Documented test confirming the local response and the remote notification both trigger from a simulated mismatch |
A pump manually taken out of service for maintenance | Manual/out-of-service status for the affected pump | Local logic excluding that pump from automatic sequencing while it is flagged out of service | Status change logged locally and visible in remote history | Documented test confirming the pump is excluded from sequencing and the status change is recorded |
A duty pump becomes unavailable during an operating cycle | Pump-available/unavailable status for each pump | Local reassignment logic among remaining pumps, subject to project-specific rules | Status change logged locally and reported through remote history | Documented test confirming reassignment occurs and the status change is recorded |
Separate Control From Monitoring
Alarms, notifications, and control actions are easy to treat as one function, but they belong to different systems with different responsibilities. An alarm is the event or indication generated for a defined condition; a notification is the delivery of information about that event to a person or another system. What clears or latches an alarm, and what escalation rules govern a notification, are separate design questions that deserve their own answers.
Function | Typically Belongs To |
|---|---|
Local alarm generation and immediate process response | Local controller |
Remote notification and callout delivery | Remote monitoring/notification system |
Historical data and reporting | Remote monitoring/notification system |
Final control action on pumps | Local controller |
OmniSite's GuardDog product page describes a cloud-based notification system and historian with configurable alarm triggers, callout lists, and reporting — an illustration of what belongs in the remote-notification row rather than the local-control row. The distinction matters most when a communication path fails: a lost connection affects whether alerts and history reach the monitoring system, but it does not, by itself, change how the local controller behaves. That separation is a project-specific requirement worth testing directly.
Define Pump Duty and Sequence Boundaries
Pump duty arrangements shape a large share of the controller's functional requirements, so they deserve their own pass through the traceability logic. A duty arrangement assigns roles such as lead, lag, or standby where applicable, while a control sequence defines how conditions initiate actions, how results get confirmed, and how exceptions are handled.
Start by identifying which states apply to the station: lead, lag, standby, unavailable, manual, and maintenance. For each state, the team should be able to answer what initiates a sequence step and what confirms the expected response actually occurred — a run command is not the same as a confirmed run. Permissives, interlocks, alternation expectations, and reset authority should be recorded as open project questions rather than assumed defaults, since a duplex arrangement common on one station is not automatically the right model for another. A permissive is a condition that must be satisfied before an action may proceed; an interlock blocks or stops an action under the approved design. Bypass authority — who may override normal sequencing and under what conditions — belongs in this same set of open questions. When a duty pump becomes unavailable partway through a cycle, the sequence needs a defined answer for what happens next — that fallback behavior requires qualified review, not an implicit assumption.
A short sequence question box helps the project team resolve this together:
What confirms a pump has actually started, not just that a command was issued?
What determines lead/lag assignment, and who can override it?
What happens if the intended next pump in sequence is unavailable?
Which resets require operator action, and which may occur automatically?
Which of these decisions sit with the local controller, and which sit with an operator or remote system?
Manual and maintenance states call for the same discipline. The project should identify who is authorized to assume manual control, which automatic functions are suspended while that control is active, what indication shows the station is in that state, and who has authority to confirm restoration to normal operation.
Documenting the questions is itself progress. Answering them with specific values belongs to the engineering and technical review stage.
Turn Instruments and I/O Into Testable Requirements
Requirements become testable when each instrument is tied to the condition it measures, not just the device itself. "A level transmitter" is not a requirement; "confirmation that wet-well level is within the expected operating band" is closer to one.
I/O, in this context, covers both inputs that convey measurements or statuses and outputs that issue commands or signals. For each required measurement, record — at a conceptual level, not as a finished specification — the signal or interface type, expected range, resolution needs, how a failure state is indicated, power and isolation questions, and any relevant environmental considerations. On the output side, the same discipline applies: which equipment receives the command, what mode authorizes it, what confirms the command was carried out, and what the controller should do if the command path or feedback signal is unavailable. It also helps to separate categories of information early: a status, a command, a measured value, an alarm, and a diagnostic signal are not interchangeable, even when they arrive through the same device. For example, a level signal that becomes unavailable or reports an implausible value needs to be recognized as a signal fault rather than mistaken for an actual level condition; resolving that distinction is a project-specific question for the engineer of record. Each requirement should state whether it needs to be visible locally, remotely, or both, and every observation should connect back to an acceptance criterion.
OmniSite's Station Utilization Score page lists examples of level, pump-current, runtime, digital-input, and output-related data available in certain products. That availability does not mean every listed data point belongs in local control logic; availability and approved control use are separate questions the project team still has to resolve.
Specify Configurability, Expansion, and Documentation
Vague language is one of the most common ways a requirement fails during commissioning. Words like "adjustable," "adequate," and "future-ready" describe an intention without defining anything a reviewer can check.
Identify which values, delays, priorities, and notification assignments may need authorized adjustment after commissioning, and treat access control, change documentation, and responsibility as open review questions rather than settled defaults. Expansion needs are easier to plan for when expressed as reserved I/O, physical space, processing capacity, communications capacity, and documentation and testing criteria — only where the project actually supports that scope. For example, if a second pump or level instrument is discussed during planning but not yet funded, the expansion requirement should describe the reserved I/O, panel space, and documentation needed to add it later, not a spare-capacity percentage or hardware model chosen without project justification. Define which documents the project expects as deliverables: a sequence narrative, an I/O schedule, an alarm list, a parameter list, a responsibility boundary, and a traceability record, where each applies.
A short replace-vague-words box keeps this concrete:
Replace "adjustable" with the specific parameter, its authorized range, who may change it, and how the change is verified.
Replace "adequate" with the specific capacity, count, or performance value the project requires.
Replace "future-ready" with the reserved I/O, space, or capacity actually planned, and the criterion that will confirm it is available when needed.
Review the Requirements Before Comparing Equipment
Before the project moves into equipment or panel comparison, it helps to run the completed package through a short check:
Does every material risk map to an observation and a requirement?
Are controller and monitoring responsibilities clearly separated?
Does each requirement have an owner and an acceptance method?
Are unresolved setpoints, sequences, compatibility questions, and regulatory matters flagged for engineering review?
Are the requirements written independently of any particular product?
Have operations, engineering, maintenance, and integration stakeholders all reviewed the package?
Different reviewers check different things: utility leadership typically confirms scope and ownership, engineering and electrical/control specialists check sequence and safety-related content, and procurement often verifies that the package stays product-independent. If any answer is uncertain, that gap is worth resolving before a vendor conversation begins.
Complete the risk-to-requirement matrix with operations, engineering, maintenance, and integration stakeholders before comparing controllers, panels, or monitoring solutions.
Frequently Asked Questions
What information should be collected before writing lift station controller requirements?Â
Start with station conditions, pump duty arrangements, known measurements and statuses, abnormal and maintenance states, responsibility boundaries between local and remote systems, and whatever documentation already exists. Confirming this in the field, rather than relying only on older drawings, gives the requirements a reliable starting point.
Is remote monitoring the same as lift station control?Â
No. Monitoring, notification, history, and reporting are distinct from local control, even when one platform provides several of these functions. Documenting which responsibilities sit with the local controller versus remote systems prevents a requirement from being assigned to the wrong place.
Should a controller specification include exact alarm setpoints and pump sequences?
The project's documents ultimately need to resolve specific settings and sequences, but those values are site-specific engineering and safety decisions. They require qualified technical review rather than a universal recommendation.
How can teams make controller requirements testable?Â
Link each requirement to an observable condition, the expected controller function or response, the responsible system, a documentation source, and an acceptance method. A requirement without a way to verify it is difficult to accept during commissioning.
Conclusion
A comparison between controllers, panels, or monitoring platforms is only as useful as the requirements that go into it. The traceability sequence — condition, observation, response, alarm and documentation, and acceptance criterion — gives a project team a way to check that every material station risk has a corresponding, testable requirement before that comparison starts. Projects like this one sit within the municipal wastewater context served by OmniSite's monitoring applications, but that context doesn't substitute for the review above: site-specific decisions still need qualified engineering and jurisdictional review, and the matrix is a disciplined starting point for that review, not a replacement for it.
Before evaluating specific vendors or platforms, ensure all key stakeholders have aligned on these baseline requirements.
A qualified wastewater-controls or electrical/control-system professional familiar with the station and applicable jurisdiction should review the final package and this disclaimer before it is relied upon.
Disclaimer: This article provides general educational guidance for developing lift station controller requirements. Actual control sequences, setpoints, alarms, electrical design, safety provisions, and regulatory obligations must be determined and reviewed by qualified professionals for the specific site and jurisdiction.
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.