Skip to main content

Objectives

From the very first beginning it was the intention of PROFIsafe to specify a comprehensive and efficient solution for both the safety device developer and the end user.

The PROFIsafe protocol should be suitable for both PROFIBUS and PROFINET networks without impacts on these existing fieldbus standards. It should be possible to transmit safety messages on the existing standard bus cables in coexistence with the standard messages (Figure 4).

 This "Single Channel" approach would also allow standard PLCs with integrated but logically separated safety processing. This way media redundancy to achieve higher availability could be realized as an option. For those users who favor physical separation of the standard and safety communications, PROFIsafe would not be a handicap. However, these users could still benefit from the same PROFINET and PROFIBUS technology on the separate networks.

The PROFIsafe protocol should not have any impact on the standard bus protocols. On the other hand, it should be as independent as possible from the base transmission channels be it copper wires, fiber optics, wireless, or backplanes. Neither the transmission rates nor the error detection mechanisms should play a role. For PROFIsafe they are just "Black Channels" (Figure 5).

The PROFIsafe protocol should free its users from the safety assessment of their individual backplane communications or other transmission paths beyond the PROFINET and PROFIBUS networks. It thus should secure the whole path from the location where a safety signal originates (e.g., F-Module in a remote I/O device) to the location where it is processed (F-Host) and vice versa (Figure 6).

The PROFIsafe protocol should be usable for safety applications up to SIL3 according to IEC 61508 / IEC 62061, or Category 4 according to EN 954-1, or PL "e" according to ISO 13849-1.

The parameters for the PROFIsafe protocol should be defined, maintained, and engineered with the standard means of PROFIBUS and PROFINET, i.e. via GSD. However, the parameters should be secured during storage, interpretation, value assignment and transfer from the configuration tool to the IO controller or DP-master and from there into the F-Device. There should be the same set of PROFIsafe parameters for all F-Devices or F-Modules in a remote I/O device to ensure uniform handling.

The individual safety parameters of an F-Device are technology-specific, e.g., drives with integrated safety, laser scanners, etc. Handling these parameters with a GSD would entail tremendous efforts and unnecessary dependencies. It therefore should be possible for F-Device developers to integrate their individual configuration, parameterization and diagnostic tools (CPD tools) via appropriate interfaces into the engineering tools of system vendors. This would facilitate the navigation and communication to the specific F-Device or F-Module.

For fast F-Device replacement in case of a failure, the system should support "Save and Restore" functionality for individual safety parameters (iPar-Server) in a uniform way. Usually the F-Host or the controller that provides the basic bus start-up parameterization should also provide this feature.

Supplementary documentation should define all aspects of a deployment of PROFIsafe devices such as requirements for

  • Installation
  • Electrical safety
  • Power supplies
  • Electromagnetic compatibility
  • Data security

Finally strong support for developers of PROFIsafe in F-Devices or F-Modules should be available in the form of PROFIsafe development kits, competence centers and test centers.
In its current version, PROFIsafe meets all of these objectives. The final concept is still straightforward and easy to understand.

Before we learn more about PROFIsafe in detail let's take a look at some preconditions and constraints.