Functional safety
Simply integrate safety
Machine and system manufacturers are increasingly turning to mapping safety functions via the communication bus. How can integration on the component side be achieved with reasonable effort?
In the past, protective or fault-detecting devices such as the emergency stop or safety light curtains were usually wired directly to the machine controller. Today, the switch from direct wiring to 'safety via bus' is becoming increasingly common - a step that promises a more flexible setup of safety-relevant applications on the one hand, but requires a great deal of know-how on the part of the software on the other.
Standards such as IEC 61508 (functional safety) not only provide clear specifications with regard to the safety functions of components, but also support their implementation. The aim is, on the one hand, to exclude systematic errors from the outset through a structured approach during development and, on the other hand, to reliably detect and handle random errors whose occurrence is unforeseeable through appropriate device concepts. Although the standard offers a great deal of support, for example in the form of checklists, many component manufacturers are reluctant to integrate secure communication themselves. One of the reasons for this is that they always have to keep up to date with the latest technology on a topic that in many cases only touches on their own core competence. So the question often arises: should you implement safety communication via the fieldbus yourself or is it better to buy in a generic solution?
The generic safety module encapsulates the entire safety function and provides safe digital I/O signals. Standard communication takes place via the 'Anybus CompactCom' communication module.
© HMSWhat are the arguments in favor of using a generic solution? First of all, it is easier to draw up the functional safety management plan. The component manufacturer no longer has to work out the individual procedure, but can implement it based on the specifications of the generic solution. A generic safety I/O solution also helps with the safe requirements specification of the device to be developed, as the development of the hardware, including iterative circuit design and coordination with a neutral test center, is completely outsourced.
The component manufacturer only has to integrate the finished safety hardware into their own product in accordance with the manufacturer's specifications. Even the implementation of the safety-relevant software is handled entirely by the manufacturer of the generic safety solution. This is a decisive advantage, as software development is inherently prone to systematic errors. Consequently, stringent processes must be adhered to - from planning and development through to testing and validation. Among other things, both individual software modules and the software as a whole must undergo certain test patterns. All in all, this means a lot of effort and high costs - another reason not to develop safety solutions in-house. And while the safety manual for the automation device also has to be written completely in-house if the safety solution is developed in-house, this can be created in a simplified manner using the guidelines of the manufacturer of the generic safety solution if it is purchased.

M580 process control now also safe
The red housing alone makes it clear - Schneider Electric has equipped its M580 process controller with functional safety and also hardened it against cyber attacks.
With a module such as the T100, secure communication via the black channel principle can be easily integrated into the existing non-secure communication bus.
© HMSThe 'Ixxat Safe T100' is an example of such a generic safety solution, which allows the safe communication of I/O signals via the black channel principle to be easily integrated into the existing non-safe communication bus. This is a TÜV pre-certified Indesign module with safe inputs and outputs as well as software tailored to the hardware concept, which guarantees safe communication up to SIL 3 or Performance Level e.
Because the T100 already has TÜV type approval, the final certification process is also much simpler. This also applies to the certification of the fieldbus or Ethernet communication. If the component manufacturer can prove that he has followed the checklists in the safety manual during implementation, this also simplifies the final acceptance with the certifying body. Finally, the user also receives support with product lifecycle management and does not have to define and implement any individual processes.
One module - different safety protocols
Various protocols for secure fieldbus communication have now become established on the market. The T100 is designed so that the same hardware can be used for different protocols. The Profisafe implementation on the T100 has already proven itself in practice. The CIP Safety protocol has now also been added. Support for the FSoE protocol is in progress.
Normally, modules for safety communication only offer inputs or outputs. As, for example, the safety-relevant actuators with their outputs are usually located in the immediate vicinity of the operator, the device and cabling effort is reduced if other local safety signals, such as emergency stop buttons, can be recorded on the actuator at the same time. This then requires the integration of safe inputs and outputs in one module. In addition, the local safety process appears as a 'single' device that can exchange both input and output signals with the higher-level safety system. Taking this into account, the T100 has six inputs and two outputs that can be configured for single-channel or dual-channel use. In some applications, sensors or actuators already provide redundant, safe output signals. In this case, the T100 simply compares the dual-channel signal at the safe inputs and then passes it on to the controller via the safe fieldbus protocol. In other cases, a logical evaluation and error detection is required locally in order to be able to reliably detect whether the signal was validly generated and transmitted by the sensor or actuator. This is the only way to detect and control errors in the system. The T100 offers outputs with dynamic test signals to detect external cabling or sensor faults. This makes it possible, for example, to detect short circuits and cross circuits in the wiring directly in the module.
The T100 is typically used in combination with the Anybus CompactCom communication module from HMS, but can also be connected to other communication modules. HMS discloses the protocol and thus enables user-specific integration. If a generic safety solution can be used in a product, it is possible to quickly save more than 80% of the development costs compared to developing the safety function in-house. If you bear in mind that even the implementation of a 'simple' safe I/O application - depending on the company's previous safety experience - can quickly incur development costs of between 500,000 and 2 million euros, the savings potential becomes all the more tangible. By way of comparison, the costs can be reduced to less than 100,000 euros by using an in-house solution.
In addition, the effort required to build up and maintain safety expertise is also significantly reduced, as the safety component is maintained by the manufacturer of the generic solution.
Author:
Stefan Kraus is Product Manager Safety at HMS Technology Center Ravensburg.












