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.
Due to the reference to sister standard IEC 61508 (2010 edition), suppliers of sensors, logic solvers and valves must seriously get to grips with updating any "SIL capability" certifications that pre-date 2010. All suppliers of devices with embedded software, operating systems and application programs must show evidence of product or system resilience to cyber-attacks.
In broad terms, the new edition has not really changed in its intended scope, but there are detailed changes and "tweaks" to terminology. Possibly the largest technical change is in the area of software - or the "Application Program" as it is now called. This is applicable when a logic solver such as a Programmable Logic Controller (PLC) is used in a safety duty. The new clauses could apply when any safety instrumented system logic solver application program is modified - so be warned!
In the management related requirements, the main update is the emphasis on formally requiring a competence management system to be in place for the management of safety systems. There is also a new emphasis on conducting functional safety assessment (FSA) during normal operation.
A new cyber security risk assessment requirement has been added to clause 8. This will be a challenge to many projects as the skillset crosses over from control system engineers to the general Information Technology (IT) domain.
The design phase now includes a specific requirement for a safety manual, and there are modified rules for claims on hardware fault tolerance. The section on application programming has been completely re-written, so should be carefully reviewed if your responsibility is coding.
The primary change in the validation stage is the requirement to show traceability of all SIS documentation in the validation record. This is a challenge on any project where multiple parties are involved and regular flat files are used for requirements. It really emphasizes the need for a database approach to functional safety requirements and validation documentation.
Operationally, an SIS now requires both a specific operations procedure and maintenance plan. Users must also collect demand and failure data for reliability calculations.
So, what do these changes mean to users of the standard? All end users must be aware of the new requirement for SIS and BPCS control system security assessment, probably implemented as part of the FSA. An SIS operations procedure and a maintenance plan will need to be developed, if not already in place. A database of failures and demands on the SIS will need to be logged.
For system integrators, or users who program their own logic solvers, there are new requirements to learn for specification and design of the application program. A checklist should be developed to ensure conformance with the new clause 12 of the standard, which is very different from the original.
Good luck with your next SIS project!