Safety integrity level verification

There are a number of requirements specified for nonlisted PLCs. According to A8.3 (P37) of NFPA 87 (2015) Controls that meet the perfomumce-based requirements of standards such as ANSI/ISA 84-00.01 Application of Safety Instrumented Systems for the Process Industries, can be considered equivalent. The determination of equivalency involves complete conformance to the safety lifecycle including risk analysis, safety integrity level selection, and safety integrity level verification, which should be submitted to the authority having jurisdiction. 

Often, time to failure data is not available for a collection of components. Incomplete data can be used to estimate failure rates imder these circumstances but one must be very careful, especially when estimating failure rate data to be used for probabilistic SIF verification. Results that are not conservative can lead designers to believe that safety integrity levels are higher than they really are. 

Bamert T., Kosmowski K.T., Sliwinski M. 2008a. Security aspects in verification of the safety integrity level of distributed control and protection systems. Journal of KONBIN, Air Force Institute of Technology, KONBIN 2008, Wroclaw. Warsaw. 150-176. 

NOTE 1 Selection of techniques and measures for the verification process and the degree cf independence depends upon a number of factors including degree of complexity, novelty of design, novelty of technology and safety integrity level required. 

ISA-TR84.00.02—Safety Integrity Level (SIL) Verification of Safety Instrumented Functions—... 

The Escher project was conceived with the goal of developing a toolset to support Verified DEC with close to 100% automated verification. The system is intended for use in applications at all safety integrity levels. We now present an outline of the toolset. 

A SLCM consists of a set of phases. As we built upon the structure of the SLCM recommended by lEC 61508 our SLCM has the same number of phases as the one from lEC 61508. Similar to lEC 61508 a phase of our SLCM has objectives, description, inputs, outputs and the related safety integrity measures for failure avoidance recommended by lEC 61508, which shall be selected or equivalently substituted according to the safety integrity level to be achieved. In addition, we added detailed activities, documentation, verification, verifier, executor and knowledge Experience as extension to the related phases. Those additional SLC components are not included in the SLCM from lEC 61508, however they are necessary because a safety development team can save a lot of effort through such kind of support. In addition a phase is associated with the related design elements (as shown in Fig. 3), which help to manage the product complexity and to specify the outputs of that phase. 

However, as we wiU see, if the safety instrumented function verification takes credit for the diagnostics to achieve a sufficiently high level of safety integrity, then the diagnostic failures wUl need to be modeled in an accurate probabilistic SIF verification. 

SIS and SIL for BMS A master fuel trip required by design codes demands multiple actions. The verification results shall confirm that the required risk reduction is achieved. However, the validation can be compromised when an SIF is not defined properly and its functional requirements are poorly specified or when all actions for total shutdown are included in the same functional requirements of the same SIF [8]. From discussions in previous chapters it is clear that the safety life cycle model not only helps with necessary ways and means to avoid systematic failures, but also helps to ensure the required integrity level to prevent random failures. The safety standards (lEC 61508/61511) required to identify a set of parameters and factors for PFDavg calculations are ... 

There are, however, many definitions of V V. In one of the most commonly used safety standards, lEC 61508, the objective of safety verification is ""...to demonstrate, for each phase of the overall, E/E/PE and software safety lifecycles (by review, analysis and/or tests), that the outputs meet in all respects the objectives and requirements specified for the phase [7]. The objective of safety validation is to. . validate that the E/E/PE safety-related systems meet the specification for the overall safety requirements in terms of the overall safety functions requirements and overall safety integrity requirements... [7]. These definitions differ in level of detail, but they can be summarized as verification is to answer the question are we building the system right While validation is to answer the question are we building the right system ... 

The FHA then needs to identify the qualitative and/or quantitative methods that will be used to verify compliance with the failure condition requirements and (if necessary) allocate responsibility to each outstanding verification (see Fig. 1.3) action. The level of detail needed for the various safety assessment activities is dependent on the aircraft-level condition classification, the degree of integration, and the complexity of the system implementation. Some authorities provide useful guidance in this regard see the decision tree in Fig. 3.3. 

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. 

In this paper, a method of software safety verification at the system level based on STPA is proposed. We investigated the application of the STPA structure to software, and we found that STPA can be directly used for software. We mapped the results of the STPA safety analysis to a formal specification to be able to verify safety requirements at the software code level. The limitation of the method is that the formal specification is done manually which may lead to much effort to construct and check the potential combinations of relevant states. Therefore, we are exploring the automation of this step and integrate it with our A-STPA tool as future work. Furthermore, we plan in-depth case studies to improve the method by applying it to real safety-critical software in industry. We plan also to investigate the effectiveness of using the proposed method during an ISO 26262 life cycle in the automotive industry. 

If safety mechanisms against all possible systematic failures would be implemented at the system level, all random failures in the E/E hardware are also covered. By adequate verifications and integration according ISO 26262 any further design error in the components could be identified. 

The different levels of the integration are used for the verification of the interfaces of the relevant elements. The typical verification criteria for the interfaces build the foundation for the apphed methodology. The objective of such tests are whether the interfaces have been developed completely, consistently, correct and if sufficientiy transparence is given for the safety case. 

These activities all fall within the lifecycle phase known as Realisation in lEC 61508 (lEC 2000), and include such 61508 concepts as manufacture and integration . They are all specified by the design and verification documents created during Steps 4 and 5, in order to meet the specifications created by Step 3, so that the EPS achieves the desired levels of safety risk, or risk-reduction, over its life-cycle. 

---