The short answer
Control Narratives
A control narrative is the plain-language document that says what a control system does: its modes, its normal operation, its setpoints, its interlocks and permissives, its alarms, and what it does when something fails. It is written before the program, tested against during FAT and SAT, and it is the document the owner holds the integrator to. Every sentence in it should be something a test can pass or fail.
Key points
- The narrative describes behavior, not implementation: what happens, under what conditions, not which rung does it.
- Modes come first: hand, off, auto, local, remote, and what each one does and does not permit.
- Every interlock, permissive, and alarm is listed with its condition, its setpoint, its response, and how it resets.
- Failure behavior is stated explicitly: loss of signal, loss of communications, loss of power.
- If a statement cannot be turned into a test step, it is not finished.
What the narrative is and is not
The control narrative, also called a functional description or a description of operation, is the bridge between the process engineer who knows what the plant must do and the programmer who must make it do it. It is written in ordinary sentences, organized by system, and it describes behavior from the outside: when the wet well reaches the lead start level, the lead pump starts. It does not say how the logic is arranged.
That separation is the point. A narrative that describes rungs and tags is a program listing in prose, and nobody outside the programmer can review it. A narrative that describes behavior can be read by the operator who will run the plant, the engineer who designed the process, and the inspector who will witness the test, and each of them can say whether it is right.
What it must contain
The structure below is what a complete narrative covers for each system or piece of equipment. The order matters less than the coverage; a missing section is a decision that will get made in the field by whoever is standing there.
- 01System overview: what the equipment is, what it does, and the instruments and final elements involved, by tag.
- 02Modes of operation: every selector position, hand, off, auto, local, remote, and exactly what is and is not permitted in each.
- 03Normal automatic operation: the sequence, the setpoints, the timers, and the conditions that move the system from one state to the next.
- 04Permissives: the conditions that must be true before something is allowed to start.
- 05Interlocks: the conditions that stop or prevent operation, whether they are hardwired or in software, and how each one resets.
- 06Alarms: every alarm, its condition, its setpoint and delay, its priority, and the response expected of the operator.
- 07Failure modes: what happens on loss of a signal, loss of communications, loss of power, and on return of each.
- 08Operator interface: what is displayed, what can be adjusted, and the range and limits of every adjustable value.
- 09Startup and shutdown: how the system is brought up from cold and taken down, and what state everything is left in.
Writing statements that can be tested
The discipline that separates a useful narrative from a vague one is that every operational statement can be turned into a test step with an expected result. If a sentence cannot be tested, it is either an aspiration or it is hiding a decision.
| Vague | Testable |
|---|---|
| The pump runs when the level is high. | In auto, when wet well level rises to the lead start setpoint (initial value 6.0 ft), the lead pump starts after a 5 second delay. |
| The system alarms on high level. | When level exceeds the high level alarm setpoint (initial value 8.0 ft) for 10 seconds, a high priority alarm LAH-101 is annunciated. The alarm clears when level falls 0.5 ft below the setpoint. |
| The pumps alternate. | On each stop of the lead pump in auto, the lead designation transfers to the other pump. Alternation can be disabled from the HMI, in which case P-1 remains lead. |
| The system handles communication loss. | On loss of communication with SCADA for 30 seconds, the station continues in auto on local setpoints. Remote setpoint changes are ignored until communication is restored and the operator acknowledges the restoration. |
| The VFD runs at the right speed. | In auto, the drive speed reference is the output of pressure controller PIC-201 (setpoint initial value 65 psi), limited to 40 to 100 percent. |
The modes section is where most disputes come from
Hand-off-auto sounds simple until someone asks what hand means. Does hand bypass the high level interlock? Does it bypass the motor overload? Can the operator put a pump in hand from the HMI or only at the panel? Does remote mean SCADA can start the pump, or only change setpoints? Every one of those questions has a defensible answer, and the wrong one is the one nobody wrote down. A good narrative states, for each mode, what the equipment does, which protections remain active, and where the command can come from.
How the narrative is used
- Programming
- The programmer builds the logic to satisfy the narrative and nothing else. Behavior that is not in the narrative is a question, not a feature.
- HMI design
- The operator interface section defines what screens must show and what values must be adjustable, which fixes the tag list for the HMI.
- Factory acceptance test
- The FAT procedure is the narrative rewritten as steps with expected results. A narrative that was written to be testable makes the FAT procedure almost mechanical to produce.
- Site acceptance test
- The same steps performed on real equipment, with the narrative as the reference for what correct looks like.
- Operations and maintenance
- Years later, the narrative is how a new operator learns what the system is supposed to do, and how a technician decides whether a behavior is a fault or a feature.
Keeping it alive
The narrative changes during design, during FAT, and during startup, and every change should go back into the document with a revision. A narrative that stops at issued-for-construction while the program keeps changing is a document that describes a plant that no longer exists. The final revision, issued as-built, belongs in the O&M manual beside the drawings and the program backup.
Where the narrative, the sequence of operations, and the cause and effect matrix all exist for the same system, they must agree. The narrative is the prose, the sequence is the ordered version of it, and the matrix is the tabulated interlocks and alarms. They are three views of one design, and the narrative is normally the one the others are checked against.
Frequently asked questions
- Who writes the control narrative?
- On most projects the design engineer writes the first issue as part of the specification, and the integrator revises it through programming and testing. On design-build work the integrator often writes it from the process description. Whoever writes it, the owner approves it, because it is the definition of what they are buying.
- How is a control narrative different from a sequence of operations?
- A sequence of operations is the ordered, step-by-step form: first this happens, then that. A narrative covers the same behavior but also describes modes, interlocks, alarms, and failure handling that are not sequential. Many projects use the term interchangeably, and what matters is the coverage, not the title.
- How detailed should it be?
- Detailed enough that two competent programmers working from it independently would produce systems that behave the same way. Setpoints, delays, ranges, and reset conditions are the details that get lost first, and they are the ones that matter.
- Should the narrative reference tag numbers?
- Yes. Behavior is described in words, but the instruments and equipment involved are identified by their P&ID tags so the narrative, the drawings, and the program all refer to the same things by the same names.
Related topics
- How to Read a P&IDWhat a piping and instrumentation diagram shows, how ISA-5.1 tag bubbles and line types encode the control system, and how to trace a loop across sheets.
- Sequences of OperationWriting the ordered, step-by-step description of what a system does: states, transitions, timeouts, and the format that lets a programmer implement it and a tester verify it without interpretation.
- Cause and Effect MatricesThe table that lists every trip condition against every action it causes: how to build one, what goes in the cells, how it distinguishes hardwired from software protection, and how it becomes the test.
- Factory Acceptance TestingTesting a control system before it leaves the shop: what must exist before the test, how the procedure is built from the narrative and the matrix, how the field is simulated, what is witnessed, and what the punch list and the sign-off mean.
- Interlocks and PermissivesA permissive lets you start. An interlock stops you. Confusing the two produces equipment that either will not run or will not protect itself.
- Functional DescriptionsThe system-level document that states what a control system does, organized from the overview down to each piece of equipment in one format: modes, control, setpoints, permissives, interlocks, alarms, sequences, and failure behavior, and how it is used.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.