Systematic failure specification

The overall quality refers to the precautions taken to guard against systematic failures. Specification errors, equipment errors, and software errors can easily occur during normal maintenance activities. Improving the overall quality involves careful thought and planning at every step of the lifecycle process. The use of an approved quality management system is recommended. 

Current functional safety standards, lEC 61508 and ANSl/lSA-84.00.01-2004 (lEC 61511 Mod), (Ref. 1 and 2) state that probabilistic evaluation using failure rate data be done only for random failures. To reduce the chance of systematic failures, the standards include a series of "design rules" in the form of specific requirements. These requirements state that the safety instrumented system designer must check a wide range of things in order to detect and ehcninate systematic failures. 

This is not to say that systematic errors cannot happen. It is clearly recognized that these failures do occur and that they do impact safety integrity. One field failure study done by one of the authors traced instrument failure reports to specific end user sites. The results showed that failure rates for the same instrument varied by over an order of magnitude from site to site. There is no doubt that this is significant. But the site specific and even person specific variables preclude an "average" probabilistic approach. That is why it is so important to understand and follow all the procedures, techniques and measures presented in the functional safety standards to avoid and control systematic failures. It is so important to have a "well designed system" for any safety instrumented function. 

Generally, less specific data turns out to be more conservative and that is appropriate for safety verification purposes following the rule that "the less one knows, the more conservative one must be." Remember that industry databases may include systematic failures, multiple technology classes, wear out failures and possible multiple reports per failure. These issues naturally cause the numbers from such sources to be high. 

The main objective of the functional safety framework is to attempt to eliminate or reduce systematic failures and random failures to as low as reasonably practical. The very fact that lEC 61508/62061 attempts to eliminate or reduce systematic failures means that not only the technical design of a brake system is involved but also all other aspects of the brake system—from concept/technical specification to design/programming and manufacturing to installation and commissioning and finally to operation, maintenance and decommissioning. 

In 2003 the UK Health and Safety Executive estimated that almost half of the primary causes for control system failures lay with inadequate specifications (Ref 2). Other key causes were changes made after commissioning, overly optimistic reliance on single channel systems, failure to verify software and poor consideration of human issues. These are systematic failures. 

Activity performed by a competent senior engineer to determine if the safety system meets the specification and actually achieves functional safety (freedom from unacceptable risk). This assessment is an important part of reducing systematic failures. It must be performed at least after commissioning and validation but before the hazard is present. 

NOTE 4 Examples of systematic failure causes including human error in the safety requirements specification ... 

The potential for systematic failure in the process specification, programming, and checkout of the SIS is not considered in the safety system PFDavg calculation. That failure rate may have a significant contribution to the potential for loss of the ability to bring the process to a safe state. When there is a failure, whether you have redundancy or not, you need to provide a way to bring the process to a safe state. Clause 11.3 presents requirements for system behavior when a fault is detected. The manual shutdown does not have to be an emergency stop button, which activates the final elements of the SIS, Independent of the logic solver, but some alternate shutdown method should be provided. 

ANSI/ISA-84.01-1996 requires that the application software be developed in accordance with the Safety Requirements Specification (SRS). ANSI/ISA-84.00.01-2004-1 also requires this, but discusses the development of the application software with relation to the safety lifecycle. Where hardware is prone to random failures, the software is more prone to systematic failures. The safety lifecycle is important, because it is the primary mechanism for reducing systematic failure. The inclusion of the lifecycle discussion in the software section does result in repetition of the design process described in ANSI/ISA-84.00.01-2004-1 Clause 11. This repetition is intended to highlight the importance of the lifecycle in the development, verification and validation of application software. ISA-TR84.00.04-1 Annex O provides a discussion of the evolution of application software development. 

The causes of systematic failures can include modification errors maintenance error software error systematic failme of hardware and specifications error. 

Refer to lEC 61508-1, table 2 (for low demand mode operation) or table 3 (for continuous or high demand mode operation) to determine the safety integrity level (SIL). The SIL then guides the selection of the techniques used for the avoidance of systematic faults in both hardware and software, so that as the risk reduction increases, or the hazard rate decreases, there is a reduction in the likelihood that systematic failures (including those resulting from incorrect specification) will result in a hazard. 

Systematic failure normally occurs on account of design failure, including incorrect specifications, using a component not fit for the operation, and or due to error in software. Safety life cycle is adapted for systematic faults. So safety standards meant for E/E/PEs take care of both. SISs (Ref. Chapter VII) are developed to prevent or mitigate hazardous events to protect people or the environment, or prevent damage to process equipment. In this connection another important issue is SIL (Chapter VIII), which is a discrete level for specifying the safety integrity requirements of safety functions, but is not a measure of risk. SIL provides means for risk reduction to a tolerable level. The fundamental question, in case of functionally safe instrumentation, is how frequently failures of function will lead to accidents. The answers can be ... 

