Risk analysis Fault Tree FMECA

Presentazione sul tema: "Risk analysis Fault Tree FMECA"— Transcript della presentazione:

1 Risk analysis Fault Tree FMECA
Gli strumenti per tenere sotto controllo tutto quello che può andare storto Risk analysis Fault Tree FMECA

2 Cosa è un failure (1) Si ha un failure quando uno degli stakeholder (utente, cliente, progettista, reparto manutenzione) è in grado di osservare una variazione sensibile (percepita come anomala) del sistema. La variazione è generalmente peggiorativa della funzione, del livello di alcuni suoi parametri, o è associata all’insorgenza di alcuni svantaggi (es. rumore)

3 Cosa è un failure (2) Failures are linked to the following variables:
loss of ideality of a device in terms of reduced performance, presence of undesired side effects and excessive consumption of resources to make the system work. Becattini N, Cascini G, Rotini F (2009) Correlations between the evolution of contradictions and the law of ideality increase. Proceedings of the 9th ETRIA/CIRP TRIZ Future Conference, Timisoara, Romania 4-6: 26-34

4 Risk Management

5 Risk Management Conoscere in modo preventivo i fattori di rischio →
“metodologia sistematica che consente per l’identificazione, l’analisi, l’eliminazione ed il monitoraggio dei rischi associati ad un processo in modo da rendere l’organizzazione capace di minimizzare le perdite e massimizzare le opportunità.” Rischio: la probabilità di accadimento di tutti gli eventi che possono comportare danni o perdite per l’azienda e le persone coinvolte. Conoscere in modo preventivo i fattori di rischio → → Eventi potenzialmente dannosi → → Il loro impatto → → Frequenze di accadimento

6 Step “Pianificazione” “Identificazione Rischi” “Analisi”
“Comparazione con requisiti minimi” “Decisione” Trasferimento del rischio Riduzione del rischio Contenimento del rischio Accettazione del rischio

7 Risk Management: i 5 step
Pianificazione: il processo di risk management deve essere pianificato e formalizzato definendone le responsabilità, gli obiettivi ed i criteri per l’accettazione dei rischi. In particolare un programma di gestione del rischio ben bilanciato deve ottimizzare sia la sicurezza che i costi ad essa associati. Identificazione dei rischi: si devono identificare in maniera preventiva i rischi connessi al progetto/sistema/processo che si sta valutando. Analisi: I rischi evidenziati devono essere caratterizzati in termini di probabilità di accadimento e di severità dell’impatto. Comparazione con i requisiti minimi di sicurezza: i rischi devono essere comparati con i criteri di accettabilità stabiliti nel piano operativo ed i risultati devono essere documentati per la successiva fase decisionale. Decisione: scegliere gli interventi necessari ad una corretta gestione dei rischi rilevati. Tipicamente si hanno le seguenti opzioni: Trasferimento del rischio tramite polizze assicurative (tipicamente coprono economicamente i danni fisici, ma non quelli derivanti da perdita di riservatezza, integrità e disponibilità). Riduzione del rischio tramite interventi preventivi mirati a ridurre il livello di vulnerabilità del sistema, ridurre la frequenza di accadimento di un evento indesiderato o a ridurre l’impatto sulle risorse colpite. Contenimento del rischio tramite interventi reattivi atti a contenere gli effetti dell’evento. Accettazione del rischio.

8 Step Industria aerospaziale

9 Tabella di rischio FAA “Federal Aviation Administration”

10 Tabella di rischio FAA “Federal Aviation Administration”

11 Tabelle di valutazione
FAA “Federal Aviation Administration”

12 Tabelle di valutazione
FAA “Federal Aviation Administration” >1/ 1/ 1/ 1/ 1/ <1/

13 Tabelle di valutazione
MIL-STD-882C

14 Tabelle di valutazione
MIL-STD-882C

15 Procedura di gestione rischio
Progettare per ridurre al minimo il rischio: il progetto dovrebbe eliminare il rischio connesso ad un certo evento o ridurlo entro i limiti tollerabili. Incorporare strumenti di controllo e sicurezza: quando la progettazione non è sufficiente ad eliminare il rischio, è necessario ricorrere a sistemi di sicurezza “attivi e passivi” incorporati nel prodotto. Incorporare strumenti diagnostici e di allarme: se le prime due fasi non sono sufficienti è necessario ricorrere a sistemi di avvertimento che segnalino con debito anticipo l’accadimento di un guasto/problema. Sviluppare procedure di sicurezza e addestramento personale: come ultima risorsa è necessario definire delle procedure formali sia per operare in sicurezza, sia per operare correttamente al momento del verificarsi di una situazione di pericolo.

16 Alcune Metodologie Secondo le norme MIL-STD-882 (System Safety Program Requirements), un sistema è definito come: A composite at any level of complexity, of personnel, procedures, material, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operation or support environment to perform a given task or achieve a specific production, support, or mission requirement 5 M Media Msn – Mission: central purpose or function Mach: hardware & software Man: Human element Media - Environment: Operational and ambient environment Manag: Management, procedure, policies, regulations Mach. Man Msn Manag.

