TÜV Cooperation Functional Safety (Home)

Preface to Draft Version 3.0

This version specifically addresses:

• Maintenance by use of tools (PC/Laptop/workstation/DCS)
• Maintenance by use of public networks (Internet, communication networks, RF-networks, remote servicing)
• General requirements for safety-related communication protocols.
• Security aspects in addition to safety-related communication.
• Availability aspects.
• Change of system data (set-points, parameter, etc.).
• Exchange of sensors and actuators and related modification of the application programs.

Not all aspects are yet addressed in this draft. Comments and suggestions that can improve this maintenance override paper in terms of safety are very welcome.

Introduction
The purpose of this document is to describe the procedures for the use of maintenance override of safety related programmable electronic systems, like sensors, controllers, and actuators. The document also shows how to overcome safety problems and the inconvenience of hardwired solutions.

Maintenance Override
There are basically two methods in use to check safety relevant peripherals connected to PLC's:

• Special switches are connected to the inputs of the PLC. These inputs are used to deactivate sensors and actuators that are under maintenance. The maintenance condition is handled as part of the application program of the PLC.
• During maintenance sensors and actuators are electrically isolated (disconnected) from the PLC and checked manually by special measures.

In some cases, for example, where space is limited, there is the desire to integrate the maintenance console to the operator display, or to have the maintenance condition covered by other strategies. This introduces a third alternative:

• Maintenance overrides initiated by serial communication to the PLC.

The available maintenance options and communication protocols must be part of the TÜV Type Approval of the safety system in order to be applied safely. If communication takes place over open networks, then in addition to the functional safety requirements additional requirements must also be in place that guarantee security. The end user needs to take into account the advice described in the safety manual.

This option is to be handled with care and further explained in this document.

We strongly recommend to keep the tools for programming and debugging separate from the tools used for maintenance override. The engineering workstation, which is used for programming, should not be used for maintenance.

Procedure for Maintenance Override
The use of non-approved maintenance tools demands a complete test of the requirements after any change has been made. The thoroughness of the test is equal to the initial acceptance test. The tests should not only focus on the changed programmed parts but also on the non-changed parts, as it cannot be guaranteed that these changes do not have an impact on the unchanged parts. Because of the cost associated with this it is often not feasible to use non-approved tools.

When using approved tools it is possible to make changes to the program taking into account the appropriate measures to maintain the required safety integrity level. After changes are being made to the program it is possible to carry out limited verification activities if this is confirmed based on the analysis of the required regression tests.
The procedures required for override or online changes must be described in the safety manual.

Approved tools generally meet the following requirements:
 

• They incorporate measurements to control random failures when the program is created or changed.
• They incorporate measurements to control random data communication failures to the PLC.
• They were developed using version maintenance and control tools.
• They were developed using tools to verify changes.
• They were developed using tools to verify the program.

Communication is established using approved protocols. It is possible to use protocols that are universally valid for the current safety level (e.g., Modbus RTU) or vendor specific, proprietary protocols that have been taken into account during the type approval process of the PLC. In general it is only allowed to use tools that have been approved for their current use.

Guidelines to carry out Maintenance Override.
These guidelines apply mainly to application engineering and operation of a plant.

Application engineering:

1. The maintenance strategy and procedures need to be established before or during application engineering
2. While the PLC application program is being created it should be determined whether later on it will be allowed to override a particular signal.
3. Maintenance overrides are enabled for the whole PLC or a subsystem  (process unit) by the DCS or other applicable authorized procedures (e.g. key switch, or password authorization).

Note: “enabling” the overrides permits, but does not necessarily turn on the overrides.
4. Because of organizational measures the operator should confirm the override condition.
5. Direct overrides on inputs and outputs are not allowed (e.g., using clamps). Overrides have to be checked and implemented in relation to the application. Multiple overrides in a PLC are allowed as long as only one override is used in a given safety related group.

Operation:

1. The alarm shall not be overridden. It should always be clear that signals are in a maintenance condition.
2. The PLC alerts the operator (e.-g. via the DCS) indicating the override condition. The operator will be warned until the override is removed.
3. During the period of override proper operational measures have to be implemented to assure that the intervention can be removed again.
4. During the period of override proper operational measures have to be implemented to assure that the intervention into the process does not lead to unacceptable conditions.
5. A program in the DCS checks regularly that no discrepancies exist between the override command signals from the DCS and the override activated signals received by the DCS from the PLC.
6. The use of the maintenance override function should be documented on the DCS and on the programming environment if connected. The print-out should include:
• the time stamp of start and end of maintenance override
• the ID of the person who activated the maintenance override -  maintenance engineer or operator
• If the override information cannot be printed online (preferred), it should be entered in the work-permit
• the tag name of the signal being overridden