A.1 Introduction Although the workflow process and procedures provided in this GN are primarily aimed at process safety time assessment for operating assets, they are equally valid for use during project development stages as well. Following sections discusses some of the variations which need to be considered while using the GN during greenfield project development. A.2 Timing The figure C.1 outlines where in the overall lifecycle process safety time assessment would need to be taken up. It also maps key stages of SIS safety lifecycle defined in IEC- 61511-1 [11] against the project lifecycle. The proposed approach identifies the Safety Requirement Specification as a project deliverable prior to both FSA stage 1 (approved for design) and FSA stage 2 (approved for construction/use) Process Safety Time activity is only mandated for Safety Requirement Specifications and therefore, can be developed during define whilst developing the SIF architecture for design. This can then be validated during execute stage, at the end of detailed design, in line with SIF verification activities for delivering a fully developed Safety Requirement Specification. During define stage Process Safety Time activity can begin after preliminary Hazard Analysis, referred as Critical Review of P&IDs using HAZOP approach (CRPH), and SIF identification using LOPA are complete. Process Safety Times may be useful in some cases to support Inherently Safer Design (ISD) review during select phase but the level of engineering definition will limit the suitability of any calculations prior to Process Hazard Analysis. Usually at the end of define there is insufficient engineering detail to give final PST value, therefore, PST calculations may require further iteration in execute where sufficient details are available to carry out more rigorous calculations. This is likely to be those hazardous event scenarios requiring transient analysis to determine whether the SIF response time is adequate (e.g. compressor analysis & transient overpressure events)
Figure C.1 - Process Safety Time in Major Projects
A.3 Roles and responsibilities All the roles and responsibilities identified in the Section 4.0 of this GN are based on generic organisation structure for an asset or region within Global Operation Organisation. For a project organisation these can be substituted by equivalent discipline roles within the project team. A.4 Input data All the design data requirements specified in Table A.1 are also valid for projects. However, the design documents need not reflect the current status of the facility. Instead, the input documents needs to be Approved for Design for PST during define stage. While for PST validation during execute phase, the document needs to be Approved for Construction /Use. A.5 Study findings and action close out Unlike operating assets where the actions resulting from the PST study are risk ranked and prioritised based on the associated risk for continued operation, for projects, all the actions needs to be addressed prior to design implementation. SELECT ISD Review DEFINE
SELEC T Feed Detailed Design CRPH LOPA PST Development SRS (Approved for Design) EXECUTE HAZOP LOPA PST Validation SRS (Approved for Construction) ISD Review Allocation of safety Functions to protection layers Design and engineering of Safety instrumented system SIS safety life-cycle phases DEFINE Stage 1 FSA
Hazard and Risk Assessment
Design and development of other means of risk reduction Stage 2 FSA However, the focus needs to be on early identification of changes which can adversely affect the cost and schedule. It is therefore important that actions with significant design change or hardware modifications are identified during define stage PST development. Experience suggests that deferring the PST development in the projects up until the stage where they are required to be demonstrated for regulatory or standard compliance results in a situation where corrective actions are difficult to make and can cause significant cost and schedule impact.