17 Alcune Metodologie SHELL H Software Hardware S L E Liveware
Environment L

18 Alcune Metodologie SHELL H L E S
Il fatto che i blocchi siano adiacenti o separati è tanto importante quanto le caratteristiche descritte dai blocchi stessi. I blocchi devono infatti essere ri-arrangiati a seconda delle caratteristiche del sistema schematizzato: una connessione fra i blocchi significa infatti la presenza di un’interfaccia fra i due elementi. Ciascun elemento del sistema dovrebbe essere descritto dettagliatamente sia dal punto di vista fisico che funzionale. Descrizione delle caratteristiche fisiche: deve fornire informazioni circa la disposizione spaziale e delle interfacce fra i vari sottosistemi e componenti. Descrizione funzionale: deve indicare che cosa deve fare il sistema e dovrebbe includere le funzioni del sottosistema e il modo in cui si integrano per assolvere alla missione del sistema.

19 Alcune metodologie Definito il sistema si passa all’analisi della criticità dei possibili eventi di rischio al fine di ottenere i parametri da utilizzare nella matrice di rischio. Cause consequencies analysis Check list Criticality Analysis Critical Path Analysis Energy analysis FTA FMEA FMECA MORT What if Analysis ….

20 Fault Tree Analysis

21 A cosa serve la Fault Tree Analysis
La FTA permette, in modo grafico e logico, di collegare fra loro i guasti dei componenti di un sistema. Lo scopo principale, è quello di partire da un guasto sul sistema (evento indesiderato) per metterlo in relazione funzionale con i guasti sui componenti (eventi di base).

22 Definizioni Evento Top indesiderato: il guasto relativo al sistema funzionale sotto esame. L’evento indesiderato può essere combinazione di numerose cause. Esso avrà, cioè, un numero “n” di eventi (nodi del sistema) che lo precedono e lo determinano ma nessun evento che lo succede Combinazione di cause: è il presentarsi simultaneo di guasti degli elementi funzionali che portano all’evento top indesiderato. La più piccola combinazione di guasti ne contiene almeno un numero necessario a causare l’evento top. Unità esaminata: l’oggetto da esaminare, identificato dalle sue caratteristiche funzionali e costruttive. Unità esaminate possono ad esempio essere sistemi, componenti ed elementi funzionali Componente: è l’unità esaminata di livello più basso alla quale può essere assegnato uno o più elementi funzionali.

23 Esempio Si supponga, per esempio, che il sistema sia formato da un motore elettrico, una batteria e due interruttori e che l’evento indesiderato sia l’impossibilità di spegnere il motore: il primo livello dell’albero potrebbe configurarsi nel modo Applicando l’algebra booleana è quindi possibile determinare tutte le combinazioni di eventi che portano al verificarsi del “Top Event” e quindi, conoscendo le frequenze di accadimento delle varie cause alla determinazione dell’affidabilità del sistema complessivo.

24 Categorie di insucessi o guasti
In particolare l’analisi FTA, classifica gli insuccessi del componente in tre categorie: Guasto primario: l'insuccesso primario è dovuto alla costruzione o alle caratteristiche materiali del componente stesso. Guasto secondario: l’insuccesso del componente è causato da influenze esterne inaccettabili, come per esempio condizioni ambientali, condizioni di applicazione o l'influenza di altre componenti del sistema. Guasto di comando: è causato da errori di natura umana o per uso scorretto.

25 Gli step della Fault Tree Analysis
Vedi dispense

26 Esempio e tabella FTA Da dispense

27 Failure Mode Effect and Criticality Analysis
FMECA Failure Mode Effect and Criticality Analysis .. della serie “Come evitare la sgradevole frase: <<Io l’avevo detto!!>>”

28 Andamento di un processo di progettazione

29 FMECA Analisi di tipo bottom-up per individuare pericoli potenziali e valutarne la criticità Obiettivi Riconoscimento e valutazione di possibili guasti e dei loro effetti sul sistema. Identificazione di interventi che possano eliminare o ridurre le possibilità di verificarsi dei guasti Scelta e pianificazione degli interventi da effettuare. Documentazione del processo

30 FMECA FMECA di Progetto (DFMECA) FMECA di Progetto (DFMECA)
Per evitare guasti derivanti da errate soluzioni concettuali, materiali e/o fornitori sbagliati. Input derivano da clienti e si basano sulle specifiche richieste. Necessità di analisi funzionale e/o FTA per definire sequenze causa-effetto. FMECA di Processo (PFMECA) Per evitare guasti derivanti da errate soluzioni produttive. Input derivano da rapporto DFMECA e da diagramma di flusso rappresentante processo produttivo.

31 DFMECA-PFMECA

32 Processo FMECA L’aggiunta di un’analisi di criticità permette di quantificare e classificare gli effetti di ciascun modo di guasto in base ad un indice di criticità.

33 Processo FMECA Segue un approccio Bottom – UP
Inizia a livello di componente Per ciascuno identifica modi di guasto Ne determina gli effetti sugli elementi di livello superiore Prosegue a ritroso fino a livello di sistema Esempio di catena causale ricorsiva

