Over the last few years, ORS has conducted multiple Functional Safety Assessments (FSAs). These have been for new development projects, brownfield modifications, and producing assets mainly for process industries. We have performed these FSAs at several stages of the project’s lifetime. From late front-end design (FSA stage 1), through detailed engineering (FSA Stage 2), after installation and commissioning (FSA Stage 3). You also conduct FSAs following several years of asset operations (FSA Stage 4 and FSA Stage 5).
There is great variation in both the assets and the stage of the project development.
However, among most FSAs, you do encounter some common issues. In an earlier article, we discussed the functional safety management and planning framework. This article aims to highlight some lessons learned associated with the identification of safety functions. In addition, it also aims to provide the definition of safety requirements (SIS lifecycle stages 1, 2, and 3).
Defining the Safety Requirements
The basis for the safety requirements that you should set on the instrumented protective measures is the hazard and risk assessments (HAZOPs) performed. These aim to identify the relevant hazards that could occur due to process excursions, and the consequences of these. For several of these process excursions, you will require instrumented protective functions. This is part of the safeguards to prevent the hazard from occurring.
Hence, the HAZOPs provide key input for the SIL allocation, giving information about the possible demands on the instrumented protective functions, the consequence should they fail, and the other available barriers. You should then use this to allocate the required Safety Integrity Levels (SIL) for the instrumented functions. Other functional requirements, such as process safety time, leak tightness, and desired response upon failure of components in the SIF (i.e. “fail direction”) shall be specified in the safety requirements specification (SRS).
The Lessons we Have Learned from Conducting an FSA
As an example, for offshore development projects in Norway, it has often been the practice to record the process hazard analyses “by exception”. This means that you only make records when you identify issues and when you take action during the HAZOP. In other words, there was no record of the identified hazards. Neither were there any records of the barriers in place for the cases where they had found the barriers to be adequate during the HAZOP.
This approach greatly diminishes the transparency and documentation basis of the decision background for the instrumented protective functions. You can mitigate the lack of transparency in this regard to a certain extent by applying the NOROG Guideline 070. Thereby stipulating minimum SIL requirements for "typical" instrumented functions, and hence "bypassing" the need for SIL allocation by risk-based methods such as LOPA. But the lack of transparency is still a concern.
Furthermore, typically the minimum SIL requirements from NOROG GL 070 were applied without further justification of the applicability of the design and asset in question.
Other Common Issues
Another recurring issue is the exclusion of entire units or packages from the scope of the analyses. For example, marine systems or “packaged equipment”. This exclusion often occurs without further justification other than citing corporate guidelines. Hence, the basis upon which they have given some instrumented functions a SIL requirement, and exclude others, isn't always transparent. This is even though such packages may give rise to multiple major accident hazards.
IEC 61511 lists several detailed requirements that you should include in the SRS. However, the users find it difficult to consolidate all of these in a single SRS. Consequently, they end up distributing them over several different documents and by generic references to corporate guidelines from the operator. This limits transparency, as well as potential introducing problems with having non-reconciled requirements.
Generic Requirements, Misconceptions, and a Lack of a Live Document
Typical issues include:
Use of “generic” requirements (such as e.g. closing time of valves) without justification for why the generic requirement is applicable. This may in the worst case lead to unsafe design. It could also lead to issues during operation (e.g. in cases where valve closing time is set to a generic 2s/inch while process safety time would allow for e.g. 5s/inch it is not necessarily a critical failure if the valve closes within 3s/inch – but asset personnel might think so if the requirement in the SRS is set generically).
Misconceptions between engineering and operation or between engineering disciplines with regard to the actions you need to take on component failures. SRS often gives generic statements. For example, “all failures shall result in shutdown” or “action to be taken upon failure is stated in vendor SAR”. As an example, for detected internal failures in transmitters, the desired action might be to either raise an alarm in the CCR or to fail high or fail low, based on the action and criticality of the SIF.
It is not always realized that the SRS shall be a live document to be used and updated during operations. This results in the engineering involved in the project development phase focusing on “finalizing” the SRS to get it approved/accepted, while “ignoring” the impact on operations. (e.g., resulting in bloated/unnecessarily extensive SRSs, generic requirements, lack of specifics, and potential re-work for the operational team to get a usable “live” SRS.)
Decreased Transparency and More Work
In general, vague links between the SIS lifecycle phases, undocumented or unjustified assumptions and separation of functional requirements across several different documents decrease transparency in the design and cause additional work.
This is a particular concern during handover from the engineering phase to asset operations. Specific issues related to later SIS lifecycle phases such as handover to operations and follow-up during operations will be the subject of a separate article.
What Conducting a FSA Taught us About How to Improve
Several of the suggestions for improvement listed here may seem self-evident. However, there is still often a failure to implement them. (We should however note that it is our experience that this has gradually improved significantly over the last years.)
As the PHA gives critical input to SIL allocation and other SIS lifecycle phases, it is important that the project’s functional safety responsible is a part of the planning of the PHA to ensure a clear link towards other SIS lifecycle activities.
There should be improvements to the operators' and EPC contractors' requirements for the recording of PHAs. Recording by exception should not be an acceptable default method due to limited transparency and information loss.
Documentation and the Purpose and use of the NOROG GL 070
When you use the NOROG GL 070 to allocate SIL, you should justify why the minimum SIL requirements are applicable (referring to NOROG GL 070 Ch 7.6). I.e., you should at least document that the design is a standard design in accordance with ISO 10418/API 14C. In addition, you should document the secondary barrier (with tag-nr). Furthermore, you should also document that the causes for demand are "standard" (e.g., failure of a control loop).
You should also document that a specific instrumented function does not have an unusual number of demands. Additionally, you should document that the consequence falls within what can “you can normally expect” (for similar applications/assets) should the barriers fail. The similarity between assets regarding process design and the consequences of hazards is the main foundation for the existence of NOROG GL 070.
This could be easy for cases where there is a proper record of the HAZOP. Just simply cross-reference to the HAZOP IDs where the instrumented function is listed as a safeguard. For this purpose, you could also use the Safety Analysis Tables.
Other Things to Keep in Mind and Questions About FSA
Where you perform a SIL allocation based on a risk-based approach such as LOPA, you should make available a list of assumptions used (such as manning, ignition probabilities, etc.) to ensure easy confirmation of their applicability at various stages in the project development. Such assumptions and premises should also be part of the assumption register, and part of the handover to operations.
Generally, you should make the effort to include all requirements to the SIS in a single SRS. In addition, you should try to also include all the requirements for the individual SIFs in the same SRS. Furthermore, to ease testing and validation of the SIFs prior to start-up, you should explicitly state requirements in the SRS. This is preferable to "generic" references to corporate standards and guidelines. This facilitates one-to-one verification that you meet the functional requirements of a SIF prior to start-up.
Do you have any questions about FSA? Or perhaps you have some other questions about the content of this article? Or maybe you even have questions about some other topic such as FMEA, conducting a HAZOP, SIL, etc. If so, feel free to contact us here at ORS.
