Conversation with a redneck coder

Let's return to one of the projects of the SimInTeh software platform distribution, which was discussed in two articles (see [1, 2]). It is also included in the “Laboratory Work on Libraries” section of the SimInTech reference system under the name “Water Heating Boiler Control”. The latter should impose increased requirements on it, as, for example, an explanatory one, advertising one or another aspect and capabilities of the software platform. In a word, it should be ideal …

Only recently one of the errors found in it was fixed. But it was not this significant event that was the reason to return to this topic, but a mailing that arrived at about the same time, advertising the capabilities of the “newest Russian engineering platform Engee”. Among its other advantages, the finite state machines (FSM) included in the platform were described[3]and in the video at the link there was a clear love for traffic lights. But the heater in this sense is no worse, and even preferable.

But the “trigger” was an emotional outburst of not the most positive assessment given to finite automata (for more details see [4]). It is noteworthy that it was voiced by those who had previously introduced this toolkit into their platform and, as one might assume, are using it. Apparently, they know the possibilities better their own machines? But seriously, this is most likely the result of the noted “surge”, which should not be taken as the truth. Nevertheless, something needs to be clarified to take into account this opinion about the CA.

So, here we have the “Heater” or “Water heating boiler control” project. I couldn't immediately find the project in VKPa for those other articles, but, to be honest, I didn't really look for it, because I decided that it would be easier to create a new one. I wanted to check what would happen if I repeated in VKPa the automata that were completely similar to the previously created software automata in the internal language of the SimInTech platform. And since they were designed according to the concepts of automata programming, there were no obstacles. But … truly – “this has never happened before and here it is again.”

Fig. 1 shows the “Heater” project created a year and a half ago (how time flies?!). The codes of its blocks (PL block type) in the SImInTech platform language are shown in Fig. 2. Next to the program code of the blocks, their models are shown in the form of CA graphs. It is these machines, except for the integrator, that we will further test in VKPa. The algorithm of the library integrator from VKPa is essentially the same as in Fig. 2.

Let's dive into the operation of the control machine…

Following the algorithm, the control unit, upon transition from the initial state, 1) switches off the heater, 2) assigns to the local variable – y value -0.1 (it goes to the integrator input) and 3) starts a 40-sec delay. Already at the next discrete time tick (see the loop at state “1”) the delay start signal is reset to zero to prevent it from being started again. After waiting for the delay to complete (x1()==false) and if the water temperature is less than the set one (x2()==true), we go to state 2, starting a 20-sec delay along the way and turning on the heater (y:=1). Then we reset the delay start signal, as in state 1. In state 2, we wait for the delay to complete or for the water temperature to be exceeded. After waiting for one or the other, we go to state 1, as at the initial start. It's hard to come up with anything simpler.

Fig. 2. Codes of blocks of the “Heater” project on the SimInTech platform NVU

A project on the VKPa platform, completely analogous to the project in Fig. 1, is shown in Fig. 3. In general, everything seems normal: the heater works, the temperature is regulated. But we would not be ourselves if we did not experiment…

Let's change the speed of the control process in relation to the delay processes in one direction or another and see what this leads to. Why such distortions? The thing is that the components of a real system can have different speeds, and so we model such properties of real systems.

In VKPa, the above is done very simply – you need to distribute the processes across different automaton spaces, setting the required discrete time times for the latter. And, by the way, will it be as simple in the case of other parallel models – threads, coroutines, etc.? I don't remember that the performance of a thread could be controlled directly, by setting its operating speed, and not by artificially inserting delays into the thread, forcing it into “sleep” mode, etc.

But first, let's pay attention to the delay trends. In Fig. 3, these are the green and blue trends. Let's remember that the heater can only be in one state – on or off. When it is on, the delay is 20 seconds, when it is off – 40 seconds. At the same time, when it is counting time, it is in state 1. All this is reflected in the signal diagrams at the temperature gain stage. Here, the delay trends are in antiphase to each other. However, when switching to the regulation mode, such an “agreement” is violated, and this should not be. Therefore, we, at the very least, “missed” this situation, i.e. simply missed it.

Well, we missed it and missed it, why blame ourselves. It's good that we discovered it. But let's see what happens if we sharply increase the control speed. For example, immediately by fifty times, i.e. we set the discrete time for the control model space equal to 1 ms (before this it was 50 ms). And what we see on the graphs (see Fig. 4) clearly contradicts the understanding of how the control system should work. Attention is also drawn to this by inserts 4a and 4b. In a situation of fast control, even the temperature increase occurs according to a law known to no one. At the same time, which was not the case before, the delays violate the agreement on working in antiphase (cf. Fig. 3 and Fig. 4).

