Can Ignition Replace Utility SCADA for 50,000 Customers?

Operators still see the existing SCADA screen while the utility weighs a move to Ignition; for a distribution system serving about 50,000 customers, the decision hinges on utility functions, data paths, and staff capacity—not screen count alone.

What must operators still be able to do?

Define the operator tasks before rebuilding graphics. A single remote-access screen and no deployed substation HMIs can reduce the number of displays to recreate, but the screen still depends on the points, communications, alarms, controls, and integrations behind it. A small screen count is not proof that the system scope is small.

Inventory the current operator workflow, including the functions operators use and any behavior they expect to match the existing system. Migration effort varies with both the number of screens and the quality and complexity of the existing application. Where operators are particular about established functionality, recreating it can consume more time than making a visually similar screen.

Have operators and engineering approve a task-and-point inventory before choosing what to migrate. The check is a signed list of required operator actions and the systems that supply their data.

Which utility functions must the platform support?

Translate utility requirements into interfaces before comparing platforms. Distribution SCADA may need more than process-style screens: planning should account for AMI, GIS, OMS, and growth such as advanced distribution management functions. Candidate platforms mentioned for distribution SCADA include Schneider Electric, OSI (AspenTech), and Survalent; selection depends on the utility’s business case, complexity, available skills, support needs, and cost. Treat these as candidates to evaluate, not as a substitute for requirements review.

Build a capability matrix and distinguish native support from an integration that depends on a gateway, converter, or custom work. Protocols and functions raised for evaluation include ICCP (TASE), DNP3, Modbus, IEC 61850, IEC 104, OMS, and FLISR. Confirm the required direction of data exchange, point types, control needs, and ownership of each interface with the platform supplier or integrator. A protocol name in a product brochure does not establish that the required utility workflow is covered.

The check before detailed development is an approved capability matrix with an owner and acceptance test for every required interface.

Can the new system be developed beside the existing SCADA?

Parallel development lets the team explore Ignition without making the production system the first test environment. Build a representative test project, confirm connectivity and screen behavior, and compare the results with the existing application before planning a cutover. A trial environment can help evaluate development effort; check its current licensing and runtime limits before using it for any operational purpose.

Parallel operation needs an explicit boundary. If both systems can write to the same field devices, define which system is authorized to issue commands during each test and who controls that authority. Avoid uncontrolled duplicate commands. Test read paths, operator actions, alarms, and failure behavior in a controlled environment; do not use a display that merely looks correct as evidence that control works.

1. Record the existing system’s source of truth and command authority.
2. Develop a test project using representative points, screens, and integrations.
3. Compare displayed values and command results against the legacy system and field behavior.
4. Document discrepancies and resolve them before approving a cutover plan.

Proceed when the test demonstrates correct values and authorized command behavior without creating conflicting control paths.

How should tags connect the operator screen to field data?

Plan the tag database before building screens. A useful hierarchy from the migration example is plant, cost center, line number, and parts of line; adapt the levels to the utility’s actual equipment and operating model. Consistent structure makes repeated equipment easier to address and prevents each screen from becoming a separate map of controller addresses.

Use reusable data structures for repeated equipment and reusable visual templates for repeated controls. The migration example uses UDTs and templates, including a toggle pushbutton whose text and colors respond to state. A template can expose properties such as button text, text color, and background color while binding its state display to tags such as control_state and actual_state through OPC. Define those tag relationships deliberately; do not assume an attractive button proves the command path is correct.

When an operator sees a blank, stale, or incorrect value, trace the path in order: screen property or binding, referenced tag, driver/device connection, then controller point. A tag fault and a binding fault are different problems. If the tag itself has no current value, inspect its device path and communications; if the tag is healthy but the screen is wrong, inspect the binding and formatting. For a command, trace in the reverse direction as well: operator action, bound command tag, driver write, controller response, and returned state.

Prove one representative repeated device end to end before cloning its UDT and template: change a controlled test state, confirm the expected tag changes, and verify that the correct text and color appear on screen.

What should the team build first, and where should an integrator help?

Make a small, representative slice rather than converting every display at once. Include a repeated device, a state indication, a command if required, an alarm or status change, and a real integration path. This exposes tag-structure and template mistakes early. If that slice works, reuse the pattern; if it does not, fix the shared structure before multiplying screens and bindings.

A single in-house engineer can develop the project, but the workload is substantial when migration competes with other duties or requires specialized scripting and integration. A hybrid approach can keep requirements, point mapping, and tag organization in-house while assigning difficult scripting, templates, or integration work to a qualified systems integrator. Ask for a site walkdown and a scoped estimate or FEED study when interfaces or legacy conditions are not well understood. That scope review is more useful than estimating from screen count alone.

Before expanding the build, have the operator or engineering owner accept the representative slice against the written requirements and record which work remains in-house versus contracted.

How do legacy signals and scaling change the migration?

Trace each point back to its actual source. A communications network recently converted to fiber still needs a defined protocol or signal path; fiber transport alone does not identify how a relay or controller communicates. Where control and communications are hardwired and relays are not directly addressable, document the wiring, intermediary equipment, and any required conversion. DNP3 or IEC 104 converters were raised as possible integration paths; select one only after confirming the actual endpoints, signal types, and required control functions.

Also identify where engineering scaling occurs. If the controller supplies raw values and the SCADA system scales them, configure and test that conversion once. If scaling already occurs upstream, a second conversion can produce incorrect operator values. Compare representative values at the controller source, tag, and display, using known engineering units and documented scaling rules.

Older controllers may not expose a structure that maps neatly to a unified tag model. One migration approach described for older PLC families is adding memory locations to match the desired structure. Treat that as a controller-specific design option, not a default migration step: first verify the installed hardware, program constraints, communications method, and change-control requirements. Do not alter a running controller merely to make the SCADA tag tree look uniform.

The check is a point-by-point trace for representative hardwired, converted, and scaled signals, with the source, conversion location, and displayed engineering value recorded.

What must pass before operators use the replacement?

Commission the full path, not just the screen. For every required point, verify that the field or controller value reaches the intended tag, that the screen binding displays the correct state, and that alarms and operator actions behave as specified. For commands, prove that the authorized action reaches the intended endpoint and that returned status confirms the result. Test communication loss and recovery so operators can distinguish a stale or unavailable value from a valid state.

Keep an acceptance record for points, alarms, commands, protocol interfaces, integrations, and operator workflows. Resolve mismatches before cutover; a successful test on one representative point does not validate every endpoint or function. Agree on the cutover authority, rollback decision, and responsible personnel before changing production use.

Final verification: have an authorized operator execute each accepted workflow in the approved test or commissioning window, confirm the displayed value and returned field/controller state, and record the result for every required interface before releasing the replacement for operational use.

Can Ignition handle a utility migration with one engineer?