Recently Control magazine editor-in-chief, Walt Boyes covered a presentation by TÜV-Rhineland’s Heinz Gall, in a post entitled, Heinz Gall on Functional Safety–from the department of “no whining”. Heinz’ key point in this presentation was:
You must have safety management, and qualified personnel are a must!
I ran Walt’s post by Len Laskowski a certified functional safety expert (CFSE) in our Refining and Chemical Industry Center whom you might recall from an earlier IEC 61511 post.
Len agrees with Heinz’ assessment. He believes the problem most engineers have with the new standard such as IEC 61511 is that it is a performance standard. This is great news for the engineering community because they get to do the engineering. However the bad news is they must do the engineering. Len recalled the days when most process manufacturers were putting together their standards on safety instrumented systems, that these standards were very prescriptive.
This made it easier from an engineering point of view but sometimes could not cover all cases. By contrast, IEC 61511 being a performance standard allows you to investigate the alternative solutions for the right safety instrumented function (SIF) for the safety integrity level (SIL).
Len stresses that this can be a very powerful tool if applied properly and there is enough time in the project schedule to do this analysis. What typically happens is that project schedules do not put in enough time or qualified resources dedicated to this activity. As with most project activities, it is much better to do this earlier in the project than later. Len’s team has been called into projects towards the end and has uncovered problems on some of the high SIL level SIFs. This has caused a scramble to find the appropriate rated instruments required.
Len advises for your IEC 61511 safety projects to plan for more engineering time in the feasibility and front end engineering design (FEED). The older prescriptive methods allowed this work to be done later in the detailed design phase. As Len puts it:
Recognizing the need for more front end work will go a long way in reducing project frustrations.
Update: I fixed a typo and would like to extend a welcome to the readers of Gary Mintchell’s Feed Forward blog (subscribe here).
