UX of diffusion siliconization installations

The story of how young specialist they gave him carte blanche to implement the automation of a complex installation, and it seems that he even succeeded.

How did I end up there

In fact officially no one, of course, gave any carte blanche. They just didn't limit it.

It was 2011, I had just graduated from university with a degree in programming in a small town. In the group, I more or less showed an interest in technology and coding, and so soon one of the bosses of a local enterprise contacted me. Sitting in the car, we chatted about my hobbies for all kinds of programming, I assured that I distinguish volts from amps and Java from Javascript, and with that the interview was successfully completed. The salary was planned around 20 thousand rubles.

Even at the interview, I was scared by the terms SCADA and PLC, about which I had heard practically nothing. It was especially scary because the digital part of this installation was all on me, yesterday’s student. Maybe someone at this enterprise would have caught me if something went wrong, but I quickly gained experience and knowledge.

Legacy

This whole thing was not a project from scratch. A similar old manually operated installation was already in operation. In addition, some other company had already begun to implement automation. I was given some files in which I did not find anything similar to automation, which I reported to management. From this point I was allowed to ignore what would now be called “legacy” and rewrite the project.

The word “legacy” also suited the physical condition of the enterprise, especially the part where I was to live. Mossy workshops and design rooms, drawing boards (!), boxes of Soviet electronic components, some ancient oscilloscopes, cans of expired soldering chemicals. Fascinating trash, in short. The picture would seem gloomier to someone who, as a child, did not delve into Soviet audio equipment and did not attach turn signals to his bicycle. But I dug in and fixed it up. However, let's return to the project.

So, you need to pump out the air from the stove very, very well and then heat something inside it for many hours. Managing this manually is tedious; the process is well automated. It is proposed to take a controller, write a control program for it, install a computer, install a SCADA system on it, sketch out a mnemonic diagram in it and connect it all. Traditionally, the controller part is called the lower level, and all sorts of things on the computer are called the upper level. Both levels are behind me. The deadline is in a couple of years.

What would a professional do? He would have done literally everything written in the previous paragraph, and that was it. And he would still be right. What did yesterday's student ultimately do with the ambitions of a developer and designer? Of course, I went to Google the best world practices to do cooler. Come up with features and so on.

Top level

So, I sat down to google how others do. Look, I even have a folder with refs from 2011:

There’s no need to look closely here, and I’ll show a couple below. Just feel the vibe (except for the automated control systems people, they smelled of this vibe for a long time). Then, within two months, a design speedrun took place.

• Level 1. I will do the same with gradients.

• Level 2. I'll write the coolest thing in 3D according to the drawings so that my head will fall off (in my first year I dabbled in 3D max).

• Level 3. I'll drink it based on the book.

• Level 4. I will write as I see fit.

• Level 5 (which I did not reach due to lack of wisdom and supervision): file it as the company needs and so that it can be supported.

Yes, yes, with a salary of 20 thousand rubles, I ordered a book from Amazon for 5 mowers, because it was nowhere to be found in pirated form. Now you can find it and even read it essence on one page. I’ll tell you about it in just one page: you need to use discreet colors, simple graphics, brightly highlight emergency situations, and show not only the current state but also the trend over time. The name of this advanced thought at that time (at least among manufacturers of vacuum ovens) was “situational awareness.” The whole book dances around this term. There is also some funny wisdom about cinematic interfaces, which true IT specialists dismiss: these interfaces communicate the situation very well, and there is nothing wrong with that, it can and should be adopted in the real world.

Enlightened by books (ok, one book) and disappointed by the “scuds” of that time, I set out to make my UI from scratch. “From scratch” not only in the sense that I installed Visual Studio and went to code a custom application in C# (WPF), but also in the sense that I discarded almost all the canons. No, it wasn’t some kind of insight where I was like “all the canons are bullshit and I know exactly how to do it.” In many ways, I found justification for my ideas after the fact.

How are “industrial” interfaces usually built? We take an overview design diagram, remove the unnecessary and make it colorful in those places where the state may change. Green, red, yellow. And definitely brighter, otherwise they won’t be able to tell green from red.

Ok, you can look at a more restrained picture, there is the same set of techniques.

The author of that book talks a lot about how on/off conflicts in visualization with good/faulty if you stupidly highlight everything in green or red. This didn’t seem enough to me, and I came to another conclusion: static paper symbols should not dictate dynamic ones. The book has something about forms, but for some reason does not cover notation.

After all, if we take a static diagram and just color it, then we in no way use the ability of screen elements to change shape. One can argue that changing the shape on the diagrams is generally unscientific, but you need to take into account the user’s training, and ours is very prepared (by us personally immediately after commissioning). You can at least show cats and dogs instead of open and closed valves. The operator is more interested in the current and previous state, rather than the correctness of the symbols according to drawing standards.

I was even once asked why the valve on my screen is not a valve. Apart from “everyone does it this way” and “according to GOSTs it must be done this way,” there were no arguments from that side. GOSTs, naturally, were not about screens. It’s just that for some reason some people interpret them very broadly. If only they could draw an internal combustion engine diagram for their cars instead of a speedometer and check engine! At the same time, I understand that in many places a strict diagram is very appropriate as an accessible backup for documentation, but this is not my case.

Along with the forms, we can also talk about proportions. On interactive diagrams, pipelines/wires and other connections continue to be drawn with thin lines as on separate types of design diagrams. This is also not necessarily correct. The color of a thin line is difficult to read.

So what did I do? See:

