<\/p>\n\n\n\n
If you have ever attended process safety training, you have probably seen the \u201cOnion\u201d model<\/strong>.<\/p>\n\n\n\n It shows how different protective systems can be arranged as concentric layers around a hazardous process. These are known as Layers of Protection (LOPs)<\/strong>, and each layer is intended to help prevent a hazardous event from developing into an accident.<\/p>\n\n\n\n For these layers to provide effective risk reduction, they need to be sufficiently independent<\/strong>. In other words, one layer should be capable of performing its protective function even if another layer fails.<\/p>\n\n\n\n One particularly important layer is the Safety Instrumented System (SIS)<\/strong>.<\/p>\n\n\n\n An SIS is an automatic system designed to detect hazardous or abnormal conditions and take the process to a safe state, helping prevent an accident or reduce its consequences.<\/p>\n\n\n\n So, what exactly is an SIS\u2014and what makes it different from an ordinary process control system?<\/p>\n\n\n\n Depending on the application, a safety instrumented function can operate in different modes.<\/p>\n\n\n\n In many process industry applications, the SIS remains ready to act and intervenes when a specific dangerous condition occurs.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n High pressure detected \u2192 SIS initiates shutdown \u2192 Shutdown valve closes \u2192 Process moves toward a safe state<\/strong><\/p>\n\n\n\n This is known as a demand mode safety function<\/strong>.<\/p>\n\n\n\n The SIS is not continuously controlling the process. Instead, it takes action when its safety function is demanded.<\/p>\n\n\n\n In other applications, the safety function may operate continuously, taking frequent or ongoing actions to keep the equipment in a safe condition.<\/p>\n\n\n\n Continuous-mode safety functions are found in applications such as:<\/p>\n\n\n\n The exact implementation varies by industry, but the fundamental principle is the same:<\/p>\n\n\n\n Detect a dangerous condition and take appropriate action to maintain or achieve a safe state.<\/strong><\/p>\n\n\n\n A Safety Instrumented System is more than just a \u201csafety PLC.\u201d<\/p>\n\n\n\n An SIS is generally made up of three fundamental subsystems:<\/p>\n\n\n\n Sensors monitor the process and measure variables such as:<\/p>\n\n\n\n These process variables are transmitted to the SIS logic solver.<\/p>\n\n\n\n For safety applications, the sensor arrangement may incorporate redundancy or voting to achieve the required level of risk reduction and reliability.<\/p>\n\n\n\n The logic solver<\/strong> receives inputs from the sensors and other sources and determines whether a safety action is required.<\/p>\n\n\n\n It then sends commands to the final elements.<\/p>\n\n\n\n The logic solver may also handle functions such as diagnostics, event logging, communication and operator interfaces.<\/p>\n\n\n\n <\/p>\n\n\n\n Final elements are devices capable of taking physical action on the process\u2014what IEC 61508 refers to as the Equipment Under Control (EUC)<\/strong>.<\/p>\n\n\n\n Examples include:<\/p>\n\n\n\n The final elements are ultimately responsible for carrying out the safety action.<\/p>\n\n\n\n Together, these three parts form the basic architecture of an SIS:<\/p>\n\n\n\n Sensors \u2192 Logic Solver \u2192 Final Elements<\/strong><\/p>\n\n\n\n But there is much more to a complete SIS.<\/p>\n\n\n\n What Else Is Part of an SIS?<\/p>\n\n\n\n A complete SIS can include a wide range of additional components and functions.<\/p>\n\n\n\n Operators may need to monitor and interact with safety functions through:<\/p>\n\n\n\n These interfaces need to be carefully designed so that operators can understand the state of the safety system without compromising its independence or integrity.<\/p>\n\n\n\n The SIS requires a reliable power supply, often including a UPS<\/strong> and, depending on the application, other supporting energy sources such as compressed air.<\/p>\n\n\n\n The SIS contains an application program<\/strong> defining how the safety functions are implemented.<\/p>\n\n\n\n This is the project-specific logic that determines what the SIS should do when particular conditions occur.<\/p>\n\n\n\n Diagnostic functions help detect failures within the SIS.<\/p>\n\n\n\n A good diagnostic system can identify faults, alert operators and, depending on the architecture, initiate an appropriate action when a dangerous failure is detected.<\/p>\n\n\n\n Modern SISs may communicate with process control systems and other plant networks.<\/p>\n\n\n\n However, communication must be carefully engineered so that connectivity does not compromise the independence or safety integrity of the SIS.<\/p>\n\n\n\n The system also relies on embedded software<\/strong> that provides fundamental functions within the SIS hardware, such as input\/output processing and event logging.<\/p>\n\n\n\n Engineering workstations or consoles may be provided for activities such as:<\/p>\n\n\n\n These functions require appropriate controls to prevent unauthorized or unintended changes to the safety system.<\/p>\n\n\n\n This is a surprisingly common point of confusion.<\/p>\n\n\n\n Some practitioners use the term SIS<\/strong> to refer primarily to the logic solver or safety PLC.<\/p>\n\n\n\n However, that is not how the term is generally used in international functional safety standards such as the\u00a0IEC 61508<\/strong> family.<\/p>\n\n\n\n The SIS encompasses the complete safety system\u2014including the sensors, logic solver and final elements\u2014together with the relevant supporting components and functions required to achieve the safety function.<\/p>\n\n\n\n This distinction matters because the reliability and performance of the complete safety function<\/strong> depend on every part of the chain.<\/p>\n\n\n\n A highly reliable logic solver cannot compensate for an unsuitable sensor or unreliable final element.<\/p>\n\n\n\n Remember the Onion model?<\/p>\n\n\n\n The principle of independent Layers of Protection is fundamental to process safety.<\/p>\n\n\n\n But there is an obvious question:<\/p>\n\n\n\n If the SIS and Process Control System (PCS) perform different functions, can they share components?<\/strong><\/p>\n\n\n\n The answer is more nuanced than simply \u201cyes\u201d or \u201cno.\u201d<\/p>\n\n\n\n A strict interpretation might suggest that the SIS and PCS should share no hardware whatsoever.<\/p>\n\n\n\n Functional safety standards, however, allow certain forms of sharing where the contribution to common-cause failure can be demonstrated to be sufficiently small.<\/p>\n\n\n\n That demonstration is important.<\/p>\n\n\n\n If a shared component can fail in a way that causes both the PCS and SIS protection layers to fail simultaneously, the apparent independence between the layers has been compromised.<\/p>\n\n\n\n Therefore, any shared components need to be carefully assessed and justified.<\/p>\n\n\n\n Modern technology has made the boundary between control and safety systems less obvious.<\/p>\n\n\n\n Many SIS manufacturers now offer Integrated Control and Safety Systems (ICSS)<\/strong> in which control and safety functions can share elements of the underlying hardware and infrastructure.<\/p>\n\n\n\n Does this mean the safety system is no longer independent?<\/p>\n\n\n\n Not necessarily.<\/p>\n<\/blockquote>\n\n\n\n ICSS architectures can use combinations of:<\/p>\n\n\n\n These features can significantly reduce the likelihood that a failure will affect both the PCS and SIS safety functions simultaneously.<\/p>\n\n\n\n But the important point is that independence cannot simply be assumed because a system is marketed as an ICSS<\/strong>.<\/p>\n\n\n\n The architecture needs to be properly assessed against the applicable functional safety requirements.<\/p>\n\n\n\n An SIS is not simply a collection of safety PLCs, sensors and valves.<\/p>\n\n\n\n It is part of a broader Functional Safety lifecycle<\/strong>.<\/p>\n\n\n\n The design of the SIS should begin with an understanding of the hazards and the required risk reduction.<\/p>\n\n\n\n Activities such as:<\/p>\n\n\n\n HAZOP \u2192 LOPA \u2192 SIL Assessment \u2192 SIF Definition \u2192 SIL Verification \u2192 SRS \u2192 SIS Design \u2192 Validation<\/strong><\/p>\n\n\n\n help establish what the SIS needs to achieve and demonstrate that the final implementation meets those requirements.<\/p>\n\n\n\n This is why SIS design cannot be separated from the wider process safety and functional safety lifecycle.<\/p>\n\n\n\n A technically sophisticated SIS is not necessarily a good SIS if it does not address the actual risks of the process or if its requirements have not been clearly defined.<\/p>\n\n\n\n Once an SIS has been designed and commissioned, the work is not over.<\/p>\n\n\n\n The system needs to be maintained, tested and managed throughout its operational life.<\/p>\n\n\n\n This includes activities such as:<\/p>\n\n\n\n The objective is to ensure that the SIS continues to provide the required risk reduction throughout the life of the plant.<\/p>\n\n\n\n Functional safety is a lifecycle\u2014not a one-time engineering exercise.<\/strong><\/p>\n<\/blockquote>\n\n\n\n Designing and managing an SIS requires more than selecting a safety PLC.<\/p>\n\n\n\n It requires a clear understanding of process hazards, Safety Instrumented Functions, SIL requirements, system architecture and the complete functional safety lifecycle.<\/p>\n\n\n\n xSeriCon’s experienced functional safety specialists<\/strong> can support clients across this lifecycle, from LOPA and SIL assessment through SIL verification, Safety Requirements Specification (SRS), SIS design support and validation<\/strong>.<\/p>\n\n\n\n Our practical, client-focused approach helps ensure that your SIS is appropriately specified, efficiently designed and capable of meeting the safety requirements of your process.<\/p>\n\n\n\nWhat Does a Safety Instrumented System Do?<\/h2>\n\n\n\n
Demand Mode<\/h4>\n\n\n\n
Continuous Mode<\/h4>\n\n\n\n
\n
\n\n\n\nWhat Is Inside an SIS?<\/h2>\n\n\n\n
1. Sensors<\/h4>\n\n\n\n
\n
2. Logic Solver<\/h4>\n\n\n\n
3. Final Elements<\/h4>\n\n\n\n
\n
\n\n\n\nWhat Else Is Part of an SIS?<\/h2>\n\n\n\n
Operator Interfaces<\/h4>\n\n\n\n
\n
Power Supply<\/h4>\n\n\n\n
Application Software<\/h4>\n\n\n\n
Diagnostics<\/h4>\n\n\n\n
Communication<\/h4>\n\n\n\n
Embedded Software<\/h4>\n\n\n\n
Engineering Functions<\/h4>\n\n\n\n
\n
\n\n\n\nIs the SIS Just the Safety PLC?<\/h2>\n\n\n\n
\n\n\n\nHow Independent Does an SIS Need to Be?<\/h2>\n\n\n\n
\n\n\n\nWhat About Integrated Control and Safety Systems?<\/h2>\n\n\n\n
\n
\n
\n\n\n\nDesigning the Right SIS<\/h2>\n\n\n\n
\n\n\n\nFrom SIS Design to Functional Safety Management<\/h2>\n\n\n\n
\n
\n
\n\n\n\nWe Can Help<\/h1>\n\n\n\n