Safety Limiter

Context

Safety function architecture is being designed. The SEPARATED SAFETY pattern has been utilized so that the control system functionality is divided into two separate systems: basic control system and safety system. However, the systems may share information. Amount of hardware needs to be minimized and thus no dedicated actuator or

other supporting hardware for the safety system can be added. To retain safety in all situations the safety system has to have full control over the process variable(s) affecting safety.

Problem

Safety system and basic control system control the same process quantities.

Consequently, the basic control system may interfere with operation of the safety system, but the safety system must have the final word on system operation.

Forces

Safety: Safety control system must always be able to drive the system into safe state (i.e. state in which system minimizes the risk of damaging itself or people around it) regardless of the state of the basic control system

Safety: Safety function is very context specific and may require arbitrary controls System independence: Separation between basic and safety control systems can be compromised

Hardware: Additional hardware is problematic (e.g. in terms of space and weight) Software: Software has no drawback of hardware in terms of spatial requirements and can be duplicated for free in mass produced devices

Cost-efficiency: Additional separate actuator for safety system increases cost

Functional Safety System Patterns 16

Hardware: Actuators with sufficient safety properties and suitability to safety and control tasks are available

Solution

Disengage the basic control system completely from the control/safety actuator.

Calculate the control signal in basic control system and limit the value with safety system. Provide the control value calculated by the basic control system to safety system that checks the safety conditions and limits the control value to safe range if necessary. The safety control system controls the actuator.

An illustration of the architecture is provided in Fig 8. The basic control system calculates the control value for the actuator. The basic control system may use any kind of algorithm freely from restrictions of safety regulations according to which the safety system has to be developed. The basic control system then passes the control value to the safety system. The purpose of the safety system is to limit the control value so that safety is retained. The safety system is developed to conform with safety regulations so it shouldn’t contain any unnecessary functions. The safety system alone is connected to the actuator.

The basic control system’s controller and the safety systems controller can either be separated devices or a single device running both safety-critical and non-safety-critical functions. The latter approach requires additional measures to be taken (see Related Patterns). The actuator needs to have sufficient capabilities to satisfy the safety standards’ requirements and it must also be suitable for the control task. Thus the actuator may prove expensive.

If the SEPARATED SAFETY pattern has been applied, no additional actuation hardware is allowed and use of the DE-ENERGIZED OVERRIDE pattern cannot be applied due to operation of the safety function (no single safe state position can be defined), the solution is the only considerable approach. Another possibility would be development of whole control algorithm according to safety requirements, but this results a costly development process and violates the SEPARATED SAFETY pattern.

Data communication from basic control system to safety control system is always a potential risk from safety control system’s point of view. However, the systems may communicate if certain conditions are met. Consequently the software architecture of safety control system needs special attention. These conditions are not too restrictive as in general communication through global data or similar data structure is not

Actuator Safety system Basic Control

system

Fig 8. Principle of software safety limiter based basic control system override Uncontrolled

quantity

Controlled and safety limited

quantity

Functional Safety System Patterns 17

recommended. Communication should be established through a well-defined interface e.g. a class method or message bus message (with strict structure).

Example

A potential application for the pattern is usage in situation in which operator controls movement of a machine (or part of it). Let’s consider a modern combat aircraft. A pilot controls the (instable) aircraft by indicating the direction she wants the plain to steer. The basic control system then calculates how the winglets need to positioned to steer the aircraft into desired direction. However, the pilot can only withstand limited amount of g-forces so the aircraft protects pilot by restricting the aircraft movement with additional safety system¹.

The architecture of the system can be as follows. The pilot steering inputs are first processed by the basic control system, which uses advanced algorithms to calculate optimum control values for the winglets (actuators). This includes at least the basic stability considerations and some other functionality such as ramping of the values.

As the calculations complete the value is passed to the G-force protection safety function. The G-force protection then calculates the amount of force observed by the pilot. If the protection function notices that too great strain is directed into the pilot it can restrict the control value. The architecture of the system is illustrated in Fig 9.

Fig 9. Combat aircraft steering control with safety limiting functionality Consequences

Complex basic control algorithm can be used without need to develop them according to safety standards

Advanced safety functions can be established through software based safety functions. Certain type of safety functions are very hard to implement with hardware solutions such as restricting motion into complex shaped space.

1 Ok, the software of a combat aircraft is probably safety-critical all the way (or at least developed as one), but for the sake of this example we consider these control tasks as separate functions. In practice the stability of the plane is probably prioritized over G-force protection, but we don’t cling into this little drawback. The functionality could be, however, used during training for instance.

Functional Safety System Patterns 18

No need for dedicated safety actuator

The solution is cost-effective especially when system is mass produced as software is cheaper to multiply than hardware

- Breaks separation between safety and basic control systems, but if implemented rationally, strong (though not complete) independence can still be achieved

- The safety system may increase the delay in control compared to situation without additional safety controller between the basic controller and the actuator

- Data communication from basic control system to safety control system inflicts a potential risk…

- … and thus software architecture of the safety safety-critical system and the data communication in general requires special care due to data obtained from system that doesn’t conform with safety standards

Resulting Context

The basic control system is disengaged from the actuator. The safety controller has full control over the actuator and can override the basic control system’s control signal. A dependency between basic control and safety system is created and basic principle of the SEPARATED SAFETY pattern is violated.

Related Patterns

The DE-ENERGIZED OVERRIDE pattern describes an alternative solution to similar problem. The pattern describes how safety and basic control system can use shared actuator without need use data communication between safety and basic control system controls. However, number of possible safety operations is restricted to one, i.e. only one safe state can be obtained.

The SEPARATED OVERRIDE pattern describes an alternative solution to similar problem. Safety system is provided with dedicated actuator. This gives safety system more alternatives to actuate the safety function and provides complete separation between basic control and safety systems. However, the approach requires additional actuator.

The SHARED CONTROLLER pattern describes how dedicated safety and basic controllers can be merged into one device and thus decrease the total device number even further.

The CASCADED SAFETY CALCULATION pattern describes what kind of software architecture can be used to manage input stream from basic controller while doing versatile safety considerations and limitations affecting single actuation unit according to the basic controller’s initial control values.