What if we reduce the speed of the control process? For example, by 30 times, setting the discrete time of the control process to 1500 ms. The quality of control, judging by the appearance of the graph, will be even a little better, but when entering the control mode, the maximum temperature often exceeds the set value. But this is most likely because the slow control does not have time to turn off the heater. But, as you can see, the overlap of the delays has not gone anywhere. Something clearly needs to be done about this…

The most radical way is to create new machines. The result is shown in Fig. 6. In delay machine a reset of its start signal on the 1->0 transition has been introduced if the water temperature exceeds the specified one (x2()==true). This eliminates its repeated start. management model three new states have been introduced – 3, 4 and 5. In states 3 and 4, the corresponding delays are expected to operate, i.e. their single states. We get to state 5 from state 2 if the temperature “jumped” above the norm. Here we wait for it to return back. And only after waiting for this, we start the delay on the transition to state 3. If we leave it as it was before, then part of the delay time, or even all of it, will be spent waiting for the temperature to return to the specified value. Moreover, if the delay works, and the temperature does not return to normal, then the machine will hang in state 3. And all this happens at the speed of the control process, which is less than the speed of the delay processes (see the inserts in Fig. 5).

The results of testing with new models are shown in Fig. 6, 7 and 8. This is, respectively, with the equality of process speeds, with the control speed less than the delay speed and when the control process speed is greater. The last experiment is noteworthy. In addition to the fact that the delay times do not intersect in any situation, the temperature is maintained more accurately and with the specified hold (40 sec) for water cooling. And, for example, on the same temperature graph in Fig. 5, the cooling time is clearly less than required by the design task and, in addition, the value of its remainder is unpredictable.

Heater operation indication

The heater operation process indication would seem to be the simplest thing that should be in the project. But for me, this is the most murky place. Firstly, you still have to get to it. The indication is hidden in the body of the “heater controller” block (see Fig. 9). Here it is as if “smeared” over its body. You can see 1) the “scattering” for calculating the Led constant and 2) the indication machine itself. Although you can see a certain meaning in the constant calculation scheme. In fact, this is a demonstration of how, along with the blocks, to create a scheme that implements related goals. In this case, calculating the color constant. Indeed, you can't create a whole machine for this?! 😉

There is only one indication machine in the circuit. Although there could be two of them – according to the number of indicators. In the VKP project, as we will see, it will be exactly like that. But this is not so important. The machines work in turns and it is quite possible to get by with one.

The indicator machine of the original project is shown in Fig. 10. Nothing special. We have what is obvious, two states – the indicator is on and off. The behavior algorithm is also transparent – first turn on, then turn off the LED and then repeat all this in a cycle. It is not clear, however, how to turn off the indicator? But let it blink … until it burns out.

Next, to understand the details of the operation of the indication machine, in SimInTech you need to get inside the states. For a classic machine, this is, frankly speaking, an unusual operation, but, let's assume, it does not contradict our ideas. At least in SimInTech, at most – in Harrell diagrams.

Let's look at the states shown in Fig. 11. Here we also have a very unusual, if not to say strange, representation of the functions of the transitions/outputs of the machine. But given the graphical description language in the SimInTech notation, we will put up with this too. Again – all this is the notorious matter of habit (there is no talk yet about the meaning).

Note that we have not yet looked into the “STATE SELECTION” and “COND” blocks. But if we are curious, then for an ordinary programmer accustomed to the classical form of describing a machine, believe me, this will be quite a challenge (I am talking about myself). Almost immediately the question arises – is it possible to determine the number/name of the current state of the machine from outside the block? Well, for example, as it is done for blocks in JVM, where it is reflected by the inState variable (see Fig. 2). I think it would not be difficult to do something similar for any machine in SimInTech. But this is not in the help or is hidden very deep in its (help) wilds.

There is one machine, and two indicators (or one, but multi-colored?). They should work with different frequencies – 5 sec (green) and 1 sec (red). And here the purpose of the Led constant becomes clear. It allows you to distinguish one LED from another or, if there is one LED, one color from another.

But how to control the indication period? This is described in detail in the second part of the article about machines in SimInTech[7]. But, having studied this description, I was unable to set a fixed operation for the indicator, defining at the same time strict times for its on and off states (see Fig. 13). Of course, my stupidity is not excluded, but is it really necessary to be more ingenious to do something like this? Probably, I did something wrong. Just what?

Operation of the indication

In my understanding, the LED lights up immediately when turned on. Maybe there is some delay (for warming up?), but it is probably not so big as to pay attention to it. I do not know how the LED switches from one color to another, but for some reason it seems that this happens quickly. Based on these considerations, a model for two LEDs was built, which is shown in Fig. 14.

