Cause and effect matrix and SIS testing: matrix to logic, FAT, SAT, bypasses, proof tests and change control

A cause and effect (C&E) matrix is the table that tells the process engineer, the programmer and the test team which plant conditions must trigger which safety actions. In a safety instrumented system (SIS) it is the reference the logic is written from and the list it is tested against: at the factory, on site, and again after every change. This article follows the matrix through a project, using what Rockwell's AADvance and Trusted safety manuals, IEC and the UK Health and Safety Executive (HSE) publish. For what a SIL is and how a safety function reaches it, see What is SIL.

What a cause and effect matrix is

IEC 62881:2018 is the international standard for cause and effect matrices. Its public summary describes the matrix as a simple format for exchanging information between engineering disciplines, in projects and in maintenance, with a minimum content taken from design documents such as P&IDs. A C&E matrix can document how plant equipment reacts to faults, so it is a reference point for safety verification. It is a different tool from the fishbone (Ishikawa) diagram used in quality work.

In the example in Figure 1, each row is a cause and each column an effect. A cause is a condition the SIS detects, such as a pressure transmitter above its trip setpoint, a confirmed gas detection or a field emergency push button. An effect is what the SIS does: close a shutdown valve, stop a pump, raise an alarm. A mark where a row and a column cross means that the cause drives that effect. A row shows what one trip will do; a column shows everything that can close one valve.

Our ICSS article lists the C&E matrices for ESD and fire and gas, numbered and under revision control, among the inputs an owner should specify, next to the safety requirements specification (SRS). IEC 61511-1:2016 sets the requirements for a SIS in the process industry, from specification to operation and maintenance; HSE summarises that lifecycle from the hazard and risk assessment to validation, periodic proof testing and management of modifications.

From the matrix to SIS logic

IEC 62881 leaves one step outside its scope: turning the matrix relations into function or source code for a PLC or DCS. Nor does it cover implementing complex or sequential logic on a particular automation platform. That step is the integrator's engineering work: each cause becomes an input condition in the application, each effect an output command, and each mark a path between them, so the finished program can be traced back to the matrix cell by cell. The matrix is read together with the SRS and the other design documents.

The AADvance manual calls for verification by a combination of review, simulation and testing (ICSTT-RM446S, p. 26). The Trusted manual recommends simulation testing of each software block, then integration of the programs with the system hardware and integration testing (ICSTT-RM459K, p. 24).

Testing against the matrix: FAT, SAT and validation

IEC 62381:2024 (edition 3.0) is the IEC standard for acceptance tests of process automation systems. Its public summary says it sets requirements and checklists for the factory acceptance test (FAT), the optional factory integration test (FIT), the site acceptance test (SAT) and the site integration test (SIT). The tests show that the system meets its specification, and owner, buyer and vendor use the standard to agree the scope and who is responsible for each activity; its annexes hold checklists for project test procedures. The general difference between FAT and SAT is explained in our industrial automation article and in the glossary.

For a SIS, the C&E matrix makes the test list easy to build. Each marked cell is a cause to simulate and an effect to observe, and an output that moves without a mark is a finding too. The same list can be used at the FAT, before installation, and again at the SAT, with the system installed at the plant.

Both safety manuals then require validation of the integrated system against the safety requirements specification. The AADvance manual adds that validation confirms the process safety time requirements are met (ICSTT-RM446S, p. 27). The Trusted manual says validation shows that each functional safety requirement has been implemented at the required safety integrity level, and asks for records to be kept throughout commissioning (ICSTT-RM459K, p. 26). HSE's guidance for assessing COMAH safety reports lists test, commissioning and validation reports, such as FAT reports, among the evidence it expects.

Bypasses, overrides and forcing

Field devices need maintenance while the plant runs, so a SIS needs a controlled way to stop one input from tripping the plant. The AADvance manual asks the operation and maintenance plan to define the overrides used to maintain sensors and actuators (ICSTT-RM446S, p. 28). The Trusted manual says sensor and actuator maintenance will need overrides in some cases, implemented as the manual describes (ICSTT-RM459K, p. 26).

