Xylem
Modernising software that certifies every pump leaving the floor.
Every pump this manufacturer ships is tested before it leaves the facility. The results of each test are used to create the certificate sent to the customer.
The legacy pump testing platform controlled the test rigs, collected instrument readings and calculated the pump’s performance. Over time, it began producing incorrect and sometimes physically impossible results, while giving engineers little visibility into the causes. Designpluz was brought in to identify and fix the underlying issues, modernise the platform and make every test result traceable from the original reading to the final certificate.
Focus Area:
- Legacy software modernisation
- Industrial IoT and PLC integration
- Database migration and consolidation
- Manufacturing quality assurance
- Test automation and certification
Our Involvement
- Legacy code assessment and defect triage
- Business analysis and solution design
- .NET application modernisation
- Microsoft Access to SQL Server migration
- PLC and OPC UA integration
- Diagnostic logging and audit trails
- Calculation engine debugging and remediation
- Test data capture and calculation enhancements
- Reporting and certificate redesign
- UI and UX design
- Software testing and QA
- Ongoing support and maintenance
By the numbers
- 5 Microsoft Access databases consolidated into one SQL Server database
- 200+ PLC configuration parameters made traceable
- 800+ pump models and performance curves in the reference library
- 450 motor performance data points across 50 test and job motors
- 7 ISO 9906 acceptance grades applied automatically
The Challenge
The testing software controls the pump testing process. It sends a flow setpoint to the PLC, waits for the test rig to stabilise, reads measurements from a bank of transducers, and uses those readings to calculate the pump’s performance and generate its certificate.
If the software produces an incorrect result, the certificate is affected as well. The challenge was that the engineering team had little visibility into how a result had been produced, making it difficult to determine whether the issue came from an instrument reading, a PLC parameter, the data collected during the test or the calculation itself.
The client approached us with three key challenges that were affecting their operations.
They are:
01 : The results could not be trusted
Tests were producing results that were clearly inconsistent with what was happening on the test rig. For example, a borehole pump could be reported as producing a head in the thousands of metres, while the recorded power could be far outside the expected range. In other cases, the system recorded zero shaft speed even when the test had run. Some instrument channels also returned zero readings throughout the test, leaving the team without the data needed to verify the result.
Each test point passed through a long chain of inputs, processing and calculations before reaching the final result:
PLC setpoint → Rig stabilisation → Raw readings → Data averaging → Transducer scaling → Head & power calculations → Speed correction → Acceptance assessment → Final result
More than 200 PLC parameters also influenced how the rig behaved during the run.
The old software recorded almost none of this. When a result looked wrong, engineers could not easily determine whether the issue was caused by incorrect transducer scaling, a PLC setting, an unreliable reading or a problem in the calculation. Diagnosis meant putting pumps back on the rig and working through the possibilities by elimination. This was slow, tied up a test bench and often ended without a definite answer.
02 : Fragmented quality records
The second problem was that quality records were spread across five Microsoft Access databases, such as pump curves, motor performance, test history, rig configuration and operational logs. Keeping these records across separate databases made them harder to manage, control and protect. The databases had limited access control and could become unreliable when used concurrently. They could also be copied or edited by anyone with access to the relevant folder, while there was no practical recovery path if something went wrong. This meant records used to certify equipment that had already been shipped could be more exposed than the business had realised.
03 : A difficult-to-change platform
The third problem was that years of accumulated changes had made the application difficult to modify safely. The test engineers had improvements they wanted to make, but introducing changes to the existing application carried a level of risk that made those improvements difficult to justify.
The Solution
We made the system diagnosable before we changed anything else
Everything that followed depended on first understanding how a test produced its final result. We instrumented the process from the first instrument reading through to the certificate, recording the raw transducer values, PLC parameters, sample data, calculations, corrections and final reported value at each stage.
This created a complete audit trail for every test. Engineers can now trace any number on a certificate back through the test to understand where it came from and identify the step that caused an unexpected result. The same record also shows which PLC parameters were active and how the rig responded, turning configuration changes into an evidence-based process rather than guesswork.
It also changed how support issues are handled. Engineers can usually investigate an issue from the original test record without putting the pump back on the rig.
We fixed the calculation engine rather than replacing it
With the test process now traceable, we could isolate the problems within the existing calculation engine without replacing the logic that already contained years of pump-testing knowledge. The behaviour of a correct test remained unchanged, which was the objective. We corrected issues such as incorrect scaling, unread channels and calculation edge cases, then added validation to prevent invalid inputs from reaching the certificate.
We consolidated five Access databases onto SQL Server
Once the application was stable, we brought the five Access databases into a single SQL Server database. We reconciled the data models, consolidated duplicated reference data and made relationships that were previously implicit enforceable.
Test records now have controlled access, backup and recovery, and all test rigs work from a single source for reference curves and other test data.
We hardened the link to the plant floor
We strengthened communication between the application and test bench through OPC UA. The system now sends flow setpoints, monitors the rig as it reaches the required conditions and reads the full instrument bank, with connection monitoring to prevent either side from working from a stale connection.
Connection failures are clearly reported to operators and logged for diagnosis, while configuration-based tag mapping allows the test rig to be changed without requiring application code changes.
We extended the platform once it was stable
With the defects resolved and engineers confident in the results again, we worked with the test team to identify the next set of improvements. We added further test-point data and calculations, streamlined the test sequence and redesigned the reporting screens and certificate.
Operators can now review raw and speed-corrected results before issuing a certificate, while a complete data export is retained with each test so the result can be examined later without putting the pump back on the rig.
The Result
Production Deployment
The platform is now in production on the client’s test rigs. The defect backlog that prompted the engagement is closed, impossible readings are caught during data collection instead of appearing on a certificate, and the original pump-testing logic in the calculation engine remains intact and produces results the engineers can rely on.
Better Diagnosis
The biggest change is how issues are diagnosed. Problems that once required pumps to be re-tested and investigated by elimination can now be traced using the record of the original test. When a result is questioned, engineers can see how it was produced and identify where an issue occurred. For a system that produces certificates for equipment leaving the business, having that level of traceability is critical.
Configuration-Driven
The platform is also now driven by configuration rather than hard-coded assumptions. This means additional test rigs and instrument configurations can be introduced without rebuilding the application. Designpluz continues to support and extend the platform as the client’s testing requirements evolve.
Project Team
Technologies Stack
Application
Industrial integration
Database
Diagnostics
Reporting
Quality,
Traceability and
Data security
- Every calculated value can be traced back through each stage to the raw reading it came from.
- Validation is performed during data acquisition to catch impossible readings before they reach the certificate.
- ISO 9906 tolerance assessment is automated, reducing manual interpretation of acceptance grades.
- All test records are protected through authentication, role-based access and point-in-time recovery.
- Reviewer sign-off is required before a test result can be released.
- A complete data export is retained alongside every certificate for future reference.
- Communication failures with the test rig are clearly reported to the operator and recorded for diagnosis.
Key Project
Considerations
