Failsafe over EtherCAT PLC

What is Functional Safety over EtherCAT, FSoE?

With a number of new KEB Functional Safety over EtherCAT (FSoE) products on the horizon, this post is a primer on FSoE and why it is important to machine builders.

 

Failsafe over EtherCAT PLC

 

Functional Safety over EtherCAT

If you haven’t seen FSoE yet (sometimes called Failsafe over EtherCAT), you will start seeing it more and more.  FSoE is a communication protocol that was developed by the EtherCAT Technology Group.  The goal was to design an industrial communication bus that would be suited for use in safety applications – up to an IEC 61508 SIL3 level.  To put this into perspective, this means the communication bus would need to operate in excess of 100,000 years without an undetected error.

 

Each FSoE node receives a unique address (16-bit) and the safe data with checksum are encapsulated in the EtherCAT telegram:

FSoE Telegram

 

Overall, the Failsafe over EtherCAT protocol has a number of different features that help detect an error in the communication, including:

FSoE error detection

 

Each FSoE slave is handled with a state machine.  Upon start-up the slave must go through the state machine in order to set any of the safe bits.  In the event of an error, the state machine is reset and the master must re-validate the connection before changing any of the safe bits.

FSoE State diagram

 

There is a lot more technical information – Members of the EtherCAT Technology Group can download a full copy of the specification at, https://www.ethercat.org.

 

 

So why should machine builders care?  Here are 5 Reasons.

 

  1. FSoE is certified to an IEC 61508 SIL3 level

The protocol was designed with a number of different features (watchdog timers, checksums, etc.) that enhance security and allow the detection of errors.

 

Very importantly, the FSoE protocol was independently certified by TÜV Süd Rail GmbH to the IEC61508 SIL3 level.

 

This is relevant because it has been evaluated by a 3rd-party safety agency and carries the appropriate certification.  When coupled with similarly certified safety hardware, the machine builder will have a much easier time having their overall machine certified for functional safety.

 

  1. FSoE is an open protocol published by the Ethernet Technology Group (ETG)

ETG hit a home run with EtherCAT.  By making the technology open and accessible it encouraged many vendors to develop EtherCAT products.  The machine builders benefitted because they had access to many different vendors and products.  The end user benefitted with high-performance technology and lower costs due to many competitive offerings.  It has been a win-win for everyone.

 

Similarly, FSoE is open and published by the ETG.  Increasingly, more automation companies will develop FSoE-based products and the ecosystem will continue to grow.  Both machine builders and end users will benefit with a wide selection of products and vendors.

 

This is not always the case with competing safety protocols on the market today.  Some protocols out there are closed and proprietary.  Any control solutions that are developed will tie a machine builder into that one vendor’s hardware and programming tools.  This introduces risk as you are tied to one vendor.

 

In short, because Failsafe over EtherCAT is open, it gives machine builders an increasing number of product options from a number of different vendors.

 

  1. FSoE can be implemented with other networks

FSoE works with standard Ethernet hardware and network cables so it can be used with other PLC vendors and with other industrial protocols.  For example, it would be possible to have a machine controlled with an Allen-Bradley or Siemens PLC but the safety functionality and safety IO is handled by a FSoE system.  The FSoE safety network could even be used with a mix of different control types – like on a large packaging line, for example.

 

This gives a machine builder flexibility.  Perhaps customers in one geography specify a PLC type from Vendor A.  Another geography specifies Vendor B.  2 machine variants can be offered but the FSoE safety control can be used across both designs.  This is a big advantage considering the huge time and cost required to certify the functional safety of the machine.

 

  1. Failsafe over EtherCAT saves wiring costs and time

Another really big advantage of FSoE is that much of the discrete safety wiring can be replaced with a network cable.  Manufacturers of rental and mobile machinery will benefit greatly from this.  The design of the safety system is largely done in the software and by using certified FSoE hardware.

 

There are a number advantages to replacing the discrete wiring:

  • Reduction in wiring time
  • Reduction in wiring errors
  • Cleaner panel layout
  • Better noise immunity

 

  1. FSoE allows for Functional Safety in the Drive (Safety Drive Profile)

    KEB has a deep EtherCAT drive portfolio.  FSoE drives are one of our differentiators.  By design, the FSoE control word allows for advanced Safe Motion functions (according to IEC 61800-5-2).  This means it is possible that a FSoE slave like an inverter can handle advanced safety functionality like Safe Limited Speed or Safe Limited Positioning.

    Safety Drive Profile, ETG 6100.1

    Safety Drive Profile, ETG.6100.1

     

    By default, the below functions are configured in the drive’s safety control word.  Additional Safe Functions are possible with manufacturer-specific bits.

    FSoE Default Safety Control Word

    FSoE Default Safety Control Word

     

    The safety function in the FSoE drive can be triggered locally with inputs or it can be enabled via the FSoE bus.  Finally, the status can be communicated back to the FSoE master with the drives Safe status word.

     

    I’d be interested in hearing any thoughts regarding Failsafe over EtherCAT or safety communication buses – advantages, disadvantages….  To talk to a KEB engineer, contact us today!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Contact
  • This field is for validation purposes and should be left unchanged.