Creation of Safety-Related Application Software: Practical Examples for Familiarization with Handling

The first safety-related controllers were introduced to the automation market over 25 years ago. What was a rarity at the time can now be found in countless machines and systems. At first glance, safety PLCs immediately differ from standard controllers due to their yellow color. But there is a much more important distinguishing feature: safety PLCs often have two beating “hearts” inside. This means that two processors control the program sequence and only enable the outputs in unison with each other. These outputs can then safely start or stop motion sequences, for example.

The advantage of the safety-related controller is its flexibility when implementing safety-related links. This is why, when it comes to implementing health and safety requirements, the safety PLC is also part of the safety chain. As a result, the safety controller has been designed accordingly by the controller manufacturer and, for example, has been certified for safety level SIL 3 in accordance with international standard IEC 61508.

However, when it comes to the application software, it is the manufacturer of the application who is responsible for this task. The relevant software development requirements can be found in the standards for functional safety. Within the scope of the Machinery Directive, these standards are EN ISO 62061 and DIN EN ISO 13849-1. The latter is often favored in machine building. The standard distinguishes between different performance levels (PLr), which have been determined as the target for the safety function in the risk assessment. The classification ranges from PLr a to PLr e for hazards with a high risk.

Separation of Safety-Related and ­Non-Safety-Related Software

The required performance level (PLr) is also crucial when creating the application software for the safety controller. Section 4.6 of DIN EN ISO 13849-1 lists general basic requirements that must be met for each performance level. They are supplemented by additional requirements that must be observed from performance level PLr c onwards.

In this context, it is assumed that the application software used is in a programming language with limited language scope (LVL – Limited Variable Language) – and preferably graphical programming. If, on the other hand, an unlimited language scope (FVL – Full Variability Language) is used, the much more extensive development and validation processes of basic safety standard IEC 61508 must be followed.

This is why most safety controllers only provide the user with a limited language scope. For example, this means that the controllers do not support program loops and program jumps, so that the software program remains clear and maintainable.

The separation of safety-related and non-safety-related application software is equally important, as the actual process control is usually modified more frequently. The programmer sometimes even makes changes just before startup. When using certified safety controllers, such as the safety PLCs from Phoenix Contact, this separation is ensured and safeguarded by a unique checksum.  

Basic Requirements in Accordance with DIN EN ISO 13849-1

Starting with the specification, the simplified V-model can be applied for the generation of safety-related application software. The basic principles for fault avoidance and fault control also include modular and structured programming, as well as the validation planning of programmed safety functions in the possible operating states.

It is not unusual for adjustments to be made to the safe application software during the course of the project. The normative requirement for the definition of suitable development activities in view of software modifications is therefore very well documented. In addition to the aforementioned basic requirements, there are further additional requirements that are mandatory from performance level PLr c onwards.

Softema Tool for Implementing ­Normative General Conditions

The query as to whether the requirements have been implemented in accordance with DIN EN ISO 13849-1 is also integrated into the Sistema software utility of the Institute for Occupational Safety and Health of the German Social Accident Insurance (IFA). Specifically, it queries the following: “… safety-related software developed in accordance with Section 4.6 or no software available.”

The implementation query is often quickly confirmed by users with a check mark. However, during the course of their work in Germany, the team at the Phoenix Contact Competence Center Services found that these requirements had only been implemented to some extent or had not been implemented at all. This was recognized by the IFA and, in addition to the Sistema software utility for the safety-related hardware, a free software tool for the normative software requirements – Softema – was made available on the German market in March 2022.

The Softema software tool is based on a matrix method that is used to specify the interconnection of the safety logic and all the required validation activities. Built-in user management enables role-based editing of the Softema project and therefore also provides protection against unauthorized changes.

Softema provides users with the methodology to implement the requirements in accordance with DIN EN ISO 13849-1. In addition to the project-specific Softema data, such as the Cause & Effect matrix, cross-project master data is available, which can be used for other Softema projects. This includes, for example, programming rules, personal data, and the description of function blocks.

Interested users can check out the hand­ling of the software tool in the Softema guides which are currently only available in German language. Furthermore, Phoenix Contact and other companies already offer Softema seminars in Germany where practical examples are used to familiarize participants with the handling.

Detection of Systematic Failures

When you reach a certain number of safety functions with a certain level of complexity, using a programmable safety controller rather than a classic safety relay is more advantageous. When the normative requirements are taken into consideration in the programming of the safety controller, this helps the user detect systematic failures early on in the creation of the safety-related application software. Hazardous situations in day-to-day work activities can thus be avoided. It is therefore necessary to integrate the normative requirements into the development process.

Services for the Development and Testing of
Safety-Related Application Software

The Machinery Directive demands compliance with health and safety requirements. This also includes the proper integration of safety functions as a risk-reducing measure. The use of safety-related application software plays a crucial role when it comes to the reliability of the safety function. However, users are often unsure of how the normative development and testing of safety-related application software should be implemented.

In Germany, therefore, Phoenix Contact offers corresponding services that provide support in various ways. They cover a wide range of training options through to the creation of the complete verification documentation including the validation and effectiveness testing of the safety function. The normative requirements of DIN EN ISO 13849-1 provide the basis for this.