Configuring a Safety Instrumented Function
Configuring a Safety Instrumented Function in SLM allows users to model the complete structure of a SIF, including its inputs, logic solver, outputs and voting layers.
Within the Instrumented Systems module, Configuring a Safety Instrumented Function involves creating a new SIF, relating it to the correct unit or Safety Instrumented System, building the required architecture and defining which elements are included in the SIL calculation.
This guide explains how to create a SIF object, organise its parent-child relationships and begin building an architecture that accurately reflects the safety function installed in the field.
What Is a Safety Instrumented Function?
A Safety Instrumented Function is a protective function designed to move a process to a safe state when defined conditions are detected. It normally includes one or more inputs, a logic solver and one or more final elements.
In SLM, the complete SIF architecture can be modelled as a structured hierarchy. This may include input groups, input voting groups, individual sensors, a logic solver, output groups, output voting groups and final elements.
This structure allows users to represent both simple and complex safety functions, including architectures with multiple layers of voting. The completed model can then be used to support SIL calculations and other Instrumented Systems activities.
Configuring a Safety Instrumented Function in SLM
To create a new SIF, navigate to the Instrumented Systems module and select the parent object beneath which the function should be created. In most cases, this will be a unit or an existing Safety Instrumented System.
From the parent object, open the Edit Tools menu and select Add SIF. SLM then allows the user to enter a new SIF ID or select an existing SIF from the same site or scope.
Existing SIF objects can be linked, cloned independently or cloned together with their child objects. These options can reduce setup time where similar safety functions already exist elsewhere in the system.
After the SIF ID has been entered, select Save and Edit to create the function and open the new SIF object. The function will then appear in the object tree beneath the selected parent.
If the SIF was created at unit level, it can later be related to an SIS by selecting it in the SIS-related functions field or by dragging the SIF onto the SIS within the object tree.
For more information about how complete systems and functions are organised, see the Instrumented Systems Overview.
Building the SIF Architecture
When Configuring a Safety Instrumented Function, the next step after creating the SIF is to build the architecture that represents the complete protective function.
On the input side, the structure may include an input group, one or more input voting groups and the individual input devices. On the output side, the same pattern is used for output groups, output voting groups and final elements. A logic solver connects the two sides.
These objects can be created individually by moving through the parent-child hierarchy in the object tree. For example, an input voting group is created beneath an input group, while an individual input is created beneath the relevant input voting group.
A faster method is available from the SIF Architecture tab. This centralised view allows users to create the logic solver, input groups, voting groups, inputs, output groups and outputs without navigating repeatedly between separate objects.
Creating the logic solver first is recommended because the graphical SIF diagram will not begin to render until a logic solver object exists.
As each object is added, its parent relationship must be selected correctly. SLM uses these relationships to position every element within the SIF hierarchy and to build the architecture diagram.
For a broader explanation of SIF components, see Instrumented Functions (IPLs).
Creating Inputs, Outputs and Logic Solvers
A complete Safety Instrumented Function consists of several related objects that together represent the protective function installed in the field. These include the logic solver, input groups, input voting groups, individual inputs, output groups, output voting groups and final elements.
The SIF Architecture tab provides a central location for creating each of these components. This makes Configuring a Safety Instrumented Function more efficient because users can add and organise the required objects without repeatedly navigating through the object tree.
Users can expand the relevant section, select the appropriate Add option and specify an ID for each new object before saving it.
Each object must be assigned to its correct parent before it can be created successfully. For example, an input voting group must belong to an input group, while each input must be assigned to an existing input voting group. SLM validates these relationships before allowing the object to be saved.
As objects are added, the SIF hierarchy is automatically constructed within the object tree. Once a logic solver has been created, the graphical architecture diagram also begins to populate, allowing engineers to visualise the complete Safety Instrumented Function.
By continuing this process for additional sensors, voting groups and final elements, users can model both simple and highly complex SIF architectures while maintaining clear parent-child relationships throughout the design.
Applying Voting Configuration
Once the Safety Instrumented Function architecture has been completed, voting must be configured so that SLM knows which objects are included within the SIL calculation. Voting is applied at each layer of the architecture, including input groups, input voting groups, the logic solver and output groups.
Users select the relevant objects that should participate in the calculation before specifying the required voting arrangement, such as one-out-of-one (1oo1), one-out-of-two (1oo2) or two-out-of-two (2oo2), depending on the design of the safety function.
When Configuring a Safety Instrumented Function, voting can be applied directly to each individual object or more efficiently from the SIF Architecture tab, where every voting layer can be updated from a single location.
This centralised approach significantly reduces navigation when working with larger or more complex architectures.
As voting is applied, the architecture diagram provides immediate visual feedback. Objects included within the SIL calculation become fully coloured, while components surrounded by dotted outlines indicate that they are not currently participating in the calculation.
This visual representation makes it easy to identify incomplete voting configurations before SIL calculations are performed, helping engineers confirm that every required layer has been configured correctly.
For additional guidance on documenting complete safety functions, see the Safety Requirement Specification (SRS).
Understanding SIL Calculation Architecture
The SIL calculation architecture is derived directly from the completed Safety Instrumented Function. Every object that participates in the voting configuration contributes to the calculation model used within SLM.
As voting is assigned throughout the architecture, the graphical diagram updates to reflect which components are actively included in the SIL calculation. This allows engineers to verify the completeness of the model before continuing with reliability analysis.
Complex Safety Instrumented Functions may contain multiple input groups, several voting layers and numerous final elements. The architecture view provides a consistent method for confirming that each layer has been configured correctly and that every required object has been selected.
If any section of the diagram continues to display dotted outlines after voting has been configured elsewhere, this provides a clear indication that additional configuration is still required before the Safety Instrumented Function is fully represented within the SIL calculation.
Using the architecture view in this way helps engineering teams identify missing relationships early, reducing rework and improving confidence in the completed Instrumented System model.
Best Practices for Configuring Safety Instrumented Functions
A well-structured Safety Instrumented Function is easier to maintain, review and verify throughout its lifecycle. Establishing a consistent configuration process helps ensure that every component is modelled correctly and that SIL calculations accurately represent the installed protection system.
- Create the logic solver before building the remainder of the architecture so the SIF diagram can begin rendering immediately.
- Always assign the correct parent object before saving new groups, voting groups or individual devices.
- Use the SIF Architecture tab to build and manage larger Safety Instrumented Functions more efficiently.
- Clone existing inputs or outputs when multiple devices share the same configuration, updating only the unique information such as the object ID.
- Confirm that every required voting layer has been configured before completing SIL calculations.
- Review the architecture diagram to ensure no dotted sections remain where objects should participate in the calculation.
Following these practices when Configuring a Safety Instrumented Function improves consistency across Instrumented System projects, reduces engineering effort and makes future modifications easier to manage.
Related Instrumented Systems Guides
Configuring a Safety Instrumented Function is one stage in developing a complete Instrumented System. The following guides explain related activities, from defining system requirements through to documenting and verifying the completed design.
- Instrumented Systems Overview
- Safety Requirement Specification (SRS)
- SIL Calculation Reports
- Cause and Effect Matrices
- Instrumented Functions (IPLs)
For additional information on the functional safety lifecycle and Safety Instrumented Systems, refer to the International Electrotechnical Commission (IEC), which publishes the IEC 61511 standard used throughout the process industries.
