As a general rule, it is not possible to turn a standard device into a safety device (F-device) just by implementing the PROFIsafe protocol: The final SIL of the device is defined by the architecture of the safety technology of the device together with the protocol and the manner in which both are implemented.
Even though PROFIsafe is suitable for safety functions up to SIL3, it may not be necessary to design and develop the F-Device also for SIL3.
Because of the “Black-Channel” principle, the PROFIsafe layer (located above the standard protocol) has no impact on the standard bus protocols and is independent from the base transmission channels. This makes implementation of the PROFIsafe driver software in devices and hosts quite easy. The following choices exist:
According to the different safety device technologies – from simple F-Modul up to laser scanners - a high variety of individual safety parameters (iParameter) exist which must be coded and protected. For that, PROFIsafe recommends a new mechanism, the so-called Universal-Parameter Server (iPar-Server). It is the responsibility of F-Host manufacturers to provide this capability, whether it is realized within the non-safety part of an F-Host as the parameterization master or within a controlled subsystem such as a non-safety PLC or an industrial computer on the same network. (For details see PROFIsafe System Description)
According to IEC 61800-5-2 some safety features (stopping and monitoring functions) are defined for drives with integrated safety (F-drives). Parts of these functions are specified in a amendment to the PROFIdrive specification.
Field devices for process automation
F-Devices for process automation follow the sector standard IEC 61511, which also takes into account the particular aspect of "proven-in-use". The PI Working Group "PA Devices" has specified, within a separate amendment to the “PA Device” specification, how to use the PROFIsafe platform for PA devices.
F-Host implementation solutions
Depending on the strategy of system manufacturers, different kinds of architectures for
F-Hosts with PROFIsafe communication are possible: stand-alone F-CPUs or integrated but logically separated safety processing within standard CPUs.
Safety processing can be realized in different ways: via hardware redundancy and discrepancy checking or via "software redundancy" or via "safeguarding" or by using already existing diverse hardware platforms.
Several products of different types from various vendors communicate within a PROFIsafe island. The products must be implemented conform to the PROFIsafe specification to ensure that this communication works correctly. Usually the conformance is documented through a certificate from the PI certification office based on the test report of one of the PI test laboratories.
The PROFIsafe protocol mechanisms are based on finite state machines. Thus it was possible via a validation tool for finite state machines to mathematically prove that PROFIsafe works correctly even in cases where more than two independent errors or failures may occur. This systematically was achieved by generating all possible cases for "test-to-pass" and "test-to-fail" situations. They have been extracted as test cases for a fully automated PROFIsafe layer tester, which is used to check the PROFIsafe conformance of F-Devices and F-Hosts. It is part of a three-step-procedure within the overall safety certification process according IEC 61508 by notified bodies (Figure 13).
It is important to note that the PI test laboratories perform the approved PROFIsafe layer tests on behalf of notified bodies such as, for example
These are the only ones to be responsible for the safety assessments according IEC 61508.
The mandatory safety manual of each and every F-Device shall provide information about the SILCL (claim limit) and the PFHd (probability of dangerous failure per hour).
PROFIsafe provides a specification for test & certification. Currently two PI test laboratories are accredited for the PROFIsafe testing.