In short. A cause-and-effect matrix lists every condition that can occur and exactly what the system does in response. It is the single document where design, programming, testing and operations meet. If it is wrong, everything built from it is wrong.
Structure
| Cause | Effect: trip generator breaker | Effect: start standby | Effect: shed load | Effect: alarm |
|---|---|---|---|---|
| Utility undervoltage with delay | X | X | ||
| Generator overload | X | X | ||
| Generator protection trip | X | X | X | X |
| Bus protection operated | X | X | ||
| Fuel low | X |
Rows are causes, columns are effects, and each cell marks which cause drives which effect, with delay or voting details in notes.
Details to capture
- Delay and time for each cell.
- Voting: 1 out of 2, 2 out of 3.
- Latching or self-resetting.
- Whether the effect is a trip, alarm, inhibit or sequence start.
- Mode dependence: auto, manual, maintenance.
- Bypass or override allowed, and who may apply it.
Process
- List causes from protection, process and operation.
- List effects from equipment and control outputs.
- Agree each intersection with operations and safety.
- Review for conflicts: two causes giving opposite effects.
- Use it to produce logic, I/O lists and test sheets.
- Control changes through revisions.
Using it for testing
At FAT and SAT, every filled cell is a test: inject the cause, observe the effect, record. Empty cells can also be tested for no effect. See acceptance framework.
Pitfalls
- Effects added in code but not in the matrix.
- Trips that depend on a single sensor with no voting.
- Alarms without defined operator actions.
- Matrix not updated after commissioning changes.
See also state machines.
Illustrative example
A review of a plant matrix finds that “generator high coolant temperature” only raises an alarm, while the operators believed it would trip. The matrix is updated with a delayed trip and a pre-alarm, and the test sheet confirms the new response.
A cause-and-effect chart
A cause-and-effect matrix lists the causes (inputs, alarms, trips) down the side and the effects (actions) across the top, with a mark where a cause triggers an effect. It is the clearest single document of what the system does.
| Cause | Open breaker | Stop engine | Alarm | Start standby |
|---|---|---|---|---|
| Generator overload | Delayed | No | Yes | Yes |
| Reverse power | Yes | Yes | Yes | Yes |
| Low oil pressure | Yes | Yes | Yes | Yes |
| High coolant temperature, first stage | No | No | Yes | No |
| Emergency stop | Yes | Yes | Yes | Yes |
How to build
- List every protection, alarm and condition.
- List every possible action with its delay.
- Agree each intersection with the operator and the maker.
- Derive logic and testing from the chart.
Benefits
- Reviewable by non-programmers, including operators.
- A direct test list for FAT and SAT: test each marked cell and some unmarked ones.
- Change control: updating the chart before the code.
Classify trips by severity
Shutdown with cool-down for non-urgent faults, immediate shutdown for damaging faults, alarm only for warnings. Defining this once prevents inconsistent behaviour.
See FAT and SAT framework and alarms and records.
The master engineering question
For every event the plant can face, does the matrix say what should happen, and does the plant actually do exactly that?
What to send us
Send protection list, I/O and sequences. Send your application details.
Questions engineers ask
Who owns the matrix?
The project engineer, approved by operations and safety.
How detailed should it be?
Enough that a test engineer can verify each response without asking questions.
Is it only for large plants?
Any plant benefits; small ones need a short version.
Can software generate it?
Tools help, but review by people is essential.
This guide gives general principles. Confirm with a project design.