GLX Connect — Engineering a Water & Wastewater Control Product Family

Role: PLC & HMI Development across the product line

Employer: GLX Technologies

Sector: Municipal water / wastewater, Texas

Platform: Siemens S7-1214 · Weintek HMI · Cradlepoint · OPC UA / MQTT Sparkplug B

The problem

GLX builds automation panels for groundwater and wastewater treatment plants for utilities across Texas. The software these plants ran was largely common — the same core logic for pumps, levels, alarms, and control sequences showed up at site after site, on the order of 80% shared. What genuinely varied was the hardware: different pump counts, instruments, chemical systems, and I/O from one site to the next.

The problem wasn't that the code was different. It was that the same code lived as a separate file per site. Because each site was its own copy, the shared 80% wasn't actually shared — it was duplicated. So a fix or an improvement that should have been made once had to be repeated across every site file by hand, and the copies drifted out of sync over time. The common logic behaved slightly differently from site to site not by design, but because no single version was the source of truth.

The goal was to stop treating each site as a fresh build and instead have a product — a proven system, maintained once, ready to deploy on demand and adapted to each site's hardware.

The solution: a product, not a per-site build

The answer was to turn that common software into an actual product line — HydroTrack and HydroControl — maintained as one thing and deployed on demand, rather than rebuilt and re-copied for every job. When a utility needs a system, it isn't a fresh project; it's a proven product configured to that site.

The mechanism that makes this work — and that cures the drift problem — is a shared function-block library. Every device type (pump, analog input, digital input, chemical dosing, generator, transfer switch) is a self-contained block, authored and tested once. The common 80% of the logic lives in that library, so a fix or improvement is made in one place and every deployment inherits it — no more chasing the same change across separate site files. The HMI follows the same principle through templates: a faceplate is designed once and reused by binding it to different tags.

What varies per site is the remaining layer that should vary: which blocks are instanced, how many, and how much I/O the panel carries to match the site's hardware. The product stays common; the configuration meets the site.

Field data reaches the PLC two ways: most instruments are hardwired as 4-20 mA analog or discrete digital I/O, but where a device speaks a serial protocol the PLC reads it over Modbus RTU instead — flow meters (rate and total), chlorine analyzers, and generator controllers (run status, faults, fuel level, and electrical values). Handling both paths behind the same block structure keeps the higher-level logic identical regardless of how a given signal physically arrives.

The product line is organized on two axes — capability tier (monitor only vs. monitor + control) and process domain (groundwater, wastewater, and light field applications).

The monitor tier reads a plant without commanding it: HydroTrack GW (46 DI / 18 AI) for groundwater, HydroTrack WW (62 DI / 26 AI) for the larger wastewater process, and SmartView, the smallest node (8 DI / 6 AI), for a single remote asset such as a well, a valve station, or a lift station. The control tier adds the outputs that turn supervision into command: HydroControl GW (62 DI / 18 DO, 18 AI / 8 AO) brings closed-loop control to groundwater, and LiftControl (30 DI / 10 DO, 2 AI) is the wastewater control pattern scaled down to one job — a lift station with up to four pumps, run-time and rotation tracking, and fault handling.

The spec deltas tell the whole story. Moving from HydroTrack GW to HydroControl GW is simply the addition of output instances — 18 digital and 8 analog outputs — turning read-only supervision into closed-loop control from the same block library. SmartView is that same architecture reduced to its smallest footprint; LiftControl is the control pattern reduced to a single station. Same product, instanced up or down to fit the job.

Every product runs the same technology stack — a Siemens S7-1214 per panel, a Weintek HMI, and a Cradlepoint router for LTE/Wi-Fi backhaul — in a NEMA 4 enclosure with UPS backup.

Connectivity by design: no vendor lock-in

Connectivity was a first-class design goal, not an afterthought. GLX's own offering, GLX Connect, is SCADA-as-a-Service — a cloud-hosted platform built on Ignition, with the panels publishing to it over MQTT Sparkplug B.

But the deliberate decision was not to force clients into that platform. A utility that already runs its own SCADA is not asked to replace it. Every panel exposes its data over open, standard protocols — OPC UA, Siemens S7 and S7 Plus, and Modbus TCP — so it drops into whatever the client already operates. Clients who want a managed cloud solution get GLX Connect over Sparkplug B; clients with existing infrastructure keep it and integrate over open protocols. The product meets the customer where they are instead of locking them in.

My role

I develop the PLC and HMI layer for this product family — completing the earlier monitor-tier products, then extending that same base into the control tier.

On the PLC side, I built the logic around the reusable function-block approach — encapsulating each device type into a block that could be instanced across products and domains, so a pump behaves identically whether it sits in a groundwater booster set or a wastewater lift station.

On the HMI side, I took over Weintek interfaces for the monitor-tier products (HydroTrack GW/WW) that had been started by others and carried them to completion through a period of team transitions. The control tier then reused that base directly: HydroControl shares the HydroTrack screens and adds the control views on top — pump rotation setpoints, output commands, and the interaction needed to run the process rather than just watch it. The result is the same operator experience across monitor and control, with alarm handling and local alarm history that let a plant run with or without an upstream SCADA connection.

