The short answer
Cause and Effect Matrices
A cause and effect matrix has a row for every condition that must cause a protective action and a column for every action, with a mark in each cell where one causes the other. It is the most compact statement of a system’s interlocks and trips, it is how a reviewer confirms that a hazard has a response and a response has a cause, and it is the test procedure for the protection once the rows are numbered. It grew up in process safety and it is just as useful for a pump station.
Key points
- Rows are causes: a measured condition with a tag, a limit, and a delay. Columns are effects: an action on a specific piece of equipment.
- A cell mark says this cause produces this effect; the matrix shows at a glance what trips what.
- Each row states whether the protection is hardwired, in the controller, or both, and how it resets.
- The matrix is the test: force each cause and confirm every marked effect, and no unmarked one.
- It documents interlocks that already exist as much as it designs new ones, and it finds the ones nobody wrote down.
The shape of it
A cause and effect matrix is a grid. Down the left are the causes, one per row: high wet well level, low suction pressure, motor overload, seal failure, emergency stop, loss of communication. Across the top are the effects, one per column: stop pump 1, stop pump 2, start both pumps, close valve, alarm high priority, dial out. A mark in a cell means the cause on that row produces the effect in that column. An empty cell means it does not. The whole protective design of a system is visible on one sheet.
| Cause | Tag and limit | Stop P1 | Stop P2 | Run both | Alarm | Type |
|---|---|---|---|---|---|---|
| High high level | LSHH-101 float | X | X high | Hardwired and software | ||
| Low low level | LSLL-101 float | X | X | X medium | Hardwired | |
| P1 overload | OL-P1 contact | X | X medium | Hardwired | ||
| P1 seal failure | MSF-P1 | X low | Software | |||
| P1 high temperature | TSH-P1 | X | X medium | Hardwired | ||
| Emergency stop | HS-ES | X | X | X high | Hardwired | |
| Level transmitter bad | LT-101 quality | X medium | Software; control to floats |
What goes in a row
- The cause
- A named condition: high high level, not "level problem".
- The initiating device
- The tag of the switch, transmitter, or contact that detects it, and the limit and any delay that define it.
- The type
- Hardwired, meaning the action happens through relays and contacts without the controller; software, meaning the controller does it; or both, meaning the controller does it and the hardwired circuit backs it up. This column is the one that reviewers care about most.
- The reset
- Whether the effect clears when the cause clears, or latches until an operator resets it, and where the reset is.
- The notes
- Bypass provisions, testing intervals, and the reference to the narrative or the drawing.
Building it
- 1
List the effects first.
Every protective action the system can take, per piece of equipment: stop, start, close, open, inhibit start, alarm at each priority, notify. These are the columns.
- 2
List the hazards.
From the process, the P&ID, and the equipment manuals: overflow, dry run, overpressure, overload, overheating, loss of a utility. Each becomes a cause row with its detecting device.
- 3
Fill the cells.
For each cause, mark every effect it must produce. Argue about the empty cells as much as the marked ones: a high level that does not start the second pump is a decision.
- 4
Assign the type.
Decide which rows are hardwired. Anything that protects a person, and anything that must work when the controller does not, is hardwired. The rest may be software.
- 5
Number the rows and columns.
The numbers are how the FAT procedure and the program comments refer to them.
- 6
Review it with operations.
The people who run the plant know the causes the designers did not list.
Using it
The programmer implements each software row as an interlock, commented with the row number. The panel builder wires each hardwired row and marks the drawing with it. The FAT and SAT procedures test the matrix row by row: force the cause, confirm each marked effect happens and each unmarked one does not, clear the cause, confirm the reset behaves as the row says. When the plant changes, the matrix changes first and the program and the drawings follow. A matrix that is kept current is the fastest answer to the question a new operator asks most: what will this do if that happens.
On an existing plant
Most plants have never had one. Building a matrix for an existing system means reading the program and the drawings and writing down what actually trips what, which is a day of work per panel and always turns up an interlock nobody remembered, a bypass that was never removed, or a protection that exists on the drawing and not in the panel. It is the single most useful document an integrator can produce for a plant they are about to modify.
Frequently asked questions
- What is a cause and effect matrix used for?
- To state, in one table, every condition that triggers a protective action and every action it triggers. It is the design record of the interlocks, the review tool for finding gaps, and the test procedure for proving them.
- Is it only for safety systems?
- It came from process safety, and it is equally useful for ordinary equipment protection in a pump station or a treatment plant. Any system with more than a handful of interlocks benefits from having them in one table.
- How does it relate to the control narrative?
- The narrative describes the interlocks in prose; the matrix tabulates them. They must agree, and the matrix is easier to check for completeness because an empty cell is visible in a way a missing sentence is not.
- Should every row be hardwired?
- No. Rows that protect people or that must work without the controller are hardwired. Equipment protection that can tolerate a controller fault is often software alone. The column that states which is the point of the exercise.
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.
- 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.
- 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.
- 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.
- 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.