A Design for Reliability Methodology for Tidal Turbine
A Design for Reliability Methodology for Tidal Turbine Devices – Roy Browett Date: 28 th January 2016 © Ricardo plc 2016 1
Design for Reliability Methodology Overview l Introduction • This presentation is a summary of the work carried out to develop a Design for Reliability (Df. R) process, focused specifically on Tidal Turbine devices. The body of work discussed comprises Phase 1 of the Ti. PTORS collaboration agreement between Offshore Renewable Energy Catapult and Ricardo UK. The Df. R process has a number of key objectives; • It can be applied to a wide range of Horizontal Axis Tidal Turbine devices. • It can be easily integrated alongside any Design Process. • Elements of the process can be used effectively as stand-alone tools. • Most of the processes already exist within other industries and are therefore supported by extensive literature and data on their applications elsewhere. © Ricardo plc 2016 2
Design for Reliability Methodology Overview l Introduction Horizontal Axis Tidal Turbine - Generic © Ricardo plc 2016 3
Design for Reliability Methodology Overview l Introduction Stress and strength interference theory diagram. Risks associated with traditional FOS assumptions Time dependant load-strength variation © Ricardo plc 2016 4
Design for Reliability Methodology Overview l Introduction • Looking forward towards Marine Energy Converter Certification schemes, the basis for certification will inevitably document reliability targets, along with functional safety and environmental targets. It will also describe the operating conditions and design survival conditions for the device. • The relative immaturity of the Tidal Turbine Sector brings challenges, principally regarding their performance against more traditional and established energy producers. • Any environmental benefits of such systems will easily be negated if they are unable to deliver energy with acceptable levels of Reliability, Availability & Maintainability. • The case for adopting Design for Reliability processes is very strong in an industry that needs to demonstrate performance and commercial equality with other systems in a very short time period. Table 1 below highlights some of the challenges: © Ricardo plc 2016 5
Design for Reliability Methodology Overview l Introduction Table 1 – A Comparison of Tidal v Established Industries © Ricardo plc 2016 6
Design for Reliability Methodology Overview l Introduction What is Reliability? RELIABILITY has two related definitions. One is the state of being dependable. The other is consistency – that is, the degree to which something yields the same or compatible result, time after time. Not to be confused with Quality ! Defined as the standard of something as measured against other things. It is a measure of excellence or state of being free from defects or deficiencies with reference to a specification or design. If a design (even perfectly manufactured – i. e. perfect quality) does not deliver reliability then aspects of the design must change to achieve this. © Ricardo plc 2016 7
Design for Reliability Methodology Overview l Introduction Quality and Reliability share some common tools but one does not imply the other © Ricardo plc 2016 8
Design for Reliability Methodology Overview l Introduction • The structure adopted for the Df. R methodology is divided into six groups which reflects the stages of a product development cycle and its associated reliability, from setting reliability targets through to reliability demonstration. These groups are defined as: • Define • Identify • Analyse & Assess • Quantify & Improve • Validate • Monitor & Control Define Monitor & Control Identify Validate Analyse & Assess Quantify & Improve • The above headings are used in this report to discuss the individual processes within each of them. © Ricardo plc 2016 9
Design for Reliability Methodology Overview l DEFINE l Quality Function Deployment • This really is the start of the Design for Reliability process. Until you know what is required of a Tidal Turbine you cannot set about designing it. • Quality Function Deployment is a process used by many organisations to capture the requirements of their customers and translate these into a set of technical requirements for the product being proposed. • In theory, the successful implementation of all the technical requirements will meet the cost, reliability, quality, serviceability, performance, legislative, environmental requirements etc. of the customer. • Find out what the customer really wants. (Sometimes the customer may not be clear on requirements!) • Engage with the customer and “brainstorm” all the requirements the product must meet: Technical, Commercial, Legislative, Environmental, Other………. © Ricardo plc 2016 10
Design for Reliability Methodology Overview l DEFINE l Quality Function Deployment • The output from the process will be a set of Engineering Specifications which have been derived from the Customer Requirements. Within the process, some trade-offs may be required where requirements conflict. These trade-offs are also processed within the Correlation Matrix embedded within the QFD matrix. • Don’t rely on the customer knowing every requirement. If Tidal Turbines is your field of expertise, you may know some of the requirements better than the customer. • Consider using a technical questionnaire for the gathering of information (the questions can be structured to ensure the correct information is provided) • Use “competitive benchmarking” information as another source of requirements. If your customer doesn’t have a clear idea of a requirement then their competitor might! © Ricardo plc 2016 11
Design for Reliability Methodology Overview l DEFINE l Reliability Block Diagram (RBD) l Before Reliability Analysis can be performed on a Tidal Turbine System, the operational relationships of the sub-systems and components must be known “bottom up”. This is usually defined (in its first iteration) at the Concept Design stage. l It is a graphical representation of how the components or sub-systems within a system are connected to provide a desired outcome, often referred to as “system or mission success”. l The outline process steps to create an RBD are : • • • Define the boundary of the system to be analysed. Break the system into functional components. Determine series – parallel combinations or groups. Represent each component or sub-system as a separate block. Connect each block by lines in a logical order for correct function of the system. © Ricardo plc 2016 12
Design for Reliability Methodology Overview l DEFINE l Reliability Block Diagram (RBD) Parallel group Series group RBD’s, if correctly constructed, can be used quantitatively to derive the following Reliability and Maintainability parameters, when the Reliability (Ri) and/or MTBF and/or MTTR (as appropriate) of the items comprising the system are known : • System Reliability (Rs) • Mean Time To Failure (MTTF) – Non- repairable system Potential “Redundancy” • Mean Time Between Failure (MTBF) – Repairable system • Mean Time To Repair (MTTR) – Maintainability NOTE: A component might have more than one failure mode in which case the effect on the system of a failure will depend on which failure mode occurs. © Ricardo plc 2016 13
Design for Reliability Methodology Overview l DEFINE l Reliability Block Diagram (RBD) Parallel group Series group Characteristics of Serial Systems There is no redundancy in the system. All components within the group are required to function for the system to function. If any one component fails, the system fails. The system comprises n independent serially connected components Redundancy is the duplication of critical components or functions of a system with the intention of increasing reliability of the system, usually in the form of a backup or fail-safe. Independent – the failure or non-failure of one component, does not change the reliability of other components Serial Systems Reliability Serial system reliability can be calculated from component reliabilities, if the components fail independently of each other. Potential “Redundancy” A serial system always has a smaller system reliability than its components © Ricardo plc 2016 14
Design for Reliability Methodology Overview l DEFINE l Reliability Block Diagram (RBD) Parallel group Series group Characteristics of Parallel Systems The system comprises n independent components connected in parallel. There is redundancy in the system. Only one out of n components within the group are required to function for the system to function. The system fails when all items fail. Parallel Systems Reliability With a parallel system, it is simpler to consider the system on the probability of system failure (Pf); Rs is then obtained as 1 - Pf. A parallel system is normally defined as comprising n components with m out of n components required for continued function. Consider the condition for m = 1. The system is only failed when all items fail. The probability of an individual item failing is (1 – Ri), so that Pf, the probability that all fail is; Potential “Redundancy” A parallel system always has a larger system reliability than its components. © Ricardo plc 2016 15
Design for Reliability Methodology Overview l DEFINE l Reliability Allocation l One of the essential criterion of a Design for Reliability (Df. R) program is defining the reliability goals that the device needs to achieve. Reliability Allocation is a process for apportioning a system target reliability amongst sub-systems and components. It is an essential tool at the design stage for determining the required reliability of equipment to achieve a reliability target for a given system, in this case a Tidal Turbine. l This involves a balancing act in order to determine how to allocate reliability among the subsystems and components. l During Phase 1 of the Ti. PTOR’s Programme, three processes were investigated for use within the Design for Reliability process and Simulation Model for Tidal Turbines: l Equal Apportionment (Doesn’t reflect real life conditions) l ARINC (This does provide weightings and could be used at the concept stage) l Feasibility of Objectives Technique (Considers real life conditions and technology limits) © Ricardo plc 2016 16
Design for Reliability Methodology Overview l DEFINE l Reliability Allocation FEASIBILITY OF OBJECTIVES – WORKED EXAMPLE Consider the mechanical / electrical system below consisting of the sub-systems as shown. A system reliability of 0. 90 in 5 years is required as a non-repairable system. Engineering estimates of complexity, technologies, performance time and environments can be made. The sub-systems and their ratings are described in the following Table, Columns (1) to (5). The allocated failure rate for each sub-system can be calculated; © Ricardo plc 2016 17
Design for Reliability Methodology Overview l DEFINE l Reliability Allocation OK (1) Values agreed through multi-disciplinary engineering team (8) (2) (3) (4) (5) (6) (7) Complexity Technology Performance Time Environment Overall Rating Complexity r’ 1 r’ 2 Low Speed Shaft 5 6 5 5 750 . 097 0. 002037 Coupling 7 6 10 2 840 . 109 0. 002289 Gearbox 10 10 5 5 2500 . 324 0. 006804 Coupling 8 8 5 7 2240 . 290 0. 00609 High Speed Shaft 4 2 10 8 640 . 083 0. 001743 6 5 5 5 750 7720 . 097 1. 000 0. 002037 0. 021 Subsystem Generator Total r’ 3 r’ 4 w’k C’k © Ricardo plc 2016 18
Design for Reliability Methodology Overview l DEFINE l Reliability Allocation Feasibility of Objectives considers • System Complexity • State-of-the-Art (Technology) • Performance Time • Environment The reliability targets for each component or sub-system are fed back into the RBD, discussed above, to yield the system reliability target. Reliability targets at component level are essential at the “Define” stage of the programme to ensure reliability targets are known and correctly specified prior to sourcing. “It is extremely difficult to increase the reliability of an existing part retrospectively………. . ” © Ricardo plc 2016 19
Design for Reliability Methodology Overview l IDENTIFY l Change Point Analysis (CPA) l CPA is used to help understand the levels of change from earlier designs (if applicable) or evaluate the risk associated with design changes when undertaking for example, Reliability Growth tracking. With a “clean sheet” design, this process will not generally be required; but during development phases, design iterations, particularly those associated with Reliability Growth, these processes will benefit from using Change Point Analysis. l l CPA assesses how much has changed, the nature of the changes, and subjectively, the risk associated with those changes. It is not intended to objectively evaluate and mitigate risks but to ensure: l (1) The risk is identified. l (2) The risk is considered within the appropriate Df. R or Quality process (e. g. FMECA, Test Plan) to objectively evaluate and mitigate any effects. © Ricardo plc 2016 20
Design for Reliability Methodology Overview l IDENTIFY l Failure Mode, Effects & Criticality Analysis (FMECA) l An FMECA should be incorporated as an integral part of the Df. R process from preliminary or concept design through to the final design. The document should be regularly updated to capture design changes, feedback from analysis, feedback from testing and the refinement of any reliability data generated throughout the programme. l The FMECA should always reflect current design and current reliability/failure data. l While the reader will probably be familiar with DFMEA basic techniques, some aspects of the FMECA applicable to Tidal Turbines are stated below. l Criticality Analysis (CA) is a quantitative procedure which ranks failure modes according to their probability and consequences (i. e. the resulting effect of the failure mode on system, mission or personnel). l The combination of the above two processes is referred to as a Failure Mode & Effect and Criticality Analysis (FMECA). © Ricardo plc 2016 21
Design for Reliability Methodology Overview l IDENTIFY l Failure Mode, Effects & Criticality Analysis (FMECA) l The approach adopted for the FMECA process, is based partly on that described in MIL-STD 1629 A and processes developed and used by DNV GL and adopted across the Wind Turbine and Offshore industries. l While the FMEA analyses different failure modes and their effect on the system, the Criticality Analysis (CA) classifies and prioritises their level of importance based on Consequence of the effect and Probability of failure. The table below shows the qualitative rankings of risks based on these. © Ricardo plc 2016 22
Design for Reliability Methodology Overview l IDENTIFY l Failure Mode, Effects & Criticality Analysis (FMECA) Consequence Classes Descriptions and rankings of severity levels for Consequence Classes Probability Classes Descriptions and rankings for Probability, based on indicative annual failure rate © Ricardo plc 2016 23
Design for Reliability Methodology Overview l IDENTIFY l Failure Mode, Effects & Criticality Analysis (FMECA) Definitions of Technical Class © Ricardo plc 2016 24
Design for Reliability Methodology Overview l IDENTIFY l Failure Mode, Effects & Criticality Analysis (FMECA) l Where failure rates, failure mode ratios and failure effect probabilities are available, a quantitative method may be used. However, the data required to complete a quantitative risk analysis is not readily available at present for Tidal Turbine devices. l As parts and failure rate data become available as the system matures, it will be possible to calculate criticality numbers and incorporate them into the rankings and analysis. l A shortcoming of qualitative criticality ranking is the inability to allow the engineer to identify high risk or Consequences of failure simply from the product of Consequence and Probability. It is possible that two or more failure modes may have similar numbers as they are the product of Consequence and Probability, but one may have a much higher severity or Consequence of failure. © Ricardo plc 2016 25
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Reliability Databases l With the exception of power electronics and controls, little data that is directly relevant to Tidal Turbine reliability is available in the public domain. For initial reliability predictions of mechanical systems, relevant sections of the Handbook of Reliability Prediction Procedures for Mechanical Equipment, published by the US Naval Surface Warfare Centre (NSWC) may be of early use in reliability predictions and allocations. l The reliability reporting systems used in the wind industry appear to be the most suitable to be adopted for Tidal Turbines, in addition, their technologies are closely aligned. l This however should not exclude the study and adoption of any best practices used elsewhere in other industries. l The Ti. PTORS Phase 1 report makes recommendations for putting into place, the basis for a Tidal Turbine industry wide Database. Table 3 on the next page is a summary of the conditions that prevail within the industry and how these would need to change in order to establish an effective Tidal Turbine database. © Ricardo plc 2016 26
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Reliability Databases Existing Proposed Individual Turbine Developers & Local Supplier Base work individually. Working group of partner Turbine Developers & Supplier members led by industry sponsor/champion. Such a group would require convincing of tangible benefits for them to participate. No requirement to share failure data. Concerns over identification of individual failures being identified against specific Tidal Devices. Concerns over commercial / IP disclosures. Condition of membership. Investigate mechanisms to make data anonymous or adopt structure similar to Boeing where developer data is “screened” from other developers. No common parts descriptions. Same component will have different names or conversely, parts with similar names will be physically different. Common Turbine Taxonomy. Could be enforced on the data base using forced field entry of “standard” nouns from a menu. Agreement required on Turbine architectures that are relevant to the database Different definitions of Reliability amongst developers. Standard definition of Reliability Variations in what information is recorded for a failure. Evaluate and adopt if suitable, current protocol as used by Reliawind or Sparta Different levels of “root cause” analysis carried out. This can range from subjective judgements about failures through to Robust and consistent “Root cause analysis” process in place and robust analysis. Difficult to determine if failure descriptions are used across the industry. FRACAS would provide this. always accurate. Table 3 – Key requirements for a Tidal Turbine Reliability Database © Ricardo plc 2016 27
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Physics of Failure l This phase of the Df. R process is concerned with investigation of the Physics of Failure associated with critical components, in the absence of sufficient statistical data (i. e. Database material), due to small populations and varied load cases, and to make recommendations for: l Improved accuracy of models for use at the Design phase by considering all loadings (external & internal). l The opportunities to enhance Condition Based Monitoring from a Diagnostic based to a Prognostic based tool and ensure it is applied in the most effective manner to Tidal Turbines. l The basic steps to implementing the Po. F approach are: © Ricardo plc 2016 28
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Physics of Failure l Defining realistic component / product requirements l Defining the design duty cycle l Define loads, load types (e. g. deterministic / stochastic) and characteristics l The duty cycle will define the mechanical, thermal, electrical and chemical loads that are experienced over time. l These loads may also be associated with manufacture, testing, storage, repair, handling as well as operating conditions. Typical additional potential failure modes on a component © Ricardo plc 2016 29
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Physics of Failure l l Identifying potential failure sites and failure mechanisms. Critical parts and their interconnections, potential failure mechanisms and modes must be identified early in the design. Potential architectural and stress interactions must also be defined. Characterising the materials, manufacturing and assembly processes. It is unrealistic to assume materials are free of defects as they often have naturally occurring defects and manufacturing processes can also induce additional defects. Designing to the duty cycle and process capability. The design stress spectra and the full scale test spectra must be based on the anticipated lifecycle usage conditions. These steps become an iterative process of the system design, design analysis and system modification (re-design) See diagram below. Po. F investigations will be enhanced by the “intelligent” use of advanced sensors, specific to the area being studied. © Ricardo plc 2016 30
Design for Reliability Methodology Overview l QUANTIFY & IMPROVE l Life Data Analysis l Life data analysis requires the practitioner to: l Gather life data for the product. (component, sub-system or system) l Select a lifetime distribution that will fit the data and model the life of the product. Estimate the parameters that will fit the distribution to the data. Generate plots and results that estimate the life characteristics of the product, such as the reliability or mean life. When the parameters to fit a life distribution to a particular data set have been calculated, a variety of plots and calculated results from the analysis can be obtained, including: l l l Reliability Given Time B(X) Life Probability of Failure Given Time Probability Plot Mean Life Reliability vs. Time Plot Failure Rate pdf Plot Warranty Time Failure Rate vs. Time Plot Contour Plot © Ricardo plc 2016 31
Design for Reliability Methodology Overview l ANALYSE & ASSESS l System Reliability Analysis l A system is a collection of components, subsystems and/or assemblies arranged to a specific design in order to achieve desired functions with acceptable performance and reliability. l The types of components, their quantities, their qualities and the manner in which they are arranged within the system have a direct effect on the system's reliability. To accomplish this, and in addition to the reliability of the components, the relationship between these components is also considered and decisions as to the choice of components can be made to improve or optimize the overall system reliability, maintainability and/or availability. This reliability relationship is usually expressed using logic diagrams, such as; l Reliability Block Diagrams (RBD) and/or l Fault Trees l l There are many specific reasons to look at component data to estimate the overall reliability of a system or sub-system to which it belongs. One of the principal reasons is that for devices such as Tidal Turbines, it is easier and less expensive to test component / sub-systems rather than entire systems. © Ricardo plc 2016 32
Design for Reliability Methodology Overview l ANALYSE & ASSESS l System Reliability Analysis l The importance of System Reliability Analysis as a tool lies with establishing the influence of Components-off-the-Shelf (COTS), within a Tidal Turbine System. l While much analytical work may be carried out on bespoke components or systems, COTS are often overlooked in terms of their effect on system reliability. The selection of an off-the-shelf component is often based solely on lowest cost which is often accompanied by a lack of information or knowledge by the supplier on the reliability of the part supplied. The adoption of System Reliability Analysis disciplines and the use of RBD’s within the Df. R tools will drive an increased awareness with the Tidal Turbine developer and contractual requirements on the component supplier, for reliability data to underpin the selection and use of appropriate COTS to meet the reliability target of the system. l l © Ricardo plc 2016 33
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Design of Experiments l Design of experiments (Do. E) is a systematic method to determine the relationship between factors affecting a process and the output of that process. l It is used to find cause-and-effect relationships The objective of Do. E as a tool in reliability engineering and quality is to investigate key interactions which, when identified, can be used at various stages to improve both quality and reliability as part of the Design for Reliability methodology for Tidal Turbines. Examples of the use of this technique can include the following design & development process stages: l l l l Design optimisation Process optimisation Supplier selection Root Cause Analysis “What-If” Analysis Component & Sub-System testing Noise factor optimisation & management. Process Factors and Responses Example of a Main effects plot (Example shows Temperature & Pressure) © Ricardo plc 2016 34
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Fault Tree Analysis l As a fault finding tool, FTA provides a logical representation of the elements in a system. l The process of constructing a fault tree allows the investigating team to consider the relationships between the parts at each level of the system. On a subjective level, this can help with uncovering potential failure causes. FTA can also be used to study probability of failure by mathematically evaluating the relationships using Boolean algebra. As an example of the fault tree usage at the design stage, a design specification might state that no single component failure shall lead to a system failure. This is the same as saying that the system should contain no single component minimal cut sets. Thus, checking the minimal cut sets can confirm that this design requirement is met. Similarly, if the specification states that a certain type of failure should not fail the system, the fault tree can be used to verify that this is being met. l l l l FTA is a commonly used process within engineering and its application and benefits are documented widely elsewhere. © Ricardo plc 2016 35
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Fault Tree Analysis Elements of a Fault Tree Diagram © Ricardo plc 2016 36
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Reliability Growth (RG) is defined as the positive improvement in a reliability metric of a product (component, sub-system, system) over a period of time due to changes in the products design and / or manufacturing process. l A Reliability Growth programme is a structured process of finding reliability problems by testing, incorporating corrective actions and monitoring the increase of the products reliability throughout the test phases. l The term “growth” is used since it is assumed that the reliability of the product will increase over time as design changes and fixes are implemented. However, in practice it is possible in some cases that no growth or negative growth may occur. l Reliability Growth is considered an essential process within the Tidal Turbine Design for Reliability methodology. This activity will be foremost in demonstrating and providing data to confirm the improvements achieved throughout the complete Df. R process. l The fundamental concept of Reliability Growth is that the reliability of an item will improve as failure modes that degrade its function are discovered and eliminated or mitigated. © Ricardo plc 2016 37
Design for Reliability Methodology Overview l ANALYSE & ASSESS l Reliability Growth The diagram shows an example of a typical RG curve across the development test phases of a programme. This illustrates the effect of the Test-Fix-Test approach to the introduction of reliability improvements and is a preferred approach provided changes can be implemented quickly. The curve shown is continuous but in reality, there is a time lapse between phases which will allow for the introduction of revised parts for the next test phase. Replacing a part with an identical part will not increase reliability. An enhancement has to be made to the function of the part to do this. Fixing a part could actually reduce reliability if it “unmasks” another failure hidden by the original part. © Ricardo plc 2016 38
Design for Reliability Methodology Overview l VALIDATE l Reliability Demonstration Testing (RDT) l RDT should not be confused with Reliability Growth (RG) and its associated processes such as Test, Analyse, Fix (TAF) although in many respects these activities have aspects in common. l RDT is mainly concerned with measuring whether or not a specified requirement has been met, normally in terms which can be contractually binding. l It may itself reveal new failure modes which require corrective action, especially if there are inadequacies in the RG programme and associated tests. l There is a relationship between RG and RDT and these activities should be planned with consideration to both processes. l The execution of Reliability Demonstration testing for Tidal Turbine devices will probably only be driven by a contractual requirement between the supplier and the customer. l The exact conditions will depend on the nature of the contract, however, it is essential that reliability targets included in any contract are realistic, can be demonstrated practically and any outcomes are enforceable. © Ricardo plc 2016 39
Design for Reliability Methodology Overview l VALIDATE l Reliability Demonstration Testing l The specification, planning and execution of a successful RDT programme, will require a team, suitably qualified in reliability processes and a thorough understanding of the associated statistical techniques in order to process and correctly interpret the data outputs. l This must be underpinned by a commitment from management and an adequate budget to implement what will be one of the most expensive and complex activities within any Df. R methodology. l An RDT demonstrates whether the achievement of given reliability parameter values can be claimed with a given level of confidence. l This definition is deliberately couched in terms of “claimed” and “confidence” since statistical parameters are being addressed and the parameters cannot be measured exactly and repeatedly in tests based on small samples. © Ricardo plc 2016 40
Design for Reliability Methodology Overview l VALIDATE l Reliability Demonstration Testing l For example if a system is tested for 500 hrs and exhibits 5 failures it can be claimed (assuming a constant failure rate) that: a) The MTBF is at least 50 hrs with a confidence of 0. 93: b) The MTBF is at least 100 hrs with a confidence of 0. 38: and c) The MTBF is at least 150 hrs with a confidence of 0. 04. • All of these statements are correct from the results quoted. Note that the higher the claim, the lower the level of confidence. • Prior to committing to RDT, the following should be confirmed: • Have the reliability requirements been defined at the start of the programme? • Has “reliability” been defined in a way it can be demonstrated? • Does RDT form part of a supplier contract? • Has RDT been budgeted (cost & resources) within the programme? © Ricardo plc 2016 41
Design for Reliability Methodology Overview l MONITOR & CONTROL l Root Cause Analysis l As part of the understanding of failures and their causes, Root Cause Analysis (RCA) is a crucial element in the product development process. l In the context of a Design for Reliability (Df. R) process, RCA will be needed in support of a Failure Reporting, Analysis and Corrective Action System (FRACAS) discussed in the next section. l An effective root cause analysis process should meet the following criteria: a. Clearly defines the problem and its significance to the problem owners. l b. Clearly delineates the known causal relationships that combined to cause the problem. l c. Clearly establishes causal relationships between the root cause(s) and the defined problem. l d. Clearly presents the evidence used to support the existence of identified causes. l e. Clearly explains how the solutions will prevent recurrence of the defined problem. ocuments he Clearly l f. the logic of the analysis. l © Ricardo plc 2016 42
Design for Reliability Methodology Overview l MONITOR & CONTROL l FRACAS l An essential part of the methodology for optimising reliability is the reporting of failures, their causes and the corrective actions taken to rectify the problem and reduce the probability of their future recurrence. l When recorded in a suitable manner, this information can be used by both manufacturers and suppliers, to understand the weakness of a particular part or system; and to use the lessons learnt from the corrective actions in, for example, the design of new products, the specifying of maintenance schedules, and the effects of breakdowns on a system’s operational availability. l Failure Reporting, Analysis and Corrective Action System (FRACAS) is a “closed loop” system used to improve the reliability of a product, service, process, or software application. l The “closed loop” in FRACAS refers to the systematic manner in which every issue that is reported is addressed, ensuring that no failure or incident is missed. © Ricardo plc 2016 43
Design for Reliability Methodology Overview l MONITOR & CONTROL l FRACAS For the development of the FRACAS process in this report, the definition of a failure is: ”An event in which an item does not perform one or more of its required functions within the specified limits under specified conditions. ” A failure can be either catastrophic (total loss of function) or out-of-tolerance (degraded function beyond specified limits). When an event such as this occurs, it should be the catalyst for the FRACAS process to begin. The disciplines of the FRACAS process make it an ideal process for populating a reliability database. © Ricardo plc 2016 44
Design for Reliability Methodology Overview l SUMMARY l In Phase 1 of the Ti. PTORS programme a detailed review has been undertaken of the potential processes that can be brought together across the 6 stages of a tidal turbine product development cycle from Design to Monitor & Control. l As outlined in this summary report these have been brought together to establish a Design for Reliability (Df. R) process, focused specifically on Tidal Turbine powertrains. l However, in order to fully develop an industry-wide, bespoke Df. R methodology that can be used across a wide range of tidal technologies, it will be necessary to test the methodology by aligning the outputs from this phase to the tidal developers own design processes, with the following objectives: 1) To map the Df. R methodology in this report to the tidal developer’s own design processes; l 2) Carry-out some of the “essential” steps for the tidal developer (e. g. FMECA, Reliability Growth etc. ), working in partnership; l 3) Identify areas of the process that require further tailoring for tidal turbine technologies; l 4) Collate any useful data that currently exists to validate any future reliability simulation tool; n anding gaps Identify l 5) out” projects to fill these gaps (e. g. component testing); and l 6) of enhanced sensor techniques aligned to the right failure modes. l © Ricardo plc 2016 45
Design for Reliability Methodology Overview l SUMMARY l Convincing suppliers that RELIABILITY matters l Don’t be scared of using “estimated” reliability values in early models l Estimated values may be traded in a balancing act to achieve targets. l As real reliability data becomes available this is fed into model, making model more accurate. It might be necessary to introduce redundancy into the design or even a different design or technology to help achieve a reliability target. When the above has been processed, there will remain some “inviolable” reliability requirements that cannot be assigned elsewhere or compromised. These will in fact become “targets” which will have to be met by supplier or developer. This element of the Df. R process which drives credible reliability targets is a key enabler for any Tidal Developer as it provides real data with which to drive reliability requirements into the supplier base as well as internal processes. With this data, reliability targets can be enforced with confidence and supported with data. l l l © Ricardo plc 2016 46
Design for Reliability Methodology Overview l SUMMARY l Skills & Budgetary Requirements l Some processes will require a high level of knowledge of statistical techniques in order to fully understand the data. l Skills are also key to the correct interpretation of analytical and test results to ensure correct decisions are made downstream. l Applies in particular to Reliability Growth tracking, considered the most technically complex task to undertake within the Df. R suite of processes. l It is equally important to ensure that adequate budgets are allocated for processes to be undertaken correctly. l Advanced planning of budgets into the model is essential for many of the Reliability processes. © Ricardo plc 2016 47
Design for Reliability Methodology Overview l SUMMARY l Justifying improvements to achieve Reliability l Changes to meet reliability targets should not be a fight between Engineering and Finance. l A key enabler, not within the scope of Phase 1, is the development of a cost model l Essential for analysing and evaluating reliability improvements, either to meet or exceed targets. l These models will be unique to the Tidal Developer and reflect the organisations costing structure. l It is an essential tool to ensure the correct (long term) value is assigned to changes that affect costs. l The model must recognise cost of failures in the field, including contractual penalties, as a balance against process or product cost increase. l The model should also be capable of looking at any offsets that are available to mitigate on-costs. © Ricardo plc 2016 48
Design for Reliability Methodology Overview l SUMMARY l How does the Design for Reliability processes align with the Design Life Cycle? Product Dev't Program me ‘Phases’ REQUIREMEN TS / PDS CONCEPT DETAIL DESIGN SUB-SYS VALIDATION (SUPPLIERS) ANALYSIS PROTOTYPE BUILD SYSTEM INTEGRATION TEST & DEVT DRIVETRAIN TESTING (prior to deployment) CONTROL PLAN FAULT TREE ANALYSIS AFFINITY DIAGRAM Design for Reliability (Df. R) Processes FMECA PHYSICS OF FAILURE RELIABILITY BLOCK DIAGRAM FMECA* RELIABILITY DATABASE RELIABILITY ALLOCATION QUALITY FUNCTION DEPLOYMENT FMECA* SYSTEM RELIABILITY ANALYSIS CHANGE POINT ANALYSIS Phase # Df. R Cycle 2 1 DEFINE 3 IDENTIFY FMECA* RELIABILITY GROWTH FRACAS RELIABILITY DEMONSTRATION TESTING ROOT CAUSE ANALYSIS HALT / HASS 4 5 ANALYSE & ASSESS RE-WORK FOR IN-SERVICE DEPLOYMENT 6 7 QUANTIFY & IMPROVE PFMEA 8 VALIDATE 9 10 MONITOR & CONTROL * Denotes FMECA Reviews Design for Reliability processes within the design life cycle © Ricardo plc 2016 49
Design for Reliability Methodology Overview l Further Information A more detailed summary of the Design for Reliability Methodology can be found in the report on the ORECatapult website. https: //ore. catapult. org. uk/ This report is backed up by a series of more detailed technical reports on the individual Df. R processes within this methodology, together with worked examples, which are also available via the ORECatapult © Ricardo plc 2016 50
Design for Reliability Methodology Overview l Ti. PTORS Design for Reliability Tool This report, which summarises work carried out by DNV GL, proposes a methodology to be followed for the development of a simulation tool for the purpose of analysing the reliability of power train components. The simulation tool will enable an improvement of reliability throughout the design process by simulating the reliability of tidal turbine powertrain systems and components. An example case is presented within this report, providing guidance on the how this may be achieved and demonstrating the feasibility of the approach. A copy of the full Design for Reliability Tool report can be found on the ORE-Catapult website. https: //ore. catapult. org. uk/ © Ricardo plc 2016 51
Design for Reliability Methodology Overview Thank you for listening. Ricardo UK Ltd – Midlands Technical Centre Southam Road, Radford Semele, Leamington Spa, Warwickshire, CV 31 1 FQ, UK Roy Browett Principal Development Engineer Driveline & Transmission Systems Direct Dial: Reception: Fax: +44 (0) 1926 477736 +44 (0) 1926 319319 +44 (0) 1926 319300 roy. browett@ricardo. com www. ricardo. com Please do not hesitate to contact us if you would like to discuss any aspects of this presentation © Ricardo plc 2016 52
- Slides: 52