Choosing a SCADA system
This article will go over the important points about choosing a SCADA system and evaluate one of the more cost effective solutions out there, Inductive Automation’s Ignition.
What is important for a SCADA system?
Price to Performance Ratio
The customer usually doesn’t mind paying a little more for a system that delivers more performance, has more features, or is more flexible than the competition. Also, the system has a whole has to be taken into account. For example, a SCADA software package could be relatively low in cost but the operating system that the server has to run on may be expensive. Additionally, the database software license may tip the scale too far. Sometimes the SCADA system requires multiple servers that run in tandem multiplying the other “auxiliary” costs across the install, and a lot of times this cost is not discussed or disclosed up-front. The user needs to be a little tech savvy to think of the right questions to ask: how many physical servers, operating system licenses, or how much are client licenses? A lot of times the licensing costs and complexity can be very confusing and frustrating for the customer.
Inductive Automation’s license model is very simple, straightforward, and has a great price to performance ratio. There are a few levels and bolt on modules for the system, but the customer knows what they are getting and paying for. The capabilities of the base system fall in comparison to the other competitors for the same cost.
Ignition is an “unlimited client, unlimited tag, and unlimited developer” system. They recommend one server per facility and if redundancy is needed it is half of the price. There are a lot of competitors that are pretty frustrated by this licensing model and it is why Ignition is being adopted a lot for new projects.
“Times are a-changing” and everything is moving into the cloud. Information technology departments want to spend more time on things like cybersecurity, network upgrades, and IP camera projects, as well as less time, maintaining physical servers; which is understandable. Data center space and computing power are coming down in price and corporations are beginning to see the value in investing in off-site computing resources. So what does that mean for a SCADA server? Well, for one it means better maintenance, but for another, it means higher potential latency. Typically, the SCADA server has been tucked behind the maintenance manager’s workstation – and totally forgotten about. There is another side of this coin, since these “updates” or “new features” sometimes break system functionality.
Some SCADA servers don’t have the ability to be cloud-hosted, so if that is a must, the designer needs to check and make sure that the system is capable of it.
With cloud hosting, the user experience is only going to be as good as the internet connection or the connection to the cloud server. The user really needs to prioritize their data and think about the path of that data as it moves through the system.
There are a lot of SCADA systems out there that talk to controllers, however, time needs to be taken to make sure that the SCADA server will be able to communicate to the controller. A SCADA system is pretty much useless without the ability to get data back and forth from the controller(s). Allen Bradley controllers require an OPC-UA communication driver to be able to communicate via ethernet and not all SCADA systems inherently have those drivers and building drivers may not always be time sensitive or cost-effective.
All controllers have to be evaluated in this manner. A facility or plant may have 10 to 50 controllers inside of it, and they may not always be the same model or even the same manufacturer. When selecting a SCADA system it is important to take all controllers (and communication media) into account.
Ignition has a strong driver set for Allen Bradley controllers. They have an OPC-UA driver for the new ControlLogix & CompactLogix family as well as legacy drivers for MicroLogix / SLC processors.
Here is a list of PLC controllers that Ignition supports right out of the box:
- Allen-Bradley Logix
- Allen-Bradley MicroLogix (1764-LRP)
- Allen-Bradley PLC5 (1785-L40E)
- Allen-Bradley SLC, DNP3
- Legacy Allen-Bradley CompactLogix (1769-L32E)
- Legacy Allen-Bradley ControlLogix
- Modbus RTU over TCP
- Modbus TCP
- Omron NJ Driver
- Siemens S7-1200
- Siemens S7-1500
- Siemens S7-300
- Siemens S7-400
- Generic TCP Driver
- UDP Driver
Ignition supports MqTT protocol. This offers in a whole new wave of IoT devices. There are not a lot of SCADA systems that currently support this.
Alarms and Notifications
One of the most important aspects of SCADA systems is the operator or maintenance personnel getting alarms and notifications. Almost all SCADA applications offer this as a core functionality, however, some are more sophisticated than others. For example, FactoryTalk alarm and events integrate great with ControlLogix and CompactLogix processors to bring the alarm to the HMI but that is typically where it stops.
With Ignition, the designer can create what are called Rosters and Alarm Pipelines. Using these they can create sophisticated alarm scenarios based on worker schedule, the severity of alarm, or any other custom attribute the user would like to add. Alarms can be configured for any analog or digital point, and when configuring analog alarms the designer can use the built-in SCADA memory tag limits.
Ignition’s alarm pipelines support email, and with a valid email address support reply emails. The operator can acknowledge an alarm through email if the designer sets it up that way. Other SCADA systems may have the ability to email alarm notifications, but to be sure the designer should verify before selecting if this is important to the customer.
Data & Reporting
SCADA systems generate a lot of data. This data is typically brought back to the operator in the form of a displayed value or trend. Some SCADA systems use standard relational databases, for example, Microsoft SQL Server, MySQL, or PostgreSQL, and others use some non-typical things like Oracle or OsiPI. These non-typical databases make it difficult to develop third-party reports or web reporting portal.
Inductive Automation’s ignition SCADA system has the ability inherently to use the following databases:
Ignition will support additional databases, and the user can add more drivers through the management web site.
Ignition does not come with report generation in the base package. However, the module is pretty low cost considering the time and labor it would take to create one from scratch. However, because the database is in a standard format, it would possible to create a custom reporting portal. Or have a report generated through SQL Server Reporting Services on a schedule or something similar. There are not a lot of SCADA systems that have built-in reporting ability, and the competitors offer this for a substantial amount more money than ignition.
All SCADA systems have a scripting layer. Some handle scripts much better than others. For example, GE iFix and Rockwell’s FactoryTalk View SE both use VBA; the former handling scripting better than the latter. Wonderware uses .NET Framework (C#), and Inductive Automation’s Ignition uses Python/Java/Jython. Jython is a combination of python and java; python syntax with access to the Java libraries.
The designer and developer need to be comfortable in the environment they choose, or they will have a hard time at least initially.
When a SCADA system is data-driven, really cool things can happen with the user experience. The designer can create dynamic screens and let the user select what they want to see and what is important to them. Then, they can save that environment for the next time they log in. With Ignition, you can bind just about anything to either tag data or data from the database. As a comparison, FactoryTalk View SE, you can ONLY bind to tag data – and even those properties are limited.
Para la versión en español de este artículo, haga clic aquí.