Reliability

Reliability Requirements

Reliability refers to the ability of a device, system, or process to perform its required duty without failure for a given time when operated correctly during a specified time in a specified environment. At present, it is obvious that numerical reliability requirements are rarely set at the invitation to tender stage of projects. A numerical analysis is generally performed later during the detailed design stage. Reliability requirements are often imposed on new contracts following particular instances/experiences of failure. This is an understandable response; however, this is not a sound strategy for achieving reliability because the suppliers may feel they have met the reliability requirements if they have dealt with the listed issues. If no reliability target is set, the underlying signal to the supplier is “supply at whatever reliability can be achieved at the lowest cost”.

Reliability Processes

API RP 17N lists twelve interlinked key processes that have been identified as important to a well-defined reliability engineering and risk management capability. These reliability key processes provide a supporting environment for reliability activities. When these are implemented across an organization, the reliability and technical risk management effort for each project is increased. The 12 reliability key processes are as follows:

• Definition of Availability Goals and Requirements Ensures that the project goals are fully aligned with overall business performance objectives and provides the focus for design and manufacture for availability and reliability assurance. The trade-off between the purchase cost and the operational expenditure needs to be understood when considering the need for reliability improvement. This should then be considered when setting goals and requirements.

• Organizing and Planning for Availability Allocates leadership and resources to the required reliability activities such that they add value to the project overall and do not adversely affect the project schedule. The reliability activities identified should be considered an integral part of the engineering process and integrated with conventional engineering tasks

in the project management system.

File:Key Processes for Reliability Management (8).png

Key Processes for Reliability Management (8)

• Design and Manufacture for Availability Should be considered an extension of good engineering practice but requires increased focus on understanding how and why failures occur in operation. Information gathered during reliability analysis activities should be considered during the design process to drive the design’s ability to achieve and deliver the specified availability requirements.

• Reliability Assurance This is the essential element of managing technical risk because it is the process of identifying, assessing, justifying, and, most importantly, communicating the information pertaining to risks to the technical effectiveness of the system.

• Risk and Availability Analysis Provides reliability management support by identifying potential faults and failure mechanisms and their effects on the system in advance of operation and to quantify risk and reliability. Analysis and models usually focus on function, hardware, or process.

• Verification and Validation Confirms that any given activity is the correct one and that it has been carried out correctly.

• Project Risk Management Addresses nontechnical risks throughout the project life cycle to enable all risks to be identified, quantified, managed, and preferably eliminated.

• Reliability Qualification and Testing This is the process by which systems are examined and evidence is provided to demonstrate that the technology employed meets the specified requirements for the intended use. The qualification process in some projects may start as early as the feasibility stage if it is known that a specific piece of unqualified hardware will be required to exploit a field.

• Performance Tracking and Data Management collects and organizes reliability performance data from all projects at all project stages to support the assessment of reliability, availability, and production efficiency. Historical reliability and availability data can be used to determine the availability goals and requirements for projects with field-proven equipment, and also understand any failures that have been experienced to provide inputs to reliability analysis and improved design.

• Supply Chain Management Ensures that reliability and technical risk management goals, requirements, achievement, and lessons learned are communicated among all organizations involved in the project. The ability to manage the various interfaces between the customers and suppliers down the supply chain is expected.

• Management of Change Ensures that any changes are consistent with the project reliability and technical risk management goals and that their impacts are fully assessed and managed.

• Organizational Learning Provides resources to ensure that information is fed back to the whole organization involved in design and system integration, and the whole organization understand the lessons to be learned from failure. The lessons learned usually cover the whole life of the project from strategic thinking and decision making through project execution and the delivery of benefits and should include both

Proactive Reliability Techniques

In a proactive environment, the orientation toward reliability is changed. Reliability engineers become involved in product design at an early point to identify reliability issues and concerns and begin assessing reliability implications as the design concept emerges. Because of the continuous requirement for improved reliability and availability, an integrated systems engineering approach, with reliability as a focal point, is now the state of the art in product and systems design. Frequently, it is desirable to understand, and be able to predict, overall system failure characteristics. Reliability and availability are typically increased:

• Through improved hardware and software fault tolerance design;
• By implementing more efficient screening tests during manufacturing, which reduces the quantity of induced failures;
• By reducing the number of incidents where an apparent failure cannot be verified;
• By increasing the time between preventive maintenance actions.

Reliability Modeling

To predict system reliability, the reliabilities of the subsystems should be assessed and combined to generate a mathematical description of a system and its operating environment by reliability modeling. Once the system reliability has been calculated, other measures can be evaluated as inputs for decision making. In this circumstance, a mathematical description of a system constitutes a model of the system failure definitions; that is, the model expresses the various ways a system can actually fail.

The complexity of a reliability model relies on the complexity of the system and its use but also to a large extent on the questions at hand, which the analysis attempts to answer. The addition of failure consequences and their costs, maintainability, downtime, and other considerations to the complexity of a model not only influences future economic realities of the system design and use, but also becomes the metrics of interest for decision makers. A reliability model attempts to represent a system and its usage in such a way that it mirrors reality as closely as possible.

