PLCopen Releases Version 2.0 of the Security Specification Part 1

please send your inquiries to us

Contact Us


  PLCopen Releases Version 2.0 of the Security Specification Part 1

5. July 2018 – In February 2006, PLCopen released its safety specification Part 1 – Safety Feature Concepts and Function Blocks, followed by User Guidelines and Additional Parts. [19659003] The original document describes the functionalities as well as comprehensive state diagrams that contribute to the understanding, references to the applicable standards, description of the fault behavior, function tests and error codes and various programming levels. As such, it is a platform for implementers. Of course, additional information on safety devices, connections and wiring is required for users

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

  1. Contains the original part 3, in particular the section about the diagnosis and the additional 5 function blocks.
  2. In addition, the Structured Text Language ST is added, as well as additional data types and functionalities. [19659006] All original function blocks have been updated with respect to the current state updated diagnostic codes, safety request and reset of the outputs, and the reset function has been extended to the falling edge by defining a new function block.
  3. In addition, 3 movement-related function blocks are removed and added to a separate document on SafeMotion

The basic idea of ​​a new standard

Mechanical engineers face a variety of security standards. This makes it expensive for machine manufacturers and in some cases impossible to fully understand them all. In the end, however, they are still responsible for their products and the associated safety aspects. This risk situation is not very healthy, especially as legislation puts more pressure on equipment suppliers. And their liability increases.

Nowadays, there is often a clear distinction between the safety-relevant part and the functional application part. This separation can be achieved by using different systems for the environments, different tools and even different people. This disconnection often results in security issues being ultimately incorporated and not integrated into the overall system philosophy from the beginning, often with limited testing. This clearly does not contribute to the general safety aspects.

More Products  Small machines with great capabilities

In addition, ongoing technological innovation now provides safety-tested digital communication buses. This supports the trend away from hard-wired systems to software-oriented solutions. A parallel can be drawn with the movement from hard-wired relay logic to programmable logic controllers (PLCs). Of course, such a trend involves a change of mindset. This type of change requires time, broad support from industry, support from educational institutions and certification bodies.

In addition, state requirements contribute to complexity. For example, the US Food and Drugs Administration has issued strict regulations that must be respected. Failure to comply can lead to heavy fines, which in turn weaken the sustainability of the organization.

The common core requirements for a safety application for machine builders in all applicable safety standards are:

  1. distinction between safety functions and non-safety functions
  2. use of applicable programming languages ​​and language subsets
  3. use of validated software building blocks
  4. use of applicable programming guidelines
  5. Use of approved error-reducing measures for the life cycle of the safety-related software

For users, the effort required to meet these high requirements should be reduced. This can be done with standardized solutions that allow a simple implementation of typical functionalities. Function block standardization and the integration and support of software tools enable programmers to integrate security into their applications from the beginning, without compromising their functionality and performance, without incurring additional costs.

To achieve this, the PLCopen committees work in two stages:

  1. Standardization in the look and feel of security 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 the developers to use safety-relevant functionalities, the comfort zone of the users must be improved, which facilitates the acceptance of this mode of operation. This can be achieved by standardizing the appearance of the security function blocks. In this way, the security functionality can be better recognized and used independently of the respective system. Retraining is not necessary, and the tendency to create dedicated security features is reduced

More Products  Conveyco Technologies publishes Warehouse Automation Guide

In addition, this supports the certification authorities. Specifying and Verifying Security Software Much Easier

Providing function blocks at a higher level makes them less dependent on the underlying hardware architecture. Architectures such as hard-wired systems, systems with secure input and output modules, and network-based systems can be supported with the same function blocks. With this parent solution, the implementation details can be hidden from users.

2: Integration of Standard Procedures

After the functionalities have been presented in function blocks, the next step is to determine how they can be combined in safety-related programs. At this level, the software tool should help the user as much as possible. For this purpose, a new BOOLEAN data type is introduced, which is applicable within the safety-relevant environment and distinguishes between safety-related and non-safety-related Boolean variables. This is the foundation of the development tool to identify safety-critical program parts and guide the user with valid connections while avoiding false connections. In this way, support for the different levels of different security standards can be implemented.

IEC 61508, Part 7, defines a reduction in the preferred programming languages ​​for the various SILs (Highly Recommended, Recommended, or Recommended). Not recommended ") On this basis, the preferred languages ​​in this specification are the Functional Block Diagram (FBD) and Ladder Diagram (LD) graphical programming languages ​​with a defined subset of the two languages.These graphical languages ​​provide a clear overview of the safety program itself; and tooling suppliers can implement a much better level of user support and guidance, which is the basis for simplifying the commissioning of the security-related program, and also supports Structured Text (ST) as the extended-level text language.

A contribution to the acceptance and use of safety-relevant functions for mechanical engineering.

More Products  ABB introduces a modular process automation solution

The following objectives have been identified and fulfilled in the PLCopen Safety Technical Committee:

  1. Definition of a standard function block (FB) library for standard safety-related functions
  2. Combining these FBs with an application program requires an environment suitable for safety-related applications. Requirements and limitations for such an environment are partially covered in this standard.
  3. Accepted concepts and capabilities of potential certification bodies that form the basis of certifiable FBs
  4. Providing an easy-to-use interface to security function [19659006] Providing a common base, terminology, and references
  5. Related to existing security standards
  6. Providing a "style guide" for additional / future FBs
  7. Providing user policies / examples
  8. Application program should be reusable across platforms
  9. The main focus of this Technical Committee is on machine safety
  10. To include other areas outside engineering , further additions are expected. These additions may be dealt with in future additions to this document.
  11. This specification should be considered as an open framework without hardware dependencies. It offers openness to implementation across multiple platforms. The actual implementation of the function blocks themselves does not fall within the scope of this standard
  12. The programming of the "safety-relevant" and "non-safety-related" logic may be possible in the same context.

Based on these lenses, the PLCopen y has created this specification to meet the basic security requirements. This specification includes:

  1. Software Architecture Presentation
  2. Programming Language Definitions
  3. Representation of Security Data Types
  4. Definition of Language Subgroups
  5. User Level Definition for Simple Programming and Error Prevention
  6. Error Handling and Diagnostic Concept
  7. Definition of a generic safety-related function block
  8. Definition of a set of 22 safety-related function blocks
  9. The definition of a PLCopen compliance method in conjunction with the use of the PLCopen Safety logo

This document essentially consists of three parts:

  1. Reduction of programming languages ​​and functions for creating safety-relevant application programs
  2. General rules for safety-related function blocks
  3. The definition of a set of function blocks with safety-relevant funct ions

Leave a Reply