Safety Requirements Specification and Functional Safety Concept
Safety requirements specification and functional safety concept
This domain tests whether requirements are complete, verifiable, and design-neutral. Expect the distinction between the functional safety concept (FSC) and the safety requirements specification (SRS), and the content needed to engineer, verify, and operate a SIF.
Core rules
- The FSC allocates safety functions to protection layers and defines the functional safety requirements; the SRS then specifies each SIF in enough detail to design and verify it.
- A functional safety requirement states what the function must do, not which vendor or architecture to use.
- The SRS covers the function and safe state, SIL, demand mode, process safety time, response time, proof-test interval, operating modes, reset, bypass, interfaces, and failure response.
- Requirements must be uniquely identified, traceable to hazard scenarios, and testable at validation.
- The SRS is a living baseline; changes follow management of change and re-verification.
Worked example
A reactor high-temperature trip must close the steam valve within 2 s of temperature exceeding the trip setpoint. The FSC allocates the function to a SIL 2 SIF; the SRS specifies sensor range and redundancy, logic response, valve stroke time, fail-safe action, a 12-month proof-test interval, and a 2 s response-time budget including sensor delay, scan time, and valve closure. "The SIS shall be SIL 2" alone is not a functional requirement; it gives the designer no verifiable behaviour.
Traps
- Writing a specification around one preferred product, which prevents alternatives and can hide gaps.
- Confusing response time with process safety time.
- Omitting the safe state and reset philosophy.
- Specifying SIL without demand mode, proof-test interval, or response time.