Not Sexy, But Needful
Functional safety is where process safety meets automation.
Instead of relying solely on operators or passive protection, Safety Instrumented Functions (SIFs) can automatically detect hazardous process conditions and take the process to a safe state—for example, by initiating a high-pressure or high-level trip.
Functional safety is not limited to the process industries. The same principles are applied across industries including machine safety, mining, railways, automotive, nuclear and medical devices.
At the heart of functional safety management sits a document that is rarely described as exciting:
The Safety Requirements Specification (SRS).
It may not be glamorous, but it is one of the most important documents in the lifecycle of a Safety Instrumented System (SIS).
The SRS defines the requirements for the SIS and its Safety Instrumented Functions. And when we say requirements, we mean a lot of them.
Each SIF can have dozens of data fields covering everything from the initiating condition and trip setpoint to response time, reset arrangements and the required safe state. For a large project, the resulting SRS can easily run to hundreds of pages.
So why does this apparently enormous document matter so much?
Why Is the SRS Important?
There are three particularly important reasons.
1. It Defines What the SIS Must Do
The most fundamental purpose of the SRS is to ensure that the requirements for each safety function are clearly defined, documented and easy to find.
Consider some seemingly simple questions:
- What should cause the trip?
- What setpoint should be used?
- Is a time delay required?
- What should happen after the trip?
- How should the SIS be reset?
- What happens if there is a power failure?
- What happens when an instrument fails?
- What is the required response time?
These requirements may originate from different studies, specifications and engineering documents.
Without a clear SRS, important requirements can become scattered across the project documentation, making them difficult to find, interpret and maintain.
The SRS brings them together into a structured specification of what the SIS is required to do.
2. It Provides the Basis for SIS Validation
The SRS is also fundamental to SIS Validation.
Validation asks a simple but critical question:
Does the as-built SIS actually meet the requirements?
You cannot reliably validate something that has not been clearly specified.
The SRS therefore provides the reference against which the implemented SIS can be checked.
If the requirement says one thing but the implemented system does another, the discrepancy needs to be identified and resolved before the SIS can be considered fit for purpose.
3. It Preserves the Design Intent
An SIS can remain in service for decades.
The engineers who originally designed it may eventually move to other projects, retire or simply no longer be available.
Years later, someone may need to modify a trip, replace a device or investigate an unexpected behaviour.
At that point, the SRS becomes more than a project document.
It becomes a record of the original design intent.
A well-maintained SRS allows engineers to understand not only what the SIS does, but why it was designed that way in the first place.
Hardware and Software: What’s Actually in the SRS?
Functional safety standards such as IEC 61508 and IEC 61511 require the safety requirements to address both hardware and software aspects of the SIS.
In practice, however, the requirements are often managed through different documents and by different parties.
Hardware Requirements
When people talk about an SRS, they are often referring primarily to the hardware requirements.
These can include requirements for:
- Sensors and transmitters
- Logic solvers
- Final elements
- Setpoints
- Response times
- Voting arrangements
- Diagnostics
- Failure behaviour
- Reset arrangements
- Proof testing
- Environmental requirements
Development of these requirements is normally led by the engineering contractor responsible for the process and SIS design.
Software Requirements
The software side is concerned with the application program—the project-specific logic used to implement the safety functions.
These requirements are often captured separately in a document such as a Functional Analysis.
The Functional Analysis can define the software requirements and the logic needed to achieve them, sitting somewhere between specification and implementation.
It may also address additional technical requirements relating to areas such as reliability and security.
This work is typically undertaken by the System Integrator.
The important point is that the hardware and software requirements must ultimately work together to deliver the intended safety function.
Traceability: The Requirement Behind the Requirements
One of the most important—and frequently overlooked—aspects of an SRS is traceability.
Every important data item should have a clear audit trail back to its source.
Why?
Because the SRS doesn’t exist in isolation.
Its requirements are derived from information generated throughout the safety lifecycle, including studies such as:
- HAZOP
- LOPA
- SIL Assessment
- SIL Verification
- Cause & Effect
- Process design documentation
- Instrument data
- Other engineering specifications
During verification, we need to be able to answer a fundamental question:
Where did this requirement come from?
If the answer requires searching through hundreds of pages of project documentation, verification becomes slow, difficult and error-prone.
If the SRS data is directly linked to its source, verification becomes much more straightforward.
This is one of the strongest arguments for moving beyond spreadsheets and disconnected documents.
Why Not Just Use Excel?
Excel is familiar, flexible and available on almost every engineering desktop.
So why not simply use it to build an SRS?
For a small project, it may be perfectly adequate.
But as the number of SIFs and requirements grows, maintaining a large spreadsheet can become increasingly difficult.
A purpose-built SRS application can provide capabilities that are difficult to manage reliably in a conventional spreadsheet, including:
Automatic Data Population
Information can be automatically transferred from source data, such as SIF lists generated during LOPA or SIL Verification.
Completeness Checks
Missing or incomplete fields can be automatically identified rather than discovered during a late-stage review.
Consistency Checks
The system can identify data that appears inconsistent or unreasonable.
Linked Requirements
Fields that should contain the same information can be linked, reducing the risk of conflicting data.
Traceability
Requirements can remain connected to their source, making verification faster and more transparent.
Change Management
Changes can be tracked and reviewed, providing a clearer history of how the SRS has evolved.
The result is not simply a better-looking SRS.
It is a more controlled, traceable and maintainable safety requirements process.
From Documents to Connected Safety Data
This is where the future of SRS management becomes particularly interesting.
The information required to build an SRS already exists across much of the functional safety lifecycle.
LOPA identifies initiating events and protection requirements.
SIL assessment determines the required level of risk reduction.
SIL verification checks whether the proposed design can achieve the required SIL.
The SRS then defines what the SIS must actually do.
Rather than treating these as completely separate activities, there is an opportunity to connect the data across the safety lifecycle.
For example, a SIF identified during LOPA could become the starting point for the corresponding SRS entry, with relevant information carried forward automatically.
This reduces duplicate data entry, improves consistency and creates a stronger audit trail from hazard identification through to SIS implementation.
SRS Support Is Coming to Vizop
At xSeriCon, we believe the future of process safety software should not be a collection of disconnected tools.
Our PHA platform, Vizop, is being extended to support SRS development, bringing many of these capabilities into a connected workflow.
The planned functionality includes:
- Automatic population from upstream safety studies
- Traceability to source information
- Completeness checks
- Data consistency and reasonableness checks
- Linked data fields
- Change tracking
- And more
The objective is simple:
Make SRS development faster, more reliable and easier to verify—without sacrificing the engineering rigour required for functional safety.
More details will be available soon.
We Can Help
Developing an SRS is not simply a matter of filling in a spreadsheet.
It requires a clear understanding of functional safety, the SIS design, the underlying process hazards and the information generated throughout the safety lifecycle.
xSeriCon’s experienced functional safety specialists can support your SRS development, helping you build a specification that is complete, traceable and practical to maintain throughout the life of the SIS.
Whether you are developing a new SRS, reviewing an existing specification or looking for a more efficient way to manage SRS data, we can help.
Want to discuss your SRS requirements?