Safety Instrumented System, SIS.

A safety instrumented system exists for one reason. To move the process to a safe state when the basic process control system, the operators, and the mechanical safeguards have not. IEC 61511, harmonized in North America as ANSI/ISA 84, governs it as a complete lifecycle rather than a piece of hardware, running from the hazard study that identifies which scenarios need an instrumented safeguard, through the safety requirement specification, to the proof-test schedule that runs for the life of the plant. The defining design rule is independence. Clause 9 of IEC 61511 requires that a fault in the BPCS cannot disable the SIS, which in practice forces separate logic solvers, separate I/O, and separate field cabling for the safety-classified loops. That independence is why the SIS is carried as its own scope on a project. When an I/O list is built from a P&ID set, the safety tags, PSHH, FSLL, ESDV, and the SIF-flagged final elements are separated into their own workbook so they get their own SIL allocation, their own cabinet, and their own proof-test cadence, and so the safety case can be audited without untangling it from the regulatory control scope. A tag that the drawing shows as safety-classified but that never reaches that separate register is exactly the gap a pre-startup safety review is designed to catch.