Case Study: Modernizing Post Falls Water SCADA from Wonderware to Ignition Perspective

City of Post Falls Water Division

Our previous system had deteriorated to the point where our operators could no longer rely on the data displayed on screen. ASQI approached this project with a relentless commitment to data integrity and field verification. Rather than applying cosmetic updates over legacy deficiencies, their team worked directly alongside our staff in the field to trace complex serial communication issues and resolve root causes down to the controller level.

Today, our department operates with complete confidence in our SCADA infrastructure. We have dependable mobile control capabilities, verified alarm notifications, and accurate historical trending accessible from both the control room and field vehicles. Furthermore, ASQI engineered a scalable architecture that ensures our planned transitions to Allen-Bradley PLCs will remain streamlined and low-risk.

The transformation from where we started is remarkable. Based on their technical execution, responsiveness, and performance throughout this modernization, ASQI has earned our trust, and we look forward to partnering with them on future initiatives.

— Matt Isch, Chief Operator, City of Post Falls Water Division

Client: City of Post Falls Water Division, Idaho
Scope: Full SCADA replacement from legacy Wonderware to Ignition 8.3 Perspective
System: 14 sites: 10 wells, 2 reservoirs, 1 booster pump, 2 standpipes, 1 PRV station, and a master RTU
Timeline: December 2025 – July 2026
Role: ASQI, subcontracting to the prime integrator

Executive summary

In roughly seven months, the City of Post Falls Water Division went from an end-of-life Wonderware system to a modern Ignition Perspective SCADA running all of its water assets: working remote start/stop, voice alarm callouts, fast remote access, and automated, verified backups.

The delivery was defined less by screens than by verification: nearly every major breakthrough came from live field evidence, not from reverse engineering. That discipline surfaced a Modbus driver incompatibility, RUGID controller archaeology, a voice-callout configuration that only live SIP traces could untangle, and a network bottleneck hiding behind "the app is slow."

Delivered and live:

• All 14 sites reading real, field-verified data
• Remote start/stop and auto/manual control via a reliable command-word scheme
• Corrected, field-verified alarm maps, including the Allen-Bradley well
• Per-asset historical trend charts
• Voice alarm callouts with operator acknowledgment
• Fast, secure remote access for operators
• Automated gateway backups with verification
• A UDT and screen architecture built to absorb the division's multi-year migration of wells onto Allen-Bradley PLCs

The challenge

The division's Wonderware system had reached end of life, and the project inherited a buggy system that had lost operator trust.

The field sites had no source of truth. Most sites have RUGID programmable RTUs speaking Modbus RTU over a serial radio network, all polled by a central master and bridged onto the WW system via serial connection. One site upgraded to an Allen-Bradley PLC on direct EtherNet/IP.

The mandate: replace it with a system operators could trust, one where every number on the screen is traceable to a verified register, and every control action does what the button says for the old and new sites.

How it was delivered

Root-causing the serial layer

Tag reads were unreliable across the Modbus fleet, the kind of intermittent failure that usually gets waved off as "flaky radios."

Instead of guessing, we instrumented the path and found the true cause at the physical/protocol boundary: Ignition's Modbus driver and the serial radio network weren't framing cleanly through serial or serial-to-Ethernet. The RTU was flushing bytes to TCP in small chunks every few milliseconds, so the driver's inter-frame timing fired mid-response and discarded valid multi-register replies as broken packets.

The fix was engineered, not patched:

• NPort gateway transmit buffering tuned to deliver whole Modbus frames rather than byte dribbles
• An advanced Modbus driver configuration with relaxed inter-frame timing to tolerate the serial radio's real-world timing
• A buffer-tag architecture that stages each site's raw registers once and derives all instance values by reference

The comms layer has been solid since.

Making the numbers true

A side-by-side audit against the still-live legacy system exposed systematic scaling defects.

Totalizers wrapped negative from signed/unsigned mismatches, runtimes were off by orders of magnitude, setpoints came through unscaled. The root cause was uniform and fixable: missing scale configuration across the Modbus well tags. Every value class was corrected and re-verified against the field.

Just as important, the operators shaped the scope: displays that the legacy hardware couldn't support honestly were cut rather than shown wrong. A system that shows fewer, true numbers beats one that shows more, wrong ones.

Architecting for a multi-year AB transition

Well 4 is the division's one Allen-Bradley site today, but it won't be the last.

The City is on a multi-year path of upgrading wells from legacy RTUs to modern AB PLCs, one site at a time. Rather than treat Well 4 as a one-off, we architected the whole application to absorb that transition.

• The UDT inheritance structure (a common BaseAssetType with a WellType specialization and per-instance configuration flags) means a new AB well is a new instance, not a new system. Optional subsystems (VFD, aquifer, ventilation, generator, chlorine/disinfection) switch on per instance through configuration flags the templates already understand.
• The Perspective screens are template-driven off those same UDTs, so the detail view, alarm panel, and trend charts for the next AB well come up largely by wiring an instance, not by drawing new screens.
• OPC/driver differences between the Modbus and AB paths are isolated at the instance level, so the Allen-Bradley specifics live where they belong without forking the type.

