How object-oriented SCADA enables scalable, replicable industrial control systems

For decades, traditional supervisory control and data acquisition (SCADA) systems based on flat tag structures have served their purpose. Yet, when facing complex, repetitive or large-scale projects, this architecture becomes a bottleneck—limiting efficiency, standardization, and scalability. Inspired by the principles of object-oriented programming (OOP), SCADA platforms now offer a more modular, intelligent and replicable approach. OOP concepts are being applied to SCADA design, and platforms from suppliers such as Aveva and Inductive Automation bring strategic advantages to the table.

Nature’s blueprint: a living analogy for OOP

There is no better analogy for object-oriented programming than stem cells in nature. A stem cell encapsulates all the genetic information necessary to replicate and generate specialized cells.

In programming terms, a stem cell functions as a base class—defining attributes, behaviors and functions—capable of creating instances, or cells, that not only inherit characteristics, but also adapt dynamically based on environmental stimuli. This is polymorphism. And since all genetic information remains encapsulated within the cell without exposing internal details, we see encapsulation in action.        

This paradigm translates clearly to industrial SCADA design, where platforms like Aveva System Platform allow engineers to model templates that encapsulate not only data structures and attributes, but also scripts, graphics, animations and alarm definitions.

When properly designed, these templates allow for the creation of multiple object instances during engineering time, each sharing core behaviors yet capable of dynamic variation using contextual tags or reference inputs. This is the power of the object context, or the "Me" reference, within templates.

2 fundamental requirements for scalable object-oriented SCADA

1. Comprehensive, flexible template design: The base object must include standardized graphics, reusable scripts, indirect addressing mechanisms, parameterized behaviors, conditional visibility and logic. This requires mastery of scripting capabilities, such as ArchestrA Script, Python, C#, and a strong data architecture vision.
2. Structured standardization at the programmable logic controller (PLC) level: Data blocks—user defined types (UDTs), add-on instructions (AOIs) or equivalents)—must follow similar object-oriented principles, encapsulating parameters, using consistent naming conventions and aligning semantically with SCADA objects. This enables automatic binding using naming and structure conventions, reducing manual work and minimizing human error.

When true integration is achieved between PLC-based control systems and SCADA supervisory systems under an object-oriented architecture, we gain not just engineering efficiency, but system robustness, maintainability, and the ability to scale and replicate across multiple plants without compromising control or traceability.

From tag-based to object-oriented SCADA

Let’s revisit what a SCADA system fundamentally is: an industrial computing system designed to monitor, control and acquire real-time data from field equipment such as sensors, actuators and PLCs. Its mission is to ensure safe, efficient and continuous operation of complex systems.

Typical SCADA components include:

• human-machine interface (HMI), which is a graphical representation of processes
• data acquisition server, which collects data from field devices
• historian, which stores data for analysis and traceability
• communications network, which links all system components, using Ethernet/IP, Modbus, OPC or other protocols
• PLC, which execute local process control logic
• core functions, such as real-time monitoring of process variables, including pressure, temperature, level and flow
• remote control of devices, such as valves, pumps or motors
• alarm and event generation
• historical logging and trend analysis
• integration with the manufacturing execution system (MES) or enterprise resource planning (ERP) software and industrial protocols.

In early SCADA systems, the architecture focused on direct tag mapping, which was practical for small installations. For instance, building the interface for a compact oil battery may only require three or four screens and a handful of tags created manually. But in large-scale projects, such as a natural gas liquid (NGL) plant, the "spaghetti" of surface connections becomes unmanageable.

Think of the evolution this way: in small projects, you’re manually connecting hoses. In larger ones, you build underground conduits with predefined connection points for present and future modules. Object-oriented SCADA follows the latter approach, laying a structured foundation first—templates/UDTs— which dramatically accelerates tag creation and interface development later.

Evolution toward object orientation

Before reaching object-oriented SCADA, platforms underwent significant transitions.

Tag-based SCADA, such as Wonderware InTouch, evolved into SuperTags—complex tag structures enabling more efficient licensing and improved UDT integration.

Indirect addressing revolutionized binding by allowing tag references via dynamic strings, enabling script-based creation and access of tag paths at runtime.

The quantum leap came with full OOP adoption: templates as encapsulated classes, with attribute areas for database/alarm integration, scripting engines for automation and graphical zones for visualization, selectable dynamically or manually.

Rockwell Automation’s PlantPAx architecture exemplifies this shift, now extended further through FactoryTalk Optix, which embraces a more refined object-oriented model, positioning it as a strong contender against Aveva and Inductive Automation’s Ignition.

Get your subscription to Control Design’s daily newsletter.

OOP principles in SCADA—key translations

Applied example—a motor object

A motor template might include:

• StartCmd (BOOL)
• RunningStatus (BOOL)
• SetpointSpeed (REAL)
• DisplayColor (STRING)
• IsRunning—an internal logic-driven attribute.

Instances such as Motor101, Motor102 share this logic but carry their own data.

Benefits include:

• reusability—instantiate templates infinitely without redundant work
• maintainability—template-level changes propagate to all objects
• scalability—ideal for fleets of similar equipment
• modularity—each object is a self-contained, testable unit
• time saving—templates accelerate configuration dramatically in large projects.

Platforms like Ignition, Aveva System Platform and FactoryTalk Optix fully support these principles, with OPC UA acting as a natural bridge due to its own object-oriented modeling of industrial nodes (Figure 1).

Present and future SCADA: modular, not more complex

More features don’t make SCADA better. Modern systems prioritize architecture over accumulated functions. That means modularity, replicability, maintainability and resilience.

Smart scaling through modularity allows:

• reusing logic and graphics without rewriting code
• centralizing control without duplicating it
• performing sweeping updates with minimal disruption.

A sustainable SCADA system:

• reduces technical debt and copy-paste errors
• requires less maintenance effort
• simplifies training via clear object hierarchies
• adapts to growth without architectural redesign.

This results in lower operational costs, better traceability and more robust systems.

Final thoughts: not more complex, just smarter

OOP, ISA-88/95/101 standards and technologies like OPC UA or MQTT don't complicate SCADA. They encapsulate complexity, providing clear, secure and structured interaction for end users.

Thinking in terms of object-oriented SCADA means adopting a paradigm with a certain level of abstraction and applying it practically in projects, following the same principles of object-oriented programming in the design of templates—remember our stem cell. The creation of a class, or template, must be done carefully by linking the I/O attributes developed in the SCADA to our generic AOI with Rockwell Automation, function block (FB) with CoDeSys and Siemens), or derived function block (DFB) with Schneider Electric. In other words, the attributes of the template must be mapped to their equivalent data points in the PLC.

A robust scripting strategy should also be developed to automate and semantically synchronize the instance names with the names of the UDTs in the PLC. When possible, graphical objects should be generated dynamically based on the signal type specified in the instance’s tag name.

If all this groundwork is well-executed, the project will accelerate by enabling faster instance creation with virtually zero errors, and this is the magic of applying the object-oriented paradigm in both SCADA and PLC environments. Standardization is the key to making all the pieces fit together seamlessly.

The SCADA of the future won’t be judged by how many tags or screens it handles, but by how effortlessly it scales, how well it adapts to change and how deeply it aligns with Industry 4.0.

It’s not about complexity. It’s about intelligent design.