What Are Best Practices and Standards for Control

Narratives?
The following technical discussion is part of an occasional series showcasing
the ISA Mentor Program, authored by Greg McMillan, industry consultant, author
of numerous process control books, 2010 ISA Life Achievement Award recipient
and retired Senior Fellow from Solutia Inc. (now Eastman Chemical). Greg will
be posting questions and responses from the ISA Mentor Program, with
contributions from program participants.

In the ISA Mentor Program, I am providing guidance for extremely talented

individuals from Argentina, Brazil, Malaysia, Mexico, Saudi Arabia, and the USA.
This question comes from Adrian Taylor. Adrian Taylor is a process control
specialist at Cristal.

Adrian Taylor’s Question

At the place I work we are typically good at documenting how we configure our
controls in the form of DDS documents but not always as good at documenting
why they have been configured that way in the form of rigorous control
narratives. We now have an initiative to start retrospectively producing detailed
control narratives for all our existing controls and I am looking for best practice,
standards and examples of what good looks like for control narratives. I
wondered if you had any good resources in this regard or you could point me in
any direction. (I did look at ANSI/ISA-5.06.01-2007 but this seems more
concerned with URS/DDS/FDS documents rather than narratives).

Hunter Vegas’ Answer

We do a lot of DeltaV systems and we use 3 different ways to “document” the

control system. As a system integrator “document” for me may mean something
than different than for you so let me explain that these documents are my way
to tell my programmers exactly how I want the system to be configured. These
documents fully define the system’s logic so they can program it and I can test
against it.

As I said there are three parts:

1. Tag List
2. Logic Notes
3. Batch Flowsheets
Obviously batch flowsheets do not apply if your system isn’t batch but the same
flow sheets can be used to define an involved sequence.

The tag list is simply a large excel spreadsheet that includes all of the key
parameters – module name, IO Name, tuning constants, alarm constants, etc. It
also includes a “comment” cell that can include relatively simple logic like “Man
only on/off FC valve with open/close limits and 30 sec stroke” or “analog input”
or “Rev acting PID with man/auto modes and FO valve” etc. Most of the modules
can be defined on this spreadsheet.

Join the ISA Mentor Program

The ISA Mentor Program enables young professionals to access the wisdom
and expertise of seasoned ISA members, and offers veteran ISA professionals
the chance to share their wisdom and make a difference in someone’s
career. Click this link to learn more about how you can join the ISA Mentor
Program.

The logic notes are usually a couple of paragraphs each and explain logic that
is more complicated. Maybe we have an involved set of interlocks or ratio or
cascade logic. If I have a logic note I’ll reference it in the tag list so the
programmer knows to look for it.

The flow sheets are the last part. I usually have a flow sheet for every phase
which defines the phase parameters, logic paths, failures, etc. (See Figure 1 for
an example of an agitate phase.) Then I create a flow chart for every recipe
which defines what phases I am using and what parameters are being
passed. (See Figure 2 for an example of a partial recipe.)

Hiten Dalal’s Pipeline Feed System Example

I find the American Petroleum Institute Standard API RP 554 Part 1 (R2016)
“Process Control Systems: Part 1-Process Control Systems Functions and
Functional Specification Development” and the ISA Standard ANSI / ISA
5.06.01-2007 Functional Requirements Documentation for Control Software
Applications to be very useful. ANSI/ISA95 also offers guidance on “Enterprise -
Control System Integration.” These types of documents in m y opinion help
include the opinion of all stakeholders in the logic without the stakeholder having
to be familiar with flow charting or logic diagrams or specific control system
engineering terminology. The functional specification in my opinion is a
progressive elaboration of a simple process description done by the process
engineer. Once finalized, the functional specification can be developed into a
SCADA/DCS operations manual by listing normal sequence of operation along
with analysis of applicable responsibility such as operator action/responsibility,
logic solver responsibility, and HMI display. You may download my example of
a pipeline control system functional specification: Condensate Feed Pump &
Alignment Motor Operated Valves (MOVs).
Figure 1: Control Narrative Best Practices Agitator Phase
Figure 2: Control Narrative Best Practices Recipe Sample
Flowchart control narrative