The result is a system where the next well upgrade is an incremental, low-risk addition rather than a mini-project of its own.

Making remote control actually work

Commissioning surfaced the delivery's most consequential control finding: the RTUs rejected bit-level writes, so remote start/stop and auto/manual commands failed.

The answer was a command-word refactor built around one writable command word per site: whole-word read-modify-write using only the function codes the hardware provably supports, with all bit manipulation done on the SCADA side.

Root-causing latency

When mobile and remote access felt sluggish, the easy answer would have been to tune the Perspective application. A controlled same-LAN test showed zero latency, which pointed the investigation towards the network.

The site's cellular remote-access appliance (a Tosibox unit on a carrier-grade-NAT cellular uplink) was forced to relay every connection through a cloud relay rather than establish a direct tunnel, because neither endpoint was publicly reachable behind CGNAT. That relay overhead, not the application, was the bottleneck: small content moved fast, but chatty Perspective sessions took 30-60 seconds to load and log in.

To isolate it definitively, we ran the same Tosibox cellular link through an alternative WireGuard-based mesh VPN. Connection times dropped from 30-60 seconds to 2-3 seconds, proving the bottleneck was the relay path, not the cellular carrier, the ISP, or the SCADA application.

Putting the SCADA in the operator's pocket

Choosing Ignition Perspective was a deliberate bet on where water operators actually work: at the wellhead, in the truck, not chained to a control-room desk.

Perspective is web-native and responsive by design, so the same verified views the operator uses on the kiosk run in a phone or tablet browser with no separate mobile app to maintain. Some screens were better to bifurcate, but the parameterized templates are common for all clients.

• Responsive layouts adapt each view to the screen: the dense multi-panel asset detail on a desktop reflows to a stacked, touch-friendly layout on a phone, so an operator standing at a well can pull up that well's live data, trends, and alarms without pinch-zooming a shrunken desktop screen.
• Action from the field, not just monitoring. Because the command-word control scheme lives on the SCADA side, the same remote start/stop, auto/manual, and alarm-acknowledge actions are available from a phone, so an operator can respond to a callout and act on it from wherever they are.
• One security model everywhere. Role-based authentication (operator vs. administrator) travels with the view, so a phone session honors the same view/write permissions as the kiosk; mobile access doesn't mean a weaker security posture.

This is exactly why the network root-cause above mattered: responsive views are only useful if they load fast over cellular. Dynamic phone and tablet access becomes a practical daily tool rather than a demo, and the responsive foundation is in place to extend to every asset view as the division leans into mobile use.

Untangling voice callouts over cellular SIP

Reliable voice callouts proved to be one of the hardest problems of the delivery, because several independent failure modes were stacked on top of each other.

Only live SIP trace evidence could tell them apart. Over the investigation we isolated and addressed:

• A vendor voice-module license expiry that silently faulted the notification system ("delivery media system not available"), caught in the logs and cleared.
• A SIP socket/port binding fault, where the user agent wasn't releasing its port on profile restart (ADDRESS ALREADY IN USE: BIND), addressed by moving to a clean local SIP port and identifying the gateway restart as the real release.
• Android security measures blocked certain SIP ports: in the process of adjusting ports, we found that Android devices block certain ports before it even gets to the phone.
• Most callout options required a public endpoint for SIP to attach to the call provider. Callcentric was the option that kept the SCADA system secure, authenticating without public exposure.

Hardening for the long run

The final phase made the system survivable.

Scheduled gateway backups with verification, an offline mirror, and a documented recovery posture now stand behind the application.

On the alarm side, the hardened callout chain above is now permanent operating equipment: voice callouts with operator acknowledgment, staged escalation, timeouts tuned from live call evidence, and the daily self-test.

Key takeaways

• Live evidence beats reverse engineering. The Modbus communication and network root-causes were diagnosed by field testing, not by trusting the old system.
• Remote access to the live master was a force multiplier during field validation. With a technician at a well and the master's received values visible remotely at the same time, field readings could be cross-checked against what the master was actually relaying, turning multi-trip diagnostics into single-visit confirmations.
• Operator scope decisions keep deliveries converging. Cutting displays that couldn't be honest was as valuable as any feature added.
• Control writes deserve the same rigor as reads. The command-word scheme works because it uses only operations the hardware provably supports.
• Root-cause the layer that's actually failing. The "slow app" was the network relay; the "flaky comms" were serial framing. Fixing the right layer is permanent.
• Backups earn their keep before you need a restore. Verified, automated backups turned a vendor outage into a routine fix.

About ASQI

ASQI LLC specializes in industrial SCADA/HMI systems for critical infrastructure and manufacturing: architecture design, platform migrations (Wonderware, FactoryTalk, Ignition), alarm management, and operator training.

Next Steps

Interested in similar results for your operation?

• Project scoping and architecture design workshops
• On-site implementation support and guidance
• Post-launch troubleshooting and optimization

Contact ASQI →