Safety requirement specification implementations

For each diagnostic implemented, testing interval and resulting action on fault detection should meet the safety requirements specification. 

Prior to development of the application software, the user provides a process risk and hazard assessment which is used to identify the software safety requirements in terms of the safety instrumented functions and their SIL. Once the decision to implement the safety instrumented functions in software is made, any conflicts, discrepancies and omissions in the safety requirements specification which come to the attention of the software designers should be addressed. One example might be the effect of the order of execution of the safety instrumented functions within the software. Another example would be the response of the application software as it relates to energy outages. 

The Safety Requirements Specification, SRS, is a specification of all Safety Related Control Functions, SRCFs, implemented by the Safety-Related Control System, SRECS. The SRECS could be the SIL3 Hoist Monitor system or the SIL3 Hoist Protector system. 

Figure 9 shows the high-level issues for consideration when making initial decisions relating to the logical safety requirements specification and implementation. 

Application software safety requirements specification To specify the requirements for the software safety instrumented functions for each SIS function necessary to implement the required safety instrumented functions 12.2.2 SIS safety requirements specification Safety manuals of the selected SIS SIS application software safety requirements specification Verification information... 

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. 

Safety requirements specification Functional requirements specification Safety integrity requirements specification Design and implementation Installation and commissioning Operations and maintenance Actions by operation personnel Actions by maintenance personnel Changes after commissioning Modification and retrofit De-commissioning... 

Consider performing an analysis to demonstrate that each of the requirements established in the safety requirements specification is implemented in the design. 

ANSI/ISA-84.00.01-2004 contains several references to the need to provide a manual shutdown backup for the logic solver. The main reference is clause 11.2.8, which states, Manual means (for example, emergency stop push button), independent of the logic solver, shall be provided to actuate the SIS final elements unless otherwise directed by the safety requirement specifications. This clause outlines a specific way a manual shutdown may be implemented, but allows the user to specify other ways to provide a manual shutdown. Manual shutdown can be initiated by the operator using the BPCS, remote or local pushbuttons and switches, or directly with process equipment, e.g., manual closure of valves. Manual shutdown capability should be provided for any SIS where maintenance bypasses are used to support online equipment repair, maintenance, and proof test. 

For example, the equipment tags of the Safety Instrumented Systems (SIS) should be specified in the Safety Requirement Specification (SRS), a live document made specifically for every installation (GL-070 2004 IEC 61508 2010). The PS should contain links to such relevant documentation. In addition to specific requirements for safety critical and barrier functions, the PS should have a clear description of equipment groups that are considered as part of the SCS/SBS. A properly created PS will allow the correct identification of critical equipment tags and the implementation of data into the CMMS. 

The first step in the acceptance process is the identification of the environment within which the pre-developed software will have to work. This environment is determined by the system-level safety function as described in the system requirements specification. Also the interface and performance requirements, as well as the safety category should be contained in the system requirements specification. This means, that during the establishment of the plant safety design base a risk and hazards analysis has been performed which rendered the categories of safety functions to be implemented by pre-developed software. This risk and hazard analysis - in spite of being out of the scope of I C engineering - has been taken as the first of four acceptance criteria that should be applied to pre-developed software independently of its safety category. 

Specific safety requirements are placed on viscoelastic substances employed in-traocularly. They must be sterile, pure and free of particles, as well as non-immu-nogenic, non-toxic and non-inflammatory. They must be biologically inert and show a balanced electrolyte content. Osmolality and colloid osmotic pressure as well as pH (see below) must correspond to corneal and aqueous humor values (pH = 7.38). They should be water-soluble and clear for implementation in the anterior chamber. Viscoelastic substances should be easily applied and removed, but, nonetheless, biologically transportable or biodegradable in the event of residues. They should be long-lasting and preferably storable at room temperature. 

DOE Order 5480.21, Unreviewed Safety Questions (DOE 1991), This order specifies the applicable conditions and basis for determining the existence of an Unreviewed Safety Question (USQ) for proposed changes or modifications to the facility design or operation. More specifically, implementation of this order requires consideration of whether a proposed activity involves a conflict with the facility Technical Safety Requirements. 

TA-V Standard Operating Procedure (TA-V SOP) Operations procedure which implement the Technical Safety Requirements (TSR), to address specific topics (e.g. isotope processing, maintenance, normal operations), or required by the SNL ES H manual to address special hazard categories. TA-V SOPs are reviewed by the appropriate HCF safety committee and are approved by line management prior to implementation. 

Proper implementation of process safety requirements is key to safety assurance at covered process sites. In this chapter we attempted to identify actions prior to and during the implementation of the PSM and RMP process safety programs. Specific actions for each of the 14 PSM elements were highlighted as well as a section on RMP implementation. Finally, a section on lessons learned and information regarding implementation evasion was presented. 

The specified requirements in the safety related specification should be shall requirements and marked with a requirement number for easier implementation and to trace these requirements in the validation test specification. The SRS-document shall not include any proposed design... 

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. 

Referring to the safety requirements hierarchy shown in Figure 3, the Operational Level deals with abstract functions with no consideration of implementation details and it follows that there are no specific human factors to consider at that level. CTA and HEA analyses are therefore directed specifically to address the human factors at the system Logical and Physical levels. At the Logical System Level (for each allocated Human SR) safety-related human Victors issues may be addressed by undertaking ... 

The relative difficulties associated with the specification, implementation, validation and verification of human safety requirements, compared with safety requirements for hardware and software, should not be underestimated and this paper has not addressed many of these difficulties in detail. However, this paper has outlined a high-level approach for a focused and integrated application of Human Factors analyses for the specification and realisation of human subsystem safety requirements. 

Such a scenario presumes that a Procurement policy and safety requirements have been established and distributed and that training on their implementation will be given. Procedurally, that is good and recommended practice. These comments are informative, but not very helpfiil with respect to specifics on how the procedures are to be implemented. 

The objective of this ciause is to provide requirements for the specification of the appiication software safety requirements for each programmable SIS subsystem necessary to implement the required safety instrumented function(s) consistent with the architecture of the SIS. 

---