Well documenting the SCADA system requirements is probably the single most significant contributor to the success of a SCADA project.
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.
Image Credits - wonderware
Another reason underscoring the importance of a functional spec is that through the design and implementation phase of a project, many decisions and compromises are made to keep the project within budget and on schedule . Only by having a firm grasp on the system functional requirements can decisions about what to cut from the project be made objectively.
It may seem obvious but let’s say it anyway: writing the Functional Specification must occur BEFORE design work on a SCADA system begins .
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:
- Describe the process
- Describe the physical layout of the process
- Assess the SCADA system’s “mission criticality”
- Describe how information will flow through the system
- Define a Security Strategy
- Document an Alarm Strategy
- 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.
Include in this section what control strategies and algorithms must be in place for the various pieces of equipment . If closed loop control is planned for any levels, temperatures, pressures, or flows it should be stated explicitly.
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.
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.
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?
Some form of structured failure analysis, such as FMEA, (Failure Mode Effects Analysis) , is beneficial at this point. This technique addresses the likelihood of failures occurring, the likelihood of detecting these failures, and the level of severity of the consequences of the failure.
Design control cannot detect potential cause or the mechanism and subsequent failure mode
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.
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.
Simply displayed on local operator workstations? Distributed to remote locations over a county-wide area network? Pushed up to a database on an administrative mainframe? Formatted into active server pages to be accessed over an intranet or internet?
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.
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 .
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.
Be sure that the final list of alarms and the alarming strategy is reviewed and approved by the process engineers in charge of the process , and the operations people who are responsible for keeping the process in control, and the maintenance people that will have to respond to the alarm conditions.
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.
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 .
It is essential to keep the notion of testing in mind at the time that the functional specs are generated. For every function that is described in the spec, a test or verification method should at least be conceived and documented .
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.
Author - Mircea Tomescu