Integrating standard signals into functional safety

Non‑binary signals such as analog inpurts and encoder readings are very common and should be incorporated into safety programs.

Electrical safety systems experienced a breakthrough in the mid‑1990s with the advent of the IEC 61508 standard. Titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety‑rated Systems, it effectively allowed microprocessor‑based controllers to be used within safety circuits, thereby ushering in the era of functional safety.

Prior to the release of IEC 61508, users were forced to resort to safety circuits that were all hardwired. These were far more cumbersome to build and difficult to fault‑find, but the heavy regulation demanded by the laws around workplace safety meant there was no choice.

Programmable controllers on the other hand give users far more flexibility when designing safety‑rated systems. They are faster to create, simpler to change and easier to duplicate. The move towards programmable safety is much like the transition away from hardwired relay circuits to PLCs that occurred several decades earlier.

Controller safety ratings

Safety Integrity Level (SIL) as defined by IEC 61508 is a measure of a component’s reliability — the more reliable it is, the less likely it is to fail dangerously, and the higher its SIL rating will be. Modern safety controllers can achieve ratings of up to SIL 3, and many also comply with Category 4 (EN 954-1) and PLe (Performance Level e, according to IEC 13849‑1). Such high levels of protection are attained by implementing a series of measures, such as extensive self-diagnostics and internal monitoring of voltages, on‑times, temperatures and more.

Additionally, both CPUs and compilers utilise the concept of ‘diverse redundancy’. This is where a program is compiled using two dissimilar compilers, often produced by different vendors. Each compiled program is then run independently but in parallel, using two dissimilar CPUs, again usually manufactured by different vendors. The result of each program is compared at the end of every execution cycle, with the system resorting to its safe condition in the event of any discrepancies.

Safety processing

Many safety controllers still operate exclusively with digital signals, which adhere strictly to only on and off conditions. Binary devices, such as switches and sensors, are connected to input terminals and are evaluated for their high or low logic state. The program then determines an output state of either on (the active state where the machine can safely run) or off (the safe state, where outputs are watt‑less, causing at least part of the machine to stop).

However, most industrial applications also use continuously varying signals, such as analog values for level or pressure, load cell analysis, temperature measurements and the like. Encoders are also commonly used for rotating devices, and these produce their own unique signal types, such as EnDat absolute encoders.

None of these signal types are binary, meaning most safety controllers have no means of evaluating them. Yet they are an integral part of the overall system and should therefore play a role in the decision-making process within the safety controller. Ideally, it should be possible to incorporate these signal types into a safety controller in a cost‑effective way.

Incorporating standard I/O into safety systems

While standard PLC signals are not safety rated, they can nonetheless be used in safety circuits for non‑critical purposes, such as resets. It’s also possible to integrate standard non‑binary inputs, such as analog values, as shown in Figure 1. Certain usage protocols will, however, need to be strictly followed. It is also important to note that once standard signals are introduced into a safety system, the overall safety will be derated to a maximum of SIL 2, Category 3 and PLd.

Figure 1: Standard non binary inputs, such as analog values, can be incorporated into a safety circuit. For a larger image click here.

It is vital that users understand the safety ratings of their machinery, and how it compares with the PLr (Performance Level requirement), as stipulated by the risk assessment made for that machinery (as per ISO 12100:2010). Furthermore — as with the implementation of any safety system — users must closely follow all documentation produced by the product vendors. No guarantees of operation or protection levels can be made if vendor documentation is not properly observed.

The sensors in the field do not need any official certification be used in safety systems, although they must follow the rule of divergent redundant channels. This means that for every non‑binary input, at least two sensors must be installed for redundancy. These sensors must also be of a different type and be wired in isolation to each other. They must connect to different terminals, at least one of which must use a safety‑rated protocol to communicate to the safety controller.

The requirement for divergent redundant sensor handling is to overcome common-cause failures (CCFs), where a single event or shared factor causes multiple sensor failures. One example is where an RTD sensor fails when the temperature it’s measuring exceeds a certain level. If two of the same sensor types were used, then both would fail. But this situation can be avoided by using different temperature sensors, for example a thermocouple as well as an RTD.

CCF is also the rationale for utilising separate compilers, each generating their own code, to execute on divergent CPUs.

Programming functions

Figure 2 shows how a safety controller can evaluate redundant analog signals via a three‑stage process: scaling, validation and limiting. Each input signal is scaled individually to ensure integer values are used (to avoid ambiguity caused by differences in precision) and are bounded correctly (to avoid overflows that subsequent multiplication operations could cause). A watchdog ensures values continually deviate slightly, so that inputs that are ‘stuck’ at values can be detected, as this could suggest faulty sensors.

The output format of the scaling functions allows the input signals to be compared directly to each other in the second stage. If the deviation between the signals is excessive, the inputs are deemed invalid — meaning the safety output will fall back to its safe state. Both the amount of deviation and the tolerance time are set within the function block, the latter allowing for some settling time of the signals.

A comparison function block can accept up to five divergent inputs, all measuring the same parameter in the field. Users can select majority inputs between either 1oo2 (one of two), 2oo3 (two of three) or 3oo5 (three of five) for its validated output signal.

Figure 2: Evaluating redundant and divergent analog signals in a safety controller. For a larger image click here.

The final stage is the limit test, to confirm if the (validated) input level falls within a specified range. Both minimum and maximum values can be set, either as parameters within the function block or as inputs. While inputs can be varied during program execution, care should be taken as to the source of the input signal. The limit function block provides three outputs: below, in-range and above the specified limits.

Although this example only shows an analog value, other signal types such as temperature and encoder inputs are handled in a similar way. Many safety-rated function blocks exist, including arithmetic operations (for addition, division and the like) and motion operations (such as speed limiting and cam monitoring). Highly complex safety functionality can be created when using these function blocks in combination. Examples include SafeCounters, SafeSpeed, SafeLoadSharing and SafeEnvelopes.

It is permissible for one of the input sources to be derived internally from within software. Motion applications are an example of this, where the servo’s encoder reading (held within the axis) is used as the standard input. A secondary encoder still needs to be mounted in the field as the diverse channel. Importantly though, this means standard motors can still be used within safety circuits.

Conclusion

Non‑binary signals, such as analog and temperature inputs, and encoder readings, are very common in control applications. They should therefore be incorporated into safety programs, which ensure electrical systems remain safe to use. Where these signal types are handled in a safety controller, users are given a far richer set of tools to work with. While the maximum achievable safety ratings for these systems are reduced, they are still workable. These systems remain a cost‑effective safety solution for many users.

*Harry Mulder is the Principal Automation Engineer at Beckhoff Automation. He has been involved in industrial automation for over 30 years and is fascinated by how new innovations keep affecting the direction of the industry. He really enjoys the practical element of his job, where he has a chance to get his hands dirty!

Top image credit: iStock.com/Edwin Tan