Rockwell Automation T80016 User Manual

Trusted

AN-T80016

Application Note

Maintenance Override Programming

TÜV Rheinland publishes guidelines on the maintenance facilities of safety related programmable systems, currently available on the Internet at http://www.tuv-fs.com/modr_3_e.htm paper is not a compulsory part of safety system operation, it has been revised over many years and serves as a guide to sensible system design. The paper has been extended to cover maintenance facilities applied over communications networks.

Maintenance overrides are used to disable inputs or outputs from a safety related system for maintenance activities, to avoid trip actions caused by spurious signals or logic tests. The preferred method for applying overrides is by hardwired switches on a panel, either via inputs to the safety system application or directly affecting the circuit. Whilst this is the most secure method, it is also inflexible; there may not be room for all necessary switches and modifications to the switch panel are complex and expensive.

. Whilst this draft

This document describes methods for implementing maintenance override facilities using programming and communications, within the TÜV guidelines.

Issue Record

Issue Number

1 June 08 Nick Owens Andy Holgate Pete Stock Initial Issue

Date Revised by Technical

Check

Authorised by Modification

Issue 1 June 08 AN-T80016 1

Trusted

AN-T80016 Maintenance Override Programming

Maintenance Override Programming

A maintenance override can be equally applied to inputs or outputs. This may also be described as an inhibit. Strictly speaking an ‘inhibit’ prevents something happening whereas an ‘override’ applies a forced state, but these two words tend to be used nearly interchangeably.

Toolset Debugger Tools

The Toolset allows input and output variables to be locked, which disconnects them from the real I/O. The downstream side of the disconnection may then be manipulated through the Toolset (for inputs, the application variable is manipulated, for outputs, the real output is manipulated).

Locking should only be used during offline testing and when the plant is not live; it should not be used as a maintenance override facility. The Processor will not hot-swap with locked variables present.

Do not use the Toolset debugger to apply overrides to a system connected to live plant. Preprogrammed maintenance override logic with security measures should be used, as described below.

Maintenance Override Programming TUV Requirements

This section lists the specific clauses from TUV’s paper which apply to maintenance override programming. It recommends methods for implementing each clause.

The following section gathers the recommended methods together into a programming specification for the safety system side of the maintenance overrides.

The TUV paper contains general details about security and the integrity of engineering tools; it is written for any possible implementation/permutation of tools for programming, debugging, commissioning, maintenance and operation. One sentence from these sections is worth applying to maintenance override programming.

1. Additional requirements must also be in place that guarantee security

This is best interpreted as ensuring that communications transactions are secure, since the paper also considers ‘authorisation’ and ‘enabling’ separately (clause 4 below).

There is no perfect way to guarantee communications security; opening a route to diverse transactions means that there is always a probability that one genuine transaction could be mutated into another genuine transaction. Packet checks and command validation will not help in this case.

The best method to improve data security therefore is to require human validation of the request. If the command is sent from DCS to system by one tag, and a specific acknowledgement is sent back to the DCS by another tag, then the operator can check that the right acknowledgement has been received. The chances of both messages being corrupted (so that the system sees one override request but the operator sees another) are much smaller than the chances of either one message being corrupted. This also fits well with the need for confirmation described in clause 5 below.

2. The maintenance strategy and procedures need to be established before or during application engineering

Overrides should not be an afterthought or applied using uncontrolled unplanned methods. The application should include override programming.

3. While the PLC application program is being created it should be determined whether later on it will be allowed to override a particular signal.

All safety related I/O should have a maintenance override. This allows any point to be manipulated without causing spurious trips. Maintenance overrides should also be considered for I/O that does not

Issue 1 June 08 AN-T80016 2

Trusted

AN-T80016 Maintenance Override Programming

have a part in ESD or F&G actions, but which may cause a significant nuisance if accidentally tripped (e.g. control room alerts).

4. 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.

The Maintenance Override Enable is a secure way of ensuring that overrides can only be applied under the site authorization procedures. Since it is only one or a limited number of points, it is usually implemented with a panel keyswitch; this is secure and easily accessible. The statement above also

llows for a DCS-based Enable. This application note advises that this should be considered only if

a there cannot be a keyswitch (e.g. for remote servicing); note the comments on override removal in clause 10 below.