The work was done alongside other engineers responsible for drawings, documentation, and project delivery; my scope was the control and interface layer that makes each product actually run.

A managed development process

This was not ad-hoc panel programming. The product line was built under a structured process that runs from concept to live operation:

• MVP — the scope and requirements for each product, defined up front before any build began.

• Design — the design artifacts produced and agreed: system architecture, PLC call structure, the function-block list, HMI overview mockups, screen layout, and navigation. The design is then locked as the baseline for the build.

• Development — the artifacts get built. Because building surfaces things the design didn't anticipate, corrections feed back into the design in a controlled way rather than ad-hoc, verified through staged reviews at 30%, 60%, 90%, and 100% completion.

• Testing — automated validation with my PLC Unit Test Platform, run in stages: first HMI-to-PLC functionality, then integration against a third-party SCADA (VTScada over OPC UA), then against GLX Connect (over MQTT Sparkplug B). Each connectivity path is verified independently, so the same data reads correctly no matter how a client consumes it. Failures loop back into development.

• Production release — panel-shop acceptance, then download to the field, where work reduces to verifying the hardware.

• Monitoring — the system runs live, and client feedback feeds the next iteration.

The key idea is that the design is a locked baseline, not a frozen one: changes after lock-in are expected, but they go through the review gates instead of happening informally. That is the difference between disciplined iteration and scope drift.

Validated before it ships: closing the loop with automated testing

The staged testing above was thorough, but it exposed a real cost: much of it was slow, repetitive manual work. Every logic change meant re-forcing values, re-checking alarms, re-verifying the HMI, and then repeating all of it after the next change — across multiple protocols. On a product line that gets revised and re-deployed across many sites, that manual burden compounds fast.

That pain is what led me to build the PLC Unit Test Platform. The idea came directly out of this project: remove the repetitive testing, validate existing logic quickly after any change, and immediately see whether a change broke something that was already working.

The platform injects simulated values into PLC tags, reads back alarms, status bits, and calculated values, compares them against expected behavior, and documents every step in a PDF/Excel report. Because the panels expose the same data over several open protocols, it can also check that a value reads identically through each path — the same cross-protocol consistency the open-connectivity design depends on.

It is worth being precise about what this does and doesn't do. The platform targets the repetitive, rule-based checks — alarm thresholds, interlocks, scaling, calculated values — the kind of verification that is tedious to do by hand and easy to get wrong when repeated across many tags and many sites. Manual testing is still part of the process: commissioning, hardware verification in the panel, HMI look-and-feel, and the judgment calls that need a person stay manual. The goal was never to remove manual testing, but to take the mechanical, repeatable portion off the engineer's plate so the manual effort can focus where it actually adds value.

This supports the broader workflow — do the heavy, repeatable verification in the shop so field time is spent on hardware and commissioning rather than re-checking logic from scratch. Automated regression tests mean a logic change can be re-verified against saved tests before deployment, catching regressions early instead of discovering them on site — and because it's one maintained product, that verified change carries to every deployment instead of being re-checked copy by copy.

The result

• A ready-to-deploy product line — HydroTrack and HydroControl, spanning two process domains and two capability tiers — so a utility's system is a proven product configured to its site, not a fresh per-site build.

• One maintained product, no more drift — the common logic lives in a shared function-block library and templated HMI, so a change is made once and every deployment inherits it, instead of being chased across separate site files.

• Adapts to each site's hardware — the same product is instanced and scaled to match each site's pumps, instruments, and I/O.

• Deployed on real groundwater and wastewater sites in Texas, running live utility water infrastructure.

• Delivered under a managed process — MVP, locked design, staged 30/60/90/100% reviews, layered automated and manual testing, release, and monitoring.

• Commissioning risk reduced — repetitive logic verification is automated and done in the panel shop, so field commissioning and manual testing focus on hardware and site-specific checks.

• Open connectivity, no vendor lock-in — a consistent platform (S7-1214 / Weintek / Cradlepoint) exposed over OPC UA, S7 / S7 Plus, Modbus TCP, and MQTT Sparkplug B, integrating with either a client's existing SCADA or GLX's cloud SCADA service.

• Spun off a reusable engineering tool — the repetitive validation work on this project became the basis for my PLC Unit Test Platform.

Skills demonstrated

Siemens S7 (TIA Portal, S7-1214) · Weintek HMI development · templated HMI / faceplate design · reusable function-block / library architecture · PLC-SCADA integration · OPC UA · Siemens S7 / S7 Plus · Modbus TCP · MQTT Sparkplug B · Ignition · VTScada · automated PLC validation & regression testing · managed development process (MVP → locked design → staged reviews → testing → release → monitoring) · end-to-end delivery (PLC → HMI → SCADA → field) · productization of control software / product-line engineering

Product family and specifications published by GLX Technologies at glxwater.com/glx-connect.