Many safety protocols exist for functional safety and safety programmable logic controllers (PLCs), including CIP Safety, functional safety over EtherCAT (FSoE). And ProfiSafe. Other safety integrity level 3 (SIL3)/performance level e (PLe) type protocols are Open Safety, CANopen Safety, IO-Link Safety and OPC UA Safety. All these protocol-based safety systems have one intent, and it’s to replace wiring, but have the same response as a wired circuit.
The main takeaway from a study of these protocols should be to understand how they can interface with your application. When considering a safety protocol, keep in mind how it will integrate in your architecture, whether it’s flexible to multivendor environments and any physical limitations it might induce. With that in mind, let’s look at ProfiSafe and see why it stands out as a safety protocol.
ProfiSafe is natively inherent to Profinet-based systems. There are 58.7 million Profinet devices installed worldwide, as of 2022, according to PI North America.
That number has most likely increased as ProfiSafe has 80-90% of the functional safety market.
There is a large Profi ecosystem supporting ProfiSafe and Profinet, which aligns with the Profibus and Profinet International (PI). ProfiSafe allows the ability to mix standard and safety inputs and outputs. This reduces wiring and may simplify the architecture. If you are creating a system for a European-based company, they may have Profinet and ProfiSafe as a standard over CIP or FSoE. Network topologies are not an issue. ProfiSafe can be run on star, line or ring topologies. ProfiSafe also interfaces well with wireless and fiber networks. ProfiSafe is SIL3-compliant based on IEC 61508 standards. All your devices—PLCs, drives, sensors and actuators—may interact on a ProfiSafe network.
If you say, “It sounds like CIP Safety and FSoE,” then you would be correct. All of them are usable for functional safety applications. FSoE is geared toward motion and may be a little faster. CIP Safety is over Ethernet and more popular in North America. All three of them use a black channel principle, in that you have safety and regular inputs and outputs traveling on the same bus.
Keep in mind though, Profibus technologies originated in 1989, making the Profi ecosystem one of the oldest in the market. PI originated the black channel idea that CIP Safety and FSoE followed. Packet formatting allows safety data to be transmitted with regular data on a black channel.
ProfiSafe appends the safety container in a packet to the end of Profinet/Profibus data instead of putting it in framer or encapsulation in a CIP message. ProfiSafe utilizes an F-Address system for safety fields, adds a cyclic redundancy check (CRC) and has a status byte with a monitoring timer. Thus, if the sequence does not transmit or gets a delayed response or fails, ProfiSafe may alarm like CIP Safety and FSoE.
Data integrity check size is a little different with ProfiSafe, in that the CRC is 24 bits, as opposed to the 32-bit CRC used by CIP Safety and FSoE. The 24-bit CRCs speed up processing of errors for industrial networks.
Get your subscription to Control Design’s daily newsletter.
The telegram formatting for ProfiSafe takes care of failures such as repetition, deletion, insertion, re-sequencing, data corruption and delay. For repetitive messages, ProfiSafe uses consecutive numbers and compares. They also time out with receipt and have a codename for the sender/receiver, which combats insertion and masquerading errors. CRC checks are used to alleviate data corruption and first-in-first-out (FIFO) errors.
How does the F Address system allow for safety to be on a black channel along with other data? F Address components have a source address and a destination address. The source has a unique decimal value between 0 and 65535, and the destination address uses 1 to 999 for Phoenix Contact modules and 1 to 65534 for other manufacturers. Phoenix Contact’s PLCnext and Siemens’ TIA Portal have configuration tools for addressing.
Addressing is important because the safety profile is part of the validation process in the safety PLC. A safety PLC may act as a host and a device, and have an F host address and an F device address. An engineer should think about the logic and the applications, physically and digitally, when setting up the safety network.
A software layer is used for the functional safety and the packets with the F-addressing allowing only safety devices to communicate to that layer, but understanding that a device may need more than one path to maintain. Setting up functional safety groups under a logical safety island may isolate functionality to one host or two hosts and then isolate control of devices to the primary and secondary hosts. This alleviates host spoofing and adds some redundancy, depending on which safety standards need to be adhered to. Otherwise, if there’s no redundant host, then alarm and troubleshoot.
The safety PLC can check the packets and the software configuration and validate changes or failures. This gives the proper checks to keep the system within functional safety limits. Thus, the network and the responses from the field are checked, along with the device configuration. On top of that, the profile in the safety side of the PLC checks for program matches. The safety program can be monitored continuously with the device health, and the telegram communications allows the ability to maintain functional safety, even if the PLC gets a system fault. PI and ProfiSafe paved the way for the CIP Safety and the FSoE, leading to safer automation.
