A cause and effect matrix is the tabular document that defines the trip logic of a safety instrumented system or interlock scheme. Causes occupy the rows: the initiating conditions, each identified by instrument tag, trip setpoint, and voting arrangement. Effects occupy the columns: the final elements and the action each one takes, close, open, trip, alarm. A mark at an intersection means that cause drives that effect. Read across a row and you see everything a high-high pressure trip does to the unit. Read down a column and you see every condition that closes a particular valve.
The format survives because it is reviewable. A process engineer, an operations superintendent, and a logic programmer can stand at the same table and check the same intersections, which no logic diagram or program listing allows. This reference covers where the matrix sits in the SIS document set, how the rows and columns are built, the qualifiers that carry the behaviour a grid cannot, how the matrix is exercised at FAT and loop check, and the ways it goes wrong in service.
Where the matrix sits in the SIS document set
The matrix is a derived document. It does not originate requirements and it does not implement them. The chain runs from hazard study to running code, and the matrix is the middle link that every discipline can read.
| Document | What it defines | What it does not do |
|---|---|---|
| HAZOP / LOPA | The hazard scenarios and the required risk reduction, which sets the SIL target for each safety instrumented function | Does not name devices, setpoints, or logic |
| Safety Requirements Specification (SRS) | The full functional and integrity requirements per SIF: setpoints, response times, voting, proof-test intervals, bypass and reset rules | Too dense for a cross-discipline review of the whole unit at once |
| Cause and effect matrix | The discrete trip logic at a glance: which initiators drive which final elements, with qualifiers for timing and resets | Does not carry integrity data; sequence detail is compressed into footnotes |
| Logic diagrams | The gate-level implementation: timers, latches, permissives, startup sequences | Hard to review across a whole unit; one drawing per function |
| Application program | The executable logic in the solver | Readable only to the programmer and the test bench |
Two boundaries are worth stating precisely. First, the SRS remains the governing requirements document under IEC 61511. The matrix summarises its discrete logic content for review and testing, and where the two disagree the SRS wins and the matrix gets corrected under management of change. Second, the logic diagrams and the application program implement what the matrix shows. When they disagree with the matrix, one of them is wrong, and finding out which is a FAT activity, covered below.
Traceability runs in both directions. Every cause row should trace back to a HAZOP scenario or an operating requirement, and every SIF the LOPA credits should appear on the matrix. A cause with no hazard record behind it, or a LOPA-credited function missing from the grid, is a finding either way.
IEC 61511 does not mandate the matrix by name. It requires the SIS logic to be specified, documented, and verifiable, and the matrix is the representation most owner standards call for because it satisfies that requirement in a form operations can sign.
Anatomy of a cause row
A cause row is complete when a stranger can test it without asking questions. The minimum content:
- Cause number. A unit-scoped identifier, 45-01 in the example below. Trip records, test procedures, and bypass logs reference this number, so it must be stable across revisions.
- Initiator tags. Every physical device in the voted set, written out: PT-4501A, PT-4501B, PT-4501C. One tag standing in for three transmitters is the single most damaging shortcut on the matrix, because it breaks the count against the I/O list.
- Description. The process condition in operating terms. "Separator pressure high high", never a restatement of the tag.
- Setpoint. Value, units, and direction. 8,200 kPag rising means something; 8,200 alone does not.
- Voting. The architecture, 2oo3, 1oo2, 1oo1. See what voting logic is and the MooN notation if the shorthand is unfamiliar. The vote belongs to the cause: the row trips when the vote is satisfied, whichever devices agree.
- SIF identifier and SIL target, where the row is a LOPA-credited safety function rather than a plain process interlock. Carrying both on the matrix lets a reviewer separate the safety layer from the operability interlocks without opening the SRS.
Anatomy of an effect column
An effect column names one final element and one action:
- Final element tag. XV-4501, P-4501A. One physical device per column. Two block valves acting together are two columns, for the same reason two transmitters are two tags on the cause side.
- Action. Stated in the header as the safe state: close, open, trip, de-energize. "XV-4501" alone is ambiguous; "XV-4501 close" is testable.
- Consistency with fail position. A de-energize-to-trip valve specified to fail closed should carry "close" as its action. Where the matrix action and the datasheet fail position disagree, the design has a gap that will surface at SAT.
- Alarm columns. Most matrices carry one or more annunciation columns alongside the hardware effects. Keep them visually separate from trip actions; an alarm is information, a trip is intervention, and conflating them is one of the classic drafting errors covered later.
A worked example
An inlet gas separator, V-4501, on an invented unit 45. Inlet shutdown valve XV-4501, liquid outlet valve XV-4502, export pump P-4501A, and a blowdown valve XV-4504 to flare.
| # | Cause | Tags | Setpoint | Voting | XV-4501 close | XV-4502 close | P-4501A trip | XV-4504 open | DCS alarm |
|---|---|---|---|---|---|---|---|---|---|
| 45-01 | Separator pressure high high | PT-4501A/B/C | 8,200 kPag rising | 2oo3 | X | X | X | X(1) | X |
| 45-02 | Separator level low low | LT-4502A/B | 320 mm falling | 1oo2 | X | X | X | ||
| 45-03 | Separator level high high | LT-4502A/B | 2,450 mm rising | 1oo2 | X | X | |||
| 45-04 | Inlet temperature low low | TT-4503 | -5 degC falling | 1oo1 | X | X | |||
| 45-05 | Manual ESD pushbutton | HS-4500 | n/a | 1oo1 | X | X | X | X(1) | X |
Footnote 1: XV-4504 opens 30 seconds after XV-4501 is confirmed closed by ZSC-4501. All trip outputs latch; reset via HS-4501 after the initiating cause has cleared.
Reading it both ways. Across row 45-01: a confirmed high-high pressure closes the inlet, closes the liquid outlet, trips the pump, and blows down to flare on a delay. Down the XV-4501 column: the inlet valve closes on high pressure, high level, low temperature, or the manual pushbutton, and on nothing else. That "nothing else" is a requirement. At FAT, an unmarked intersection that actuates is a failure exactly as a marked one that does not.
Note what row 45-02 does not do. Low level protects the downstream pump from gas blow-by, so it closes the liquid outlet and trips the pump while leaving the gas inlet open. The plant rides through it. A drafter who marks every cell in a row "to be safe" has converted a targeted protection into a unit trip, and operations will find out on the first spurious low-level event.
Qualifiers. Where the real behaviour lives
The grid answers one question, whether a cause drives an effect. Everything else rides on qualifiers, and the qualifiers deserve the same review attention as the marks.
| Qualifier | Typical notation | What it means |
|---|---|---|
| Time delay | X(1) with a numbered footnote | The effect actuates after a stated delay, often triggered by confirmation of a prior effect |
| Latched output | L, or a general note | The output holds after the cause clears, until a named manual reset is operated |
| Bypassable | B, with a reference to the override procedure | A maintenance override (MOS) is permitted for this cause, under authorization, logging, and a time limit |
| First-out | F | This cause is captured and displayed as the initiating event when multiple causes follow in cascade |
| Permissive | P | The condition must be healthy to permit a start; it does not trip a running unit |
Three of these are perennial trouble.
Delays encode sequence. The blowdown in the example must wait for the inlet to be proven closed, or the flare receives the pipeline inventory as well as the vessel contents. The delay time, its trigger, and the confirming device (ZSC-4501, a position switch, itself an I/O point) all belong in the footnote.
Resets define the operator's contract with the trip. A latched trip that clears itself when the process variable recovers will restart equipment nobody expects to restart. The matrix states latch or no latch per effect, and names the reset device. The reset pushbutton is a tagged input and belongs on the I/O list like everything else.
Bypasses are where the matrix and the plant drift apart fastest. Every cause that can be overridden for maintenance carries the qualifier on the matrix, and nothing in the logic carries an override the matrix does not show. An MOS switch that exists in the application program with no mark on the matrix is invisible to the HAZOP revalidation team, and that is precisely the kind of gap incident investigations find.
The matrix at FAT, SAT, and loop check
At the factory acceptance test, the matrix is the test script. The witness forces each cause at the logic solver inputs, in turn, and verifies three things: every marked effect actuates, every qualifier behaves as footnoted (delays timed with a stopwatch, latches held, resets required), and no unmarked effect actuates. Voting is exercised deliberately: for a 2oo3 cause, single-channel force must not trip, two channels must, and the failure of one channel should degrade per the SRS. The marked-up, signed matrix becomes the acceptance record.
At site acceptance and loop check, the split of labor matters. The loop check proves each device end to end, field terminal to logic solver channel, against the I/O list. The cause-by-cause trip test then proves the logic against the matrix, with real devices where practical and injected signals where the process cannot be exercised. The two activities catch different faults. A loop check finds the transmitter landed on the wrong channel; the matrix test finds the channel wired correctly to the wrong logic. Skipping either leaves a class of fault untested until a real demand finds it.
The signed matrix from SAT is the baseline the operating plant inherits. Every proof test and every trip investigation afterwards reads against it.
Where the matrix goes wrong in service
The failure modes repeat across plants and are worth checking for by name.
Drift from the logic. A change is made in the application program under time pressure, the matrix revision is deferred, and the deferral becomes permanent. Five years later the matrix describes a plant that no longer exists. The control is procedural: the matrix is a controlled document, revised under management of change like the P&ID, and no logic change closes out until the matrix revision is issued.
Undocumented bypasses. Covered above, and worth repeating because it recurs: overrides added to the program during commissioning to get the plant started, never removed and never drawn. Audit the program's override blocks against the B marks on the matrix.
Voting mismatch with the I/O list. The matrix says 2oo3; the I/O list carries two transmitters, or one row standing in for three. Or the reverse, three transmitters wired and the matrix showing 1oo1 because a revision on one document never reached the other. The cross-check is arithmetic: count the tags per cause row, count the AI rows per SIF on the I/O list, and reconcile every difference.
Orphan rows and columns. An effect column with no marks in it, or a cause that trips nothing, is usually the residue of a half-completed deletion. Either finish the change or reinstate it; an orphan on a safety document invites the next reviser to guess.
Alarm and trip conflation. A row whose only marks are in alarm columns is not a safety function, whatever the row heading claims. If the LOPA credits it as a protection layer, the matrix has just exposed a design gap.
Mapping the matrix onto the I/O list
During detailed design the matrix and the I/O list describe the same hardware from two directions, and each is the completeness check for the other.
Every initiator tag on a cause row is an input on the SIS I/O list, one row per physical device: a 2oo3 cause contributes three AI rows, each carrying the same SIF identifier and the voting architecture. Every final element column is at least one output row, and usually more than one point in total: a shutdown valve is a DO for the solenoid plus, commonly, two DIs for the open and closed position switches, one of which the matrix may already reference in a delay footnote. Reset pushbuttons, bypass switches, and first-out displays are I/O points too, and they are the ones most often forgotten because they live in the footnotes rather than the grid.
Run the reconciliation both ways before the I/O list freezes: every tag on the matrix has its rows on the list, and every SIS-classified row on the list traces to a cause, an effect, or a qualifier on the matrix. A tag that appears on one document only has a story, and the story is worth hearing before construction wires it.
Much of this data starts on the P&IDs, and when a matrix arrives as a scanned sheet on a brownfield job, Tagsight reads it and returns the cause rows, effect columns, and intersection marks as a structured workbook for the engineer to review.
Further reading
- What is a cause and effect matrix, the short-form definition this reference expands.
- What is voting logic, how a SIF decides a trip condition is real.
- 1oo2, 2oo3 voting architecture, the MooN notation on the cause rows.
- SIL-rated I/O and BPCS separation, the I/O list the matrix reconciles against.
- Redundant I/O on the I/O list, one row per physical device in a voted set.