SCADA: in search of the ideal

According to my observations, most intelligent ACAD specialists working with SCADA go through several stages of “emotional growth”: mastering some SCADA, searching for something better, ideas and attempts to write their own version, developing a philosophical attitude to the problem and using one of the existing ones products.

Yes, there are exceptions. For example, there are very enthusiastic and persistent enthusiasts who create something that works, but they do not change the picture at all.

Let's try to figure out why this happens and whether there can be a way out of this vicious circle.
Note: further considerations will mainly concern commercial products, but in many respects are true for open source projects, which will be discussed separately.

As a first approximation, the process of working with the SCADA system is reduced to several actions: selecting parameters for exchanging data with the PLC, developing mnemonic diagrams in a special editor, and setting up event logging and parameter states. To ensure the complex behavior of graphic elements of mnemonic diagrams and simple mathematical calculations, scripting is used or it is generally assumed that the means of simple animation configured in the editor are sufficient.

This approach is largely justified - it is easy to learn, you can quickly implement simple projects. By and large, you may not even have minimal programming knowledge to get started.

Today there are a fairly large number of SCADA systems that differ in their capabilities, cost, ease of development, etc. It would seem that choose the appropriate option and begin to create the good, bright, eternal ... But then it turns out that everything is not so simple.

1. As soon as the need arises to create a large project with a large number of elements on the mimic diagrams or the need for any noticeable amount of computation, the very low speed immediately catches the eye. The situation is especially comical when you have to shift the calculations to the PLC, although its speed is not comparable to modern PCs. Most often, you can also forget about organizing the execution of several threads.
   
   
2. An attempt to do something not envisioned by SCADA developers easily translates into very non-trivial solutions with enormous labor costs.
   
   
3. Closed internal mechanisms and incomplete documentation. For example, try to find for commercial SCADA a complete description of data storage formats and database structure.
   
   
4. Many authors of articles on modern software development strategies speak negatively of the common approach, when incomparably greater attention is paid to the creation of new functionality than optimization and code testing. Unfortunately, this is often observed in the SCADA world. Sometimes in the development process you have to spend more time circumventing the undocumented behavior of the system than actually developing. But these are industrial systems with high reliability requirements.
   
   
5. High cost - when creating a large industrial facility worth several million, allocating 5-10 thousand euros is not a big problem, but if we are talking about relatively inexpensive equipment produced in large print runs, costs of even 200 euros per copy can turn out to be unacceptable luxury.

A few words about open source systems. With sincere respect for the developers, it seems to me that the idea, despite all the attractiveness, is practically not feasible. The reason is the huge labor costs in the absence of a visible community. There are too few people interested in such a product and at the same time able to write high-quality code in an object-oriented language, ready to spend their free time on such a project. Actually, the awareness of the amount of work to create something that can compete with existing commercial products, and makes you give up.

Now that we have an idea of ​​the difficulties, we will try to formulate the requirements for an ideal SCADA and see if it is possible to solve the problem if we slightly go beyond the traditional paradigm.

1. High speed required. This means that there should be no interpreters, the output must be an executable machine code.
   
   
2. The ability to easily and without significant risks change the behavior of existing components or add your own.
   
   
3. Transparency of formats for storing settings and historical data. For example, the need to make a specific selection from archives for building reports should not result in long-term reverse engineering of the tools included in SCADA.
   
   
4. Simplicity and speed of development. It is necessary to minimize code writing and use visual programming to the maximum. If for work on the automation project it will be necessary to spend significantly more efforts in comparison with commercial SCADA, then who will need all this?
   
   
5. Convenient and modern development environment (IDE). The usual tools of any programmer are needed: code completion, version control, etc.
   
   
6. Low cost of third-party software, and ideally free and open source code.
   
   
7. All these requirements must be implemented with the minimum possible effort of several developers.

This begs the solution - we need to take the existing good environment for visual programming and create a library of components for it, tailored for the specific tasks of SCADA systems. Reasoning in this way, I opted for Qt. There are a lot of ready-made components, and an excellent IDE, and a huge community of developers.

When I first met Qt, I was simply amazed at the internal logic and richness of this library. As soon as the task arises of doing something, very often it turns out that this is already practically implemented in Qt and you just need to adapt it to your needs.

When the task is correctly formulated, it remains simple to implement it, which I started to do some time ago. To date, managed to implement a minimal gentleman's set of components.



The created set can be conditionally divided into several groups.

1. Components for communication with the PLC
   
   
   • Tag system. In fact, a buffer between drivers and other parts of the library that provides access to data from various program components.
   • Driver Client for OPC DA2. In my opinion, at the moment this is the most popular way to exchange data with the PLC and it is quite difficult to find at least some common device without an OPC server.
   
   
2. Providing recording and access to archival information
   
   
   • Alarm system.
   • Logs of technological parameters.
   
   
3. A set of graphical components (widgets).
   
   
   • Construction of graphs and trends from technological parameter logs. Everything is classic here - the choice and configuration of the display of accumulated data.
   • Work with emergency messages - output of active messages, confirmation by the operator (acknowledgment), access to archive information.
   • Display of various elements of mnemonic diagrams. As polls showed, most companies use their own icons to show the status of technological equipment. For this reason, a component was created that allows you to display graphic images (including those with a blinking effect) depending on the values ​​of the tags.
   • Building large animated piping schemes. I have never met any ready-made analogues in any SCADA, but the need is obvious - try to get directions in an extensive system with two to three hundred valves.
   • A set of components to facilitate the creation of custom elements.

Of course, there is still a long way to go, but now several possible directions for application are being examined, in addition to actually all types of classical tasks of industrial automation:

• Creating utilities for solving side problems in existing systems. For example, I happened to write an analogue of Matrikon OPC Data Manager with richer functionality, spending only about four hours on it and saving quite considerable money.
• Development of applications for working with scientific instruments.
• Smart home systems.

Somehow imperceptibly for me, my hobby turned into something more, causing interest in other people. There was an idea to turn this work into a startup, but so far everything depends on a lack of people who are ready to share this work with me. If you have a desire to take part in the development of a startup, to stand at the origins of a new company or to try yourself as a co-founder, write me in a personal.

A little more information can be found on the page on Facebook .

I will also be very grateful for constructive criticism and new ideas.

And finally, a small video FAQ: