Open search

TÜV-approved safety concept reduces cost and effort

Moba (Germany) has released a whitepaper called “Be on the safe side with just a single CAN bus.” This is an excerpt of the paper and a Q&A with the author Boris Zils. The full whitepaper is available at the Moba website.

Cranes, lifting equipment as well as many other mobile and stationary machines and industrial systems must satisfy high requirements in order to avoid critical states (Photo: Moba)

THE DEGREE OF AUTOMATION in mobile machines has increased considerably in recent years. Today, it is considered essential that high functional safety requirements be met in order to avoid critical states. The implementation of the directives for machine safety specified in ISO 13849 is, however, anything but trivial in practice. The required redundant systems lead to an increase in time and cost expenditures. A new CANopen based solution, which has been approved for use in safety applications by the technical inspection association (TÜV), now ensures that cost and effort for the user can be reduced considerably in spite of high safety standards.

Safety systems have long been used in mobile machines. The familiar analog system architecture was, and remains common. Duplicated systems are used to provide the necessary redundancy in order to ensure the functional safety even in the event of a malfunction. With respect to functional safety, there is nothing wrong with such a solution. The amount of wiring does, however, become significant if multiple sensors are in use. This is because each sensor must be connected to one of the two controllers with a separate line.

Bus systems allow considerable simplifications. It is no surprise, therefore, that the digital CANopen system architecture has found increasing acceptance in mobile machines. CANopen is very interference resistant and very fast, i.e. it can operate in real time and can be simply expanded if necessary. Two controllers are, however, still needed for functional safety system architectures. The amount of wiring is reduced considerably though, as it is not necessary to wire separate cables from the controller to each sensor. Rather, multiple sensors can communicate via the same CANopen bus. Compared to an analog system architecture, additional components can be added much more easily - and can also be added at a later date.

Cranes, lifting equipment as well as many other mobile and stationary machines and industrial systems must satisfy high requirements in order to avoid critical states (Photo: Moba)

The safe CAN architecture offers another option: CANopen safety sensors can
also be integrated. It allows safety-oriented components to be operated next to non-safety-oriented components in a single CANopen network. When using CANopen safety sensors (PLd), a single bus is enough. This sounds good - and it is - but there is a catch for many applications: the comparisons take place in the sensors. If different applications require different tolerance windows for the measurement values, this leads to problems. Furthermore, not all sensors are currently available in corresponding functional safety versions. If one wishes to connect non-common sensor types, a second bus is once again needed in safety applications.

Functional safety without CANopen safety

There is, however, a practically oriented solution available now that offers advantages in such cases: even without special CANopen safety sensors, CANopen can be safe with just a single bus. This has been approved by TÜV for the first time. Even with safety applications in heterogeneous application environments, all applications can operate on just a single CAN network. It is even not necessary to rely on sensors that use the CANopen safety protocol. The achievable reduction in wiring with this approach makes great economic sense, since the costs incurred for wiring are typically estimated between 20 % and 30 % of the component investment, depending on the application.

Cranes, lifting equipment as well as many other mobile and stationary machines and industrial systems must satisfy high requirements in order to avoid critical states (Photo: Moba)

When selecting sensors, the user now has various options available. For example, monitoring the slope of a telescoping boom, one does not need to use a CANopen safety sensor. One can - if desired - also use two ‘normal' one-channel sensors or one two-channel CANopen sensor, such as the Moba MSS slope sensor. Both sensor channels are connected to the same bus, but send their messages with two different node IDs. Because reliable fault detection is ensured, this structure is considered to be PL-d compliant. If desired, another (safe) CANopen network can be connected to the redundant controller. The new CANopen-based solution, approved by TÜV for functional safety applications, thereby ensures that cost and effort for users can be considerably reduced in spite of high safety standards.

Q&A with Boris Zils

Q: Is the redundant MSS slope sensor compliant with CiA 410?
A: The MSS sensor is not compliant with CiA 410. We see an advantage by sending the measured value and its status within the same PDO.

Q: Which process data are mapped into the two PDOs and which CAN-IDs are used?
A: Process data are: Measurement value and sensor status for example: out of range. CAN-IDs are used according to the CiA 301 predefined connection set.

Q: How does the MSS slope sensor guarantee data consistency between both measured values (e.g. by a running number or an absolute time-stamp)?
A: Procedures like: Power diagnostics, watchdog etc., and mainly procedures to avoid common cause failures are implemented in the sensors. Time out, crosschecking methods and plausibility checks are implemented in the redundant host controllers. Running numbers or an absolute time-stamp would be an improvement in order to achieve higher diagnostic coverage, but are not implemented yet.

Q: Are there any requirements for the receiving devices (e.g. host controller) or for the used crosschecking method?
A: The redundant controller and the software structure (cross-checking method etc.) have to be approved according to ISO 13849. Moba is working on a safety manual for the system structure and software principle for its range of redundant Codesys controllers.

Q: Up to which SIL or PL level is this approach approved and by whom (which TÜV)?
A: PL-d is established (e.g. TÜV Nord)

Q: How do you avoid unintended reconfiguration during runtime by means of SDO?
A: The approved software has to prevent SDO messages send by mistake among others. Some certain objects are write-protected in normal operation-mode.


Publish date