Safety Instrumentation System (SIS)

Principles, Scenarios and Suitability

An SIS implements safety instrumented functions derived from hazard analysis, using sensors, a logic solver and final elements within a functional-safety lifecycle. General image monitoring is not an SIS, and an alert is not equivalent to demonstrated risk reduction.

SIS means safety instrumented system. A SIF is a specific protective function defining what action follows a hazardous condition. Sensors observe, a logic solver evaluates the defined logic and final elements act physically. Sending a message to a person is different. Calling a dashboard safety-related must not imply it supplies a proven protection circuit.

Functional safety manages these duties throughout analysis, operation, review and change. SIL requires specific assessment and evidence, not an image-reading score. Independence includes power, networks, instruments and people. Additional observations may help operations, but inspect any new dependency that could affect protection rather than assuming a separate screen means a separate system.

Illustrative Design Scenario

Educational scenario: keep dial readings used for trends separate from a purpose-designed trip circuit. If images disappear, the dashboard marks the data unusable without injecting signals into the logic solver or claiming to replace the protective circuit.

Suppose images read gauges normally checked on operator rounds while protection uses its own designed instruments and logic. Image loss calls for checking the supplementary information path, not changing or bypassing the trip circuit. A normal trend does not justify disabling protection, and a warning message does not prove the entire protective function works.

Keep supplementary monitoring read-only, or have specialists assess any proposed relationship with protection first. The latter requires more evidence and change control. Use documents and simulators to explain information loss; do not create dangerous physical conditions or disable protection to obtain experimental results.

Inputs and Prerequisites

Study must begin with hazard analysis, SIF boundaries, safety requirements and lifecycle records authorised by the plant owner. Do not assign SIL from model accuracy or computer uptime.

Hazard analysis identifies dangers. Safety requirements specify functions and conditions requiring demonstration. Documents need a version, owner and authorised study boundary. Do not disclose sensitive system details beyond what the assessment requires.

Supplementary-data output should show quality, time and dependencies requiring review, not a SIL calculation or SIF approval. Competent personnel must separately determine the required evidence and verification for the actual protective duty. Data-quality acceptance cannot stand in for that specialised work.

Trial and Integration Workflow

Evaluation and Acceptance Criteria

Acceptance follows safety requirements and validation by competent personnel, including proof testing and evidence of independence for the actual scope. Ordinary image systems can be assessed for data quality and disclosure of limitations; image experiments do not establish SIL or SIF reliability.

Proof testing checks functions under a plan defined by competent personnel. It is not an image trial producing correct answers. This guide specifies neither physical test steps nor intervals, because those depend on the actual design, risks and site.

For supplementary observations, use images and simulated events to verify clear unknown states and absence of writes into protective paths. Have the functional-safety owner review connection boundaries and changes before use. Keep this validation distinct from acceptance of the protective system itself.

Failure Cases and Limitations

Average accuracy is not a substitute for probability of failure on demand or common-cause analysis. This content is not a SIF design, SIL calculation or equipment endorsement. General-purpose AI should not be the sole protective circuit relied on against hazards.

A common cause can disable several components together, for example through an unassessed shared resource. Two information sources do not prove independence. Computer uptime measures running time, not the probability that a protective function fails when demanded.

Standards provide a study framework and identify evidence to prepare; they do not certify a general-purpose system as an SIS. Proposed future functions must be distinguished from current installation scope. They do not reduce the duties of the plant owner or functional-safety specialists.

Practical Checklist

• Is it explicit which system provides monitoring only?
• Is a competent person responsible for functional safety?
• Are SIL claims excluded from accuracy and uptime results?

References and Further Reading

• UK HSE — Control systems and functional safety
• NIST SP 800-82 Rev. 3 — Guide to OT Security