Joke. I also drew this, but with more or less traditional symbols for the manual control panel. The diagram could look exactly the same on the screen. It's a pity I didn't take a photo with the lights.

So, we want to make better use of shape, color and proportions (okay, in 20k/month no one asked for this except me). Let's throw out the complex static valve designation…

… and we begin to look for the form. The “pipes” are thicker so that you can then color them according to their condition, the valves will be very roughly depicted, but so that they “work”.

Some kind of crap. And the shape did not change much when the state changed. And ugly PPC. The angle just changed. He turned a circle, damn the designer)) Let's try more boldly:

ABOUT! That's so clear. What will be on the diagram?

Again some kind of crap. Everything merges. Maybe even worse than according to the canons it would be. But we haven't used the “pipes” yet. How to use them? Color/shading. And for what reasons do you paint? By closed and open valves, of course. It sounds simple, but in reality it is not simple at all.

If we imagine that there is a certain highway with four valves in a row,

-------><------><------><------><------
       V1      V2      V3      V4

then what is the point of coloring the V2-V3 area according to the state of these valves with V1 and V4 closed? Some kind of “AND” or even some kind of “OR” looms here. But if you take a pipe system with jumpers, then there simply won’t be enough to count all sorts of I/LI. Or count? “What if this is a count,” I remembered the university and jotted down the following:

The edges are valves, the vertices are pipes (by the way, this is counterintuitive from a purely visual point of view). Now you can work with this. The achievement of an atmosphere in a vacuum system is already a real business case, the customer will be happy. Let's see what happens if we tint the areas according to the graph. Hatching – reachability of the atmosphere, filling – evacuation, no filling – default.

ABOUT! Clearly. There was no need to bother with the valves at all, but let them be, because they are prettier. Yes, and do not draw traditional valves onto a thick pipe.

The graph model of a system of pipelines and valves can also be used to protect against the “fool”. Here it should be noted that in the installation we have provided three modes:

• Full automatic. Like a washing machine.

• Manual “logical” control (from a computer via a controller).

• Manual electromechanical control (buttons on the cabinet). The so-called “adjustment”.

And if, according to automatic and electromechanical systems, either the fool will not do anything, or we cannot do anything with him, then with manual control from a computer, we can check the command before giving it for execution. For example, you can simulate the opening/closing of a valve on a separate graph instance, and if the action leads to a loss of vacuum or overload of the pump, you can ask the operator for confirmation.

I even made the borders of the dialog boxes for a reason. Without it, the windows were a little lost. Again, no one asked, he came up with the problem himself and solved it.

Charts

Visualizing the current state is one thing. Showing how the situation developed is another thing. The book about HMI highly recommends the graphics. Big ones, small ones. I agreed with the recommendations and recorded all parameters with real-time display and periodic saving to disk (in case the computer turns off). It was possible to close and open the application again, losing no more than 10 seconds of data.

I tried to do something even cooler – so that the current session would also be registered on the controller itself. But the closer I got to commissioning, the more I realized that I was doing something that no one was asking for. Featureism. I learned later that they usually do it much simpler.

In the screenshot above you can see that I was confused about making sure that the graph on the left had a logarithmic scale. Good component allowed me to redefine a lot. The parameters were fixed about once a second. If you push so many points into several charts for many hours, then everything hangs. If you record less often, the feeling of real time disappears. As a result, I made an intermediate data source for these graphs, which, given the selected scale, reduced to a value close to the pixel width of the graph, and it worked very quickly.

There was also printing of schedules. Custom, high-quality, vector. It looked great when printed to a printer or PDF. I am pleased with this development technically, but from a requirements point of view it was, of course, a strong overkill.

Lower level

The legacy project was focused on the PLC (programmable logic controller) DirectLogic. I tried their DirectSOFT programming environment, and it seemed somewhat underdeveloped to me. Perhaps I'm too much of a programmer and not enough of an engineer. Anyway, a colleague showed me CoDeSys 2.x, and it already looked like a normal IDE, which was at least stuck in the year 2000, and not in 1995. Controllers took Aries.

As it turns out, programming such things is a separate genre. It has something from ordinary desktop programming, something from microcontrollers, something even from game development (in terms of states, etc., not graphics, of course). Your customer is a technologist who documents the order in which things should work and what to react to.

When someone sees a photo of a Windows computer at an industrial facility and jokes that now it will go into BSOD and take the nearest populated areas with it, then know that the technological process is almost certainly controlled by another computer, more predictable, and a PC with Windows is yes, frontend.

It’s difficult to visualize with screenshots what I coded in the PLC. First of all, this is, of course, an automatic mode program. They turned on one pump, waited, opened the valve, waited, and so on. The upper level, meanwhile, constantly (many times per second) reads via Ethernet a small area of ​​the controller’s memory, which represents the state of the process and individual elements. Commands from the top level are written to the same area, and the controller executes them if acceptable (for example, it is unacceptable to respond to commands for manual control of valves in automatic mode).

What was also cool was that the PLC program had to be done long before all the pieces of hardware were assembled together. Therefore, instead of a real stove, you, for example, collect three incandescent lamps (one per phase) in an iron box and connect this to a thyristor regulator where the stove will then be connected. You put a thermocouple in the same box, and with the constants tweaked in the program, you can already debug the heating procedure. Integration testing. Pre-production environment.

Fortunately, the PLC program turned out to be practically without frills. It could be supported by a person who is not passionate about custom implementation like I was then.

After three years and a couple more similar projects, I realized that my skills would be more useful where the software is not just a free application for hardware, I pulled myself up to the required minimum in web development and went to shift json from left to right for more reasonable money.