“With this specification, we help users achieve functional safety at the plant and machine-level more easily and independent of the underlying architecture,” says Elco van der Wal, PLCopen’s managing director. “The easy-to-use interface to the safety functionality supports this. The concepts will be usable and re-usable in a wide range of applications, providing a common basis, terminology, and references. The accepted functionality and concepts will be approved by certification bodies, providing the basis for certifiable function blocks, user levels, and lowering certification costs for users.”
The independent PLCopen association, together with its members and safety-related third-party organizations, defined safety-related aspects within the IEC 61131-3 development environments. The safety aspects, therefore, can be supported by a dedicated software tool, which is integrated into the software development tools. As such, say PLCopen officials, it combines the logic and motion application development with the related safety aspects. This combination can help developers integrate safety-related functionality into their systems at the beginning of the development cycle. Also, it should contribute to better understanding of safety aspects, as well as reducing the certification time and costs for relevant organizations.
“The basic requirements for safety application for the machine builders are independent of the applicable safety standards,” says van der Wal. “They include separation between safety and non-safety functionality, deployment of applicable programming languages and language subsets, deployment of validated software blocks, usage of applicable programming guidelines, and use of the common, known error-reducing measures for the lifecycle of the safety related software.”
Standardization Aids Safety
For users, adds van der Wal, these demanding requirements should be controlled and reduced. This means normal functionalities can be implemented via standardized solutions. “Standardization in functionality and integration support from the software tools helps the programmers integrate safety in their applications from the beginning, without inhibiting functionality and performance, and without adding costs,” he adds. “This was exactly the target of TC5. With support from nearly all relevant safety control suppliers, software suppliers, and safety-related organizations, they produced the first specification.” This should mean less user education and a simpler transfer of knowledge and application software between different controls.
“It also tackles the ‘not-invented-here syndrome’, which often is a cause of errors and additional costs,” says van der Wal. “By using tested functionality, and support in the programming environment, including language definition with subsets of functionality, one is able to create safety related application programs for easy commissioning.”
In order to fulfill the requirements, different levels of certification are applied, according to PLCopen officials.
“Certification of the software tool supplier is one of them,” adds van der Wal. “The development environment, including safety-related function blocks and underlying hardware, have to be certified by the relevant safety-related bodies. In order to be certified, certain rules, as described in IEC 61508 and IEC 61511, are applicable. The PLCopen specification provides a framework for this, but the overall requirements are beyond the scope of PLCopen, and have to be dealt with by third-party organizations.
Certification or conformity of the application also is required. PLCopen says that within an application, a certification includes the safety-related software combined with infrastructure such as sensors, switches and actuators, and connection schemes described in standards such as IEC 62061. Certification or approvals for the application software are made easier. However, the full application has to be dealt with by dedicated third-party organizations.
The specification is available for download at the PLCopen website www.plcopen.org.