Beyond requiring an Enable, the statement above is quite open. The Enable must be active to allow overrides to be set, but it can be implemented equally as a pre-requisite (must be set before overrides may be set) or as a final authorisation. There is no indication whether removing the Enable will also remove all maintenance overrides; however this is the common interpretation when the Enable is a pre-requisite (see clause 10 below).

5. Because of organizational measures the operator should confirm the override condition.

This prevents accidental application of overrides, providing a measure of security. This application note recommends that this is tied in with the suggested method for security in clause 1 above, where the command and acknowledgement must agree before the override can be applied.

This command – acknowledgement security has one disadvantage. If a command is sent, acknowledged and not confirmed, then the transaction remains permanently waiting and may be inadvertently completed in the future. This application note recommends that if an override is not acknowledged within a time window, the transaction is reset. The window is typically 30 seconds which allows for decision making time and communications/graphics delays.

6. 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.

This also does not allow variable locking. Overrides must be applied in a planned controlled manner.

7. Multiple overrides in a PLC are allowed as long as only one override is used in a given safety related group.

A safety related group is a set of I/O that has the same safety function. For example, do not allow the override of more than one of a set of three gas detectors in a group of three, or allow all high pressure safety alarms to be overridden for a vessel. Ensure that the process is still protected. The definition of ‘safety related group’ should be limited to all devices supplying the same or similar detection/protection to the same or associated safety parameter (level, pressure, fire, gas) in the same or in linked areas.

8. The alarm shall not be overridden. It should always be clear that signals are in a maintenance condition.

This statement is referring to the alarm raised at the DCS to indicate an active maintenance override and would make more sense if it followed clause 9. However, clauses 10 and 11 imply a similar requirement on the safety system that the operator must be still aware of the alarm state during the override of an input.

Keep the DCS alarm separate from the overridden safety point (do not use the safety point as the DCS alarm). The DCS alarm should still indicate when the input is in alarm. This will create nuisance alarms during maintenance, but the operators will be aware of the maintenance through the site permit system and can check if the alarm is genuine.

9. The PLC alerts the operator (e.-g. via the DCS) indicating the override condition. The operator will be warned until the override is removed.

See clause 8. The presence of an override should be clear to the operator, e.g. by an alarm and an entry in the event log. The second clause is sometimes implemented as a returning alarm alerting the operator every new shift, so that new personnel do not have to hunt through hundreds of historical alarms to be aware of override status. Some sites demand that permits are suspended and overrides

Issue 1 June 08 AN-T80016 3

Trusted

AN-T80016 Maintenance Override Programming

are removed at the end of a shift; in this case the fresh re-application of an override will automatically generate a new alarm.

10. During the period of override proper operational measures have to be implemented to assure that the intervention can be removed again.

Removing the override should be guaranteed. A suggested solution is to ensure there is more than one way to remove overrides. In addition to individual override removal procedures, removing the Maintenance Override Enable could remove all overrides that it enables (see clause 4 above). This is a typical solution.

However, if the Maintenance Override Enable is based in the DCS, and the DCS fails with overrides still set, there is no remaining secure way to remove overrides. This is a good reason to make the Maintenance Override Enable a hardwired keyswitch instead of a DCS operation.

11. 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.

This is linked to clause 7 above. If it is not possible to assure supervised safe operation within the safety system using multiple monitoring points for the same safety function, then manual monitoring (e.g. a firewatch) or a partial shutdown is needed; these ‘operational measures’ are outside of the system’s scope.

12. 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.

This is often overlooked. It is possible to cancel overrides using the Toolset online debugger; the DCS alarm and override indication will quietly disappear. Application changes could also cause the system to ‘forget’ applied overrides. In addition to the override control in the system, there must also be functions running in the DCS that highlight dropped or unauthorized overrides. This could either be via scripts that generate alarms or by graphical indications that make the discrepancy obvious, e.g. a partly coloured icon on an override summary page. A script is better because it doesn’t require the override summary page to be permanently visible.

13. 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:

o the time stamp of start and end of maintenance override

o the ID of the person who activated the maintenance override - maintenance engineer

or operator

o If the override information cannot be printed online (preferred), it should be entered in

the work-permit

o the tag name of the signal being overridden

This requires an event log; on newer systems this is more likely to be on disk than on paper. The DCS will record the currently logged-in username as the ‘ID’.

Issue 1 June 08 AN-T80016 4

+ 8 hidden pages