PLCopen releases version 2.0 of the Safety Specification Part

The original document describes the functionalities as well as extensive state diagrams which add to the understanding, references to the applicable standards, description of error behavior, functional checks, and error codes, and identifies different programming levels. As such it is an ideal platform for implementers. For users, additional information on safety devices, connections and wiring is of course needed.

After so many years, an update was needed resulting now in Version 2.0 of this document. This version contains many changes:

• Incorporates the original Part 3, especially the section on diagnostics and the additional 5 function blocks.
• In addition, the Structured Text language ST is added, as well as additional datatypes and functionalities.
• All the original function blocks have been updated w.r.t. diagnostic codes, the outputs safety demand and reset requested, and the reset functionality has been extended to trailing edge via the definition of a new function block.

Also there are 3 motion related function blocks removed and added to a separate document on SafeMotion.

The rational of a new standard

Machine builders are faced with a large set of safety-related standards. This makes it expensive and in some cases unfeasible for machine builders to understand them all fully. Yet in the end they are still responsible for their products and related safety aspects. This risk situation is not very healthy, especially since legislation imposes greater constraints on the equipment suppliers. And their liability increases.

Nowadays there is often a clear separation between the safety-related part and the functional application part. This separation can be made by using different systems for the environments, different tools, and even different people can be involved. This separation often results in the safety aspects being included at the end, and not integrated into the whole system philosophy from the beginning, and often with only limited tests performed. This clearly does not contribute to the overall safety aspects.

Also, the on-going technological innovation now provides safety-approved digital communication buses. This supports the trend away from hard-wired systems towards software-oriented solutions. A parallel can be drawn with the movement away from hard-wired relay logic towards programmable logic controllers, PLCs. Such a trend, of course, involves a change in the mindset. This type of change requires time, widespread support from the industry as a whole, support from educational institutes as well as from certification bodies.

In addition, governmental requirements add to the complexity. For instance, the US-based FDA, Food and Drugs Administration, has set strict regulations that must be complied with. Non-compliance can result in heavy financial penalties, again weakening the sustainability of the organization.

The common basic requirements of a safety application for machine builders within all applicable safety standards are:

• Distinction between safety and non-safety functionalities
• Use of applicable programming languages and language subsets
• Use of validated software blocks
• Use of applicable programming guidelines
• Use of recognized error-reducing measures for the lifecycle of the safety-related software

For users, the effort to fulfill these high requirements should be reduced. This can be done using standardized solutions, which enable typical functionalities to be implemented easily. The standardization of function blocks and integration and support from software tools enables programmers to integrate safety in their applications from the beginning, without adversely affecting their functions and performance, and without adding costs.

To achieve this, PLCopen Committees are working on two levels:

1. Standardization in the look and feel of safety function blocks
2. Integration of standard procedures in the development environment

1: Standardization in the Look and Feel of Safety Function Blocks

In order to help developers use safety-related functionalities, the comfort zone of users must be improved, thus making it easier to accept this way of working. This can be done by standardizing the look and feel of the safety function blocks. In this way the safety functionality can be better recognized and used independently of the applicable system. Re-training is not necessary and the tendency to create dedicated safety functionality is reduced.

In addition, this assists the certification bodies. Specifying and checking the safety software becomes much easier, and therefore quicker, less risky, and less costly.

Providing function blocks at a higher level makes them less dependent on the underlying hardware architecture. Architectures such as hard-wired systems, systems containing safe input and output modules, and network-based systems can be supported with the same function blocks. With this higher-level solution the implementation details can be hidden from users, making the implementation of safety-related software much easier and less costly. This also improves the comfort zone of users.

2: Integration of Standard Procedures

Once the functionalities have been presented in function blocks, the next stage is to determine how to combine them into safety-related programs. At this level the software tool should help the user as much as possible. For this, a new BOOLEAN data type is introduced that is applicable within the safety-related environment, and provides a distinction between safety-related and non-safety-related Boolean variables. This provides the basis for the development tool to identify safety-critical program parts, and guide the user with permissible connections, while preventing incorrect connections. In this way, support can be implemented for the different levels of the various safety standards.

IEC 61508, Part 7, defines a reduction in the preferred programming languages for the different SILs ("Highly Recommended", "Recommended" or "Not Recommended"). Based on this, the preferred languages within this specification are the Function Block Diagram (FBD) and Ladder Diagram (LD) graphical languages with a defined subset of the two. These graphical languages provide a clear overview of the safety program itself, and tool suppliers can implement a much better level of sup-port and guidance for users. This forms the basis for simplified commissioning of the safety-related program. In addition Structured Text (ST) is supported as textual language for usage in Extended Level.

This represents a major contribution to the acceptance and use of safety-related functions, thus eliminating several obstacles as they now exist, and are described above, especially for the machine building industry.

The following objectives were identified and met within the PLCopen Safety Technical Committee:

• Definition of a standard function block (FB) library for standard safety-related functionality
• Combining these FBs with an application program requires an environment that is suitable for safety-related applications. Requirements and restrictions for such an environment are partly dealt with in this standard.
• Accepted concepts and functions by potential certification bodies, providing the basis for certifiable FBs
• Providing an easy-to-use interface to the safety functionality
• Providing a common basis, terminology, and references
• Related to existing safety standards
• Providing a "style guide" for additional/future FBs
• Providing user guidelines/examples
• Application program should be reusable across platforms
• The primary focus of this Technical Committee is safety in machinery
• To include other areas beyond the machine building industry, further additions are expected. These additions can be dealt with in future additions to this document.
• This specification shall be seen as an open framework without hardware dependencies. It provides openness for implementation on different platforms. The actual implementation of the function blocks themselves is outside the scope of this standard.
• The programming of "safety-related" and "non-safety-related" logic may be possible in the same context.

Based on these objectives, the PLCopen y produced this specification to meet the basic safety requirements. This specification includes:

• Representation of the software architecture
• Definition of the programming languages
• Presentation of safety-related data types
• Definition of language subsets
• Definition of user levels for easy programming and error prevention
• Error handling and diagnostic concept
• Definition of a generic safety-related function block
• The definition of a set of 22 safety-related function blocks
• The definition of a PLCopen compliance procedure combined with the use of the PLCopen Safety logo

This document basically consists of three parts:

1. Reduction in programming languages and functions, to enable safety-related application programs to be created
2. General rules for safety-related function blocks
3. The definition of a set of function blocks with safety-related functions

This new version 2.0 of the PLCopen Safety specification Part 1 can be downloaded from our website.