FMEA and Functional FMEA A generic approach Tor Stålhane, NTNU, IDI FMEA problems Trammel and Davis: • Have to go through the FMEA process with a lot of unimportant failure modes. • Component-by-component review takes a considerable amount of time => teams get frustrated since most components assessed had minimal or no impact on the system Kmenta and Ishii: • Performed too late, FMEA does not affect key product / process decisions • FMEA does not capture key failures • FMEA is often an afterthought “checklist exercise” • The process is tedious • The Risk Priority Number gives a distorted measure of risk. Our solution – a generic approach Generic failure modes instead of component specific failure modes to obtain: • A consistent, sufficient and uniform set of failure modes. • Simplified FMEA, using only a sufficient level of details. • Not having to invent failure modes => free analyst to focus on failure causes, consequences and prevention. Generic failure modes => reuse of • Results from components and component assemblies. • Actions which are used to mitigate the failure modes. Using generic failure modes Be ware: Generic failure modes • Are not a replacement for using you head • Are most useful in the early stages where we still have a lot of choices when it come to – architecture – barrier solutions • Should be used as guide words in the analysis Generic failure modes - CESAR Component type Software systems - control system, e.g., a PLC Hardware component, e.g. a pump or a sensor Failure mode Omission – something is not done, no action Commission – something more is done Wrong action Too late – right action but too late No action Wrong action Generic failure modes - NRC ID Failure mode A1 Fail to perform the function at the required time A2 Fail to perform the function with correct value A3 Performance of an unwanted function A4 Interference or unexpected coupling with another module Elaboration Deviation from requirement in time domain Deviation from requirement in value domain Deviation from expected performance Deviation from expected system performance due to module interaction Remarks Omission, No action, No output, Reacts too late Wrong output Commission, Wrong action Commission Harrison’s human failure modes No 1 2 3 4 5 6 Failure mode Errors of omission Comments Something that should have been done is not done Errors of commission Something more has been done is not done Errors of sequence Actions has been done in a wrong sequence Errors of repetition An actions has been done too many / few times Too much / little Too much or too little has been done Too early / late / An action was done too early / too late / for long too long Enables the inclusion of operators in the safety analysis Simple FMEA – early phases Failure effect on the next Recommendations Unit description Failure mode Failure cause level Failure description FMEA in the early phases of product development has much in common with Preliminary Hazard Analysis – PHA “Recommendations” should be used for • Possible barriers • Design changes • Requirements changes Functional FMEA Function Functional Effects failure mode Function description Current detection Cause method Comments Generic functional failure modes – should be used as guidewords: • Over • Under • No • Intermittent • Unintended FMEA vs. Functional FMEA – 1 We can use • FMEA when focusing on the components’ inner working • Functional FMEA when focusing on the functionality that a component provides to its environment - usually parameter values FMEA vs. Functional FMEA – 2 FMEA for each control unit. Functional FMEA for the boiler, which provides the real value / service to the users 7 3 8 6 1 2 8 4 5 Extended FMEA – Trammell and Davis Project title FMEA type Design System Group Prepared by Core team Requirement Failure mode Effect of failure SEV Cause or mechanism OCC Current design and control DET RPN Recommendations SEV OCC • SEV: severity of failure mode if it occurs • OCC: rate of occurrence of the failure mode for • Current design • After design changes • DET: rate of detection – how often do we detect this failure mode if it occurs. • RPN: SEV * P(event | not detected) * P(not detected) DET RPN Why generic fault trees Several organizations have developed generic fault trees for systems in their domains. A fault tree • do not identify how a failure propagates through a system to cause an accident • can be used to see which failures can cause the top event in the fault tree. An FMEA can show whether the root cause events can occur for the system under consideration. Generic fault tree – water supply failure Generic fault tree – blowout Combining FMEA and FTA Generic hazards Murphy’s law: “If something can go wrong, it will”. However: What can go wrong, depends on the system’s operating environment. A generic hazard list is a list of hazards that are possible in a certain domain or environment Simple hazard lists Hazard list item Task description / location Reference no. Hazard description Date last reviewed Risk Assessment Matrix score Initial Controls / Barriers Reference Owner Status Current Grow your own hazard list You should start with a list of the domain-specific generic hazards. Add items identified from brainstorming and experience from: • Developers • Maintenance personnel • Users Remember to include all barriers – also those that are just planned for. From hazard to catastrophe To analyse a potentially dangerous event we need to consider • Where will it hurt us – e.g. people, assets, environment or reputation • How likely is it that it will hurt us – the accident likelihood • How can we prevent the accident – barriers and controllability Likelihood Reputation Environment Assets People Severity Consequences 0 No injury or No damage health effect No effect No impact 1 Slight injury or health effect Slight damage Slight effect Slight impact 2 Minor injury Minor or health damage effect Minor effect Minor impact 3 Major injury Moderate or health damage effect Moderate effect Moderate impact 4 PTD or more Major than 3 damage fatalities Major effect Major impact 5 More than 3 Massive fatalities damage Massive effect Massive impact A Never heard of in the industry B Heard of in the industry C D Has happened in the organization or more than once per year in the industry Has happened at the location or more than once per year in the organization E Has happened more than one per year at the location Controls / barriers Controls and barriers are used actively in some risk assessment models – e.g. ISO 26262. All hazard list items should include all barriers that are • Tried – been used before • Possible – known from literature, other industries etc. Controls, barriers and the FMEA results • Prevention. Change the design or implementation to remove or reduce the probability of the failure’s occurrence => preventing a risk (potential problem) from becoming a real problem • Handling. Prevent the failure’s consequences • Reduction. Reduce or control the failure’s consequences. Barriers Failure propagation From failure to failure mode Cause – consequence diagram Sensor error Wrong temperature Increase heat Too high pressure Too hot vessel Wrong command Safety valve OK Sensor s.a. low N Y Combustibles N Y Y Explosion CU EQ EN Fire N Input Focused FMEA – IF-FMEA Component ID Output failure Description mode FM1 Description of FM1 FM2 … List of input sources Component Component input deviation malfunction Input deviations Component that can cause failures that can FM1 cause FM1 … … Input source 1 Component Input source 2 Input source 3 Output l Temp. sensor Temp. controller Pressure sensor Component: Temp. controller Output failure Description mode On / Off signal to heating unit Generic functional failure modes – should be used as guidewords: • Over • Under • No Input sources: Temp. sensor, Pressure sensor Input deviation Component l malfunction Omission: fail to update based on The controller sensor signals should have kept Commission: Turn on when inactive (no Under – too low something not should have kept change needed) from temp and/or related to temp or or should have pressure off pressure input is turned the heat done instead on Wrong: controller sends wrong signal … … … … Example – initial hospital system X-ray machine PC Network X-ray Data base FMEA with generic failure modes Unit description PC and medic X-ray machine and operator Failure description Failure mode Failure cause Wrong action No action Wrong action No action Network Wrong action No action X-ray database Wrong action No action Failure effect on the next level Get wrong X-ray Get no info X-ray linked to wrong person Don’t work at all Recommendations Bar-code reader for patient ID Reliability requirements Sends info to Reliability wrong address requirements Reliability No traffic requirements Local, temporary database Returns wrong Reliability info requirements No info returned Mirror database Example – final hospital system X-ray machine PC Network Temp Data base Controller X-ray Data base Mirror Data base Bar code reader
© Copyright 2024