## 1 Introduction  
This article discusses the specifics of fPLC configuration and programming and their impact on the safety function. PLCs specially designed for this purpose are commonly used today to implement safety functions in the industry. To distinguish this category of PLC from standard PLCs, the designation \"safety PLC\" or \"fail-safe PLC\" is used (for this article, we will use the designation \"fPLC\"; the designation \"sPLC\" will be used for standard Programmable Logic Controllers, not intended for the implementation of safety functions). The fPLCs use a composite fault safety technique to achieve safety (more on this technique can be found in, for example, [1]) and are designed to be as easy to use as possible for the user. In practice, this means that the way they are configured and programmed is close to the way sPLCs are configured and programmed. However, it cannot be entirely identical because a dual architecture is used to implement the composite failure safety technique, and some specifics are associated with executing a program using such an architecture. The configuration and programming of the fPLC must also be adapted to these specifics. They aim to achieve the required Safety Integrity Level (SIL) and apply it to both hardware and software. In terms of hardware, it is primarily a question of the correct selection of sensors and actuators and their correct connection according to the safety function requirements. The connection of sensors and actuators concerning the requirements of the safety function is dealt with in more detail in the literature [2, 3]. In terms of software, it is primarily a matter of using programming procedures and methodsthat will ensure the required function and enable its verification in various (even non-standard) operating states. To simplify the procedures for ensuring safety, standardized hardware connections have been developed on the hardware side [4; 5; 6], and software modules [7] that cover the most common application problems are prepared on the software side. These solutions significantly facilitate the achievement of the required SIL. However, there are also applications for which standardized solutions are not suitable and which require an individual approach. In such cases, the limitations resulting from standardized solutions become a significant barrier to application development. One example of such a limitation is the Ladder Logic (LAD) programming language, resp. Function Block Diagram (FBD) used for fPLC programming. The fPLCs do not allow the programming of safety features in other languages typical of sPLCs. These are mainly different versions of the structured text. Therefore, it is not possible to use third-party software tools for programming the fPLC, which make it possible to create a model of the functional behavior of the safety function (SF; the model can be, for example, a state diagram) and, after debugging it, to generate a program in structured text. Examples of such software are Rational Rhapsody, Visual Paradigm for UML, Millet UML Modeller, Modelio, MagicDraw, Matlab, etc. With sPLC, the ability to automatically generate code from third-party tools is becoming an increasingly used solution for performing complex functions. This led us to the idea of exploring the possibilities of implementing safety functions using two sPLCs joined in a dual architecture. The architecture can suitably eliminate the consequences of accidental sPLC failures and thus affect the safety or reliability of the created control system. Using sPLC, the possibility of using code automatically generated by various modelling and simulation tools to implement safety functions would be retained. This would bring undeniable advantages in programming more complex functions, not only in the design and programming phase of the system but also in its verification and validation. A common feature of the use of an fPLC vs. two sPLCs is the utilization of a composite fail-safe technique using a dual architecture.