What makes a good SCADA system?
A successful SCADA specification and good installation depend on choosing and utilizing proven and reliable technology, with adequate and comprehensive training of all personnel in the operation of the system. Whilst one should rightly anticipate significant development and maintenance savings by adopting a SCADA product for the implementation of a control system, it does not mean a “no effort” operation.
The need for proper engineering can not be sufficiently emphasized to reduce development effort and to reach a system that complies with the requirements, that is economical in development and maintenance and that is reliable and robust.
12 golden rules in specifying and implementing a SCADA system are listed below:
Rule #1 – KISSS
Apply the ‘KISSS’ principle (Keep it simple, stupid and secured) and ensure that the implementation of the SCADA system is simple.
Security is exteremely important and you must focus on various types of threats which must be considered in order to plan the security management of a SCADA system.
Rule #2 – Response times
Ensure that the response times of the total system (including the future expansion) are within the correct levels (typically less than one-second operator response time).
Response time must be defined in two cases:
Project without control
The data provided by the devices are only monitored. The response time is the time between retrieving data from a device and updating the database of the SCADA. The time depends on the data type and where in the SCADA the data will be displayed or stored.
Project with control
The data can be controlled by the operator and monitor. Usually, the response time is the time between any orders given by an operator at the Supervision level and the display of corresponding status change.
Rule #3 – Redundancy
Evaluate redundancy requirements carefully and assess the impact of failure of any component of the system on the total system. If any processes or activities in the system are critical, or if the cost of loss of production is high, redundancy must be built into the system.
Rule #4 – Open systems approach
Apply the open systems approach to hardware selected and protocols communication standards implemented. Confirm that these are indeed TRUE open standards.
Rule #5 – Scalable architecture
Ensure that the whole system including the individual components provide a scaleable architecture (which can expand with increasing system requirements).
Rule #6 – Asses the total system
Assess the total system from the point of view of the maximum traffic loading on the RTU (Remote Terminal Unit), communication links and master stations and the subsequent impact on hardware, firmware and software subsystems.
Rule #7 – Functional specification
Ensure that the functional specification for the system is clearly defined as far as number of points are concerned, response rates and functionality required of the system.
Rule #8 – Testing
Perform a through testing of the system and confirm accuracy of all data transferred back, control actions and failure of individual components of system and recovery from failures.
Rule #9 – Individual components
Confirm operators of individual components of the system in the (industrial) environment to which they would be exposed (including grounding and isolation of the system).
Rule #10 – Documentation
Ensure that all configuration and testing activities are well documented.
Rule #11 – Involving operators
Ensure that the operational staffs are involved with the configuration and implementation of the system and they receive thorough training on the system.
Rule #12 – Clear, concise and simple
Finally, although the temptation is there with a sophisticated system, do not overwhelm the operator with alarm and operational data and crowded operator screens.
Keep the information of loading to the operator clear, concise and simple.
Reference: Practical guide to SCADA for industry – B. Dailey and E. Wright