REST technology instead of OPC in industrial automation systems

This topic is enlightened on the problem of data exchange in industrial automation systems m / y PLC and various software. Before proceeding directly to the presentation, I want to say that I am in a stupid position ... The fact is that the main part of my colleagues in the workshop are not IT specialists and I work within the framework of those tools that are the “de facto” standard - SCADA packages, development environments for PLC and OPC server. Few of them are interested in what is under the “hood” of these tools, although most of the problems about which they stumble lie precisely there and are embedded in the underlying technologies. On the other hand, the process control system is quite a specific area and I am not sure that a programmer without experience in this field will be able to penetrate what I will try to convey in this post. So it turns out that this topic is intended for a small percentage of specialists who understand IT and an automated process control system at the same time.

OPC Criticism

With the development of automated process control systems, the manufacturers of PLC and software faced the problem of interaction between mobile devices and software using different protocols. The solution to this problem, initiated by Microsoft, was the OPC protocol, which was originally based on DCOM technology. This protocol is currently used everywhere and in spite of the rather well-developed nomenclature of specifications, the vast majority of implementations are based on DCOM technology, which has caused many problems:

')

• Networking. OPC has a northern architecture client based on Microsoft's DCOM technology. Support for network communication in DCOM is limited and requires additional configuration of node security. Thus, the implementation of OPC in multi-level corporate intranet networks is difficult, and data transmission via the Internet is simply impossible. This disadvantage is critical when building systems of the MES or ERP level, which leads to the need to introduce special gateways that transmit data between themselves in their format not limited to DCOM and provide data on OPC.
• Binding to Windows. DCOM technology only supports Windows, which does not allow deploying the OPC server in the controller and creating client software for mobile devices (based on iOS, Android, etc.). For the same reason, it is not possible to use a Unix-based (Linux) system that is resistant to virus attacks to collect and store data.
• Configuration. The basic concept of OPC technology is a tag, in order to get information about any signal, you need to “start” it in the OPC server configuration and in the configuration of each client software. Thus, configuration costs increase in proportion to the number of customers and levels in the automation system. In addition, often these levels or clients are served by different organizations that simply may not find out quickly about new data, which leads to irrelevance of the testimony of their systems.
• Closed protocol. OPC technology is positioned as an "open" technology, but this is not the case. Access to the specification and development tools is provided only to OPC Fundation members for a fee. Such a business model rallied large manufacturers to each other, and all the others became consumers of finished products. Even for a trivial task in the field of the OPC-based process control system, one has to buy something.

As you can see there are a lot of problems to start searching for alternatives.

REST in industrial automation

When, as a hobby, I was developing web applications on RubyOnRails, I was amazed how easy it is to solve data transfer problems using the REST model! Then I thought about the possibility of applying this approach in the process control system. As it later turned out that this idea was already formulated by a specialist from Australia Tom Todenham, here you can read his work on this topic (or my translation ). To arouse interest in this idea, I will cite theses on its advantages:

• Networking. Using the HTTP protocol as a transport allows you to transfer data via the Internet and multi-level corporate networks. Also, it does not require additional configuration of nodes, unlike OPC technology.
• Platform independence. HTTP is supported by all operating systems, which allows you to create clients for mobile devices. In addition, due to the simplicity of HTTP, it is possible to implement a REST server at the controller level and remove data from it without intermediate gateways.
• Configuration. Since the basic concept of REST is a resource, group access to data is possible (like access to a table in SQL), so new data in the system can be processed automatically without additional configuration. It is also worth noting that HTTP allows you not only to receive data from resources, but also to create and configure them, which allows you to manage the REST server from the client side using universal methods.
• Openness REST uses open standards for data transmission and presentation (HTTP, HTML, XML, JSON ...), which are supported by all programming languages ​​and platforms, which allows you to create automation applications with minimal investment in tools.

As an example of a simple implementation in Ruby, you can read my article . There is also a project for REST access to the Arduino peripherals - RESTdunio

Current situation and future plans

The author of the article on REST-PCA, Tom, created a website xpca.org/ and initiated the creation of a new architecture for XPCA industrial automation systems (eXtensible Process Control Architecture), which includes data exchange in the REST style, and then went into the shadows ... There is also a newsletter On this topic - XPCA Google Group , which is currently not active. As conceived by the author, the specifications of the new protocol will be developed on the basis of crowdsourcing and will be open.

I, in turn, launched the open source project of the first implementation of the XPCA server on .NET \ Mono - Galilei . At the moment, Galilei supports a REST interface for configuration and a simulator of random numbers, in the near future I plan to write drivers for ModBus and OPC. If you want to help the project and join the community will be very happy.



Thanks for attention)