What Are Best Practices and Standards for Control Narratives?

The post What Are Best Practices and Standards for Control Narratives? first appeared on the ISA Interchange blog site.

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.

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

We are mainly DeltaV now.

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.

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.

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

 

Figure 1: Control Narrative Best Practices Agitator Phase

 

Figure 2: Control Narrative Best Practices Recipe Sample

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 my 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).

See the ISA book 101 Tips for a Successful Automation Career that grew out of this Mentor Program to gain concise and practical advice. See the InTech magazine feature article “Enabling new automation engineers” for candid comments from some of the original program participants. See the Control Talk column “How to effectively get engineering knowledge” with the ISA Mentor Program protégée Keneisha Williams on the challenges faced by young engineers today, and the column “How to succeed at career and project migration” with protégé Bill Thomas on how to make the most out of yourself and your project. Providing discussion and answers besides Greg McMillan and co-founder of the program Hunter Vegas (project engineering manager at Wunderlich-Malec) are resources Brian Hrankowsky (consultant engineer at a major pharmaceutical company), Michel Ruel (executive director, engineering practice at BBA Inc.), Leah Ruder (process systems automation group manager at the Midwest Engineering Center of Emerson Automation Solutions), Nick Sands (ISA Fellow and Manufacturing Technology Fellow at DuPont) and Bart Propst (Process Control Leader for the Ascend Performance Materials Chocolate Bayou plant).