Why functional specification is essential for success of a SCADA project

SCADA system requirements

Well documenting the SCADA system requirements is probably the single most significant contributor to the success of a SCADA project. It may seem obvious but let’s say it anyway: writing the Functional Specification must occur BEFORE design work on a SCADA system begins.

The biggest cost and schedule killer on a project is having to rework part or all of a design. This is because every phase of a project is built on the foundation of data and work performed in a preceding phase.

If some equipment function or I/O point or signal format is missed or omitted, the work of adding or correcting it later in the project can have a seriously negative impact.

Functional Specification of SCADA project

The best known medium for building an understanding of the system requirements comes in the form of a Functional Specification. The document carefully lays out, in a structured fashion, how the process operates and how the SCADA system will interact with that process.

It seems that there is no established standard for a Functional Specification. But, it’s ok to believe that any definition of the functionality of a system should be done with a “top-down” approach, i.e., work on the over-arching functions, tasks and communications first and then work down to more specific tasks and functions.

Regardless of the format, the functional spec should contain the following elements:

1. Describe the process
2. Describe the physical layout of the process
3. Assess the SCADA system’s “mission criticality”
4. Describe how information will flow through the system
5. Define a Security Strategy
6. Document an Alarm Strategy
7. Define System Testing and Acceptance Criteria

1. Describe the process

Include material inputs, outputs, processing steps, cycle times, periods of operation, a complete detailing of normal operating conditions as well as any abnormal conditions that could exist during routine operations.

The need for more sophisticated control loops like cascade or feed-forward or the need to interface to variable frequency drives should be identified up front. Special needs for placing these loops into or out of automatic or manual control should also be documented.

Go back to contents ↑

2. Describe the physical layout of the process

Include any documentation, drawings, sketches, etc, that provides a feel for where the processes and related equipment are located relative to each other and to the intended Operator Monitoring/Control Stations.

Include any known or suspected restrictive conditions that may exist within the parameters of the project. Shortage of adequate electrical power, or extreme heat or humidity conditions, or the involvement of classified hazardous areas should all be brought up at the beginning of the project rather than sometime after things have gotten underway.

Go back to contents ↑

3. Assess the SCADA system’s “mission criticality”

What might be the consequences if a failure in the SCADA system results in the process going out of control? Minor inconvenience or out-and-out catastrophe? What if data or communications are lost? Is it simply an operational or procedural nuisance or will public safety be compromised?

It results in a ranking of the different failures that can occur.

Failure Mode Effect Analysis (FMEA)

This type of assessment will drive decisions regarding the hardware platform that will be selected and the need for redundancy in processors, networks, and data storage devices.

Extremely critical processes, ones that, if not operating correctly, can cause injury or significant damage to equipment or property should be identified as such as this will drive decisions in selecting hardware that can make a real difference in cost.

Providing redundancy in CPUs or I/O or comm links can all be accomplished but at a considerable cost.

Go back to contents ↑

4. Describe how information will flow through the system

• Begin at the beginning with Operator Inputs and Record-Keeping, records that operators currently keep on paper forms that they create or are supplied with, entries made in log books, etc.;
• Information that is available through existing process instrumentation, circular or strip chart recordings that are made;
• Information that will be available through linkages with other information systems, databases, existing SCADA systems, etc.;
• Information that will flow into the system through the SCADA I/O, temperatures, pressures, flows, etc.;
• and finish up with what the destination of the SCADA information is intended to be.

Included in this section should be a listing of the I/O points that will be configured in the system, the range of engineering units for these points, a desired frequency of update for each point.

Go back to contents ↑

5. Define a Security Strategy

Typically, at least 2 user levels are implemented in a SCADA system. The first level is for average users and generally permits access to all operational screens and permits modification of process setpoints as necessary for smooth operation of the plant.

The second level is usually given a higher level of access, access to configuration screens and permission to modify alarm points and data collection frequencies.

Go back to contents ↑

6. Document an Alarm Strategy

First, define the points in the system that will need to be alarmed. Next, determine if you wish to have different levels of severity for the different alarms that will exist in the system. Sustained deviations between a setpoint and a process variable for a non-critical process parameter will generally result in a simple deviation alarm and simple operator notification is the appropriate response.

The same type of deviation on a more critical process value might coupled with process interlocks or operator corrective action guidelines therefore this level of alarming should be treated differently within the system.

Alarms that will be coupled to emergency shutdowns of process equipment should receive yet a higher priority within the system.

Also have a strategy in mind for how alarms will be logged, acknowledged and cleared out of the system. This will probably be different for the different types of alarms. It is commonplace for a log file to be built, (and perhaps printed out in hard copy), that documents every action and event that occurs within the SCADA system including alarms.

Alarms that are operator notifications can often be self-clearing, i.e. when the deviation goes away, so does the alarm. Higher priority alarms ought to be latched in so that an operator acknowledgement will quiet the klaxon but as long as the alarm condition exists, the alarm cannot be fully cleared.

The motives and goals of these different groups are quite different, so there will be much negotiation before the final list and strategy is approved.

Process engineers generally want more alarming than is practical resulting in the occurrence of many nuisance alarms. These are bothersome to the operators and quite often are jumpered out or overridden shortly after they are implemented. It is far better to install a reduced set of alarms that are meaningful and useful to the operators.

Maintenance people generally prefer alarms that can act as predictors of equipment malfunction rather than process deviations so they will have some alarms in mind that might be overlooked by the first two groups.

Go back to contents ↑

7. Define System Testing and Acceptance Criteria

The final thing that should be said about functional specifications is to mention their role in the testing and validation of a SCADA system after commissioning.

This document will come in handy later on when it becomes the basis for your System Acceptance Testing Plan. If you can’t conceive of a test or verification step for the function you are describing, then perhaps you really do not need that function or you don’t understand it well enough to describe completely.

Go back to contents ↑

Reference // SCADA systems in wastewater treatment by Stephan J. Sosik, CEO Process-Logic, LLC