34 FMECA I Passo Decomposizione del sistema fino al livello di dettaglio desiderato. Generalmente 3-4 livelli fino alle LRU* Si ottiene diagramma ad albero Da questo è possibile partire con la definizione della catena causale di guasto * Line Replaceable Units (LRU), ovvero quelle parti che in caso di guasto non subiscono operazioni manutentive ma vengono direttamente sostituite.

35 FMECA I Passo Esempio Albero DFMECA

36 FMECA I Passo Esempio Albero PFMECA

37 FMECA II Passo Si definiscono le funzioni di ogni elemento del diagramma (FA). Si specificano i possibili malfunzionamenti/guasti degli elementi (nei casi più semplici è la negazione della funzione) I malfunzionamenti dei livelli più bassi sono “cause”, quelli dei livelli intermedi sono “modi”, quelli dei livelli superiori sono “effetti” È possibile utilizzare diagrammi causa-effetto

38 Esempio DFMEA Guasto Causa Effetto
Ingranaggio rotto, la sezione non ha retto. La pompa non invia benzina Errato dimensionamento Automobile ferma La benzina ha corroso guarnizione. La pompa perde Materiale guarnizione inadatto Auto va male, rischio incendio Filetto del raccordo sbagliato. La pompa non si monta Raccordo progettato considerando versione precedente Blocco produzione

39 Esempio PFMEA Guasto Causa Effetto
Ingranaggio rotto. Pompa non invia benzina Cattivo trattamento termico Automobile ferma Guarnizione allentata. Pompa perde Operatore non ha serrato adeguatamente viti coperchio Automobile va male, pericolo incendio Filettatura difettosa. Pompa non si monta Usura eccessiva maschio Blocco Produzione

40 FMECA III Passo Definire criticità dei guasti
Metodo 1: Criticality Number Definire criticità dei guasti a = “percentuale di guasti all’interno di una certa tipologia” b = “probabilità che si verifichi l’effetto” l = “tasso di guasto” t = “periodo di funzionamento”

41 FMECA IV Passo Metodo 2: Risk Priority Number Severity = “valutazione della gravità dell’effetto di una Failure sul cliente. Assume valori [0;10] ed è riferito a ciascun effetto che una failure può avere” Occurance = “esprime la probabilità che si verifichi una causa di guasto. Assume valori [0;10 ]” Detectability = “capacità del design control di evidenziare l’origine di una potenziale failure. Assume valori [0;10]”

42 Tabelle RPN

43 Tabelle RPN

44 Tabelle RPN

45 Tabelle RPN

46 Tabelle RPN

47 Modulo FMEA

48 Esempio Tabella FMECA

49 Esempio Tabella FMECA

50 Punti di Forza FMECA Riduce le spese concentrando modifiche nella prima fase del processo di sviluppo. Riduzione di riparazioni in garanzia e reclami. Dinamicità del documento che segue l’evoluzione tecnica del prodotto. Aumento della conoscenza del prodotto. Capacità di formalizzare lo know-how. Formazione di un DB storico di dati/parametri tecnici.

51 Punti di Debolezza FMECA
Difficoltà per il calcolo del CN. Soggettività nei parametri del RPN. Equivalenza dei tre parametri del RPN. Esistono combinazioni dei valori dei tre parametri D,S,O t.c. ad uno stesso punteggio del RPN corrisponde una diversa possibilità che la non conformità giunga al cliente. Mancanza di valutazioni economiche. Semplificazione del modello si guasto che assume solo due stati : “funzionante” - “rotto”. Lunghi tempi di implementazione.

52 Note a chiusura

53 Risk Management, FTA, FMECA (1)
Il risk analysis viene in generale fatto per decidere se fare o non fare un impianto, se imbarcarsi in un’impresa o meno, se finanziare o no un’azienda. È simile alla FMECA, infatti le due variabili considerate Severity e Probability sono le stesse. A differenza della FMECA nell’RA non c’è traccia della Detectability in quanto la decisione deve essere presa in un preciso momento e diviene irreversibile anche se il giorno dopo ci si accorge (detect) di un cambiamento di una delle due variabili di cui sopra. Possiamo quindi dire, semplificando un po’, che l’analisi del rischio è come se fosse una FMECA in cui una variabile è considerata fissa (la non detectability).

54 Risk Management, FTA, FMECA (2)
La fault tree analysis è un’analisi di tipo logico statistico, per poter essere effettuata ha bisogno di una serie di dati piuttosto importante e che le catene causali nel sistema possano essere modellate in maniera completa ed in modo logico. La fault tree si applica molto bene in campo elettronico in cui le relazioni fra i componenti sono prevalentemente relazioni logiche e dove sono presenti i dati di affidabilità dei singoli componenti. Mentre la fault tree si concentra sulle catene causali e sulla propagazione dei guasti all’interno del sistema, la FEMCA si occupa delle foglie dell’albero dei guasti concentrandosi sugli eventi maggiormente critici e cercando di fare un’analisi dei modi e soprattutto delle cause di guasto. La FMECA è orientata a riprogettare l’elemento per ridurre il rischio mentre la fault treee analysis si focalizza nella riprogettazione dell’architettura.