Twelve golden rules for specifying and implementing a good SCADA system
A successful SCADA specification and a good installation depend on choosing and using proven and reliable technology, with adequate and comprehensive training of all personnel in the operation of the system.
12 golden rules for specifying and implementing a good SCADA system
While significant savings in development and maintenance should be rightly anticipated by adopting a SCADA product for the implementation of a control system, this does not mean an “effortless” operation.
The need for proper engineering cannot be overstated enough to reduce development efforts and achieve a system that meets requirements, is economical in development and maintenance, and is reliable and robust.
12 golden rules for specifying and implementing a SCADA system are listed below:
Rule 1 - KISSS
Apply the 'KISSS' Principle (keep it simple, stupid, and secure) and make sure that the implementation of the SCADA system is simple.
Security is extremely important and you should focus on different types of threats to consider when planning the security management of a SCADA system.
Rule 2 - Response time
Make sure the total system response time (including future expansion) is within the correct levels (typically, operator response time less than one second).
The response time must be defined in two cases:
Project without control
The data provided by the devices are only monitored. Response time is the time between retrieving data from a device and updating the SCADA database. The duration depends on the type of data and where the data will be displayed or stored in the SCADA.
Project with control
Data can be controlled by the operator and monitor. Generally, the response time is the time that elapses between the orders given by an operator at the Supervision level and the display of the corresponding change of state.
Rule 3 - redundancy
Evaluate redundancy requirements carefully and assess the impact of any system component failure on the entire system. If system processes or activities are critical or the cost of lost production is high, redundancy must be built into the system.
Rule 4 - Open systems approach
Apply the open systems approach to the selected equipment and to the communication standards of the protocols implemented. Confirm that these are indeed true open standards.
Rule 5 - Scalable architecture
Make sure that the entire system, including the individual components, provides a scalable architecture (which can grow with increasing system requirements).
Rule 6 - Evaluate the overall system
Evaluate the overall system from the point of view of the maximum traffic load on the RTU (Remote Terminal Unit), communication links, and master stations, as well as its impact on the hardware, firmware, and software subsystems.
Rule 7 - Functional specification
Make sure the functional specification of the system is clearly defined with respect to the number of points, response rates, and required system functionality.
Rule 8 - test
Perform a by testing the system and confirming the accuracy of all data transferred back, control actions and failure of individual system components, as well as recovery from failure.
Rule 9 - Individual components
Confirm the operators of the individual system components in the (industrial) environment to which they would be exposed (including system grounding and insulation).
Rule10 - Documentation
Make sure all configuration and testing activities are well documented.
Rule 11 -Involve operators
Make sure that the operational staff is involved in the configuration and implementation of the system and they receive extensive training on the system.
Rule 12 - Clear, concise, and simple
Finally, while the temptation is there with a sophisticated system, do not overload the operator with alarm and operating data and overloaded operator screens.
Keep loading information to the operator clear, concise, and simple.