The short answer
Functional Descriptions
A functional description is the organized, complete statement of what a control system does, written for the whole system and structured so that every process area, every piece of equipment, and every loop has its own section in a consistent format. Each section states the equipment and its instruments, the modes of operation and how they are selected, the control strategy and its setpoints with their ranges, the start permissives, the run interlocks, the alarms with their priorities, the sequences where they apply, and what happens on a failure of the instrument, the communication, or the power. The control narratives written per process become its sections, the sequences of operation become its sequence subsections, and the cause-and-effect matrix summarizes its interlocks. It is written by the engineer with the owner during design, approved before programming starts, tested against at the factory and site acceptance tests, used to train operators, and revised under change management for the life of the system, because a functional description that does not match the plant is a plant that nobody can explain.
Key points
- One structure for the whole system: overview, then areas, then equipment and loops, each in the same format.
- Every equipment section states modes, control, setpoints, permissives, interlocks, alarms, sequences, and failure behavior.
- Narratives, sequences, and the cause-and-effect matrix are parts of it, not rivals to it.
- Written with the owner before programming; approved; tested against; kept current.
- Setpoints appear with ranges and units; a value with no range is a value nobody can change safely.
- The functional description is the document the HMI permissive list, the alarm list, and the test procedures are built from.
What it is for
A programmer needs to know what to build; a tester needs to know what to check; an operator needs to know what the system will do; an engineer ten years later needs to know why it does it. One document serves all four when it is organized so that each can find the section they need and the section says everything about that equipment in a predictable order. That is the functional description. Specifications call it by several names; the shape is the same: a system overview, a section per area, a subsection per equipment or loop, and appendices for the tables the sections reference.
Structure
| Section | Content |
|---|---|
| Introduction | Purpose, scope, the systems covered, the documents it references: P&IDs, I/O list, instrument list, network drawings |
| System overview | The process in a page; the control system architecture; the sites; the operating philosophy; the modes that apply everywhere |
| Conventions | Tag naming, the meaning of hand, off, auto, local, remote; alarm priorities; how setpoints are presented; units |
| Area sections | One per process area: intake, treatment, storage, pumping, each lift station. Each area has an overview and equipment subsections |
| Equipment and loop subsections | The standard format below, for every pump, valve, blower, feeder, analyzer, and loop |
| Sequences | Step tables for backwash, startup, batch, cleaning, with the step, action, transition, timeout, and fault response |
| Alarm list | Every alarm with its tag, condition, priority, deadband and delays, and the operator response |
| Cause and effect | The interlock matrix: each cause across the top, each effect down the side |
| Setpoint list | Every setpoint with its default, range, units, and who may change it |
| Communications | What talks to what, the protocols, the fallback on loss |
| HMI | The display hierarchy, the faceplates, the permissive and interlock displays, the reports |
| Failure modes | System-wide: loss of SCADA, loss of a controller, loss of power, loss of communication, and what runs on what |
The equipment section
Every equipment subsection follows the same format, so that a reader knows where to find the interlocks for pump 2 because they are in the same place as the interlocks for pump 1.
- Description
- What the equipment is, its tag, its instruments, its drive or starter, and what it does in the process.
- Modes
- How hand, off, auto, local, and remote apply, where each is selected, and what each permits. What the HMI can do in each mode.
- Control
- The strategy in auto: on-off with levels, staging, PID with its variable and its element, ratio, cascade. The setpoints, each with a default, a range, and units.
- Start permissives
- The list, in the words that will appear on the HMI permissive display, with delays and deadbands.
- Run interlocks
- The conditions that stop it while running, whether each latches, and how each is reset.
- Alarms
- Each alarm on this equipment with its condition, priority, delay, and the response expected of the operator.
- Sequences
- A reference to the sequence table, or the steps if short.
- Failure behavior
- What the equipment does on a failed instrument, a lost communication, a controller fault, or a power loss and return.
- Indications and records
- Run hours, starts, totals, and what is historized.
How the other documents fit
A control narrative is the prose for one process, written early to capture how the owner wants it to run; it becomes the area overview and the control paragraphs of the equipment sections. A sequence of operation is the step table for one sequence; it becomes a sequence subsection. The cause-and-effect matrix is the interlock table drawn across the whole system; it is an appendix that summarizes what every equipment section says. The functional description is the whole, organized; the others are the parts, and a project that writes the parts without assembling the whole has a set of documents that contradict each other by commissioning.
Writing and approving
- 1
Draft with the owner
The engineer writes; the operators and the process engineer read every section and change what is wrong. The operators know how the plant is actually run.
- 2
Make every statement testable
A sentence that cannot be turned into a test step is rewritten until it can. The pump starts when the level rises above the lead start level for five seconds, not the pump starts on high level.
- 3
Put the setpoints in tables
With defaults, ranges, units, and the role that may change them. The setpoint list appendix is generated from the sections.
- 4
Approve before programming
The owner signs the revision that the programmer builds from. Changes after that are change records.
- 5
Test against it
The factory and site acceptance test procedures are written from the sections: each permissive, each interlock, each alarm, each sequence step is a test line.
- 6
Keep it current
Every change record that alters behavior updates the section, and the revision history says what changed and why.
Signs of a good one
- A new operator can read the section for a lift station and predict what it will do tonight.
- A programmer builds from it without a meeting.
- A tester writes the acceptance test from it in an afternoon.
- Every setpoint on the HMI is in the setpoint list with the same default and range.
- The revision on the cover matches the plant, because the last change record updated it.
Frequently asked questions
- How long should a functional description be?
- As long as the system needs and no longer: a lift station is a few pages, a treatment plant is a hundred or more. The equipment sections follow a template and are terse; the length comes from the count of equipment, not from prose. A document that is long because it explains theory is a document that is not read.
- Who owns it after the project?
- The utility. The integrator writes the first revision with the utility and hands it over; the utility keeps it under change management and gives the current revision to the next integrator. A utility that lets the integrator keep the only copy has outsourced its own understanding of its plant.
- What is the difference between this and a control narrative?
- A narrative describes one process in prose, often early and often for one purpose. The functional description is the complete, structured statement for the whole system, and it absorbs the narratives as sections. Small projects sometimes use the terms interchangeably; the structure and the completeness are what matter.
- Should the functional description contain code?
- No. It says what the system does, in language the owner can read and the tester can check; the program says how. A tag name or a setpoint tag reference is useful; a rung is not. When the code and the description disagree, the description is the reference and the code, or the description, is corrected through change management.
Related topics
- Control NarrativesWhat a control narrative is, what it must contain, how to write statements that can be tested, and how it drives programming, FAT, and the owner’s acceptance.
- 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.
- PermissivesThe conditions that must be true before a device may start: how permissives differ from interlocks and trips, the list a pump or feeder usually needs, coding them so the HMI can say why a start was refused, and the rules for time delays and bypasses.
- 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.
- Change Management for OTA change process sized for a utility control system: what counts as a change, the request with risk and rollback, owner approval, the window, backup before and verification after, the baseline update, the emergency path, and the record.
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.