P&IDs show what is installed, but they do not say how the plant should behave when a pump trips or a level climbs too high. A clear written description of the control intent fills that gap before a single line of logic is written.
Every DCS and PLC project needs one document that says, in plain language, how the plant must be controlled. A well written control narrative aligns process, operations and programmers, and later becomes the yardstick for testing.
What Is a Control Narrative?
A control narrative is a written description, in plain engineering language, of how a process unit must be monitored and controlled, covering each loop, interlock, sequence, operating mode and alarm. It turns the static picture of a piping and instrumentation diagram into behaviour that a programmer can configure and an operator can understand.
The document is also called a functional description, a loop description or, in larger projects, part of the functional design specification. The names vary between companies, but the purpose is the same: agree what the system must do before anyone decides how to program it.
Cross Company, a US system integrator, says a typical control narrative defines all control loops, including range, description, alarms, graphic depiction, interlocks and automated logic. It also lists the equipment, the software items such as totalizers and calculations, and the concurrent tasks that run outside sequences.
Why Every DCS Project Needs One
Tetra Tech states that a functional specification defines how an automation or control system must operate, including its response during normal operation, edge cases and fault conditions. It advises developing the document before programming begins and keeping it as a living document as the system evolves.
Without a control narrative, programmers guess the intent from P&IDs and old logic, and the guesses surface as arguments during commissioning. With one, the process engineer, the operations team and the DCS function block programmer all work from the same words.
In an ISA Mentor Program discussion on Emerson Exchange 365, Hiten Dalal describes a functional specification as a progressive elaboration of a simple process description written by the process engineer. Once finalised, it can be developed into a DCS or SCADA operations manual.
9 Essential Sections of a Control Narrative
Section four should match how the system really switches modes, as explained in DCS control modes, manual, auto and cascade. State clearly whether a loop returns to auto by itself after a trip or waits for the operator.
Sections five to seven carry most of the value and most of the effort. Write them unit by unit, in the order the plant actually operates, so reviewers can follow the process from feed to product.
Give every control narrative paragraph a number such as 5.3.2 and quote the tag numbers it describes. Test sheets and punch list items can then point to an exact clause instead of a vague page.
Writing a Good Loop Description
A good loop description names the measured variable, the transmitter range, the controller action, the final element and its fail position. For a level loop on a feed tank, it would say that LIC 101 controls level between 0 and 100 percent by throttling LV 101, which fails closed, with a normal setpoint of 60 percent.
Advanced strategies need extra detail. A cascade control loop must say which controller is master, how setpoint tracking works and what happens when the slave goes to manual, and a split range loop must give the split points.
| Item | Example Entry | Why It Matters |
|---|---|---|
| Tag and service | FIC 205, reflux flow to column | Ties text to the P&ID |
| Range and units | 0 to 40 m³/h | Sets scaling and alarms |
| Action | Reverse acting | Prevents runaway on start |
| Final element | FV 205, fail open | Defines safe position |
| Setpoint source | Cascade from TIC 210 | Shows strategy links |
| Alarms | High 36, low 4 m³/h | Agrees limits early |
Keep each description short and factual. Hunter Vegas, writing in the same ISA Mentor Program thread, describes logic notes of a couple of paragraphs each for complex interlocks, ratio or cascade logic, linked from a tag list, a method that suits DCS control strategies of any size.
Interlocks, Permissives and Sequences
Interlocks need the most precise wording, because a vague sentence becomes a dangerous assumption. Many projects summarise them in a cause and effect matrix and keep the reasons, resets and bypass rules in the control narrative text.
Showing which trip came first saves hours after a shutdown, so specify first out alarm logic wherever several causes can trip the same equipment. Safety instrumented functions belong in the safety requirements specification, defined in the SIS safety lifecycle, and the narrative should only reference them.
Sequences are easier to review as numbered steps with transitions and timeouts. For batch plants, organise them by phase as described in ISA 88 batch control, and programmers can convert them directly into a sequential function chart.
Emerson Exchange 365 notes that API RP 554 Part 1 covers process control system functions and functional specification development. ANSI/ISA 5.06.01, by contrast, focuses on user requirement, functional and detailed design documents.
Control Narrative Versus Related Documents
Plain language description of loops, interlocks, modes and sequences.
Formal document covering the whole system, hardware, software and interfaces.
Table of initiating causes against resulting actions.
Requirements for each safety instrumented function and its SIL.
The overall rules for redundancy, naming and alarm philosophy usually sit one level higher, in a control system philosophy document. The narrative then applies those rules to each unit without repeating them.
Review With Process and Operations
The best review is a table top walk through with the process engineer, an experienced shift operator, the maintenance lead and the programmer. Read each clause aloud against the P&ID and ask what happens if this signal fails or this pump trips.
Operators catch practical gaps that designers miss, such as a restart that needs a manual valve opened first. Record every comment, the agreed answer and the new revision number before the programmer starts the configuration.
Freeze an approved revision before coding and route every later change through a formal change request. A control narrative that keeps changing without control turns the FAT into a negotiation.
Effort Formula for a Control Narrative
Writing time grows with the number of loops, interlocks and sequences. A simple estimate uses your own company norms for hours per item, so the numbers below are planning assumptions, not industry statistics.
Working days = Hours ÷ 8, rounded up
Example:
40 loops × 1.5 h = 60 h
25 interlocks × 1 h = 25 h
4 sequences × 8 h = 32 h
Hours = 60 + 25 + 32 = 117 h, about 15 working days
Control Narrative Effort Calculator
Second Worked Example: A Small Dosing Skid
A chemical dosing skid for a water plant in Maharashtra has 12 loops, 8 interlocks and 2 sequences, using the same hours per item. Hours = 12 × 1.5 + 8 × 1 + 2 × 8 = 18 + 8 + 16 = 42 hours.
Dividing by 8 gives 5.25, which rounds up to 6 working days. Add time for the review meeting and one revision cycle, which often take as long as the first draft.
From Narrative to FAT and Commissioning
Each numbered clause becomes one or more test steps in the factory acceptance test. The tester simulates inputs, watches the logic and graphics, and signs the clause only when the behaviour matches the text.
After site installation, the same clauses guide the site acceptance test and the cold loop and hot loop testing. Any change found on site goes back into the control narrative so the as built document matches the running plant.
McElhanney prepared the Hudson’s Hope water treatment plant narrative linked below, which is a real public example. Its sections cover the process overview by unit, start up and normal operation, emergency plant shutdown, manual operation and functional programming.
Control Narrative Quality Checklist
- Every tag in the narrative exists on the P&ID and instrument index.
- Each loop states range, action, fail position and setpoint source.
- Every interlock lists cause, delay, effect, reset and bypass rules.
- Sequences have numbered steps, transitions and timeouts.
- Mode changes and bumpless transfer behaviour are described.
- Failure responses for bad signals and communication loss are defined.
- Process, operations and maintenance have signed the review.
- Revision history shows what changed and why.
Alarm limits named in the narrative should follow the site alarm philosophy, as explained in alarm management to ISA 18.2. Good narratives also mention the key graphics and trends that operators need for each unit.
- Shared understanding before programming starts.
- Fewer surprises and disputes at FAT and SAT.
- Clear basis for test sheets and training.
- Faster troubleshooting years after handover.
- Takes time from busy process engineers.
- Plain language can still be ambiguous.
- Must be maintained after every change.
- Does not replace the safety requirements specification.
Real Water Treatment Plant Control Narrative
How Control Systems Are Tested at FAT
Control Narrative FAQ
It is a plain language description of how a process unit must be monitored and controlled. It covers loops, interlocks, sequences, operating modes, alarms and failure responses for every unit of the plant.
The document turns the static P&ID into behaviour that programmers can configure. Operators and process engineers can review a control narrative without reading any logic diagrams.
The process engineer usually provides the operating intent, and the control systems engineer turns it into structured clauses. On turnkey projects the system integrator often prepares the first draft.
Operations and maintenance staff then review it in a walk through meeting. Their practical field comments are essential before the revision is frozen for coding work.
It should name the tag, service, measured variable, range and units. It should also give the controller action, the final element, its fail position and the setpoint source.
For cascade, ratio or split range loops, add the links between controllers. Alarm limits and any special tuning or setpoint tracking needs belong in the control narrative as well.
A functional design specification is usually a broader formal document covering hardware, software, interfaces and testing. The narrative focuses on the control behaviour of each unit in plain, everyday engineering words.
On many projects the narrative forms one chapter of the larger specification. Smaller projects often use the control narrative alone as the agreed functional basis.
Use both together for the clearest result. The matrix gives a quick grid of causes and actions that is easy to check line by line during testing.
The narrative explains the reasons, delays, resets and bypass rules behind each line. Safety instrumented functions should only be referenced, with details kept in the safety requirements specification.
Each numbered clause becomes one or more test steps on the test sheets. Testers simulate inputs and sign each clause only when the behaviour matches the text exactly.
Any deviation is recorded as a punch item with the clause number. This makes the test objective and avoids long arguments at the end about what was really intended.
Update it whenever logic, setpoints, interlocks or sequences change during commissioning or later operation. Each update needs a new revision number and a short note of the change.
An outdated document misleads the engineers who troubleshoot the plant years later. Treat it as a living record that always matches the running control system on site.
Related Articles
- Cause and Effect Matrix
- Factory Acceptance Test for DCS, FAT and SAT
- Control System Philosophy, 30 Key Concerns
- Piping and Instrumentation Diagram
- DCS Control Strategies
External References
- Hudson’s Hope WTP Control Narrative Rev F, McElhanney for the District of Hudson’s Hope
- Control Narratives, Cross Company
- Functional Specification, Wikipedia
What We Learn Today
- A control narrative describes in plain words how each loop, interlock, sequence, mode and alarm must behave, so everyone agrees on intent before programming starts.
- Nine sections cover scope, process overview, equipment, modes, loop descriptions, interlocks, sequences, alarms and failure responses, each written as numbered, testable clauses.
- Review the draft with process, operations and maintenance, freeze a revision before coding, and turn every clause into a FAT test step.
