Improving Safety and Security with Automation MOC

Technology
Improving Safety and
Security with Automation MOC
Continuous improvement in pipeline operations is dependent on frequent automation parameter
changes, but these are often excluded from Management Of Change (MOC). This article will
explore how process safety can be maintained pipelines by including multi-vendor automation
systems in a rigorous MOC process.
In 1931, Herbert William Heinrich who was the
Assistant Superintendent of the Engineering
and Inspection Division of Travelers Insurance
Company wrote a revolutionary book entitled
Industrial Accident Prevention, A Scientific Approach.
His research became the basis for the theory of
“Behavior-based safety”Behavior-Based Safety, which
seeks to minimize accidents by eliminating at-risk
behaviors in the workplace.
Others have expanded upon Heinrich’s work over
the years, and in 2003 ConocoPhillips Marine released
a bellwether study reinforcing the connection
that Heinrich found between workplace behavior
and accidents. Stunningly, ConocoPhillips Marine’s
study found that for every fatality there may be as
many as 300,000 human errors and at-risk behaviors.
The message of these studies is that fatalities, lost
Figure 1. Safety Pyramid © ConocoPhillips Marine 2003
workdays, recordable injuries, and near misses can
only be eliminated by focusing on the at-risk behaviors,
which are their root cause.
The term at-risk behavior would seem to imply recklessness
or even wrongdoing. The truth is however, that
at-risk behaviors most often consist of honest mistakes
made with only the best of intentions. Often, decisions
and actions are required right away, and without full
knowledge of all the information necessary to ensure
their correctness. The inevitable result is mistakes,
which contribute to the inventory of at-risk behaviors.
One commonly employed process to reduce the
number and scope of human errors, is Management Of
Change (MOC). It is a core process for managing
modifications to such things as infrastructure and equipment,
and although it can consume significant amounts
of time and resources, it is generally credited with
improving safety. However the proper management
of automation changes is generally not fully addressed
in MOC regulations, such as the Singapore Standard
SS 506 Part 3. As a result, most automation systems
operate with significant vulnerabilities associated with
poor automation change management. And most are
unaware of these vulnerabilities.
Automation MOC
Automation systems in modern plants are extremely
complex. Their data resides in disparate systems,
databases, measurement devices, and applications,
all of which undergo continual change as improvements
are made in the pipeline. Generally, if an
50 JULY-SEPT 2012 Visit our websites at www.safan.com

automation change affects a drawing or other entity
currently under change control, then an MOC case
is initiated. Otherwise, robust change management
most likely does not occur. As automation systems
directly control the process, the wrong modifications
to them could have a tremendous negative impact
upon safety, economics, environmental compliance,
and reliability. (It should be noted that certain types
of routine parameter modifications, which are core
to daily process operations, such as changes to
setpoints, control modes, and manual outputs, must
necessarily be an exception to the MOC process.)
Undocumented and unapproved changes to automation
systems have been identified as contributing
factors to a number of recent industry incidents
and accidents. And, with the advent of new viruses
that can affect the interaction of control systems
with the process, ensuring that every automation
configuration change is detected and then reconciled
with an approved management of change
(MOC) case in a timely manner has become a
crucial element of control system security.
A major complaint concerning the traditional MOC
process is the great consumption of time and resources
necessary to be compliant with regulations.
This is a considerable impediment to the full adoption
of MOC for automation, in that the process
takes more time and energy to implement than the
time required to make the actual automation changes,
and so seems excessive by comparison. The ratio of
work to benefits is perceived to be skewed heavily
toward work and away from benefits, and so MOC
for these types of changes is often excluded from the
work process.
An incident caused by unmanaged automation
change recently occurred at a petroleum refinery
(this could easily be translated to a pipeline) operated
by one of PAS’ clients. A specific process
measurement was oscillating into and out of the
alarm state, creating a nuisance for the process
operators. It was noted that the measurement excursions
past the alarm trip point were both small in
amplitude and duration, so the operating supervisor
raised the high alarm trip point in order to eliminate
the nuisance. However, unknown to him, the new
level at which he set the alarm was above the safety
shutdown trip point. A short time later, the unit
unexpectedly shut down.
It is possible that a traditional MOC process could
have prevented this incident through its regimen of
peer reviews, approvals, and pre-startup safety reviews.
However, routine automation changes occur
so frequently that the sheer volume of MOC cases
would quickly overwhelm staff. In a scenario, such
as the one above, the amount of MOC-related work
is so much greater than the effort to simply type in
the new parameter, that traditional MOC would
simply not be practical.
So this situation presents a dilemma. To ensure
that only safe and appropriate modifications are
made to configurations, each change, whether to
the actual configuration or to the underlying computing
infrastructure, must be under strict MOC
control. However, the traditional MOC process is
untenable for general use with automation. A shorter,
more streamlined, MOC process that evaluates,
approves and tracks all changes, but does not entail
more effort than the modification itself is clearly
needed for most parameter-only automation configuration
modifications.
But, since most automation configuration changes
are parametric in nature, and can easily be changed,
how can we be certain that all modifications were
made under MOC control? How can we be assured
that an unapproved, and potentially dangerous
modification has not slipped into our systems? One
possible answer is if the automation databases were
continually monitored for changes and compared to
already approved MOC cases to determine if those
changes were actually authorized. In this scenario,
any changes that do not reconcile with a specific
MOC case, would therefore be considered unapproved
and thus require investigation.
Integrity Software and Intelligent MOC
Integrity Software from PAS does exactly that. First,
it imports the entire automation configuration database
at regular intervals and compares it to the
database image taken during the last import. It then
tracks and reports on all changes made between
import intervals. While most automation system manufacturers
are able to track changes within their own
JULY-SEPT 2012 51

