Factory SCADA General Design Principles

INDUSTRY TRENDS

Creating your own SCADA System Standards

In a world where standards and guidelines are becoming increasingly accepted and valued, it is surprising to observe that in many instances the implementation of SCADA (Supervisory Control and Data Acquisition) systems and HMI (Human Machine Interface) systems is still carried out in a piecemeal fashion. Little or no time is spent planning standards for such systems in companies that would otherwise very closely specify MIS or hardware based Engineering projects.

Perhaps the reason for this is that SCADA systems are usually not controlled directly either by corporate MIS or Engineering departments. Often, it is left to time pressured production personnel to select and implement a system as best they can with the limited time resources they have available. This can result in a mixture of SCADA packages and varying levels of sophistication in the Operator Interfaces generated over time.

A more sane approach is the production of a SCADA / HMI General Design Principles standard to guide and unify implementation efforts. This article describes some of the issues that should be addressed by this standard.

What are General Design Principles?

In broad terms, the General Design Principles (GDP) document defines aspects of the SCADA system that represent the style (or 'look and feel') to an operator and external interfaces. The GDP should be a living document, modified in the light of experience of what does and doesn't work.

A GDP may be written for implementation using a specific SCADA software package if site or corporate standards apply. Alternatively, it may be written to enforce a core of functionality that must be implemented by all SCADA systems and to define the Operator Interface so that operators trained on one SCADA system will be able to transfer to another with minimal adjustment.

The GDP is also a contract between the SCADA and PLC programmers, making each aware of the requirements of the other. This avoids misunderstandings that can often delay and frustrate a project. Ideally, the GDP should be produced before the first SCADA system is implemented. However, benefits can still be gained if a GDP is produced after incompatible systems have been installed. Over time, as each of these is modified during normal maintenance, it can be brought more into line with the GDP specifications.

Defining an Operator Interface

The Operator Interface is the most visible component of a SCADA system. Designing a good, consistent interface provides dividends in operator training and plant operation.

Part of the scope of the GDP is to specify screen templates and design guidelines that will enable the implementation team to create screens that have the same style.

Special purpose external applications interfacing to the SCADA system often have to be created. If these interact with the operator they are subject to the same rules as SCADA screens, making the use of such applications transparent to an operator.

Navigating the system enables the operator to get from one display to another. Navigation techniques include very structured menu hierarchies at one end of the spectrum to totally unstructured 'spaghetti' menus at the other. Most systems implemented will be somewhere in the middle. The GDP describes the navigation model selected and how and when this should be implemented.

Specifying the Operating Environment

One of the primary functions of the GDP is to specify the operating environment for the SCADA system.

This includes items such as:

the minimum level of computer hardware
the display technology that may be employed and minimum display resolution
acceptable touch-screen technologies
manual data input hardware such as keyboard, mouse, or touch-screen
the Operating System
network topology and networking software
methods of implementing external interfaces to other components of the wider company system

Most of the issues involved at this level of the GDP may have already been specified as company standards by the MIS department.

Device Models

Plant and equipment is generally built up of standard components such as motors and valves that operate in standardised ways and have standardised status values. These are identified in the GDP so that models for these can be created.

These models provide a consistent interface to each piece of equipment. Each model can be later implemented using 'Wizard' or other similar technologies offered by the SCADA system vendor. Once these models are created they can be reused any number of times on different SCADA projects.

A further benefit of consistent device models is that PLC programming is forced into consistent, documented interfaces. This is becoming increasingly important as the SP88 standard becomes established and compliant batching software systems become more available.

The list of standard devices in the GDP will obviously grow over time and, if well maintained, will form a comprehensive catalogue of the interfaces available from the plant.

Conventions

The GDP should also define a number of conventions to be used. These are more mundane, but nevertheless important, items.

One such item is a standard colour scheme. Imagine the confusion if, in one part of the plant a motor device coloured red means 'stopped' while in another part the same type of motor coloured red means 'dangerous condition'. This may seem a recipe for disaster, but a piecemeal approach to SCADA implementation has resulted in such anomalies.

Naming conventions should also be prominent in a GDP document. Adopting a standardised, consistent naming convention for devices controlled by the system, real time data tags, graphics screens and all disk file based components of the SCADA system goes a long way to constructing a scalable and maintainable system. In some cases, the naming conventions used will be imposed on the system by some external influence; they should be properly documented and codified in the GDP.

Conclusion

There are a large number of benefits to be gained by producing a GDP, ranging from reduced planning and implementation times to lowered operator training costs.

With its ability to specify requirements from the MIS, Production and Engineering departments, the GDP is an invaluable tool in the planning and implementation of SCADA / HMI systems.