System Design, Architecture and Verification
System design, architecture and verification
This domain tests how sensors, logic solvers, and final elements are arranged to meet the SIL, and how verification and validation are planned. Expect voting architectures, HFT, proof testing, interfaces, bypasses, and factory/site testing.
Core rules
- Architectures are described by voting: 1oo1, 1oo2, 2oo2, 2oo3. Redundancy improves availability or safety depending on arrangement and failure mode.
- Hardware fault tolerance (HFT) is the number of faults the architecture can tolerate while still performing the safety function; it is not the same as redundancy count.
- The weakest subsystem often sets loop SIL: a SIL 3 logic solver with a SIL 1 valve gives a SIL 1 loop unless the valve is upgraded or the architecture compensates.
- Verification confirms the design meets the specification; validation confirms the installed system meets the user's needs in the real process.
- Bypasses, overrides, and maintenance overrides need procedures, alarms, time limits, and compensating measures.
Worked example
A SIL 3 high-pressure trip uses a 2oo3 transmitter voting arrangement, a SIL 3 logic solver, and a single shutdown valve. The transmitter and logic solver support SIL 3, but the single valve's PFDavg and HFT do not, so the loop cannot claim SIL 3. Options include a redundant valve with independent solenoids, a higher-integrity valve, or a lower target SIL with additional non-SIS layers.
Traps
- Adding redundancy without checking common cause and maintenance feasibility.
- Treating a 2oo3 arrangement as automatically SIL 3.
- Forgetting final-element stroke testing and partial-stroke diagnostics.
- Using validation to excuse a specification gap.