Mr. Thiesmann, the supply bottlenecks are leading to reengineering and alternative solutions. What impact does this have on safety certification in accordance with the safety standards? How can re-certification be prevented?

Tobias Thiesmann: There is little that can be done to prevent this. If the alternative components are within the given specification and have the same design, we evaluate it internally and report the change to the responsible notified body. If a significant change has to be made to the alternative component, such as a change to the layout, circuitry or software, these changes must be re-examined by the notified body - up to and including recertification.

More and more safety functions are being mapped in software. What should the user pay attention to when implementing them?

In principle, mapping safety functions in software is not a problem. However, this software should run on hardware that is suitable for use in the area of functional safety. This can usually be recognized by the fact that the manufacturer specifies the corresponding characteristic values - i.e. safety integrity level, performance level or safety category. However, the software itself must also meet certain requirements. The ISO 13849-1 and 13849-2 standards provide a starting point here. In most cases, programmable hardware that allows safety functions to be mapped in software is supplied by the manufacturer with a suitable programming environment. Once the software has been created, validation must also be carried out to ensure that the implementation of the software meets the requirements of the risk assessment, for example.

User software is also used on safety control systems. What does this mean in terms of compliance with safety certification?

The Protect PSC1 programmable safety controllers form the basis of many safety solutions - with customer-specific software on request.

© Schmersal

The safety parameters specified by the manufacturer generally only apply to the hardware and firmware of the safety controller. As the name suggests, the user software is the responsibility of the creator, i.e. the user. Although software errors in the narrower sense are often intercepted via the programming environment, the actual program logic is not included in this check. This means that not everything that is compiled is also functionally secure.

In addition to using safe hardware and a suitable programming environment, the user must document the suitability of the software through validation. In addition to the suitability of the control system, questions relating to the specific application also play a role in achieving certain safety parameters - for example, protection against unexpected restart or the integration of feedback loops.

Schmersal is on hand to advise users. What questions keep coming up? Where do you see the greatest need for action?

The first question is often the selection of the right hardware for a specific task. This is often followed by advising the customer on how to integrate the security solution into the application. What often falls by the wayside, however, is the use of synergy effects. Modern, programmable safety logic often offers the opportunity to standardize safety solutions as well as other functions such as interfaces for documentation, diagnostics and communication. This potential is often wasted because it does not immediately generate new revenue for the user and people therefore want to 'leave everything as it is'. Unfortunately, the long-term increase in productivity often falls by the wayside.