Object Oriented Programming in Graphic Languages

Object-oriented programming (OOP) is a concept that is designed to facilitate the development of complex systems by introducing new concepts that are closer to the real world than functional and procedural programming languages. As Wikipedia writes, “Ordinary human language as a whole reflects the ideology of OOP, starting with encapsulating the idea of ​​an object in the form of its name and ending with the polymorphism of using the word in a figurative sense, which ultimately develops the expression of the representation through the name of the object to a full-fledged concept - class."

But from the point of view of everyone who first came across these abstractions, after the classical procedural languages ​​it did not become clearer, it seems on the contrary it was still more confused.

On the other hand, there are graphical notations of the program that are not close to the human language, but much more understandable than even any code, not like OOP. It is possible that this is more clear to me, spoiled by an engineering education, but there are many people like me and this text for the same spoiled physicists who do not understand high abstractions.

Here, for example, is a real description in the graphical notation of the NPP gate valve control algorithm:

On the left are the input signals, on the right are the commands.

It seems to me that even a child can read such an algorithm:

• If the pump is turned on for 60 seconds and the flow rate is less than 10, then open the recirculation valve.
• If the pump is switched on, then give the command to open within 5 seconds to the valves 001 and 002.
• If the flow rate is greater than 20 and the pump is turned on, then within 5 seconds to send the shutter valve 003 a command to close.

When I was a student, I worked part-time by creating a library of components for Delphi and was familiar with OOP firsthand. Then, when I came across real nuclear power plant control programs, I was very surprised that there was no abstraction, encapsulation and, forgive me, polymorphism, only pure C, and MISRA C’s recommendation that was cut down by the rules so that everything was reliable , portable, safe.

The peak of C cutoff in my practice was FIL, for RBMK reactor control systems. In it, functions were pre-written in C, compiled, and then called on the basis of a text file, where they were described in the FIL language. As a result, it was possible to call only a limited, but carefully tested and debugged set of functions. And all this is in the name of safety and reliability.

But at the same time, the reactor control system and the NPP control system as a whole is just the case where the principles of OOP should be applied to their full potential. In fact, there are many similar equipment - valves, pumps, sensors, everything is easily classified, there are ready-made objects that correspond to real equipment. It would seem that here it is - use OOP, classes, inheritance, abstraction, and polymorphism. But no, you need pure C and these are security requirements.

And then - even more interesting. In fact, the program for managing the nuclear power plant is not written by the programmer, but by the technologist - only he knows what and when to close, open, turn on, and most importantly - he knows when to turn off the canoe, so as not to crash. And the programmer must carefully implement all this in C code. And even better, that there would be no programmer at all, and the technologist himself drew the technological algorithms of the control programs in graphical form, automatically generated C code and loaded it into the control equipment. International safety standards recommend this; in this case, a programmer - like a violinist - is not needed. He introduces only additional errors and distortions in the implementation of the thoughts of the technologist.

What was my surprise when I found out that the NPP technologists and designers, independently of the programmers, have developed and successfully used object-oriented programming, and even in graphical notations, but the resulting code fully meets the security requirements and does not contain artifacts of the OOP methodology .

In fact, if you look at the code that is generated from the circuit in Figure 1, we will see pure C without any classes there.
For example, the algorithm entry table:

/* Index=0
   UID=0
   GeneratorClassName=TSignalReader
   Name=KBA__AA.KBA31EY001.alg_inp
   Type=Вход алгоритма */
state_vars->kbaalgsv0_out_1_ = kba31ap001_xb01;
state_vars->kbaalgsv0_out_4_ = kba31cf001_xq01;

Just assigning variables.
Any block is described as calculating the output by input, taking into account the parameters specified in the list of constants. For example, the “More” block looks like this in the code:

/* Index=5
   UID=5
   GeneratorClassName=TLogBlock
   Name=KBA__AA.KBA31EY001.smu.GT2
   Type=Операция БОЛЬШЕ */
locals->v5_out_0_ = state_vars->kbaalgsv0_out_4_ > consts->kbaalgsv3_a_;

The block output is the result of comparing the input signal with a value in a constant.

Thus, in other blocks, the local variables from the input variables are sequentially calculated, and at the end of the program cycle, the variables are written to the output variables.

/* Index=14
   UID=14
   GeneratorClassName=TSignalWriter
   Name=KBA__AA.KBA31EY001.alg_out
   Type=Выход алгоритма */
if((action==f_InitState)||(action==f_GoodStep)||(action==f_RestoreOuts)){
 kba31ey001_yb01 = locals->v8_out_0_;
 kba31ey001_yb11 = state_vars->kbaalgsv9_out_0_;
 kba31ey001_yb12 = state_vars->kbaalgsv12_out_0_;
 kba31ey001_yb02 = locals->v13_out_0_;
};

Where are the classes here, you ask?

The whole methodology related to OOP is in variable names. It would seem that this could be in the variable name? And there may be a whole abyss. For example, the variable name is kba31ap001_xb01, just a variable in C code that meets the requirement for the name of the variables. However, for a design engineer, it looks something like this: “Reactor compartment, industrial water supply system, first pump, start-up”. All this conversion magic happens thanks to the wonderful German coding system (Kraftwerk-Kennzeichensystem) KKS, quote:

“This coding classification system is designed for power plants and has great potential, and also takes into account the features of freely programmable microprocessor hardware.

Along with the marking of technological equipment, executive bodies (shut-off, safety, shut-off, etc. valves, auxiliary mechanisms), measuring points, mounting units, automation devices, buildings and structures, the KKS system allows marking algorithms and programs of various kinds and purposes (processing algorithms for measured technological parameters, signaling, automatic regulation, technological protections, logical control: locks, ABP, step-by-step programs, - calculation of t hniko-economic indicators and diagnostics of technological equipment), input, output and intermediate signals of algorithms and programs, video recordings of all levels are displayed on video terminals, cables, etc... "

But the most interesting in the last part of the name is _xb01 , which is specified through the underscore. If you look at the signal base for the management project, we will see classes there that are understandable and familiar to everyone who once, somewhere and somewhere was interested in OOP (see Fig. 2).

We have classes, or tables, in the figure this is the "Categories" column. For example, “KD1” which has a table of pattern signals, fields of the class Upper measurement limit, lower measurement limit, sensor reading , etc. Is an abstraction.

And there is also an implementation of this class — a specific sensor, for example, TK21F02B1, located in the circuit, as you might guess from its name, in the “Reactor compartment, industrial water supply system, at the first pump”, and the fact that this is a flow sensor is in this title, but it’s not accurate.

And this instance of this class has specific signals and their values, in the process of the program, and they can be accessed by the names of the fields of the class. For example, a sensor reading is indicated by the variable TK21F02B1_XQ04.

At this point, we can say, wait, this is not OOP at all, or even not OOP at all, it’s just a data structure, it is in standard C. And where is the encapsulation of the methods in the class? Data processing should be in the class, then this will be the real kosher OOP method.
Let’s see how the sensor reliability control subroutine looks in graphical form. Figure 3 is a part of the signal processing circuit:

It can be seen that in the processing subroutine the variable names TK21F02B1_XQ04 are used, formed according to the KKS rules and based on the class field table. In the above example, the sensor readings are calculated in percent TK21F02B1_XQ03 according to the set values ​​of the fields of the class instance such as TK21F02B1_Xmin and TK21F02B1_Xmax.

If we turn to the code generated from this scheme, we will see a simple assignment of a value to a variable, pure C and no pluses and OOP.

 /* Index=12
   UID=12
   GeneratorClassName=TSignalReader
   Name=KD1.kd3_45.SR6
   Type=Чтение из списка сигналов */
state_vars->su100v12_out_0_ = tk21f02b1_ai;

And assignment of the calculation result, also as a simple assignment of a variable (with checking for the validity of the number, so as not to drop the system if we received an error as a result of signal processing)

/* Index=100
   UID=100
   GeneratorClassName=TSignalWriter
   Name=KD1.kd3_45.SW3
   Type=Запись в список сигналов */
if(isfinite(locals->v63_out_0_)){
 tk21f02b1_xq04 = locals->v63_out_0_;
};

And at what moment does the union of these fields of the class of processing methods appear? In fact, I am familiar with two options for this focus. Now we will analyze one of them. (The second option is examined here .. )
Let's see how the block in which the processing program circuit is located is configured on the diagram (see Fig. 4).

We have a circuit on which we place blocks of a submodel of a graphical programming language; inside these blocks is a graphical circuit, part of which is shown in Figure 3, a program for processing signals from sensors.

In the properties of this block, we see the fields of the signal database and a drop-down list that contains signals already existing in the database, instances of the class, specific sensors of this type. It is enough to choose the desired sensor, an instance of the class by name, and a miracle happens. In the scheme, all reading and writing blocks receive names of the type TK21F02B1_XQ03 , (class instance sensor name + field name).

Now, when generating the C code, all variables will receive the values ​​of the desired sensor. And the programmer is not needed, the technologist did everything himself when he developed the scheme in the graphic programming language for the NPP control algorithm.

To assign the names, a special automation script is used in the control system design environment, approximately the same as in Figure 5. All reading blocks in the diagram are assigned names consisting of the name of the object and the name of the field in the class (see Fig. 5).

Ясно, что аналогичным образом может быть создано неограниченное количество вариантов обработки сигналов, по сути методов для класса в методологии ООП. Точно так же могут быть сформированы для датчика, его подведение при отображении на видеокадрах SCADA системы, или например обработка процедур изменения уставок. Создается схема в графическом виде, сохраняется виде блока и используется при необходимости.

Подведу итог: в графических языках программирования методы ООП так же применяются и приносят пользу. А после генерации исходного кода управляющих программ, все артефакты методологии ООП, исчезают и остается, чистый С, безопасный, надежный, верифицируемый.

Понятно, что такое применение средств автоматизации кроме ускорения разработки, позволяет так же значительно сокращать время разработки количество ошибок в управляющих программах.