Fig. 15 shows the visualization of the operation of indicators in SimInTech and VKPa. In SimInTech, the LED sometimes slows down when turned on or can blink so briefly that it is unlikely to be noticed against the background of the pause. It is clear that at some moments they even work in antiphase. It seems like a trifle – well, who will pay attention to problems with LED blinking? But the point, as you should understand, is not at all about this.

The point is the accuracy and quality of the design, which is what the educational project should demonstrate. Since it is one thing to heat water for a student who is comfortably seated in it in a suit (see video [5]) and it is quite another to crash into the Moon at full speed. In both cases the control system makes a decision, but… the effect is clearly different! So you always need to think about the quality of the development. Whether it is a simple demonstration example, complex rocket control or a multi-component control system for a nuclear reactor (I have already begun to answer the question asked in [4]).

Is it necessary to create a very cumbersome system like nuclear reactor control to prove the capabilities of automata programming? I think not. It is better to focus on the qualities of the design system, the technology of work in which should mix such errors. Automata succeed in this. Otherwise, they would not be given so much attention. But, of course, much depends on the implementation. And how any component of a system of any complexity and volume can be replaced by a finite automaton is demonstrated by the same project in Fig. 1 (see also Fig. 2). I hope I answered the question?

Conclusion

In SimInTech, in my opinion, the machines are not very well made. Think about how the implementation of the KA model can be considered successful, in which only one thing remains from the model – the name. If this is a success, then for another model, different from the KA model. Maybe for this reason, the analysis of even such a simple project as the control of a water heating boiler revealed a sufficient number of problems. Of course, everything can be explained by carelessness, inattention or something else. In the end, there is the experience and art of the developer.

Of course, nothing can be ruled out, but I am still worried about something else… You can't give an assessment based only on the name and without delving into the essence. Especially when the essence is set out in theory. Automata are a rare case when the theory exists and is actively used in practice. In the commentary (see [4]) we are talking about finite automata, their theory, the scientists who created this theory, and all this is declared unworthy of attention, obsolete, etc., etc. We need to prove something again, prove it… by controlling reactors, flying to the Moon, Mars. Of course, not without this and this is also understandable. And I even understand why SimInTech should be “our everything”. But still, I think we need to be more strict and objective in our assessment?

Nuclear reactor control is not the most convincing and objective argument proving the advantages of SimInTech over VKP or, especially, over MATLAB. I am 100% sure that no less large-scale projects have been made on the latter. But this fact does not mean that MATLAB is better than SimInTech. It is simply used more often.

Sometimes, and in my opinion almost always, it is much better and more effective to explain something on a not very large, and by the standards of nuclear reactor management even a tiny example, to demonstrate the quality and/or superiority of one or another approach to designing any, even the largest, systems. And then projects like a traffic light, a heater, an RS-trigger model appear [8] and other seemingly very simple tasks. But each of them has its own special feature, which is difficult to get to/see in a large project.

All of the above is not another attempt to “denigrate” – God forbid! – SimInTech. And to someone it may seem so. This is an attempt to restore the truth. And the truth is that the machines in SimInTech differ from the machines in MATLAB, and they in turn differ from the machines in VKPa. Moreover, the first two platforms do not implement the classical (correct!) finite automata, which are considered in the theory of automata, but which are implemented by VKPa. Therefore, all the negative words and assessments said about finite automata have nothing to do with classical automata. All of them, at a minimum, are addressed to models that accidentally coincide with them in name.

There are finite automata that are talked about, there are finite automata that are considered by theory, and there are automata that are used in practice. In the overwhelming majority of cases, these are different models. This is where the catch lies. And perhaps it is good that Turing, Neumann, Mealy, Moore or the same academician Glushkov did not have the chance to develop nuclear reactors. The first somehow proved the universality and generality of his model without them, and Glushkov, without referring to atomic projects, put automata at the basis of discrete cybernetics and the synthesis of digital circuits. “Simintechs”, “matlabs” and “vkpa”-shki come and go, but theories remain. They are what are worthy of discussion and comparison.

To paraphrase a well-known joke – “we need to think more about theory”… Without it, practice programming is dead (including the management of nuclear reactors). In the original, however, it is the other way around (the theory is dead, and practice is blind), but in our case it is equivalent.

Well, what does the redneck coder have to do with it? We met him after the article was published [9]. Read it – you won't regret it. And what to do in a similar situation is your choice. But of course, you need to think…

Download link for example: https://cloud.mail.ru/public/gEyC/GuK8iL86K

