The recently updated process sector safety instrumented system (SIS) standard IEC 61511 now requires that a "security risk assessment is carried out to identify security vulnerabilities of the SIS" . But how should such an assessment be approached, and what can you do to prepare for it?
There have been well publicized examples of cyber-security breaches in the public domain, including the 2017 National Health Service (NHS) "Wannacry" ransomware as an example. Perhaps less well known by the general public was the 2017 "Triton" attack on Schneider Electric's Tricon TMR safety systems on a Saudi Arabian Petrochemical plant. That led to an unplanned shutdown of the process rather than any major hazard, but it could easily have been a very different outcome.
Read on to see the software buyer's guide table...a comparison of 4 cloud-based software solutions. This blog will will look at the main reasons why using such software is better than many traditional approaches, which companies are working in the domain and the questions you should ask before you choose a solution.
The safety life-cycle was a term first used in IEC 61508  to describe the different steps of activity required to develop an electrical/electronic or programmable electronic safety system. Today, that standard is mostly applied when an equipment manufacturer is developing a new safety-related product or system. A similar safety life-cycle was also framed by IEC 61511 . This one is more applicable to a safety system projects where the equipment from different suppliers is put together to form an overall system used in a safety duty. This IEC 61511 safety life-cycle is the main context for the software being reviewed in this blog.
Without effective functional safety assessment and audit, you may never know whether your safety system will perform when it is really needed. That is perhaps a bold statement, but read on if you think you disagree...
Automated systems have been used in safety applications now for a few decades. As a result we should have some good collective experience for handling projects that involve using these systems to reduce risk.
The safety systems I'm writing about in this blog are variously called ESD, HIPPS, BMS, IPS, ICSS, SIS, SRECS  or possibly some other multi-letter abbreviation that I've forgotten to mention. These systems typically use discrete (on/off) or analog sensors to detect hazards, programmable logic to decide how to act, and final elements that take action; usually without human intervention.
For the third blog of this series, the focus is on proof testing. This article will look at what proof testing is, why it's needed, and give some outline examples of proof test procedure requirements. It will also introduce some issues I've personally experienced during audits and assessments of proof test procedures in the process industry sector.
The term "proof testing", in the context of safety instrumented systems, was first introduced in the IEC 61511  standard when it was first published back in 2003. The idea of a proof test comes from the assumed fact that a safety function which is rarely needed (low demand) must be exercised at some frequency to check for "undetected" faults.
Operation and maintenance procedures for Safety Instrumented Systems (SIS) will vary from company to company. However, there are some specific requirements that need to be covered for safe continued operation.
The first blog on this topic discussed general operation and maintenance (O&M) requirements for sustaining the integrity of a SIS. This second article discusses the requirements for developing and maintaining SIS O&M procedures.
How do you ensure a Safety Instrumented System in operation will maintain its original design integrity for a lifetime of 15+ years?
The IEC 61511 (2016) safety life-cycle provides some brief guidance for operation and maintenance of a safety instrumented system (SIS) in clause 16. The stated objectives are to ensure that the validated system’s safety integrity is not compromised in any way, and that the SIL for each safety instrumented function (SIF) is sustained over the whole system lifetime.
Once an SIS reaches the operation stage, it's important that equipment is regularly inspected and maintained. Proof test procedures should have been developed for each safety function. The frequency of carrying out these inspections and tests should already have been determined by probability of failure calculations.
The process sector standard IEC 61511 is aimed at applications where instrumented systems are used for risk reduction in the process industry sector - including applications in chemicals, oil and gas, pulp and paper, pharmaceutical manufacturing, food and beverage, and non-nuclear power generation. Reduction of risk can be applied in the context of people, the environment and asset loss.
The original standard was published in the early 2000's, so edition 2 is a planned update. The intent of re-publishing it is to amend things that were not clear or simply were not working so well.
The headline poses a tricky question. Process accident history is awash with many examples of apparent incompetence involving safety instrumented systems (and other protection layers), some of them resulting in literally billions of dollars of losses, not to mention large environmental impact and loss of human life. So, developing and maintaining competence in the area of important protection layers such a Safety Instrumented Systems (SIS) would seem to be a "no-brainer".
However, in the real world, important competence development methods, such as attending training classes, seem to get pushed onto the back burner especially when times are tough. So, what is the typical cost of training personnel in this field of engineering?
Process facilities should be designed as far as possible to be inherently safe. Inherent safety involves reducing hazardous inventory and making the process mechanical design sufficiently robust.
However, it is not always possible to reduce risk to tolerable levels by inherent safety measures. Where further risk reduction is required, protection layers will be needed to prevent incidents propagating into accidents. Mitigation layers will be needed to minimise the consequences of hazardous failure events. LoPA provides special rules for protection layer credit which, when applied correctly, should ensure that adequate risk reduction is applied in the design.
Functional Safety Assessment (FSA) has been a requirement in IEC 61511 - Safety Instrumented Systems for the process industry sector, since the first edition published back in 2003. An FSA is one of the clear activities required to claim compliance with the IEC 61511 standard. The stated objective is to ensure that functional safety and safety integrity are achieved.
However, in practice many organisations have viewed FSA as an activity to be completed when a new safety instrumented system (SIS) gets installed, and of course, that is absolutely correct. But what about existing, or "legacy" systems? The question is, would it even be beneficial to carry out an FSA on an SIS that has been installed for many years and possibly even pre-dates the IEC61511 standard?