Last updated on July 22, 2023

Functional safety compliance

Achieving complete compliance with "risk-based" functional safety standards like IEC 61511 is a great objective to have, but is it, in fact, possible? 

More...

Experience with process industry functional safety assessment and audit would suggest that 100% compliance is NOT realistic when there are approximately 593 clauses, sub-clauses and bullet-point requirements in IEC 61511 [1].

To judge compliance, IEC 61511 requires that "each of the requirements in Clause 5 through 19 has been satisfied to the defined criteria and therefore the clauses' objectives have been met" [2].

So, how do end users with potentially catastrophic hazardous events decide from a list of nearly 600 items what is crucial and what is "nice to have" in meeting the objectives of the 15 clauses numbered 5 through 19 for a safety instrumented system?

Only 65% compliance may be achieved

From many experiences of independent audit and assessment of safety instrumented system projects, it is apparent that only around 60% to 70% of functional safety requirements that apply are actually met by a typical design.

This would beg the question of how these systems are then justified for going into service with a hazard?

Any justification for putting a safety system into service will ultimately be the responsibility of the duty holder. They may base their decision on an independent assessment, or they may not.

Either way, what must be avoided are any crucial requirements being jettisoned as somehow unimportant.

Compliance is trickier than you think.

Some might say that providing evidence that all "shall" rules in a standard is the only way to demonstrate compliance. I would not argue with that in principle, but there are definite cases where it is possible to say that non-compliance does not directly impact the final design.

A good example of this is where functional safety planning is evidently poor. IEC 61511 very clearly requires planning activities for the safety life-cycle, with several "shall" requirements in several places. However, in some projects the planning for functional safety activities is very high-level, inadequate, and sometimes even non-existent.

So, if a project proceeded without a good plan, does this mean the eventual system that is installed is no good? The answer is impossible to provide without specific detail, but there is a clear possibility that poor planning could lead to time and cost overrun, and this may not impact the final system that is implemented.

How to justify non-compliances...categorize requirements

To tackle this issue of "what is crucial" versus what is "nice to have", I would suggest that requirements can be categorized into the following groups:

  1. Level 1 "parent" requirements which must be met.
  2. Level 2 "child" requirements which need a plan for completion, or a full justification if they are not met.
  3. Level 3 "friend" requirements which are good to have, but if not met, they will not directly impact safety.

A top-level "parent" requirement must categorically be met. For example, "a hazard and risk assessment shall be carried out..." [3] is a very clear and crucial top-level requirement. If there is no evidence of a hazard and risk assessment having been completed, then there is no basis for design of any safety function or system.

A relatively recent "child" requirement in the same section of IEC 61511 is that "a security risk assessment shall be carried out to identify the security vulnerabilities of the SIS" [4]. This is still something that very few companies have achieved in practice. It does not mean that the thousands of installed systems in the world are inherently unsafe, but it does mean that threats may exist which could lead to an unsafe situation. A plan should be made to complete the exercise and implement any required changes.

"Friend" requirements, which are good to have, may already have been categorized by the standard as "should" rather than "shall". However, in practice I have found that there are some detailed requirements which simply do not affect safety, but can improve a project.

Conclusion

It is wise to categorise requirements in preparation for a functional safety assessment or audit. This will allow the exercise to go much smoother and ensure that time is spent on the most important aspects which truly affect the final system.

You can read more about functional safety compliance in our Ultimate Guide to the Safety life-cycle, chapter 4.

References

[1] IEC 61511: Functional safety of safety instrumented systems for the process industry sector. This standard is now variously known as IEC 61511 edition 2:2016 or BS EN 61511:2017 in UK and ANSI/ISA 61511 in the USA.
[2] IEC 61511-1 Clause 4.
[3] IEC 61511-1 Clause 8.2.1
[4] IEC 61511-1 Clause 8.2.4

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Register For ONLINE Learning

The link below will redirect you to our Member's Area

>
Success message!
Warning message!
Error message!