This article: https://cloud.mail.ru/public/JHxF/nKvfre3DX

Literature

1. Automata programming in SimInTech and VKPa. https://habr.com/ru/articles/717190/

2. C++, parallelism and introduction to automata-based programming in SimInTech. https://habr.com/ru/articles/719592/

3. Creating a finite state machine in Engee. Let's create a traffic light model. https://www.youtube.com/watch?v=9mW39zhGLbI

4. How much is syntactic sugar in graphical programming languages? https://habr.com/ru/articles/822133/comments/#comment_27007724

5. Heater. https://www.youtube.com/watch?v=U4en3cPCvHs

6. Finite state machines in the SimInTech dynamic modeling environment. [Электронный ресурс]Access mode: https://habr.com/ru/post/307090/ free. Language: Russian (date of access 02/28/2023).

7. Finite state machines in the SimInTech dynamic modeling environment. Part 2. [Электронный ресурс]Access mode: https://habr.com/ru/post/307162/ free. Language: Russian (date of access 02/28/2023).

8. Model of parallel computing. https://habr.com/ru/articles/486622/

9. How American corruption turned a nuclear physicist into a redneck coder. https://habr.com/ru/articles/824250/.

P.S.

Let's change the delay anyway, making it like this (Fig. 16):

Changed only a little – the condition of transition along the loop in the state “2”. And there is an explanation for this: the delay should count only when the operation flag is set. Before the change of the transition condition, it, being launched, continued to count even when the operation flag was reset. And the reason is also simple – violation of the orthogonality condition of transitions (this is the theory of the model): the loop was triggered, and not the transition to the state “0”. This is the error that we fixed. And it showed up during testing, when visualization showed the simultaneous activity of both delays. Although ideally it should have been detected at the stage of formal analysis of the model. Unfortunately, it is not there yet. But this does not mean that it is not possible in principle. In theory, that is.

Changing the delay

Before this, we organized the delay in the form of a tick counter. This is clearly inconvenient, since when changing the tick duration, you need to recalculate their number and change the local variable .InpDelay for each of the delays. On the other hand, VKPa has ready-made library delays that can be used. These are serial and parallel delays.

A serial delay is a nested automaton, when called, the automaton that created it “hangs” in the current state, and the transition to the next state will occur when the nested automaton completes its work. A parallel delay is a process parallel to the current process, which will complete its work after the delay time has expired. It does not slow down the automaton that created it, and the moment of completion of the delay is determined by the activity of the corresponding process: the process is active – the delay has not expired, the process is not active – the delay has expired. The FAutomaton process has operations that allow creating these delays – CreateDelay(n) and CreateParDelay(n), and for a parallel delay, an operator for checking its activity has been introduced – IsActiveParDelay().

Let's replace the counters in our delays with a parallel delay call. We'll get the following control and delay models (see Fig. 17):

Delays work according to a single algorithm. Having received a command to start – predicate x1() == true the project delay creates a parallel delay from the library and goes to the “1” state. Here it checks, firstly, the start flag and, secondly, the activity of the delay process. If any of the predicates takes a false value, then the transition to the “0” state occurs, i.e. the delay becomes inactive. The action to reset the delay start signal – y4() is started when the delay has expired on its own. This is necessary to exclude a false start of the delay.

The control machine has also undergone very minor changes (cf. the control machine in Fig. 6 and Fig. 17).

But you can go even further – create delays directly in the control machine. This will immediately exclude the delay machines themselves (not to be confused with the library delays of the VKPa platform). We will get the model shown in Fig. 18.

We have a very simple model of the heater in comparison with Fig. 6. Two delay machines “self-cancelled”. The number of states in the control decreased, there were fewer predicates and actions. Now, on the transition to state “1”, we create a parallel delay and wait for its completion. From state “2”, we go to state “1” when the 20-sec delay is completely completed. But if the temperature exceeds the specified value, we do not wait for the delay to complete, but immediately go to state “3”, turning off the heater. In state “3”, we wait for the temperature to return to normal and only after that, on the transition to state “1”, we create a 40-sec delay – a delay for the heater to cool down from the normal temperature.

That's all – sleight of hand and no fraud!

Catch up and overtake?

The basis of the VKPa platform is the real-time kernel. Creating a heater control system according to the terms of the technical specification requires fairly long delays, with the regulation process occurring after the 500th second. Because of this, monitoring the temperature regulation process is a rather tedious task. But in SimInTech, this – calculating the control process – takes literally seconds. Envy, though! 🙂

