This is the first blog in a series of reflections on several aspects of SCADA systems. All are based on the experience of mine or of my colleagues. I believe that the lessons learned can be useful for other implementers and users of SCADA systems.
This blog will address the communication costs that result from using third-party OPC or OPC UA servers.
Lessons learned from not implementing ICCP/TASE-2
Let me start with a story from practice: in 2005, we deployed an MES system at a customer that needed to communicate with other SCADA systems using the IEC 60870-6 protocol, also known as ICCP/TASE-2. We did not have this protocol implemented, so we used an OPC server from a reputable manufacturer. Since we built the system as highly available, with 2 redundant application servers, we needed to license 2 of these OPC servers. They were relatively expensive (the price was in the tens of thousands of euros).
This was followed by several years of the gradual development of the MES system, increasing the number of users, enhancing functionality .. in short, over time we needed to replace application servers with newer and more powerful ones. At this point, we encountered a problem - the license of OPC servers was tied to hardware and could not be migrated. The manufacturer wanted the customer to pay a new license, the price of which was higher than the price of the new hardware! In the end, we solved this problem "the engineering way". Old application servers were further used as dedicated communication servers. On the one hand, the customer was satisfied that he did not have to buy expensive licenses, on the other hand, he had to run old servers for several years. There were costs related to this operation (power supply, cooling) and maintenance (cleaning, prophylaxis, patching).
Before the next generation upgrade, we implemented support of the ICCP / TASE-2 protocol in D2000.
OPC (UA) to rule them all
An integrator deploying SCADA systems commonly encounters a protocol that their SCADA does not support. What is the simplest and fastest solution? Purchase of a protocol converter - in the form of an OPC or OPC UA server. Just configure it and the problem is solved. Or is it?
Let me offer a few arguments that demonstrate the disadvantages of using third-party OPC (UA) servers.
· Purchase price of the OPC server. If I only need one instance of the OPC server, the price can be low. What if I need to communicate with multiple devices, or install OPC servers on multiple communication computers? Also, the next point is related to this one.
· Licensing and Restrictions. How many devices or measured points (tags) can the OPC server handle? If it has any limits (e.g. 5000 measured points), are there any risks of reaching them and having to purchase and install another server? What about CPU load? Can it use multiple cores, or does it have a bottleneck somewhere that causes one processor core to be fully utilized and the others to have nothing to do?
Just an illustration - when I use the protocol available in Ipesoft D2000, the protocol license is paid only once, regardless of the number of communication lines. Each communication line (serving e.g. one serial or TCP or UDP line with several stations) has its own service task. In the case of some protocols there are even 2 tasks (receiving / sending), or more (e.g. for IEC-104 server or for IEC- 101 on redundant lines), so a large configuration can use a lot of CPU.
However, if I divide the communication into several D2000 KOM processes (either within one application server or on remote communication servers, e.g. due to the functionality of the KOM Archive), it is necessary to purchase a license for each D2000 KOM process.
· License migration and virtualization. Can the license be migrated (to new hardware, etc.)? Is it possible to use it in virtualized environments? To increase performance by adding cores or by migrating a virtual machine to another host?
· Configuration. Not everyone is aware that the OPC server also needs to be configured. In some cases, the configuration is simple. For example, in the case of protocols supporting autodetection of measured points and "browsing" (BACnet), or reading the configuration from an external file (e.g. Siemens OPC UA server working with the configuration of a project created by the TIA Portal tool). But even in the case of the mentioned OPC UA server, it took colleagues several days to configure it according to their needs (it was to work in a redundant deployment).
· Scalability and high availability solutions. Does the license have restrictions on the number of measured points? How does the price rise when you need to expand? If I build a system with high availability, the price will be higher. Twice? More? It depends on the specific product.
Besides, each configuration change will need to be made twice. Alternatively, you can export the configuration of the "primary" OPC server and import it to the "secondary" one.
· Backup and recovery. You surely back up your SCADA system configuration. If you use external OPC servers, don't forget about them as well. The backup should be made after each reconfiguration - either in the form of export to a file, by backing up the Windows registry branch, or by backing up the entire (virtual or physical) machine on which the OPC server resides.
· Maintenance and patching. How does the OPC server manufacturer distribute patches for identified functional or security issues? Is it a paid service? Does the price depend on the number (and scope) of licenses? How long is the availability of patches guaranteed?
· Compatibility and platform limitations. If (Not if, but when!) the customer requests a migration to a new version of the operating system (usually when replacing hardware, but this may also happen earlier, for example, due to the termination of OS support), will there be an OPC server supporting this version? What about license migration? And the migration of the configuration to a newer version of the OPC server?
For OPC UA servers, which, unlike OPC servers, are not limited to the Windows platform: is there a version for another platform? For example, Linux or ARM platform? If a customer wants to migrate a SCADA system to Linux in the future, will he not be limited by the unavailability of the OPC UA server and the need to run a dedicated Windows server because of it?
· Customization and adjustments. The OPC server is usually a closed package. Does the one you chose offer the ability to implement new features or adapt the behavior of the communication protocol to any non-standard behavior of the device? What if you run into some problems - e.g. memory leaks or instability during long-term use (weeks and months without restart)? How will its manufacturer react to this? Will they want you to be able to reproduce the claimed behavior in some "laboratory" environment? This is often difficult in the case of communications.
For comparison - for specific projects (our or OEM partners‘) we often modify the behavior of communication protocols. This change is activated through the so-called protocol parameters.
All mentioned points are independent of the SCADA product used (but, of course, their relevance depends on the features of a particular OPC server). If we need to communicate e.g. 1000 tags via OPC server, then we need a 1000-tag license of the OPC server (if its licensing is based on the number of tags), but at the same time we need a license for these tags in the SCADA system (again, if the licensing is based on the number of tags, or if we do not have "Unlimited" license).
Alternatives
What other options does the integrator have?
The first one is the development of a communication protocol. Ideally, the SCADA product manufacturer should develop a driver for the required communication protocol and add it to the list of supported ones. It depends on the flexibility of the manufacturer (availability of development capacities and protocol complexity). And of course - on the price. :-)
For our application server D2000 - this happens quite often, this year, for example, the General Electric SRTP and Omron FINS protocols were implemented due to new projects.
The advantage is that the protocol is automatically available in future versions, including various improvements and enhancements (available as a part of maintenance).
The second option is the development of a communication protocol. This is the way if SCADA supports an interface for programming its own "plug-in" communication protocols. In the case of Ipesoft D2000, it is enabled by the D2000 KomAPI interface, which allows the implementation of protocols in the form of DLL libraries on the Windows platform, respectively SO libraries on the Linux platform. This option is used by our OEM partners, especially if they repeatedly encounter a specialized protocol and it is more flexible for them to develop a protocol driver at their own expense than to have it implemented by us.
Conclusion
OPC and OPC UA servers as protocol converters are certainly useful. Before selecting them, it is necessary to carefully consider all the pros and cons - also in the long term and in terms of further development of SCADA applications, including hardware replacements, operating systems, and possible expansion. You don’t want them to cause the total costs to be much higher than originally calculated, or to necessitate migration to another product may due to various restrictions. In the case of a technically proficient customer, it can be beneficial to involve him in decision-making. He can add his own specific reasons that did not occur to either me or you, to the lists of pros and cons.
Ing. Peter Humaj, www.ipesoft.com
