Project safety lifecycle

The project safety lifecycle for the design, operation and eventual decommissioning of a hazardous plant is summarized in Fig. 2.1. The most important purposes of the safety lifecycle are to ensure that (a) design work is properly planned, and (b) safety requirements are traceable from beginning to end. 

The standard recognizes that the specified activities might be structured in different ways, provided that all the requirements are complied with. This restructuring can be beneficial if it allows safety activities to be better integrated into normal project procedures. The purpose of Clause 6 of lEC 61511-1 ANSI/ISA-84.00.01-2004 Part 1 (lEC 61511-1 Mod) is to ensure that if a different safety lifecycle is used, the inputs and output of each phase of the lifecycle are defined and all essential requirements are incorporated. 

Decommissioning To ensure proper review, sector organization, and ensure Safety Instrumented Function (SIF) remain appropriate. 18 Apply appropriate safety lifecycle phase during project execution... 

ANSI/ISA-84.00.01-2004-1 addresses the competency requirements for individuals involved in the safety lifecycle. Competency requirements are not addressed in ANSI/ISA-84.01-1996, because competency was already addressed in OSHA 1910.119 for all disciplines involved in process plant design, maintenance, and operation. Since the standard has an international scope, the competency requirements are presented for the benefit of those owners/operators that do not have a regulatory system in place that defines these requirements. ISA-TR84.00.04-1 Annex C provides additional guidance on the management of functional safety through effective project management and quality control processes. 

The safety lifecycle for l C equipment Reliability requirements for high-integrity systems Software quality management Functional specifications and traceability Setting up a high-integrity software project Common-mode failure I C architecture... 

The particularities include those things that were retained too project specific and therefore shall be described at instantiation time. Such things include the contents of the project and organization chart the particular tools that will be actually used the actual topics and schedule of the training courses the names of the staff the justification of the roles the actual inputs and outputs of each safety lifecycle phase (although suggestions were made in form of templates). 

As mentioned in the previous chapter our solution strategy to manage and control the related overall costs is to create a common and reusable safety lifecycle model that can be customized and tailored to a specific safety development project. The key success criteria for this solution strategy are reusability and low cost in the customization and tailoring. 

There are no clearly defined design elements for hardware and software development to manage complexity of a safety development project. Although system, subsystem, component and module are used in the SLCM, there is too much interpretation freedom, which leads to uncontrollable uncertainty and difficult in specifying the required outputs of each safety lifecycle phase. 

ISO 26262 generally assumes that products are developed within a project structure. Here there is a chance that divisions or organizations develop products according to a general interpretation or implementation of a product lifecycle ( Project independent tailoring of the safety-lifecycle ). This means a process scope is developed, that represents a valid derivation of ISO 26262 but can also be optimized in regards to infrastructure and product aspects. 

From the point of view of functional safety it is not about the fiilfillment of the requirements that are derived from any process models. The safety-lifecycle has to be derived correctly and sufficiently. It is important for project planning and the planning of safety activities that the safety concepts are implemented in a way that sufiiciently ensures safety goals. 

The cube structure of Nancy G. Leveson is no longer discussed in this book. Only the product technical viewpoint is further considered. The organizational stmcture or the viewpoint of customers or suppliers— those are considered in the product planning, project planning and determination of organizational interfaces. However, these aspects form the basis for the planning of safety activities in the project safety plan as a derivation of the safety lifecycle (compare to ISO 26262, part 2, chapter 6.4.3, Planning and coordination of the safety activities ). 

For this example the design strategy is to initialize the lifecycle design (Figure 2) and break down the lifecycle phases into ten steps consistent with Figure 2 and Table 1 (safety lifecycle overview). At this point in the project, it may be beneficial to use the lifecycle table to assign responsibility for each lifecycle phase as shown in Table 1. 

