What Is a Control Narrative?
The Plan Behind the Logic

Back to Blog

What a Control Narrative Contains

A control narrative, sometimes called a control philosophy or functional description, translates process intent into requirements a programmer can implement and a technician can test. It typically covers: normal operating description (what the equipment does in steady operation), control loops (which variables are controlled to which setpoints and by what), sequences of operation (startup, shutdown, and switching steps in order), interlocks and permissives (conditions that must be met to allow an action, and conditions that force a trip), alarms (what is annunciated and at what limits), and shutdown logic (what causes a safe shutdown and how the plant returns to service).

It is written in structured plain English, not code, precisely so that people who are not programmers - process engineers, operations, safety reviewers - can read it, agree it is correct, and sign off before automation work begins. Good narratives reference the P&IDs and tag names so every statement ties to a specific instrument.

Why the Control Narrative Matters

The control narrative is where the logic is agreed once, in language everyone understands, rather than being reverse-engineered from ladder or function-block code later. It is the specification the PLC/DCS programmer builds against, the checklist commissioning uses to write factory and site acceptance tests (does the system actually do what the narrative says?), and the reference operators and future engineers consult to understand why the system behaves as it does.

In oil and gas, where interlocks and shutdowns protect people and equipment, a clear narrative is also a safety and compliance artifact: it makes the intended trip conditions explicit and reviewable. A vague or missing narrative is a common root cause of automation projects that drift, fail acceptance testing, or leave operators unsure what the system will do in an upset.

A Skeleton That Works

There is no single mandated format, but narratives that hold up through commissioning tend to follow the same order:

1. Scope and references: the P&IDs, cause and effect charts, and instrument index the narrative is written against, with revision numbers.
2. Process overview: a short plain-language description of what the unit does, for the reader who arrives cold.
3. Operating modes: auto, manual, maintenance, local and remote, and what is permitted in each.
4. Loop-by-loop control descriptions: each loop's measurement, final element, and control action.
5. Sequences: startup, normal shutdown, emergency shutdown, and restart, written as numbered steps.
6. Interlocks and permissives: each condition, its action, whether it latches, and how it resets.
7. Failure responses: behavior on loss of signal, loss of power, and loss of communications.

Keep numeric limits out of the prose. Alarm and trip values belong in a referenced table or the alarm database, where they have one authoritative home; the narrative explains intent and behavior. That split lets a setpoint change go through review without rewriting the document, and it stops the narrative and the configuration from quietly diverging.

A Worked Fragment: Vague vs Testable

Vague: 'The pump stops on low level.' Testable: 'When level transmitter LT-101 falls below the low-low limit, the logic stops pump P-101, closes inlet valve XV-101, and raises a low-low level alarm. The trip latches. Restart requires level above the reset limit and an operator reset from the HMI.' The second version names the initiating instrument, every action and its order, the latching behavior, and the restart path - all in symbolic tags traceable to the P&ID.

Testability is the standard to write to. Every sentence should convert directly into a step in the factory acceptance test and later into a field loop check: do this, observe that, pass or fail. If a sentence cannot be turned into a pass/fail test step, it is a statement of intent rather than a specification, and it needs another pass before a programmer touches it.

Where Narratives Go Wrong

The recurring gaps are the abnormal paths. What does a loop do when its transmitter reads bad quality - hold last value, drive to a safe position, alarm? What happens when power returns after an outage - does anything restart itself? What do outputs do at the instant of a mode switch from auto to manual? Can two sequences ever command the same valve, and which wins? And for every interlock: does it latch, and who is allowed to reset it? Narratives that answer only the normal path get rewritten during commissioning, at the most expensive possible time.

The other failure is drift after startup. Logic changes made during commissioning and later operations never make it back into the document, and years later the narrative describes a plant that no longer exists. Treat it as a living document: a logic change and its narrative revision travel in the same management-of-change package, and periodic audits compare the running program against the written behavior.

Who Writes It, and When

The narrative sits between design and programming: it is written once the P&IDs are mature and the process hazard reviews have produced their required safeguards, and it is agreed before logic programming starts. The process engineer supplies the intent and constraints, the controls engineer turns them into implementable statements, and operations reviews for operability - can a human actually run the plant this way? Safety instrumented functions are specified in their own safety requirements documents; the narrative references them rather than duplicating them, and trip settings for protective functions remain the responsibility of qualified process-safety personnel.

On a small brownfield job the whole thing may run a few pages, and that is fine. The value is not the page count; it is that someone wrote down, and someone else agreed to, exactly what the system will do before anyone programmed it.

Frequently Asked Questions