To produce useful results in a timely fashion, models often have to balance the effort of reflecting a close-to-reality and using practical simplifications. This implies that oftentimes models contain approximations based on engineering judgments and reasoned arguments to reduce the complexity of the model. This can easily lead to a false” impression of accuracy and a potentially incorrect interpretation of the results by using sophisticated mathematical models in situations in which the quality of the input data is not equally high. The main objective of reliability modeling is to identify weak points of a system as areas for improvement, although it is a quantitative tool. So there is a need to focus on the comparison of results for various system design solutions rather than on the often prompted question about the absolute results. In this respect a reliability model can be an extremely valuable tool for making design decisions.

The process of reliability modeling always begins with the question about the objective of the analysis. Only if the objective and the expected outcome are clearly defined can an appropriate modeling technique be chosen. The most common analysis techniques include, but are not limited to, reliability block diagrams, fault tree analysis, and Markov analysis, which is also known as state-time analysis. Oftentimes a combination of those tools is required to address the objective of an analysis adequately.

Reliability Block Diagrams (RBDs)

The general purpose of RBDs is to derive reliability predictions during the design phase of hardware developments and to provide a graphical representation of a system’s reliability logic.

Concept

Rather than making absolute predictions of system reliability, RBDs establish a basis for design trade-off analyses. Like the other reliability engineering tools, RBDs allow product evaluations and identification of problem areas before a design is finalized. An RBD represents a clear picture of system functions and interfaces and shows the failure logic of a given system. It models the interdependencies of logical system components and allows the overall system reliability to be computed. The results can be used to verify compliance of subsystems within system-level requirements.

Especially in cases of complex systems with redundancies, RBDs are helpful tools. Using reliability engineering software allows the user to take into account various types of redundancies, such as active, standby, and others. Even the failure probability of imperfect switches can be included in a model. Once a model is established, sensitivity analyses can be performed by changing the configuration, adding redundancies, and modifying maintenance strategies–to name just a few of the options. The results help to prepare design decisions between various competing configurations. Reliability block diagrams can also be used to visualize the system structure and to aid in training and troubleshooting.

Timing of Application

A top-level RBD can be constructed as soon as a system layout has been defined. An RBD may be required whenever a design FMECA is performed. The best timing for use of a reliability block diagram is as early as possible in the design process.

Requirements

RBD users should understand the various types of redundancies as well as the system architecture and functionality. In addition, thorough knowledge of how the system operates and reliability parameters (e.g., hazard rate) for each block in the diagram are needed.

Strengths and Weaknesses

API RP 17N illustrates the strengths and weaknesses of RBDs: Strengths

• The best method of graphically representing complex system logic;
• Good visualization of redundant system logic;
• Good precursor to all other analysis methods.

Weaknesses

• Construction of RBDs can be difficult for complex systems;
• Numerical assessment of the RBD can be very time consuming (if performed manually or if multiple nested RBDs are apparent);
• Becomes very data intensive when there are more detailed levels;
• May require multiple RBDs for multiple functional modes.

References

[1] American Petroleum Institute, Recommended Practice for Subsea Production System Reliability and Technical Risk Management, API RP 17N, 2009, March.

[2] R. Cook, Risk Management, England, 2004.

[3] H. Brandt, Reliability Management of Deepwater Subsea Field Developments, OTC 15343, Offshore Technology Conference, Houston, 2003.

[4] Det Norsk Veritas, Risk Management in Marine and Subsea Operations, DNV-RPH101, 2003.

[5] J. Wang, Offshore Safety Case Approach and Formal Safety Assessment of Ships, Journal of Safety Research No. 33 (2002) 81–115.

[6] J. Aller, M. Conley, D. Dunlavy, Risk-Based Inspection, API Committee on Refinery Equipment BRD on Risk Based Inspection, 1996, October.

[7] International Association of Oil & Gas Producers, Managing Major Incident Risks Workshop Report, 2008, April.

[8] C. Duell, R. Fleming, J. Strutt, Implementing Deepwater Subsea Reliability Strategy, OTC 12998, Offshore Technology Conference, Houston, 2001.

[9] M. Carter, K. Powell, Increasing Reliability in Subsea Systems, E&P Magazine, Hart Energy Publishing, LP, Houston, 2006, February 1.

[10] H.B. Skeels, M. Taylor, F. Wabnitz, Subsea Field Architecture Selection Based on Reliability Considerations, Deep Offshore Technology (DOT), 2003.

[11] F. Wabnitz, Use of Reliability Engineering Tools to Enhance Subsea System Reliability, OTC 12944, Offshore Technology Conference, Houston, 2001.

[12] K. Parkes, Human and Organizational Factors in the Achievement of High Reliability, Engineers Australia/SPE, 2009.

[13] M. Morris, Incorporating Reliability Centered Maintenance Principles in Front End Engineering and Design of Deep Water Capital Projects, http://www.reliabilityweb. com/art07/rcm_design.htm, 2007.

[14] Det Norsk Veritas, Qualification Procedures for New Technology, DNV-RP-A203, 2001.

[15] M. Tore, A Qualification Approach to Reduce Subsea Equipment Failures, in: Proc. 13th Int. Offshore and Polar Engineering Conference, 2003.