A SCADA operating system is the main set of software on a device that handles all the system's processes. The operating system talks with the device's hardware and provides services that applications can use. This means that SCADA operating systems manage input and output devices. Without an operating system, your SCADA system would be useless.
As a provider of custom remote monitoring and control solutions for the last 30 years, we at DPS know that the right SCADA operating system has the potential to save you a lot of money and boost your profitability. Evaluating these systems can be tricky though, and you need to be careful or you may end up with a system that isn't helpful at all.
Because of that we want to make sure that you're able to make an informed decision. So, let's dive into how you can choose the best SCADA operating system in order to maximize this investment.
As much as SCADA can help you improve your operations, it's important to remember that this benefit depends directly on the quality of the operating system you choose.
Here are some of the pitfalls to a hurried, impulsive SCADA operating system purchase:
You might spend a lot of money on unnecessary costs.
You might go over your budget, but still have a system that doesn't meet all your needs.
You can end up with an inflexible system that won't expand along with your network.
You might have a difficult to use interface with poor alarm descriptions, which you'll lead you to be short on the information you need to prevent a monitoring crisis.
Not to talk about wasted labor, time and money with more training, repairs, and employees that don't know what to do.
Reliable service is the crucial driver of customer satisfaction. It doesn't matter how low your prices are, if don't provide reliable service then you'll lose customers. This means that an increased network reliability helps you gain competitive a edge.
An efficient SCADA operating system will enable you to accomplish both goals: enhanced network visibility and a competitive edge.
So, when evaluating your options, you should make sure that your operating system provides you with the following necessary tools to be effective:
It's important to look for a SCADA operating system that provides easy tools for programming derived alarms (reports of complex events that track combinations of sensor inputs and data/time statements) and soft controls (programmed control responses to sensor inputs).
Derived alarms are "virtual" alarms created through user-defined formulas that coordinate inputs from several alarm points and apply logical operators to them. An example of a derived alarm is the combination of a low battery and a broken generator. Either condition isn't only a major alarm by itself, but in combination, they are a critical alarm.
The value of derived alarms is that they provide a way for you to watch for alarm combination scenarios. You don't have to scan your monitoring screens to figure out what's going on with your network. If you've configured your derived alarms, you've told the SCADA operating system what to watch for, and it will keep track of your alarms for you.
Also, with a derived alarm formula keeping track of critical events, you don't have to worry that your staff will miss the significance of a cascade of alarms - your system will alert the staff to the true situation, and even give them detailed instructions on who to inform and what to do next.
Derived alarms are flexible enough to monitor and control nearly any aspect of your network. Here's some of the ways you can use derived alarms to get better visibility of your networks.
Notification when scheduled events don't happen when they should.
For example, notification can be sent if scheduled generator self-tests don't happen on time, or if tower lights don't turn on at the scheduled time.
Operate a secondary notification device.
You can create a derived alarm based on a specified list of critical alarms from the RTUs sites. If any of the alarms on the list occur, the derived alarm triggers a derived control, which operates a control relay that operates a secondary notification device.
Notification of LAN failure using a heartbeat alarm.
In this application, two derived alarms and two derived controls are set to be an indicator of continued LAN function. The alarms are configured so the following sequence of events happens in a regular time period: control relay A triggers derived alarm B which operates control relay B which triggers derived alarm A which operates control relay A, starting the sequence over again.
Data transport between the master station and the relays is over LAN. Each alarm has a notification qualification time greater than the time period specified for the alarm-control sequence.
If the alarm-control sequence operates normally, you'll never see an alarm. If, however, the LAN fails, one alarm will not be able to operate its control relay to trigger the next alarm in the sequence, and the alarm will be left standing - and you'll know a LAN failure has occurred.
Notification of events that are only alarms when they happen at a certain time.
This allows you to set alarms for conditions that are not problems when they happen during regular business hours, but are a real issue when they happen after-hours and weekends. For example, a door might be left unlocked 8-6, Monday through Friday. But the door should never be open at any other time.
You can create a derived alarm that ignores the door during the workday but sends an alarm notification if the door is opened at other times. You can use similar derived alarms to keep you notified of after-hours uses of power, lights, air conditioning, and so on.
Receiving detailed notifications from your SCADA operating system is your first line of defense - you can't prevent a critical network outage without the right information.
Your operating system isn't complete without the capability to send detailed and actionable notifications. Vague and unintelligible alerts won't help you prevent network problems - meaningful alerts will. You'll send the right person with the right tools to the right location.
In order to get the most out of your notifications, ask yourself these three questions:
Which level of details do I need?
Keep in mind that to be able to adequately respond to an alarm, you'll need an alert that includes meaningful details. Vague alerts like "Alert: Alarm Point #3" might leave you guessing about what to do next. Is this a simple update that can be ignored or a critical problem that requires immediate attention?
Do I want my system to tell me when an alarm clears?
This feature is especially useful if you're on your way to a distant remote site and the alarm clears, letting you know en route that there's no longer a threat. So you can turn around and head back, instead of wasting time going all the way to the site for an alarm that has already cleared.
Do I need flexible notifications that escalate?
When an alarm goes off in your network, it's important to make sure that there's someone to respond. With escalating notifications, you'll have a list of people to be notified if an alarm is not acknowledged. If the first person on the list is unable to respond then the next person is notified (and so on down the list). With an escalation list, you won't have to worry about a single person missing an alarm for hours at a time.
You also need notifications that are capable of reaching you no matter where you are or the time of the day. 24x7 notifications could be the difference between an outage and network uptime. Look for SCADA operating system that is capable of giving you this flexibility via email, SNMP traps to a master, text messages, pages, or voice dial-outs to your phone.
With better notifications, you'll enjoy economic benefits as well as better work logistic coverage. Efficient alerts lead to better awareness, which means you can respond faster to network problems. You'll be able to improve service reliability and avoid preventable outages.
A SCADA operating system's interface featuring a graphical display allows operators to view alarms visually on layered geographic maps. This multiple layer support allows operators to drill down from regions, to cities, to sites, to photographs of their equipment racks. This provides visualization of alarms right down to the network devices themselves, rapidly accelerating repair operations.
Look for an operating system that has a graphical display featuring more capabilities than simply providing graphical alarm status updates. It's useful, for example, to have a display that can be used to view statistics on individual devices, tracking the frequency of polls or device alarms occurring in a given period.
Having a graphical display can bring you many benefits, including:
Visual alarm representation on geographical maps
This enhances network visibility by providing a bird's eye view of the entire alarm network.
Support for multiple map layers
Your operational system should be able to allow you to drill down to the device level to view specific alarm information.
Control familiarity for Windows users
This is important for an intuitive user experience.
Make sure your graphical display supports User ID's, which greatly reduces the potential for unauthorized access.
What happens when your SCADA system is constantly sending multiple status events and non-alarms that require no action other than an acknowledgment?
Your staff starts to believe that all alarm reports are nonessential alarms. Your personnel may stop responding to any alarm - even critical ones - defeating the function of the SCADA operating system.
These nonproductive alarms are what we call nuisance alarms, and they can have devastating effects.
An advanced SCADA operating system will be able to filter out nuisance alarms, so your staff can stay focused on preventing serious threats to your network.
Your nuisance alarm filtering feature should include capabilities, such as:
If your devices can self-correct problems, then you might not need to know about them. Your operating system should let you filter these alarms by using an alarm qualification time that sets how long the alarm condition must be in effect before an alarm is declared.
You should be able to silence, for a specified length of time, alarms that oscillate and create a lot of alarm activity.
Oscillating alarms might also be tagged to stay silent until untagged.
Also, alarms that are simply not important do not even need to appear on your monitoring screen. These alarm reports should go directly to the history file, where it should be recorded and retrieved later for analysis, if necessary.
Your SCADA operating system is a long-term investment that will last for as long as 10 to 15 years. So you need to make sure it will support your future growth for up to 15 years.
As your business expands and your number of sites increases, it's important to have an operating system that can also grow. Rather than swapping out your system every time you outgrow it, look for an operating system that is scalable.
Keep in mind that it's easier and most cost-effective to add alarm capacity in a controlled way in the immediate future than to rush a new deployment through when you've exceeded your alarm capacity.
When you're planning your SCADA system, take the future into consideration. You don't want to commit to an operating system that's inadequate for your future needs, at the same time avoid spending too much for alarm capacity you won't immediately use, either.
Take a step back and look at your entire network. Do you have redundant communication paths? Power systems? Transport systems? HVAC?
Your SCADA operating system is just as critical to maintaining proactive service, because losing it will leave you blinded to your network status. So, you should make sure that it supports redundant master stations.
Unfortunately, many companies only have one single SCADA master, which can cost them a lot in the long-run. Usually, there are three times when a company chooses to deploy redundant operating systems:
Following industry best practices from the start
After an event when visibility was lost
As budget permits
By having a SCADA operating system that supports redundant masters, you're protecting yourself from an expected problem impairing your network visibility. No matter how reliable your master is, it can potentially fail for reasons outside of your control (natural disaster, electrical damage, vandalism, etc.).
When investing on a redundant master station, make sure:
Your primary and secondary masters can automatically synchronize between themselves, so the secondary takes over with current data.
Your acknowledged alarms can be transferred, so you avoid responding to recent alarms again after the secondary takes over monitoring.
Your secondary master station takes over immediately when the primary goes offline - maintaining continuous visibility and notifications.
Because events like natural disasters can have such devastating effects, a common best practice is to have a geographical separation between masters. This means that the primary and secondary masters are kept in two different locations - providing your SCADA operational system with the ultimate protection against things, such as natural disasters and vandalism.
Early SCADA systems were built on closed, proprietary protocols.
However, these single-vendor solutions aren't a good idea because sometimes vendors drop support for their products or even just go out of business. Even large, well-known organizations might eliminate their telemetry equipment divisions.
Also, these protocols work well with the equipment they were designed for, but you might end up having to integrate equipment with incompatible protocols. A protocol mediation solution is the most efficient way of integrating two networks.
Especially if you have legacy devices, protocol mediation can extend their useful life without limiting the future development of your SCADA system.
Having a SCADA operating system that supports multiple protocols is a best practice that safeguards your network against unplanned obsolescence - integrating networks while preserving investments in legacy equipment.
An efficient SCADA operating system can boost your team's productivity and save you money. You'll waste less cash on expensive truck rolls - saving money for other, more important projects. However, deploying an operating system can be a sinkhole of costs, delays, and equipment with limited capabilities.
Your SCADA system shouldn't hold you back, it should help you. If you're not careful, your remote monitoring and control project can take a turn for the worse.
To avoid the headaches and frustrations associated with a poorly executed SCADA project, it's important to arm yourself with the right information to avoid making costly mistakes.
At DPS, we've provided support for hundreds of clients undergoing SCADA implementations, so we know how much a hassle-free process is important. That's where our SCADA Tutorial white paper comes in.
This tutorial will give you a solid introduction to SCADA system. You'll learn what to look for, what to avoid, must-have features, and some case studies of real-world applications. So, to have a complete knowledge about SCADA simply download your free copy of the SCADA Tutorial.