Control narratives written for the person who inherits them
The document that explains why the control system does what it does is written once, by someone who is leaving, for an audience they never meet.
A control narrative describes what the control system does and why: the strategy for each loop, the sequence logic, the interlocks, the modes, and the reasoning behind the design choices.
It is the primary reference for anyone modifying the system later, and it is typically produced as a project deliverable, filed, and never updated.
What it has to contain
The process objective for each control scheme — what it is trying to achieve, not just what it does mechanically.
Time-management practices can help engineers balance maintenance, projects and unplanned interruptions. A related reference is available at https://www.monitask.com/blog/10-must-read-books-about-time-management/.
For process facilities, the surrounding management framework is covered in OSHA process safety guidance.
The strategy: which variable is controlled, what manipulates it, what the constraints are, and how cascade, feedforward or override arrangements interact.
The modes and how transitions between them happen, including what an operator sees and does.
Interlocks and permissives: the conditions, the actions, and — critically — the reason each exists.
Failure behaviour: what happens on loss of signal, loss of communication, controller failure.
The reasoning: why this approach rather than the obvious alternative. This is the part that is always omitted and always needed.
The configuration already documents what the system does. The narrative exists to explain the choices, and it is the only place that information will survive.
Writing for the reader
Narratives are frequently written in a form that mirrors the configuration — block by block, in the order the software is structured. That serves the person implementing it and not the person trying to understand it.
Organised by process function, in the sequence the plant operates, with the strategy explained before the detail, it becomes readable by a process engineer who does not know the control platform.
Interlocks deserve special treatment
Interlock documentation that lists conditions and actions without reasons produces a specific failure years later: an engineer investigating a nuisance trip cannot tell whether an interlock protects against a hazard or was added for convenience, and the safe assumption — leave it alone — accumulates.
Every interlock should record what it protects against and where that requirement came from, ideally traceable to the hazard study that generated it.
Keeping it current
A narrative that has not been updated for a decade is worse than none, because it is trusted and wrong.
The only mechanism that works is to make narrative update part of the change process: a control system modification is not complete until the narrative reflects it. This requires the narrative to be in a form that is easy to edit and easy to find, which argues against a large formatted document produced by a contractor.
Format matters for survival
A narrative delivered as a PDF, produced from a document nobody has the source for, will not be updated. One held in an editable form, under version control, with an owner, has a chance.
This is worth specifying in the project deliverables. The editable source is the deliverable; the formatted document is a rendering of it.
The test
The useful question is whether an engineer unfamiliar with the plant could, from the narrative alone, explain what the control system will do in a given abnormal scenario.
Trying that with a real narrative and a real scenario, during the project rather than years later, reliably identifies what is missing while the people who know are still available.
The relationship with the hazard study
Many interlocks and alarms exist because a hazard study identified a scenario requiring them. That link is frequently recorded in the study and not in the control documentation.
A narrative that references the originating study for each protective function makes the reasoning traceable and, importantly, makes it possible to determine whether a proposed modification affects a safeguard that was credited in a risk assessment.
Without the link, an engineer evaluating a change has no way of knowing which interlocks are risk-reduction measures and which are operational conveniences.
Narratives for sequences
Sequence logic is harder to document than continuous control and is documented worse. A narrative describing a sequence step by step, with the permissive conditions, the actions, the expected duration and the failure handling for each step, is what allows the sequence to be understood without reading the code.
For sequences with many steps, a tabular format is more usable than prose and considerably easier to keep current.
Making it findable
A narrative that exists and cannot be located is functionally absent. It should be reachable from the places people look: linked from the display, referenced in the operating procedure, indexed by equipment.
Several sites have had success embedding a link to the relevant narrative section directly in the control system, so that an engineer examining a loop can reach its documentation without leaving the tool.
Narratives and the operating procedures
Control narratives describe what the system does; operating procedures describe what the operator does. The two overlap and are usually written by different people at different times.
Where they disagree, the operator follows the procedure and the system does something else. Reviewing them against each other, at least for the sequences and abnormal scenarios, catches contradictions that neither document reveals alone.
This review is best done during commissioning, when both are being written and both authors are available.
Keeping them proportionate
Narratives that attempt to document every detail of the configuration become large, expensive to maintain and consequently out of date.
The useful scope is the intent and the reasoning, not a transcription of the logic. The configuration itself is the authoritative record of what the system does; the narrative explains why it does it that way.
A narrative that can be maintained is worth more than a comprehensive one that cannot.
Reviewing them with operations
Narratives written by engineers describe the design. Reviewing them with experienced operators identifies where the plant is actually run differently, which is information the engineering team frequently does not have.
Those divergences are worth understanding: either the operating practice should change, or the design assumption was wrong, and both are useful findings.