In order to keep up with SimInTech, we will introduce the virtual discrete time mode into VKPA. So far so good! It turned out this way. First, the applied processes of the project must be transferred to the main automaton space and go to the real time control tab by clicking the “Access rights” button in the “kernel: automaton spaces” dialog. Here you can disable the real time mode by setting the duration of the discrete virtual time cycle (see Fig. 19). Then you need to return to the automaton space control dialog and set the desired real time for the InitFsaWorld space. By decreasing it, we will speed up the operation time (now calculation) of the model, and by increasing it, we can consider the work of the project in slow time.

Since the project uses an integrator and if it is not in the “virtual time space”, then the same discrete time must be set for the integrator space. As a result, the heater control schedule can be obtained in less than 20 sec (with a discrete modeling time of 2 ms). A 25-fold acceleration is a very noticeable effect of the new mode (see Fig. 20). With a discrete time of 1 ms, the acceleration will already be 50 times. In the asynchronous mode, the speed will be even higher.

We have not yet achieved the calculation speed in SimInTech. But, firstly, such a task was not set, and, secondly, there is an explanation for this. The main thing is that the VKP platform is tailored for real-time operation, and SimInTech is a modeling system, the purpose of which, so to speak, is calculation. True, it is possible to set the modeling/calculation mode in real time, but this will be, although something similar to real time, but rather conditional. To make SimInTech work in this mode, you need to set synchronization with real time in the settings and specify the acceleration coefficient. Experiments have shown a fairly large error in this mode. On the “Heater” project, it was within a few seconds. In addition, in the calculation mode, you can only make individual changes to the project. For example, you can change the temperature setting, but you can no longer change the scheme “on the fly”.

Should we continue “healing”?

There is such a concept in the design of complex technical systems – Hardware in the Loop (HIL). The article told about it [10]. And here is what the all-knowing artificial intelligence (AI) answered:

Hardware in the Loop (HIL) design is a method used in the development and testing of complex control systems, such as automotive systems, aircraft systems, or industrial controllers. This method allows testing and verification of the behavior of an embedded control system in conditions as close to real-life as possible, but without the need for actual physical objects or the system.

Key aspects of HIL include:

Integrating Hardware into the Simulation Cycle: During HIL testing, real electronic devices (hardware) are integrated into a virtual environment where they interact with models of other parts of the system.

Environmental Simulation: Virtual models (simulators) are used to emulate the external environment and realistic operating conditions in which the system will be used. This may include models of engines, road conditions, atmospheric conditions, etc.

Real-time testing: HIL enables real-time testing, which is necessary to verify the performance and correct operation of controllers and other control equipment.

Safety and Cost-Effectiveness: HIL testing avoids the risks associated with testing new systems in real-world conditions (such as hazardous situations for people or possible damage to equipment) and also reduces costs, as physically assembling complex systems can be expensive.

The basic steps of the HIL testing process typically include:

Model development: Creation of highly accurate mathematical models of the system or processes that the control system must control.

Controller Integration: Embedding a real controller into the created virtual model.

Simulation and Testing: Conducting a series of tests that evaluate the controller's responses to various conditions and scenarios emulated by the model.

Analysis and correction: Comparison of the obtained results with the expected ones, identification and elimination of errors or deviations.

HIL is widely used in the automotive industry for testing automotive controllers (e.g. engine management systems, anti-lock braking systems, etc.), in the aerospace and defense industry for testing flight control and navigation systems, as well as in the energy industry and in the development of various types of industrial equipment.

Does this remind you of anything? If not, then reread the article again and… again. Until you see it. The stages of our control system development in one form or another reflect the stages of design using the HIL methodology. And now, I hope, it has become clear why the project of developing a heater control system is preferable in some ways to the traffic light control project. Of course, in the case of a traffic light, we can also talk about modeling the external environment. But this is a different topic than the design of technical objects. Namely, simulation modeling of systems. The first is more about the design of specific technical systems – the same cars, and the second is about modeling a fairly complex external environment in relation to technical objects (traffic lights).

In any case, the traffic light control system is clearly simpler than the heater control system. The first simply blinks at set time intervals, ignoring external conditions, the second reacts to the external environment, monitoring its temperature. This is what required the creation of a control object model, which in turn allowed us to test the created control system quite effectively and clearly.

But, by the way, not all traffic lights are the same. But that's a separate conversation. I had such a traffic light in my practice, which I hope to tell you about later…

Thus, knowing nothing about HIL, we nevertheless used this approach to the fullest extent when designing a control system for a conventional boiler. I hope that we did not violate anyone's copyright in doing so.

Wonderful are your works, O Lord!

Literature

10. Hardware in the Loop (HIL) or how to screw up a model with a controller. Why and who needs it? https://habr.com/ru/articles/833392/