While performance and efficiency of the SCADA software package with the current plant is important, the package you will purchase should be easily upgradeable to handle future requirement. The system must be easily modifiable as the requirement change and expandable as the task grows, in other words the system must use a scaleable architecture.
Before going into details, first let’s list the topics we will discuss:
- Distributed SCADA system
- Tasks in SCADA system to define precisely
- Important Request When Purchasing SCADA
The main approach to follow in designing the SCADA system is distributed. Where the SCADA system is shared across several small computers (usually PCs). However, the potential problems you can face in using distributed SCADA system are:
- Communication between different computers is not easy, resulting in possible configuration problems.
- Data processing and databases have to be duplicated across all computers in the system, resulting in low efficiencies.
- There is no systematic approach to acquiring data from the plant devices – if two operators require the same data, the RTU is interrogated twice.
Client server system
An effective solution is to examine the type of data required for each task and then to structure the system appropriately. A client server approach also makes for a more effective system.
A client server system is understood as follows:
A server node is a device that provides a service to other nodes on the network. A common example of this is a database program. A client on the other hand is a node that requests a service from a server. The word client and server refer to the program executing on a particular node.
A typical implementation of a SCADA system is shown in the figure below.
There are typically five tasks in any SCADA system. Each of these tasks listed below performs its own separate processing and each of them is of particular importance to be well defined and implemented.
- Input/output task
This program is the interface between the control and monitoring system and the plant floor.
- Alarm task
This manages all alarms by detecting digital alarm points and comparing the values of analog alarm points to alarm thresholds.
- Trends task
The trends task collects data to be monitored over time.
- Reports task
Reports are produced from plant data. These reports can be periodic, event triggered or activated by the operator.
- Display task
This manages all data to be monitored by the operator and all control actions requested by the operator.
A large system with 30 000 points could have architecture as indicated below:
There are (at least) three request you must demand when purchasing SCADA system from supplier:
A typical example of a SCADA system where one component could disrupt the operation of the entire system is given in the diagram below.
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. This can be done in a number of ways as indicated in the following diagrams.
The primary server would constantly communicate with the secondary server updating its status and the appropriate databases. If the primary server fails, the standby server will then take over as the primary server and transfer information to the clients on the network.
Dual server redundancy
Dual LANs and PLCs
SCADA system response time should be carefully specified for the following events. Typical speeds that are considered acceptable are:
- Display of analog or digital value (acquired from RTU) on the master station operator display (1 to 2 seconds maximum)
- Control request from operator to RTU (1 second critical; 3 seconds non- critical)
- Acknowledge of alarm on operator screen (1 second)
- Display of entire new display on operator screen (1 second)
- Retrieval of historical trend and display on operator screen (2 seconds)
- Sequence of events logging (at RTU) of critical events (1 millisecond)
It is important that the response is consistent over all activities of the SCADA system.
Hence the above figures are irrelevant unless the typical loading of the system is also specified under which the above response rates will be maintained. In addition no loss of data must occur during these peak times.
A typical example of specification of loading on a system would be:
- 90% of all digital points change status every 2 seconds (or go from healthy into alarm condition).
- 80% of all analog values undergoing a transition from 0 to 100% every 2 seconds.
The distributed approach to the design of the SCADA system (where the central site/master station does not carry the entire load of the system) ensures that these figures can be easily achieved.
A typical figure quoted in industry is that if expansion of the SCADA system is anticipated over the life of the system the current requirements of the SCADA system should not require more than 60% of the processing power of the master station and that the available mass storage (on disk) and memory (RAM) should also be approximately 50% of the required size.
It is important to specify the expansion requirements of the system, so that;
- The additional hardware that will be added will be of the same modular form, as that existing and will not impact on the existing hardware installed.
- The existing installation of SCADA hardware / control cabinets / operator displays will not be unfavorably impacted on by the addition of additional hardware. This includes items such as power supply / air conditioning / SCADA display organization.
- The operating system will be able to support the additional requirements without any major modifications.
- The application software should require no modifications in adding the new RTUs or operator stations at the central site/master station.
Reference // Practical SCADA for Industry by David Bailey and Edwin Wright