Safety requirement specification validation activities

The objective of the SiS safety vaiidation is to vaiidate that the SIS achieves the requirements stated in the safety requirements specification. Validation activities should be completed prior to the placing of the SIS into operation. 

Validation—The activity of demonstrating that the safety-instrumented system under consideration, after installation, meets in all respects the safety requirements specification for that safety-instrumented system. 

The validation activities including validation of the safety instrumented system(s) with respect to the safety requirements specification including implementation and resolution of resulting recommendations. 

Each phase of the SLC must be controlled to maximize the probability that a finished system meets all quality, regulatory, safety, and specification requirements. If an SLC approach is applied properly, no additional work will be required to validate a system. For each SLC period and event, computer systems validation requires that the development processes are documented work products. As explained in Chapter 2, phase gate verification activities performed during each event may be a perfect place to review and quantify the quality of all products needed to support the next phase. 

Some safety-related systems (e.g nuclear reactors) are categorised as such simply because they pose an unacceptable safety risk to their environment and they require additional protection systems to contain that risk within an acceptable level. In contrast, systems such as Air Traffic Control or Railway Network Control are designed specifically to provide risk reduction and can be likened to one big protection system. This paper presents a generic approach for the specification and realisation of safety requirements for the technical and human elements of both types of safety-related systems. The term realisation is used here to cover all activities associated with requirements implementation, validation and verification. 

The software validation shall show that all of the specified software safety requirements (see 12.2) are correctly performed, and the software does not jeopardize the safety requirements under SIS fault conditions and in degraded modes of operation or by executing software functionality not defined in the specification. The information of the validation activities shall be available. 

The overall life cycle discussions in the standard mainly covered in this main Clause 7, having 17 major sub-clauses. Now coming back to main life cycle phases in Fig. VI/4.0.2-1, it is seen that the first part of the safety life cycle is basically the analysis part comprising concept, scope for the system/EUC, hazard/risk analysis, creation of overall safety requirements, and identification of specific safety functions to prevent the identified hazards safety requirements allocation. The middle part is realization activities (Clause 7.10) as detailed in Figs. Vl/4.1.4-1 and Vl/4.1.4-2, are dealt with in Parts 2 and 3 discussions. The next part of the life cycle is related to installation and commissioning (Clause 7.13). Then comes the validation (Clause 7.14), operation and maintenance (Clause 7.15), modification, retrofit (Clause 7.16), and finally, decommissioning (Clause 7.17). 

Safety features of the GFR may include passive and active safety systems that will require new analysis tools for design and safety evaluations. These analysis tools will in turn require verification and validation with a combination of separate effects and integral experimental programs that will be developed specifically to address phenomena unique to the GFR. 

The terms verification, validation, and functional safety assessment are used in ANSI/ISA-84.00.01-2004-1. Each term implies that specific activities are taking place or that specific requirements are being met. Annex D provides an overview of these three terms. 

---