Independent failures of devices are analyzed to identify roots, and it is possible to reduce reoccurrence of failure. Random failures are physical failure while mostly systematic failures (design failure) occur due to human error, mainly hence a local issue. CCFs are application and/or installation specific. In lEC 61511, adapts different strategies to handle various failure types to make SIF devices are useful in the life cycle as long as these are installed and managed as per design basis and operating procedure. Now, the focus shall be on failure characteristics to conceive how these affect SIF performances. 

Systematic faults occur due a combination of conditions resulting in a reproducible failure of the system, and are most often attributable to software issues in programmable safety systems. This failure may be a result of some error in design, operation or production process, installation and/or maintenance. Improper implementation of MOC at any stage could be responsible for systematic failure also. Device manufacturing errors can be addressed by diversity this increases the SIF complexity. Diversity can be applied to sensor, I/O technologies, control and software platforms, and even product development teams. Incorrect specification, implementation. 

This guidance is not intended to replace BS EN 61511 but to supplement it specifically in relation to tank overfill protection SIS. It does not cover all the requirements of BS EN 61511. Where guidance is not given on any requirement, such as protection against systematic failures, then reference should be made to the standard. 

Systematic failures which are not attributable to specific component failures and are therefore unique to a given system and its environment. They include design tolerance/ timing-related problems, failures due to inadequately assessed modifications and, of course, software. Failure rates cannot be ascribed to these incidents since they do not enable us to predict the performance of future designs. 

Quality aspects must be considered at every stage in the specification, design, construction, testing, commissioning, operation, maintenance and modification of the PES, in relation to both hardware and software. The level of quality is determined by the procedural and engineered measures for the avoidance of errors in design and other defects which could cause systematic failure. 

The identification of CCFs among reported failures would overlook many possible causes of CCFs if focusing on complete CCFs alone. Systematic failures, i.e., failures that are due to errors made in specification, design, installation, or operation and maintenance, and which are not due to natural degradation of the component state, may be replicated for several components. When a systematic failure is found, it is important to also ask if other components may have been affected. Therefore, in the failure reviews, it has, for each systematic failure, been questioned whether the failure could have resulted in multiple failures within a relatively short time window. If yes, the failure has been defined as a potential CCF. 

The possible error propagation in the horizontal level can also only be limited conditionally, since each systematic failure at the specification can for example be a potential source of error. In order to achieve something like more error-safeguarding appropriate barriers are needed in the horizontal levels, which can prevent further error propagation. lEC 61508 proposed in its first edition not to mix safety-related and non-safety-related software or software of different integrity levels in one microcontroller. 

An important distinction is made in [Bell 91] between the terms Reliability and Safety Inte ity within the context of the HSE guidelines [HSE 87]. Reliability addresses failures of a system due to hardware failures, that is, hardware failures resulting from various breakdown mechanisms that occur at random. Safety Integrity addresses both reliability and systematic failures that are due to errors that have been made at some stage in the specification, designs, construction, operation or maintenance of a system. Systematic failures are particularly important in the context of complex systems and are therefore particularly relevant to PES. 

Systemic failures are due to human errors (e.g. mistakes, misconceptions, miscommunications, omissions) in the specification, design, build, operation and/or maintenance of the system. Errors in this case are taken to include both mistakes and omissions. Errors can be introduced during any part of the lifecycle and errors are caused by failures in design, manufacture, installation or maintenance. Systematic failures occur whenever a set of particular conditions is met and are therefore repeatable (i.e. items subjected to the same set of conditions will fail consistently) and thus apply to both hardware and software. It is difficult to quantify the rate at which systemic failures will occur and a qualitative figure based on the robustness of the development/build process is normally used. The probability of systemic failures is often evaluated by means of safety integrity (or development assurance) levels. 

Systematic failures A failure caused by errors in the specification, design, constmction operation or maintenance which cause the item to fail under some particular combination of inputs or conditions. All software failures are systematic failures. 

Systematic errors can occur anywhere in the design and implementation process or during the operational life of an SIS device. These errors put the SIS on the path to failure in spite of the design elements incorporated to achieve robust hardware and software systems. Systematic errors are minimized using work processes that address potential human errors in the SIS design and management (e.g., programming errors or hardware specification errors). 

Now all the minimum pieces are theoretically in place to confirm or refute a hypothesis. For many simple and straightforward failures, general knowledge of the component failure mode behavior, used in conjunction with the specific information gathered for a particular incident, may be sufficient to diagnose the causes. However, most process safety incidents are complex in nature and have multiple underlying system causes. Therefore, a systematic deductive approach is usually appropriate. 

---