The existing pump-monitoring platform can be replaced incrementally with an Ignition-based telemetry system, but the first deliverable should be a read-only prototype rather than a fleet-wide control system. Prove one complete data path: simulate or acquire one pump’s signals, convert them into engineering units, record them, display them, and recover cleanly from a communications interruption. Coding is only one part of the work; signal definition, calibration, timestamps, network boundaries, failure handling, and field verification determine whether the result is trustworthy.
Symptom Interpretation
The first symptom is an aging monitoring platform that still operates but cannot economically cover the remaining fleet. Only 4-6 units are currently outfitted, while one proposed replacement was approximately $30,000 per pump before any possible recurring charges. A second symptom is reliance on screen streaming when clients need remote telemetry. Screen streaming can present an operator display, but it does not create structured records, quality indicators, searchable history, or a controlled interface for downstream consumers.
| Observed condition | Likely engineering issue | Prototype response |
|---|---|---|
| A display shows values, but applications cannot consume them | The information exists only as pixels rather than structured tags | Acquire named process values at the data source and expose read-only records |
| Older units work, but expansion is costly | The current architecture is tied to proprietary hardware or software | Prove an open data path with documented interfaces before selecting fleet hardware |
| Simulated values look correct on a screen | The user interface has been tested, but the physical measurement chain has not | Add a staged test with one real controller or data-acquisition endpoint |
| Remote viewers lose data during a network outage | The design assumes continuous backhaul connectivity | Record locally, preserve timestamps and quality, then forward retained data after recovery |
| Pump rate disagrees with field observations | Scaling, calibration, units, or the rate calculation is wrong | Trace the value from sensor output through raw input, scaling, historian, and display |
The term here means telemetry: measurement, timestamping, storage, and presentation of operating data. It does not mean commanding pump starts, engine speed, shutdown bypasses, or pressure setpoints. Keeping the prototype read-only limits risk while the measurement architecture is being validated.
Telemetry Data-Path Mechanism
A defensible system preserves meaning through every layer. A pressure sensor or engine interface produces a signal; field input hardware converts that signal into a raw value; a PLC or other acquisition device assigns process meaning; Ignition reads the value; the historian stores the value with time and quality; and a visualization layer presents it to an authorized user.
Each recorded point needs a signal source, engineering unit, valid range, update behavior, quality state, and timestamp origin. Without that metadata, a plausible trend can still be wrong. For a linear analog measurement, the scaling relationship is:
Engineering value = EU minimum +
((Raw value - Raw minimum) / (Raw maximum - Raw minimum))
× (EU maximum - EU minimum)Read the raw and engineering endpoints from the instrument, input-module configuration, and calibration records. Do not substitute familiar ranges. If pump rate is calculated rather than directly measured, document every input to the calculation, including displacement information and any correction for operating conditions or slip. When those inputs are unavailable, display the measured source available from the existing equipment and label its unit rather than creating an inferred rate.
Simulation exercises tag changes, screen behavior, database writes, alarm logic, and communications-loss handling. It does not reproduce sensor wiring faults, grounding problems, input-module configuration, controller scan behavior, protocol-driver behavior, or engine-interface faults. Treat simulation as the first test layer, not as a PLC hardware acceptance test.
Prototype Scope and Acceptance Criteria
Choose one pump and a small set of consequential values: pumping rate, discharge pressure, and selected engine information already available from the equipment. Inventory the actual source of each value before building displays. The source list must state whether each point comes from an analog channel, discrete status, controller register, engine interface, or an existing communications endpoint. Signal types and protocol details must come from drawings, controller configuration, or direct measurement because they are not defined by the desired dashboard.
| Prototype layer | Required decision | Acceptance condition |
|---|---|---|
| Signal definition | Source, unit, range, and ownership of every value | Each displayed point traces to one documented source |
| Acquisition | Simulation first, then one real endpoint | Changes arrive with correct value and quality |
| Storage | Local test database, such as SQLite, or another selected historian target | Records retain value, timestamp, and quality through a controlled test |
| Visualization | Operator view versus client read-only view | Users see only the data and functions assigned to their role |
| Remote transport | Direct Ignition presentation or an MQTT path to another consumer | Remote access does not expose the controller network |
| Failure behavior | Response to endpoint, gateway, database, or backhaul loss | Bad or stale data is visibly different from current good data |
The acceptance test should measure data integrity rather than visual polish. A prototype is credible when an engineer can identify where a value originated, how it was scaled, when it was sampled, what happened during a failure, and whether stored history matches the source.
Incremental Build Procedure
Create an instrument and data-point register for the selected pump. For each point, record the physical quantity, source device, signal or protocol type, engineering unit, expected operating range, required display behavior, historical requirement, and whether the prototype may only read it.
Draw the data path from the field source through the PLC or acquisition endpoint, Ignition gateway, database, and client display. Mark every network boundary and every component that can assign or alter a timestamp.
Build simulated values in Ignition for the selected measurements. Exercise steady values, gradual ramps, abrupt changes, out-of-range conditions, frozen values, and unavailable quality. The simulation should mimic process behavior, not merely generate random numbers.
Apply scaling and units once at the defined ownership layer. Avoid applying one conversion in the PLC and a second undocumented conversion in the SCADA project. Display the raw value during commissioning so the conversion can be audited.
Configure history in the selected test database. Store quality with the measurement, and select a recording policy that captures meaningful process changes without pretending that repeated identical samples add information. Obtain the required recording interval from operational and client requirements rather than guessing it.
Build a minimal display containing current rate, current pressure, selected engine values, data quality, last update time, and historical trends. A viewer must be able to distinguish a valid zero from missing, stale, or bad data.
Interrupt the simulated device connection and database connection separately. Confirm that the display changes quality state, the last-good value is not presented as current data, and data recovery follows the chosen buffering policy.
Replace one simulated source with one real controller or acquisition endpoint. Compare raw input, controller value, Ignition value, stored record, and displayed value at the same stable operating condition.
Add MQTT only after the local acquisition and history path passes. Define who publishes, who owns topic structure, where authentication terminates, how retained or delayed messages are treated, and which timestamp survives transport.
Repeat the tested template for additional points and pumps. Keep pump-specific addressing, ranges, and calibration data separate from reusable display and history logic.
Numbered Verification Checks
Check 1: source identity. Expect every displayed measurement to map to one entry in the point register and one physical or simulated source. An unexplained duplicate, alias, or calculated value fails the check.
Check 2: end-to-end value. Apply a known source condition and expect the raw input, scaled value, Ignition value, stored value, and display to agree after accounting for the documented conversion.
Check 3: engineering units. Expect the label, trend axis, database metadata, and client presentation to use the same unit. A numerically plausible value with a mismatched unit fails acceptance.
Check 4: timestamp progression. Expect timestamps to advance from the designated source clock and remain ordered through storage and remote delivery. Identify clock ownership before diagnosing apparent latency.
Check 5: communications failure. Disconnect the acquisition endpoint and expect bad or unavailable quality rather than a silently frozen current value.
Check 6: database interruption. Stop the database path and expect a visible storage fault. After recovery, verify the chosen buffering behavior and check for gaps, duplicates, or reordered records.
Check 7: independent reference. Compare pressure and rate with a calibrated reference or the established measurement source. Expect agreement within the tolerances defined for the instruments and process; obtain those tolerances from calibration and equipment documentation.
Check 8: access boundary. Log in as a client viewer and expect read-only access to approved data. The account must not expose controller configuration, gateway administration, or control commands.
Production Transition Architecture
A desktop is suitable for learning and prototype hosting, including testing the separation between an Ignition gateway and an engineering workstation. It does not by itself establish production suitability. Before field deployment, select hardware by environmental rating, power behavior, storage endurance, serviceability, network interfaces, and the pump installation’s electrical conditions. Read those requirements from the site and equipment documentation.
Keep the control path local to the pump. Remote telemetry should not be required for the engine or pump to remain in a defined local state. Place remote client access outside the controller network and mediate data through an authenticated application or broker boundary. If MQTT is selected, it carries structured data between publishers and subscribers; it does not replace input protection, PLC logic, local shutdown functions, historical validation, or user authorization.
Define ownership before scaling. The hardware specialist should own field wiring, instrument compatibility, electrical drawings, input protection, and commissioning measurements. The SCADA developer should own tag modeling, history, visualization, quality handling, user access, and application tests. Controller and network changes need joint review because an error at either boundary can produce believable but incorrect telemetry.
Recurring Engineering Pitfalls
Treating a simulator as hardware proof: A simulated tag confirms application logic. It does not validate actual signals, wiring, isolation, calibration, or communications configuration.
Starting with the client portal: A polished remote page cannot repair an undocumented or incorrectly scaled source. Prove the local measurement chain first.
Using screen streaming as a data interface: Video can support observation, but it cannot supply structured history, per-point quality, or machine-readable telemetry.
Showing the last value as live: Preserve the last value for diagnosis, but pair it with quality and last-update time. A frozen pressure reading must not look current.
Adding multiple visualization stacks too early: Ignition, MQTT, a broker, and Grafana can serve different roles, but every added layer introduces authentication, timestamps, data mapping, and failure modes. Add a layer only when an acceptance requirement calls for it.
Allowing remote writes during prototype work: Keep the path read-only until control authority, permissives, shutdown behavior, cybersecurity, and change management have been engineered and tested separately.
Copying configurations across pumps without checking ranges: Similar pumps can use different sensors, scaling, addresses, or engine interfaces. Revalidate the point register for every deployed unit.
FAQ
How do I start an Ignition pump telemetry prototype?
Select one pump and a few values such as rate, pressure, and engine information. Simulate them first, then replace one simulated point with a real endpoint and trace it through acquisition, history, and display.
How do I simulate a PLC before buying hardware?
Use simulated Ignition values to exercise ramps, abrupt changes, invalid ranges, frozen data, and unavailable quality. Follow that test with one real controller or acquisition endpoint because simulation cannot validate wiring, input configuration, or protocol behavior.
How do I send Ignition pump data to remote clients?
Prove local acquisition and storage first, then provide a read-only application boundary or publish structured data through MQTT. Keep client connections outside the controller network and preserve value, timestamp, unit, and quality across the boundary.
How do I verify pump telemetry before deployment?
Apply a known source condition and compare the raw input, scaled controller value, Ignition value, stored record, and display. As the final verification step, interrupt communications and expect the client display to mark the value unavailable or bad instead of presenting the last reading as current.