systems, Integrity software does so across system
boundaries, and is therefore able to track signal
genealogy throughout integrated systems. A common
example of a signal crossing the boundaries of
interoperable systems is a safety transmitter that is
connected to a Safety Instrumented System (SIS),
which passes the measured value to a Distributed
Control System (DCS) for display, which in turn
passes it to a process historian for archiving. Integrity
software provides this signal mapping and
change tracking for over 50 different automation
systems as well as their Microsoft Windows©- based
underlying architecture.
An optional application for Integrity Software,
iMOC provides the next necessary aspect of the
automation MOC solution. It
is an intelligent management
of change application designed
specifically to address
the special needs of automation.
iMOC provides robust
management of change capabilities
that are easy to engineer
and use, but more
importantly reconcile the
changes detected by the Integrity
Change Tracker with
the specific MOC cases that
authorized them. This capability
ensures that all unapproved
automation changes
are identified to system administrators,
and reports of unreconciled changes
are automatically generated.
Simplified MOC
As discussed above, the traditional MOC process is
impractical for most automation modifications. In
situations where an automation change does not also
involve modifications of equipment, drawings, procedures
or other items under change control, PAS suggests
a special classification of the MOC process that
is initiated, approved and closed out by the automation
professional that actually makes the change. This
process would employ a simple checklist form that
would describe the change, include the necessary
approvals, and be electronically signed by the person
making the change. It is assigned a tracking number
and saved as an MOC case by the iMOC software,
and then on the next import of the configuration
database by the Integrity Software, the modifications
are reconciled with the MOC case that authorized
them (Figure 2). A report of all unreconciled modifications
is generated so that unauthorized changes are
immediately identified and communicated to the responsible
parties. Those unreconciled changes may
then be either accepted as they are or a new MOC case
may then be created to authorize changing them back
to an acceptable state. With minimal effort, this process
ensures that no unauthorized changes remain in
the automation systems.
Figure 2. Reconciliation of Modifications to a Specific MOC Case
Clearly this simplified MOC process is not appropriate
for all MOC classifications, so the iMOC Workflow
Builder provides the ability to develop different templates
for various types of workflows. For example,
there is a class of automation modifications that affect
drawings, procedures and other items, and therefore
requires a longer, more complicated workflow. These
other variations in workflow templates are then associated
with the appropriate work classifications, and
are selectable from a menu as MOC cases are initiated.
Figure 3 is an example of one of these longer
workflow templates under construction in the iMOC
Workflow Builder. The MOC workflow is composed of
elements called states and transitions. States are repre-
52 JULY-SEPT 2012 Visit our websites at www.safan.com

y automatically identifying and
cross-referencing all configuration
linkages and places where
an automation parameter is used.
This feature significantly speeds
preparation of RFCs by reducing
the time spent researching the
scope of the change, and also
ensures that no critical use of the
parameter under change is omitted
from the process.
Figure 3. An MOC Workflow under Construction
sented by the rounded rectangular boxes, while transitions
are represented by the arrows. Each state may
have a checklist associated with it that comprises
various user-selected elements such as checkboxes,
data-entry fields, attachment boxes for attaching documents,
expression boxes for calculations and electronic
signature boxes for recording approvals and
completions. Transitions contain the logic that either
moves the case to the next state or routes it to an
alternate path.
Engineers spend a substantial amount of time acquiring
approvals in order to initiate cases, move them to
the next phase, or close them out. Integrity iMOC
reduces time spent gathering approvals by using Web
2.0 technology to “push” them to the approvers. Userdefined
approval logic may be applied so that for
example, if a primary approver is unavailable, a secondary
approver would automatically receive the approval
request. And, if the approvers don’t respond in
a timely manner, iMOC reminds them that they have
an outstanding approval task. These features provide a
significant reduction in time spent on non-value-added
activities associated with the MOC process.
iMOC software also helps reduce engineering time
spent on preparing initial Requests For Change (RFC)
Conclusion
While MOC is a core process
in process industry plants around
the world, the amount of effort
required to implement it for typical
automation changes is so disproportionate
to the changes
themselves that is not always applied.
This practice leaves infrastructure
vulnerable to unapproved, undocumented,
and potentially even malicious changes made to their
automation systems. Only through a program of rigorous
MOC that reconciles automation changes to
the MOC cases that authorized them, can unapproved
or undocumented changes be eliminated as a
cause of incidents. The Integrity and iMOC applications
from PAS work in harmony to provide rigorous
MOC that reconciles automation changes with minimal
effort, and thus improve the safety and security of
your process automation.
PP
This publication thanks Mr. Chris
Lyden, President of PAS for providing
this article. Prior to PAS, Mr.
Lyden spent 26 years at Honeywell
and held several executive positions
including Vice-President of Sales for Honeywell
HiSpec Solutions and Vice-President, General
Manager. In addition, Mr. Lyden worked at
Invensys Process Systems as Vice President of
Global Marketing where he served on the leadership
team which helped restore the company
to financial health.
JULY-SEPT 2012 53