The post What Are Best Practices and Standards for Control Narratives? first appeared on the ISA Interchange blog site.
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.
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:
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.)
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).
Source: ISA News