There’s an old saying about data… “put rubbish in, get rubbish out”
- Issues with unreliable SCADA Data?
- How can you have reliable SCADA data without throwing everything away?
- Are Time Series Protocols for SCADA Systems essential?
- So why aren’t some SCADA systems event logged?
- How can I improve the Operator SCADA Experience?
- Big issues for SCADA Systems that should be avoided
- SCADA Data Management Strategies by Design
- What should a data management plan for SCADA include?
- Do the devices to be monitored can influence SCADA Network Design and the architecture?
- Why do some SCADA Systems fail to operate?
Issues with unreliable SCADA Data?
Common data issues with SCADA systems include slow data acquisition, low resolution data, nil or minimal event logged data and the resultant unsynchronised data sets. These factors all contribute to a poor operator experience, ineffective use of diagnostics, limited management of network performance and limited asset reporting and the opportunity to optimise the network and its assets. These issues go well beyond the immediate purpose of SCADA (Operational Management) by impacting on the entire enterprise. Many SCADA system Operators have regressed back to implementing advanced software alarm initiatives to overcome poorly designed data. The possibilities for an organisation are endless, if data quality issues were removed, the data was trusted, the organisation had high levels of confidence in what they see and advanced analytics were applied. The truth is, poor data makes very sophisticated software applications appear to be unreliable and untrustworthy.
How can you have reliable SCADA data without throwing everything away?
For two decades, very few organisations have benefited from total enterprise system design. Enterprise SCADA system designs should mean taking a holistic approach and designing your SCADA system inclusive of communication devices, electrical interfaces, software systems, security and enterprise historian or reporting suite.
The design criteria ought to have clear requirements about system availability and include provision for a more deterministic data management outcome (use of LAN or WAN bandwidth). This approach starts with the goals of the business and all key stakeholders including operations. The data management plan and enterprise design is ultimately a balancing act of acquisition speed and operator experience versus the richness of the data and hence business intelligence. With modern technology the compromising factor is now significantly reduced with faster communications, more resilient protocols and improved SCADA software platforms, however, this can still be easily compromised by data repositories becoming significantly larger as data storage (remote and local) continue to increase and these design inputs not being fully considered. The required system availability and security model to be deployed can have significant impacts on the system architecture. Understanding the existing infrastructure’s use of resources is the starting point for developing a plan to retain previous investments in technology. Unfortunately, there are still some cases where the chosen technology should be thrown away.
Are Time Series Protocols for SCADA Systems essential?
Most SCADA systems in Australia and around the world are not fully event logged, in fact many are not event logged at all. For distributed assets, this is a must. Bold as this may seem, it is simply not cost effective to use “non-time series” protocols like MODBUS for over the air data management on large critical assets. Operators using systems which do not leverage the use of time series protocols have poor decision support on critical infrastructure and essential services management because the time of events across sites are not synchronised and data is not rich enough to diagnose process or equipment issues. On local plant this can be less of a problem, unless plant and distributed assets have interdependencies (e.g. networked assets). In these situations, time synchronisation is one of the most significant functions every system must have functional.
So why aren’t some SCADA systems event logged?
There are a number of factors that have contributed to a situation where SCADA systems are implemented with minimal or no events being logged. These factors include substandard or “not fit for purpose” protocols in use However, the primary factor that has led to poor operator experience with SCADA is the vendor’s poor implementation of the time series protocol. Most vendors originally augmented time series protocols into their SCADA products and even today some do not support natively. Augmented solutions suffer significant performance issues, have additional engineering configuration requirements and therefore higher maintenance costs and are more complex to manage. Because of the reduction in SCADA platform performance with augmented systems, many end users were left with the decision to operate their systems in real time, forgoing any of the benefits of time series protocols like DNP3, Kingfisher Series 2, 61850 etc. In addition, for novice SCADA implementers, typical SCADA design is more about how something looks rather than how it functions for all stakeholders, its network performance, or back office data integrity etc.
Ultimately SCADA systems including telemetry, networks, device operation etc should be designed for the business’s primary purposes including asset data, remote asset control, wide area network management and overall asset effectiveness.
Event logging process variables generated by an intelligent field device (IFD’s, RTUs, IEDs) requires a defined and scalable strategy to limit the amount of data generated to an acceptable level while still creating meaningful and contextual data that creates the information necessary to operate and maintain an asset. An oversupply of data even with today’s advanced technologies, may still inhibit SCADA performance if not designed carefully.
How can I improve the Operator SCADA Experience?
Operators need information that is up to date, contextualised and trusted. This means the latest information including historical records need to be available when they analyse plant or equipment within a network. At the first instance, this is what SCADA is typically used for, however this operator need, may compromise the needs of other stakeholders that require rich data sets for planning or other analytical purposes.
To meet everyone’s needs, a trade-off between available bandwidth and the speed at which the data becomes available to the operators as information is generally made in the total system design. However, with some careful use of protocol functionality, applying human application design and engineering data management at the source, this operational “compromise” cannot really be detected and everyone wins including the budget.
The enterprise design is about finding the sweet spot for the organisation. This can be done without having to develop customised software applications and making use of standard tools and devices now readily available. This generally cannot be done using technologies and design methodologies only suitable for local plant systems (ie PLCs and DCS based architectures).
Report by Exception (RBE) is one technique necessary to alert the operators of a pending or immediate issue with the plant or asset. For best operator experience managing remote plant, an RBE event should also instigate the collection of all historical data (logged events) from the site/plant or asset relevant to the event. This can then be presented as contextual information that provides greater situational awareness for the operator. When using HMI’s and other visualisation tools, not knowing if the information you are looking at is accurate, should be a thing of the past. Yes, the early days of Telemetry made operators suffer significant pain before operating plant, however, this should no longer be the case.
Big issues for SCADA Systems that should be avoided
A blended system using RBE for alarms and “real time” scans for other data creates unsynchronised data sets and ultimately the data becomes “untrusted”. Even though the system is reporting information by design, this is a very bad situation to be avoided at all costs.
SCADA Data Management Strategies by Design
With any large network of remote devices (e.g RTU’s/IED’s) the operator is challenged to make quick and accurate decisions to ensure service delivery KPI’s are maintained. Maintenance groups are challenged by resolving equipment and plant issues with minimal resources. Decision support is vital to both operations and maintenance personnel. All types of data generate the information for decision support, therefore it’s important the data management design includes an appropriate strategy to deliver trusted and contextual information in a timely manner where the operator doesn’t need to be a systems engineer to interpret what can be relied upon in particular situations.
What should a data management plan for SCADA include?
Answers to the following help develop the right data management strategy and acquisition design;
Do the devices to be monitored can influence SCADA Network Design and the architecture?
Most networks are IP based and with the use of private narrow band UHF/VHF Radio and by message routing they can be optimised for minimal overheads. In basic networks where the only important operational factor is the instrument or device’s (e.g. power meter or water meter) current state to be as up to date as possible, a poll only solutions may work. It is particularly important to note for metering solutions the scan or sample rate is days, not seconds, and usually operational control, is not a functional requirement. In these systems, history and sequence of events (SOE) is not important. These networks are optimised by data gathering at sub nodes so that the poll master is only polling limited sites and limited instruments or devices. This type of network is effectively distributing overhead throughout the network and can increase acquisition efficiency by several fold. Such networks are found in low cost instruments where most devices are the same and effective operational management can only be achieved through real-time status. However, in some cases these networks can fail rapidly due to cascading issues such as time-outs or node failures.
Complex networks can be found where the assets are autonomous and perhaps part of an overall distributed network (system). In such cases, the network design needs to leverage the technology and operational requirements to provide the right operator experience without compromising the necessary data required by the rest of the organisation. In particular, where control systems and automated actions are implemented without operator action, and especially at times of failure, damage or mishap, the logging of events and system actions becomes increasingly important for forensic analysis at all levels of an organisation.
Why do some SCADA Systems fail to operate?
This article has been developed to articulate that Enterprise SCADA System design is less about software configuration and more about network design and appropriate architecture. Many vendors have been run out of town because their software has functioned as designed but operators have been unhappy. Granted that sometimes this may be because it was an incorrect software platform choice, however, more often the issues are related to systems design and the lack of appropriate data management strategies being implemented end to end.