The Trusted manual strongly recommends that I/O forcing is not used to support field device maintenance, because forcing is provided for application testing (ICSTT-RM459K, p. 27). Removing a module that has no partner or smart slot configured (a fail-safe configuration) also needs override or bypass signals for the time the module is out, so that no safety response is triggered by accident (pp. 27–28).

HSE's control systems guidance puts override management into the operating procedures: authorisation, security, recording, monitoring and review of overrides, and reset requirements. The same page says trips should not reset themselves unless that has been justified, and that protection systems should show that a demand to perform a safety function has been made. Who may write a bypass into the SIS is also a security question, but the security levels of IEC 62443 are a separate scale from SIL.

Proof testing after commissioning

Internal diagnostics do not see everything. The Trusted manual says that in most configurations some elements are not tested by the system's diagnostics: the final passive elements of some I/O module types, the FTAs that interface with the sensors, the actuators themselves and the field wiring. It asks for planned maintenance testing so that faults do not accumulate, with the maximum interval defined during system design, before installation. The manual strongly recommends an interval of less than 12 months, and its Appendix F gives proof test methods (ICSTT-RM459K, p. 27).

The AADvance manual asks the operation and maintenance plan to include the procedures for recalibrating sensors and actuators and for testing the system periodically, with the maximum intervals between tests (ICSTT-RM446S, p. 28). The controller's self-test cycle, which completes every 24 hours (p. 41), is internal diagnostics, not a proof test of the loop.

HSE explains why the interval matters: the failure probability of a protection system depends critically on how often it is proof tested and on how well the test finds failures that normal operation does not reveal. HSE expects proof test procedures with success and failure criteria, end-to-end tests including sample and impulse lines, tests at the conditions expected at a trip, and a checked reinstatement of each sensor after the test. Its COMAH guidance asks sites for the proof test frequency and how it was derived.

Changing safety logic: management of change

The C&E matrix and the program change together. The Trusted manual says design changes shall be managed carefully, under documented procedures that are the end user's responsibility, with guidance from the system integrator (ICSTT-RM459K, p. 28). After a declared baseline, recommended at the end of each lifecycle step and at the latest before the potential hazards are present, every change follows the formal change procedure. Each requested change is recorded, its impact is analysed before it is authorised, and the test covers the change itself plus non-regression testing (p. 29).

The AADvance manual requires change control procedures with records of modification requests, the impact analysis of proposed modifications and their approval (ICSTT-RM446S, p. 24). HSE adds that unauthorised modifications must be prevented, that competent persons design and carry out changes, and that safety verification confirms the required safety function and integrity remain afterwards. Its COMAH guidance asks that the site's management of change procedures cover safety instrumented systems.

What TDL checks first

These are our own working habits on an SIS project or an existing AADvance or Trusted system, not vendor requirements:

• The SIL target of each safety function comes from the plant's hazard and risk assessment and the safety requirements specification. We implement and test against it; we do not set it.
• We check that the C&E matrix revision matches the SRS revision and the program in the controller, and list any cause or effect that appears in one and not the other.
• We read the bypass and override philosophy before writing logic: which inputs may be bypassed, who authorises it, how a bypass shows on the operator screens and how reset works.
• We ask for the proof test procedures and intervals, and check that the logic and screens support them.
• We agree the FAT and SAT procedures with the owner or EPC before testing, built from the matrix so that every marked cell has a test step.
• On a running system, we take a backup and compare the program with the last approved baseline before any change.

How TDL approaches it

TDL builds SIS for SIL 2 and SIL 3 functions on AADvance and Trusted, including ESD and Fire & Gas. Our ICSS and safety systems service covers cause & effect implementation and witnessed testing, and our control system packages for EPC contractors include testing and commissioning. At the Phu My Gas Distribution Station, we installed and programmed the inlet shut-off valve system across AADvance and ControlLogix, through test run and hand-over. At Thai Binh 2 Thermal Power Plant, we provided technical consultation for the ESD system on Trusted, including field operation and testing according to the SAT documents. At Golden Pass LNG in Texas, a TDL engineer carried out functional testing of the BMS/SIS for SIL 2 safety functions during commissioning.