A suitable maintenance strategy should be developed for equipment by considering the criticality and failure mode, and then applying a mixture of the forms of maintenance described above. In particular, the long-term cost of maintenance of an item of equipment should be estimated over the whole life of the project and combined with its capital cost to select both the type of equipment and form of maintenance which gives the best full lifecycle cost on a discounted basis), while of course meeting the technical, safety and environmental specifications. 

At the outset of developing the plan it should be recognised that projects change and mature during their lifecycle. As such, it can be wise to revisit and reissue the plan from time to time (although a radical update immediately before the safety case is validated against the plan may prove questionable). In particular one needs to take... 

The intent of this subclause is to ensure that, within the overall project, adequate safety planning is conducted so that all of the required activities during each phase of the lifecycle (for example, engineering design, plant operation) are addressed. The standard does not require any particular structure for these planning activities, but it does require periodic update or review of them. 

The Safety Plan specifies the safety activities (mainly the gathering and assessment of Evidence) to be conducted throughout the project lifecycle and the allocation of responsibilities for their execution. 

All documents created for a project should be reviewed by an independent person from the creator of the document. At certain stages of the lifecycle, the standard recommends that a functional safety assessment be performed by an assessment team that contains at least one senior, independent, competent person. This independent person can be an employee of the company or a contracted third-party, as long as the reviewer understands the process hazards, the company s management system, the full SIS lifecycle, and the fundamentals of appropriate design, installation, operation, maintenance, testing, and reliability. This person should not be part of the project team, report to project team management or plant operations, and should have the authority to prevent the project from proceeding if deviations are not addressed. 

Abstract. This paper aims at describing the contribution of the technological brick Safety Architect to the CRYSTAL project. The goal of the CRYSTAL project is to provide a platform of interoperability between tools supporting all the steps constituting the lifecycle of a product. 

Although the NORSOK concept covers the entire lifecycle the main impact has been on the development and construction phases, see figure 1 below. This new approach created boom activity in the new development projects and in the construction and supply industry activities far beyond their normal capacity. This was followed by a panic reaction the winter 1998/99 resulting in a full stop as a response to a short term oil price of less than 10 per barrel. The price grew fast to 20-30, but in a power-play with the authorities for improved conditions, i.e. reduced safety requirements, the industry used 10-12 as a reference price on oil. 

Generally, the SRS contains the relevant information to specify and operate the instrumented safety functions and provides the basis for design. The required information for the SRS is normally included in previous documents such as HAZID report, SIL compliance report, and so on. Most of the required contents of the SRS would not be available during early project phases because the actual data is not reflected on these documents. The SRS document is subject to follow-up and updating by vendor data through all lifecycle phases of the SIS. 

The SLCM recommended in lEC 61508 only defines the requirements on each phase. There are no clearly defined activities and approaches that are sufficiently concrete for execution. This fact leads to additional effort that a safety development project needs to specify the concrete activities and approaches to satisfy the related requirements if it directly uses the recommended lifecycles. 

To address the design constraints we have selected several safety development projects with different hardware and software complexity in order to collect inputs, and to understand the related domains, the corresponding problems, needs and development environments. They are also used to verify our SLCM. In addition, we have used the functional safety initiative of the automation product division (one of five ABB divisions) as a platform to collect the related experience and knowledge in the safety development to ensure reusability of our SLCM. To guarantee the conformance we had our SLCM assessed by TUV in the context of the certification of our FSM Add-on [6], which includes our SLCM. Fig. 2 illustrates our development strategy. As input for the development of our SLCM we also referred to different development lifecycle models such as V-model [12], RUP [11], Harmony [13] and the best practice, knowledge and experience [4,5,13,14]. 

The Hazard Log is a database containing aU om systems (independent from the lifecycle phase) and all known hazards. Known Hazard in this case means that this problem has already occurred, either during development or operation. We call these hazards Technical Hazards to distinguish between such already emerged safety relevant technical problems and theoretical hazards, derived from safety analyses. After contract award, new projects are entered immediately into this database. Eveiy hazard, once defined, stays in the hazard log, even if it is closed companywide, just as a project remains in it over its whole lifecycle. 

---