Rockwell Automation T80016 Application Note Maintenance Override Programming - Manual (Page 2)

Trusted TM
AN-T80016 Maintenance Override Programming
Issue 1 June 08 AN-T80016 2
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. Pre-
programmed 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