Configuring a Safety Instrumented System (SIS)
Configuring a Safety Instrumented System in SLM allows engineering teams to group related safety functions, connect them with the process units they protect and maintain the information required for Safety Requirements Specification reporting.
Within the Instrumented Systems module, a Safety Instrumented System (SIS) can contain one Safety Instrumented Function or a combination of multiple functions and function types. The same SIS can also be associated with more than one process unit while retaining clear relationships between each function and its original unit.
This guide explains how to create and view an SIS, link the appropriate functions and generate the associated SIS SRS report from the engineering information stored in SLM.
What Is a Safety Instrumented System in SLM?
A Safety Instrumented System in SLM is an engineering object used to group one or more protection functions within the Instrumented Systems module. It provides a structured location for maintaining system-level information while preserving the individual engineering records associated with each function.
An SIS may contain:
- A single Safety Instrumented Function.
- Multiple Safety Instrumented Functions.
- Different types of instrumented and protective functions.
- Functions associated with one process unit.
- Functions distributed across several process units.
The SIS object does not replace the individual function records. Instead, it establishes a system-level relationship between the functions that collectively implement the required protective actions.
For an introduction to the wider module structure, see the Instrumented Systems Overview.
Creating a Safety Instrumented System
A new SIS object is created beneath the appropriate Unit object within the Instrumented Systems hierarchy. Creating it at the unit level establishes the initial relationship between the system and the process area in which it is used.
Before creating the object, engineers should determine:
- Which unit initially owns the SIS record.
- Whether the SIS contains one function or several functions.
- Which types of protection functions will be included.
- Whether the SIS must be shared with additional units.
- Which engineering information must be captured for the system-level SRS.
Once created, the SIS can be populated through its dedicated data-entry views. These fields store the system-level information that will later appear in the SIS Safety Requirements Specification report.
Individual functions can be configured separately before being associated with the SIS. The Configuring a Safety Instrumented Function guide explains how complete SIF architectures are created within the module.
Using an SIS Across Multiple Process Units
A Safety Instrumented System may be associated with more than one process unit. This supports installations where a common SIS implements protection functions across several areas of a facility.
When an SIS is shared between units, the SIS object becomes visible within each associated unit. However, the individual functions linked to it remain within the units where those functions were originally created.
For example, an SIS may contain:
- A Safety Instrumented Function located in Unit A.
- An interlock located in Unit B.
- Another protective function located in Unit C.
Sharing the SIS does not duplicate or relocate these functions. It creates a common system-level relationship while preserving the correct unit ownership and engineering context of each function.
This structure helps engineering teams represent plant-wide protection systems accurately without creating duplicate function records or losing traceability between functions and their associated process areas.
MSS also provides an Instrumented Systems software solution for centrally managing protection-layer architecture, SIFs and Safety Requirements Specification information.
Linking Functions to a Safety Instrumented System
After a Safety Instrumented System has been created and associated with the appropriate process units, individual protection functions can be linked to it. This relationship defines which functions are implemented by the SIS while maintaining each function as an independent engineering object.
The most common method of linking functions is through the Related Functions field within the SIS object. Selecting this field displays a list of available functions that can be associated with the system.
Engineers simply select the required functions, save the changes and the SIS relationship is created. If a specific Function ID is already known, the search facility can be used to quickly locate the correct function before linking it.
Alternatively, functions can be linked by dragging and dropping them directly onto the Safety Instrumented System within the object tree, providing a faster workflow when configuring multiple functions.
To understand how individual protection functions are configured before they are linked into an SIS, see the Instrumented Functions (IPL’s) guide.
Managing Linked Functions
Relationships between a Safety Instrumented System and its associated functions can be updated at any time. This flexibility allows engineering teams to refine the system as projects develop, equipment changes or protection strategies are modified.
If a function has been linked incorrectly, it can be removed using the same Related Functions table. Simply clear the relevant selection and save the changes to remove the relationship without affecting the function itself.
Because the functions remain as independent engineering objects, removing them from an SIS does not delete any engineering information. Function configuration, calculations and documentation remain intact while only the system-level association is removed.
This approach provides a clear separation between configuring individual protection functions and organising them into complete Safety Instrumented Systems, making ongoing lifecycle management significantly easier.
Benefits of Grouping Functions Within an SIS
Grouping related protection functions into a Safety Instrumented System provides a structured view of how protective actions are implemented across a process unit or an entire facility. Rather than reviewing individual functions independently, engineers can assess the complete system as a single engineering entity.
Using an SIS also improves:
- Engineering traceability.
- Safety lifecycle documentation.
- Safety Requirements Specification management.
- Cross-unit visibility.
- Engineering reviews and audits.
- Consistency across multiple Safety Instrumented Functions.
As project information evolves, the linked functions and associated SIS documentation remain synchronised, helping engineering teams maintain accurate records throughout the functional safety lifecycle.
Generating an SIS Safety Requirements Specification (SRS)
Once a Safety Instrumented System has been configured and all appropriate functions have been linked, the information stored within the SIS object can be used to generate a comprehensive Safety Requirements Specification (SRS) report.
As engineering data is entered across the various SIS tabs, SLM automatically builds the information required for the system-level SRS. This ensures that the report reflects the latest configuration of the Safety Instrumented System without requiring engineers to manually compile documentation.
The generated report typically includes:
- Safety Instrumented System identification.
- Associated Safety Instrumented Functions.
- Engineering attributes entered within the SIS object.
- Relationships between linked protection functions.
- Supporting Safety Requirements Specification information.
For organisations managing detailed Safety Requirements Specification documentation, the Safety Requirement Specification (SRS) guide explains the wider documentation process.
Exporting the SIS SRS Report
SLM provides multiple methods for generating an SIS Safety Requirements Specification report. Engineers can create the report directly from the Safety Instrumented System object or generate it through the dedicated reporting interface within the Instrumented Systems module.
To generate the report from an SIS object:
- Open the required Safety Instrumented System.
- Select the Print Out View tab.
- Click Print.
- The system generates the report and sends an email containing a secure download link.
Alternatively, the report can be generated from the SIS SRS reporting view by selecting the appropriate Site, Unit and SIS before clicking Generate. Once processing has completed, a notification email is sent containing a link to download the finished report.
This reporting process allows large reports to be generated in the background without interrupting engineering work.
Best Practices for Configuring a Safety Instrumented System
Following a consistent configuration process helps maintain accurate engineering records and ensures every Safety Instrumented System remains aligned with the functions it is intended to implement.
Recommended best practices include:
- Create the SIS before linking protection functions.
- Associate the SIS with all relevant process units where required.
- Link only the functions implemented by that Safety Instrumented System.
- Review linked functions regularly during project development.
- Complete SIS information before generating SRS documentation.
- Use the generated reports to support engineering reviews and lifecycle documentation.
Applying these practices helps maintain complete traceability between Safety Instrumented Systems, individual functions and the documentation required throughout the functional safety lifecycle.
Learn More About Instrumented Systems
Configuring a Safety Instrumented System is one part of managing the complete functional safety lifecycle within SLM. The Instrumented Systems module connects system-level information with individual protection functions, Safety Requirements Specifications and engineering documentation to provide a complete engineering record.
Related resources include:
- Instrumented Systems Overview
- Configuring a Safety Instrumented Function
- Instrumented Functions (IPL’s)
- Safety Requirement Specification (SRS)
- SIL Calculation Reports
- Calculations
For additional guidance on functional safety requirements for Safety Instrumented Systems, refer to the International Electrotechnical Commission (IEC), publisher of the IEC 61511 standard for the process industries.
Configuring a Safety Instrumented System
0:06
Welcome to this Application Explainer video, part of our Instrumented Systems topic range.
0:11
In this video, we’ll cover the subject of configuring a safety instrumented system in SLM within the SLM Instrumented Systems module.
0:20
Safety Instrumented Systems may be built as a grouping of functions where, per IEC 61511, an SIS may be used to implement one or more Sifs and may include other functions or actions.
0:35
The following information will be covered in this training.
0:38
Chapter one will be creating and viewing an SIS.
0:41
Chapter 2 will be linking functions to an SIS, and Chapter 3 will be printing an SIS SRS.
0:53
In Chapter 1, we’ll be covering how to create a new SIS object and things to consider.
0:59
ANSIS is a grouping of one or more functions, but it’s not necessary for all other SLM SIF functionality.
1:07
Within the Instrumented Systems module, a Safety Instrumented System Object or SIS may be created under the Unit Level object.
1:23
The SIS may be specified to contain only a single safety instrumented function, or it may contain any combination of other functions and types of functions within the same unit where the SIS resides.
1:38
Additionally, an SIS may exist within multiple units while containing functions from each unit.
1:45
Placing a function within an SIS existing in multiple units will not result in the function existing in other units.
1:52
Only that thesis itself is shared between the units and covers functions from each process unit.
2:03
In Chapter 2, we’ll be covering how to link appropriate functions to an SIS and things to consider sharing SIS and functions within Thesis between units.
2:15
Once Thesis is created and linked to all appropriate units, the functions to be implemented within it may be selected.
2:23
The simplest way to do this is open the Related Functions field to edit, place a check next to the functions to be edited, and click on Save.
2:37
This table may also be used to search for the function ID if it is known.
2:48
Or an alternative approach to linking functions to an SIS may also be to simply drag and drop functions to the sys just within the object tree.
3:03
If any mistake is made in linking functions, they will also be unlinked just as easily within the same relational Functions field.
3:15
By unchecking them from the list and clicking Save once more.
3:26
In Chapter 3, we’ll be covering how to export the SIS SRS report.
3:32
Things to consider.
3:33
The reports may be sent through e-mail instead of being generated directly in the system.
3:39
With the SIS now created and the function that covers identified, various fields are available to be entered across the separate view tabs.
3:50
The fields within each of these views, as they are entered, will populate the sys SRS available from the Print Out View tab or from the SISSRS Print Out report here in the Instrumented Systems module.
4:15
To export the report, simply click on the Print button from the Print Out View tab on the SIS object and the system will send an e-mail with a link to download the report.
4:29
Or from the SIS SRS Print Out report view, select the appropriate site, unit and SIS ID options and click Generate for the system to do the same.
4:50
When it completes this task, the notification will be sent to your account’s e-mail, where you’ll be able to download the file directly from the systems page.