Cause and effect · editable CSV · no signup
Cause-and-Effect MatrixTemplate & Worked Example
Translate trips, interlocks and safeguarding requirements into an auditable matrix with delays, latching, bypass, reset and verification ownership.
What this document controls
A cause-and-effect matrix maps each initiating condition to the outputs, trips, alarms, permissives and sequence actions that must follow. A usable matrix also records Boolean sense, voting, delay, latch/reset behavior, bypass rules, priority and a test ID. The matrix is compact evidence of discrete logic intent; it does not replace the narrative needed for modes, sequences, analog control and recovery.
File facts
- Format
- CSV / spreadsheet
- Account
- Not required
- Project data upload
- None
- License
- CC BY 4.0
Field dictionary
Columns worth keeping
| Field | Why it exists | Example |
|---|---|---|
| Requirement / row ID | Stable trace into narrative, logic cross-reference and test protocol. | CE-P101-04 |
| Cause tag and condition | Defines the real initiating signal, sense and threshold/state. | LSLL-101 = active |
| Validation / voting | Records debounce, persistence, quality and voting before the cause becomes true. | 2.0 s on-delay |
| Effect | Names each commanded state, inhibition, alarm and sequence transition. | Stop P-101A/B |
| Priority / order | Defines timing where effects must occur in a controlled sequence. | Immediate output; alarm same scan |
| Latch / reset | Prevents ambiguous recovery and unintended automatic restart. | Latched; local HMI reset when clear |
| Bypass rule | Defines authorization, indication, timeout and remaining safeguards for temporary bypass. | Engineer role; max 2 h; banner + event |
| Alarm response | Connects the trip to an actionable operator message and controlled priority. | High priority: verify tank level |
| Safe state basis | Points to approved hazard/risk documentation instead of asserting “fail safe.” | HAZOP action 24 / SRS SIF-04 |
| Implementation owner | Identifies PLC, SIS, package or hardwired system responsible for the effect. | SIS-201 |
| FAT/SAT test ID | Makes verification evidence discoverable for every important row. | FAT-SIF04-07 / SAT-SIF04-03 |
| Status / exception | Controls open design decisions, test failures and accepted deviations. | Approved for FAT |
Workflow
Build it in the right order
- 01
Collect approved initiating requirements
Use HAZOP/LOPA/SRS outputs, machinery risk assessment, control narrative, package data and operating constraints. Do not invent safety functions in the spreadsheet.
- 02
Normalize causes
Give every cause an exact tag, Boolean sense, quality requirement, threshold, delay and voting rule. Separate sensor failure from process trip.
- 03
Expand effects
Record each commanded safe state, inhibit, alarm, first-out and sequence transition. Distinguish command removal from physical proof.
- 04
Define reset and bypass governance
State latching, reset eligibility, authority, indication, event logging, maximum bypass duration and compensating measures.
- 05
Trace implementation and tests
Assign one control-system owner and map the row to logic, HMI, FAT and site validation evidence. Keep failures and exceptions visible.
Quality gate
Review before issue
- Every cause uses explicit active sense, quality, threshold/voting and delay—not only a tag name.
- Each effect names the demanded state and owner; “shutdown system” is too vague.
- Command and achieved final-element feedback are separate requirements where proof matters.
- Reset conditions prevent automatic restart unless the approved design explicitly permits it.
- Bypasses have authorization, indication, expiry/restoration and audit behavior.
- Safety-related rows trace to the approved safety requirements and validation plan.
- The same effect is consistent across matrix, narrative, PLC/SIS logic and HMI text.
- Every critical row has positive, negative, timing, reset and failure-path tests.
Worked record
Worked matrix: low-low tank level
The row below is richer than a simple X at the intersection of one cause and one effect. It preserves the delay, latch, reset and evidence needed to implement and independently verify the requirement.
| ID | Cause | Validation | Effects | Reset / bypass | Owner | Evidence |
|---|---|---|---|---|---|---|
| CE-P101-04 | LSLL-101 active | 2.0 s persistent; quality good | Remove P-101A/B run; inhibit start; first-out; operator alarm | Latch; reset only when clear and commands off; no routine bypass | PLC-201 | FAT-P101-21 / SAT-P101-08 |
| CE-P101-05 | LSLL-101 bad quality | status invalid for 3.0 s | Disable Auto start; alarm bad measurement; hold defined state | Auto recovery only after good quality stable 10 s | PLC-201 | FAT-P101-22 |
Connect it to the rest of the project
Cause-and-effect guide
Learn notation, document ownership, lifecycle and implementation patterns.
Open reference →Control narrative template
Define modes, sequences, analog behavior and recovery around the matrix.
Open reference →SAT guide
Turn approved matrix rows into witnessed installed-system evidence.
Open reference →Frequently asked questions
Is a cause-and-effect matrix only for safety systems?
No. It is useful for ordinary PLC interlocks, package shutdowns, process trips and alarms. Safety-related functions require additional lifecycle, independence and validation controls defined by the applicable standards and approved project basis.
Does an X in the matrix fully define an effect?
Usually not. The implementation also needs demanded state, order/timing, latching, reset, alarm, feedback proof and failure behavior. Use notes or a normalized row format when a simple grid cannot preserve those requirements.
Should one cause have multiple rows?
It may. Separate rows are clearer when the same source has different thresholds, delays, quality conditions or system owners. Keep stable IDs and avoid combining conditions that cannot be tested independently.
Who should approve the matrix?
Approval depends on scope. Typical reviewers include process, operations, controls, instrumentation, electrical, package vendors and safety specialists. Safety requirements must follow the project’s formal safety lifecycle and competency rules.
Share or cite this template
Link to this landing page so readers receive the field definitions, use boundary and future revisions with the file.
https://plcprogramming.io/tools/cause-and-effect-matrix-template