A little more about errors in the design of process control systems and PLC programming

I came across this article and if the subject of the conversation is very interesting, let me develop a little bit of this topic.

Let's take the same scheme ( really, rather clumsy, I hope the author will forgive me for using it) from the post mentioned:


')
The first weak link of this scheme, which caught my eye, is not the K1 relay at all, of course, also worthy of mention, but the inscription “Emergency stop” on the normally-open contact of the SB1 button.

It is easy to imagine that a broken cable from this very button will cause the operator to press it until the pulse is lost, until the equipment gets up from overheating, or while the circular saw finishes its colleague, or press it with a hydraulic press.
Helixa redid the scheme at the end of the post, but this error remained.

Let's get a little deeper:

When designing automated process control systems, and especially components of emergency shutdown, one should be guided not by the arguments “either way or that”, but by quite clearly written standards. To describe them entirely is not for Habr, but let's glance briefly.
EN 60204 describes three categories of emergency shutdown:

- (0) uncontrolled shutdown through immediate power down;
- (1) stop with power preserved until the drive stops;
- (2) controlled stop.

Still, according to EN 418, emergency stop and emergency shutdown are distinguished. The easiest way to separate them according to the source of danger. If something moves, then stop with an emergency stop. If the danger is due to electric shock, shutdown with emergency shutdown (oil-oil, aha).

Finally, the command device (in this case, the button itself) must be self-locking with unlocking a conscious action "in place."

Uff, four paragraphs of the text about one contact ...

Before you open AutoCad and draw a diagram, it would be correct to conduct a risk analysis, take into account the experience of emergencies, read about systematic failures, changes in regulations, safety requirements, determine SIL, and so on, you can continue for a long time. But in the conditions of some Chelyabinsk Metallurgical Plant, this looks unlikely, unfortunately.

Therefore, we will go from the most important constraint - the budget, determining that the main priorities for us are:

- the integrity of the hands and feet of our colleagues;
- integrity of the equipment;
- minimum intervention in the budget.

Now Dichalt comes running and says that the first two points are mixed up in places ...

In the article to which I refer, the author uses Siemens equipment, which is also my favorite for several reasons. Let's continue with the same equipment, but instead of the strange button SB1 we take the correct one, i.e. emergency stop mushroom-shaped push-pull switch with two groups of contacts. We will use normally closed.

In addition, we change the controller, and take not 314, but for example 315F. The letter F means Failsafe. In short, these are fault tolerant controllers specially sharpened for security. Of course, such controllers can also be used for normal control tasks, dividing the safe and unsafe part of the hardware and software.

Let's connect our button S1 as one two-channel sensor with a rating of 1oo1, as shown in the diagram (sorry for the notes with a pencil and handwriting):



And now let's move on to the second part of the story, i.e. PLC programming and errors.

In order to program our safety function (emergency stop), we need Step7 with the Distributed Safety package installed. The main difference from the programming of the “conventional controllers” line is the absence of my favorite STL language, the absence of some operations with numbers and, in general, the reduction of any functional whose writing may cause a programmer difficulty or error. We only have F-LAD and F-FBD.

The simplest program for 6 buttons, 5 light bulbs and 2 contactor using Distributed Safety becomes like this:



However, for this example, we consider one standard FB 215 “F_ESTOP1” program block: Emergency STOP up to Stop Category 1.

The meaning of a separate, protected software block for processing one emergency stop button is very simple. Firstly, the programmer will not be mistaken, and secondly, this unit, exactly as the hardware, into which we load it, is certified and will guarantee to work as it should.

The block interface is simple. Help for him is as follows:



The principle of operation is described in the screenshot, but for those who do not know English, I will explain the challenge of this unit in our example.
So, the button, the input module 4/8 FDI, the output module and contactors K1, K2. Below you will find a beautiful picture with our example in the gland.

Call the block and bind the addresses:



Here the main thing is the input #e_stop_i - this is the signal from our button. Tripping any of her contacts will result in a unit at this input. The output #e_stop_q is further bound to the output module and to the contactors. The main thing behind. In addition, there is a need for confirmation, that is, after the button is triggered, the operator does not just have to press it to its initial position by turning "in place", but also to confirm the reset with another button, key, or clicking the mouse on the HMI interface.

We save, compile, evoke, fill and other actions with the ending - it (sorry, lunch is close), - voila. The emergency stop system is ready, which will turn off our saw or press in case of a button press, cable break, diagnostic error, loss of communication, power supply, module malfunction, and much more.

Here it is, in the form of a ready-made stand, which helps to understand the details of safe design and programming:



Since I like comments, here are a couple of questions on attentiveness and ingenuity:

1. Why is there a single red address in the call to the “F_ESTOP1” block?
2. How would you connect the contactors K1 and K2?

Thank!

PS: next time I’ll write about S7 / S8 contacts)