Companies involved in energy or energy-related transmission and distribution are finding that the lifecycles of SCADA (supervisory control and data acquisition) systems are not as long as they once were, due to rapidly developing technologies and changing market requirements driven by ongoing deregulation, liberalization, and privatization of energy-related markets. As a result, it is more common to see requirements for integrating traditional SCADA functionality with external commercial and technical applications, such as network information systems, customer information systems, computerized maintenance management systems, and geographical information systems.

Control systems currently available from most large control system vendors offer advanced integration opportunities.

The basic building blocks required of a control system capable of integrating third-party applications include:

• Component-based, object-oriented system architecture;
• A SCADA server that can be changed without changing HMI;
• OPC connectivity; and
• Ability to re-use programming for third-party application integration in future projects.

SCADA systems facilitate operation of energy and energy-related networks; a growing industry trend is use of a multi-utility SCADA system (see graphic). Such a SCADA system must include utility-specific applications to empower operators and support engineers to access all process control information within an enterprise in real time and in a user-friendly manner to improve enterprise performance.

Utility-specific applications, such as leak detection, pipeline simulation, outage and leakage management, usually differ in software architecture, and are not difficult to integrate if they are component-based applications supporting integration technologies like CORBA, OPC, and OLE, and run on the same platforms as the SCADA system. However, integrating monolithic application suites of software with poorly defined application programming interfaces (APIs) is difficult and ill-advised due to the high costs of integration involved. Unfortunately, monolithic types of legacy applications are often used in energy and energy-related transmission and distribution systems.

(Learn more about CORBA at www.corba.org; OPC at www.opcfoundation.org; and OLE at http://support.microsoft.com)

Additional opportunities for extending integration possibilities are available if changes are made to the SCADA HMI. For example, it is possible to substitute existing SCADA HMI modules with the ones from the integration platform, like alarm and event lists, trend displays, and faceplates with those from third-party applications (such as process viewers or distance plots). As a result, components of a given SCADA system may be defined for each application, depending on customer requirements and future re-use opportunities. User management functionalities on the HMI level can be re-used from the integration platform.

In such an extended architecture (as shown in the 'SCADA system network configuration' graphic), the SCADA system core includes: real-time database (responsible for handling process variables related to data acquisition, control commands, alarm handling, and archiving); process connection module that interfaces controllers of I/O devices; processing module; and SCADA API. The process connection module can poll the controllers of I/O devices at a user-defined polling rate.

The server may reside on the same computer as the SCADA server software or on a separate computer. The client is usually the operator workstation.