---
# System prepended metadata

title: 14 - Sistemi tolleranti ai guasti
tags: [Misure]

---

---
title: 14 - Sistemi tolleranti ai guasti
tags: Misure
info: dal video 10-22 (minuto 1:30:00) fino a video 10-27 (minuti 1:03:20)
description: Blocco slide 14
---

# 14 - Sistemi tolleranti ai guasti
Introduciamo la parte del corso relativa alla tolleranza.
![](https://i.imgur.com/KBbynhP.png)
Siamo partiti da qui: abbiamo parlato della Failure Mode and Effects Analysis, dell'Hazard Analysis, la teoria dell'affidabilità. Abbiamo detto che noi, in fase operativa, lavoravamo con i metodi di supervisione e diagnostica: tutte le tecniche che abbiamo visto rientrano in questa categoria e possono essere usate per pilotare la fase di manutenzione.
C'è la parte di Fault-Tolerant design (in verde) che non è stata trattata ma che rientra sempre nella fase di progettazione. 
Nel video che fa vedere parla di un sistema avanzato di controllo e supervisione montato su un aereo (prototipo di un aereo militare). C'è un controllore a bordo che semplicemente regola l'autopilota: questo controllore deve essere reso tollerante ai guasti. Quindi il controllo gestisce il guasto. Il guasto gestito nel video è la rottura di un'ala dell'80%: vengono riconfigurate le azioni di controllo per riuscire a mantenere un volo autonomo con prestazioni ridotte, con l'obiettivo di non schiantarsi. Questo è controllo fault-tolerant. In un altro video fa vedere un drone che perde un'elica e il sistema di controllo lo deve comunque far atterrare.
Un'altra applicazione, più vicina al design, si occupa non di controllare la rottura, per esempio dei giunti dei robot, ma di modificare il design dei robot per trovare quello ottimo che è in grado di tollerare i giunti rotti. Non adatto il controllo al guasto, ma progetto affinchè quel guasto venga tollerato.

## Introduzione
Questa è l'ultima parte relativa alla diagnosi e tratta, in particolare, i sistemi tolleranti ai guasti: sono le modalità che mi permettono di gestire la presenza di un guasto all'interno del sistema. Quando vogliamo andare a fare diagnosi ci poniamo al livello dei Supervisory and safety methods, che mi permettono di andare a vedere se c'è stato un comportamento corretto oppure no del mio sistema. Questi possono poi pilotare il processo di manutenzione e fanno parte di quella che viene definita fase operativa di supervisione. A monte c'è la fase di progettazione e verifica del sistema. Si fa una FMEA su tutti i componenti per identificare tutti i possibili guasti e le loro conseguenze sul sistema; poi si fa l'analisi dell'affidabilità, discriminando tutti i guasti che conducono all'inaffidabilità e si va a riprogettare quelli che sono troppo frequenti. La stessa tipologia di analisi viene anche fatta sull'hazard analysis, ovvero un'analisi dei possibili rischi che hanno conseguenze importante sulla salute di cose o persone: si individuano i guasti che influenzano negativamente la safety.
Noi ci poniamo nella parte meccanica solo nell'ambito della fault-tolerant design, ovvero nella progettazione in grado di tollerare i guasti.

Quando noi vogliamo andare a migliorare l'affidabilità di un sistema, abbiamo due macro-possibilità: 
- fare tolleranza: si riferisce all'idea di contenere le conseguenze dei guasti in modo tale da mantenere il sistema sempre funzionante
    - evitare che un fault degeneri in un failure
    - affidandosi alla ridondanza
    - ammettendo una degradazione nelle specifiche di funzionamento
-  l'alternativa è il perfezionamento (di cui noi non ci occupiamo perchè è relativa al design) che consiste nel migliorare l'affidabilità del sistema andando ad utilizzare lo stato dell'arte della componentistica, cioè migliorando la progettazione
    - utilizzare componenti tecnicamente all'avanguardia
    - tramite una manutenzione regolare
    - includendo la parte di diagnosi precoce dei guasti

In ogni caso, a prescindere dalla tecnica scelta, il costo del sistema va ad aumentare.
Noi ci concentriamo sulla tolleranza.

## Strutture ridondanti di base
La **ridondanza statica** richiede che i moduli operino in parallelo tra di loro, che abbiano tutti lo stesso segnale di ingresso e che siano tutti attivi contemporaneamente. Le loro uscite sono connesse ad un semplice modulo di votazione che confronta i segnali e decide, a maggioranza, qual è il segnale di interesse tra quelli che ha in ingresso. In questo modo, $n$ moduli ridondanti possono tollerare un numero di guasti pari a $(n-1)/2$, con $n$ che è il numero di moduli ridondanti che deve essere dispari.
![](https://i.imgur.com/g7sunJB.png)
In questo caso stiamo parlando di una ridondanza secca basata su moduli che operano senza alcuna conoscenza diagnostica.

Se vado ad introdurre diagnosi, come posso rendere più efficiente la ridondanza? Come posso integrare l'informazione diagnostica in un modulo di ridondanza?

La **ridondanza dinamica hot standby** è un altro tipo di ridondanza in cui i moduli sono pesati in modo binario in base a se funzionano correttamente oppure no. Lo schema si complica un po'. Ci sono due moduli, entrambi operativi. Le loro uscite vanno nel modulo di fault detection (serebbe meglio fault isolation ma avendo due moduli va bene la detection): questo modulo determina quale dei due moduli sta funzionando correttamente e quale invece no. Questa informazione viene inoltrata ad un modulo di riconfigurazione, che di fatto è un comando che pilota uno switch, e in uscita viene fatto transitare il segnale del modulo che funziona correttamente. Supponiamo che i moduli siano due sensori, nel caso dell'immagine il sensore due ha avuto un problema, per cui il modulo se ne accorge e fa transitare il segnale del primo sensore. 
Questa ridondanza viene detta dinamica perchè c'è uno switch che, dinamicamente, alloca l'uno o l'altro. Nello specifico viene poi definita 'hot standby': standby è il modulo ausiliario, hot perché il modulo ausiliario è sempre operativo, ovvero i moduli non sono mutuamente esclusivi ma operano sempre entrambi.
![](https://i.imgur.com/gOzQyzb.png)

La **ridondanza dinamica cold standby** è un'alternativa che impatta ancor più positivamente sull'affidabilità. Utilizza non un modulo che funziona sempre in parallelo, ma un modulo che funziona solo a bisogno. Complichiamo ancora un po' lo schema. Il modulo uno sta funzionando e c'è una fault detection che va al modulo di riconfigurazione. Se il modulo uno smette di funzionare, questo viene disattivato e viene attivato in modulo due, cambiando lo stato dei due switch iniziali. Viene anche cambiato lo stato dello switch che fa passare l'uscita. La ridonzanza è sempre dinamica, ma è 'cold standby', perchè il modulo ausiliario opera solo alla presenza di un guasto. In pratica, si è introdotto un ulteriore stadio di riconfigurazione, al fine di preservare la vita del sistema, nello specifico la vita del modulo due, fintanto che non si verifica un guasto sul modulo uno.
![](https://i.imgur.com/6SCcCg5.png)

### Confrontro tra strutture ridondanti
Questa è la ridondanza dal punto di vista teorico. Ragioniamo sulle implicazioni di natura ingegneristica: quale tipo di ridondanza è più utile? La migliore è la ridondanza dinamica cold standby perchè, facendo lavorare solo un modulo alla volta, impatta positivamente sull'affidabilità del sistema, perchè una volta esaurito il tempo di vita del modulo uno, ho ancora tutto il tempo di vita del modulo due: praticamente raddoppio il tempo di vita utile del modulo che sta funzionando. Inoltre, a livello energetico, non alimentando entrambi i moduli risparmio energia (a livello pratico questo impatta di meno).
Invece quello che peggiora dalla ridondanza dinamica rispetto a quella statica è la complessità del sistema. Inoltre tra la dinamica cold e quella hot aumenta il numero di interruttori: oltre ad aumentare la complessità c'è un altro problema ovvero che posso aumentare le possibilità di guasto (anche gli interruttori si possono rompere). Inoltre, dal punto di vista fisico, gli interruttori non sono istantanei, quindi nel commutare introducono un ritardo. 'Cold' anche perchè un macchinario quando non lavora è freddo: quando viene attivato avrà comunque un piccolissimo transitorio e non darà subito la stessa uscita che dava l'altro modulo prima di guastarsi, ma servirà qualche decimo di secondo (caso migliore) o secondo (caso peggiore) prima di dare il segnale corretto. Da un punto di vista pratico, è importante che la commutazione dallo stadio di funzionamento con modulo uno a quello di funzionamento con modulo due sia tale da non pregiudicare il corretto funzionamento del sistema.
**Ricapitolando**: la ridondanza dinamica ha il grosso vantaggio di estendere notevolmente l'affidabilità del sistema con un numero minore di moduli, ma nel farlo introduce la complessità del modulo di fault detection (che comunque qualcuno deve pregettare) e va ad integrare degli switch il cui tempo di commutazione non è trascurabile.

In ogni caso, negli esempi le ridondanze dinamiche hanno due moduli, ma può essere implementata con un numero a piacere di moduli, così come la ridondanza statica.
Nella pratica, comunque, spesso si adottano schemi ibridi per poter compensare pregi e difetti delle varie configurazioni.


## Stadi di degradazione dei componenti
Quando il mio stadio ridondante va ad operare, quello che va a fare è sostituire il comportamento non corretto di un modulo con il comportamento corretto di un altro modulo.
A livello implementativo, si parla spesso di stadi di degradazione: si intende che al progettista incaricato del sistema è richiesto un grado di ridondanza, e quindi un grado di tolleranza ai guasti, che considera ingobro, peso, complessità e (soprattutto) costi. Non si va a ridondare all'infinito, ma ci sarà un massimo grado di tolleranza e ogni volta che un componente non funziona più, si degrada un modulo, si va in uno stadio di funzionamento degradato, dove gli stadi di degradazione del sistema sono divisi in quattro categorie:
* **Fail (F)**: a prescindere dal livello di ridondanza introdotto e dal numero di failure(s), il sistema smette di funzionare. È lo stadio di degradazione peggiore, in cui non ci dobbiamo MAI trovare, perchè il sistema è irrecuperabile.
* **Fail-Operational (FO)** è lo stadio diametralmente opposto al primo: una rottura di un componente è tollerata e il sistema continuerà a funzionare correttamente dopo quel failure. Questo è lo stadio in cui ci troviamo quando usiamo due moduli in ridondanza dimanica o tre moduli in ridondanza statica.
* **Fail-Safe (FS)** è uno stadio intermedio tra i due estremi: dopo uno o più failure(s) dei componente, il sistema possiede uno stato sicuro (passive fail-safe) oppure è portato in uno stato sicuro tramite un'azione speciale (active fail-safe). Un esempio, è il meccanismo di fail-safe attivo dei portatili legato alla temperatura del processore: quando si supera una temperatura di circa 90° il bios invia un segnale di shut-down e la macchina si spegne. È un sistema che non va a rottura, ma che smette di funzionare, anche se solo temporaneamente.
* **Fail-Silent (FSIL)** è un altro stadio intermedio che si trova tra il fail e il fail-safe: dopo uno o più failure(s) dei componenti, il sottosistema rotto rimane inattivo verso l'esterno (es. si spegne e non influenza gli altri sottosistemi in modo negativo) e il sistema complessivo opera con performance degradate. 

Questi sono gli stadi che si possono verificare, dove quelli che possono essere codificati grazie all'operazione di tolleranza solo il fail e il fail-operational. Generalmente si richiede che ci sia un peggioramento delle prestazioni del sistema associato di volta in volta alle operazioni non critiche: quando non ci sono guasti tutto deve funzionare perfettamente, quando ci sono i guasti si possono tollerare dei cali di performance su quelle funzioni che sono meno critiche, lasciando le critiche (che riflettono il corretto funzionamento del sistema) per ultime.

Nel video di esempio del drone, ad un certo punto un'elica smette di funzionare e si vuole garantire l'atterraggio del drone. Al momento della rottura, il drone inizia a ruotare su se stesso ma il controllore accetta questa condizione. Il drone con 4 motori può dare 4 spinte, quindi controlla 4 gradi di libertà, ovvero l'altezza, il roll, il pitch e lo yaw. Se i motori diventano 3, non posso più controllare un grado di libertà: non posso smettere di controllare l'altezza, nè il roll o il pitch (il drone si muoverebbe lateralemente o avanti e indietro) e non riuscirei più a comandarlo per farlo andare dove voglio. Quindi sacrifico la rotazione, perchè è quello meno critico, serve solo per mantenere stabile la telecamera. Le performance si degradano ma le operazioni critiche rimangono intatte. 

La ridondanza va a fare esattamente questo:
![](https://i.imgur.com/MWjolXO.png)
* nella ridondanza statica con 2 moduli tollero 0 fault (la formula è $(n-1)/2$, se n=2 ho un valore minore di 1). Ho uno stadio di degradazione fail (F): se arriva una rottura sul modulo, il sistema smette di funzionare. Se avessi ridondanza dinamica, invece, posso tollerare 1 fail. Sono nello stadio di degradazione fail-operational alla prima rottura, fail alla seconda (ho comunque 2 moduli).
* se ho 3 moduli con ridondanza statica tollero 1 fail e sarò fail-operational/fail; con ridondanza dinamica tollero due guasti e sarò FO/FO/F.
* il discorso è analogo per le altre strutture

![](https://i.imgur.com/QtlafDv.png)
Qui abbiamo un esempio di Triplex con ridondanza statica, quindi quello a 3 moduli. Abbiamo anche un esempio di Duo-duplex sempre statico: ci sono due moduli a due, dove a loro volta votano sulle uscite di ogni singolo modulo binario.

## Ridondanza hardware e ridondanza analitica (o software)
> La **ridondanza hardware** fa affidamento su misure provenienti da due o più componenti identici tra di loro (es: è quella vista nella ridondanza sia statica che dinamica viste in precedenza).

> Nella **ridondanza analitica** o software le misure sono provenienti da uno o più componenti (anche diversi tra di loro) e da un insieme di relazioni analitiche.

In questo secondo caso vado a sostituire uno o più moduli con l'informazioni proveniente da un modello. Da qui ridondanza 'software': un modulo viene elaborato via software tramite le informazioni provenienti dagli altri moduli hardware. Questo si fa trasformando una schema di ridondanza hardware utilizzando un nodo software che crea un modulo chiamato 'modulo virtuale'.
Nel caso dei sistemi a ridondanza hardware, rispetto a quelli analitici:
* funziona meglio perchè c'è più hardware. La capacità di individuazione dei guasti è maggiore. 
* una volta rilevato il guasto, è possibile fare affidamento sui componenti fisici ridondanti per consentire al sistema di funzionare correttamente: se il guasto è su un attuatore, la ridondanza hardware mi permette di sfruttare anche la capacità di attuazione (cosa impossibile da fare con un sensore virtuale).
* si ottiene maggiore affidabilità ma aumentano costi e ingombro complessivo. Per questo, molto spesso, soprattutto nei sistemi di piccole dimensioni o di basso costo, vengono integrati oltre ai moduli hardware di ridondanza, anche dei moduli analitici.

### Ridondanza analitica nei sensori
![](https://i.imgur.com/lmDLIo1.png)

Supponiamo di avere un ingresso di cui non conosciamo l'ingresso $u$, ma abbiamo a disposizione le misure dei segnali di uscita $y_1$ e $y_2$. Se si conoscono i modelli dei sottoprocessi $G_{M1}$ e $G_{M2}$, allora io posso ottenere una stima del segnale proveniente dal sensore $\hat y_1$, da confrontare con l'uscita $y_1$ per capire se c'è un guasto. La stima $\hat y_1$ sarà semplicemente $y_2*\frac{G_{M1}}{G_{M2}}$. Quindi il blocco in basso è uno stimatore in forma analitica.

![](https://i.imgur.com/px87ZaM.png)
Altro esempio. Supponiamo di avere la misura dell'ingresso $u$ e misuro un'uscita sola $y_1$. Se conosco il modello, posso ottenere la stima del segnale uno $\hat y_1$ da confrontare con il segnale proveniente dal sensore, che sarà $u*G_{M1}$, ovvero il segnale di ingresso per la funzione del processo.

Dall'unione di questi due schemi, otteniamo:
![](https://i.imgur.com/eTAyWXf.png)
Con un voter, otteniamo uno schema di ridondanza in cui il secondo e il terzo ramo sono stati ottenuti tramite ridondanza analitica. In questo modo ho due sensori ma tre misure, di cui una è completamente virtuale. La presenza di tre valori permette di individuare il guasto, isolarlo e scegliere quale valore utilizzare come alternativa.
Questo schema è simile ai metodi di rilevamento guasti basati su modello. Questa ridondanza cerca delle informazioni basandomi sui modelli. Quindi questi sono dei metodi analoghi a quelli visti per andare a creare i residui, quindi le feature basate sul rilevamento model-based: ricostruisco la stima dell'uscita basandomi sul modello. Non a caso la diagnosi model-based viene anche detta diagnosi che sfrutta la ridondanza analitica.
La ridondanza analita consiste nello sfruttare le relazioni funzionali per creare delle variabili da confrontare con le misure.

## Attuatori tolleranti ai guasti
Finchè parliamo di sensori, si possono utilizzare quelli virtuali, ma ciò non è possibile quando parliamo di attuatori: non esistono gli adattatori virtuali! Gli attuatori richiedono sempre la ridondanza hardware, mentre per i sensori si possono abbattere i costi introducendo la ridondanza analitica.
![](https://i.imgur.com/jdlGUF4.png)

## Comunicazione tollerante ai guasti
Immaginiamo un sistema industriale: è formato da tante macchine che lavorano in parallelo che sono collegate al bus su cui girano tante informazioni. È chiaro che non solo l'attuazione e la sensoristica devono avere ridondanza, ma anche lo stesso bus di comunicazione deve essere ridondante. Se ho un bus solo e c'è un problema, salta tutta la comunizione. Quando si progetta un sistema industriale complesso:
* si usano più bus di comunicazione 
* ognuno dei bus deve avere la sua alimentazione seperata
* deve connettere tutti i nodi del sistema
* devo avere una logica per la gestione distribuita degli accessi multipli (ingegnere delle telecomunicazioni)

## Controllo tollerante ai guasti
Con controllo tollerante ai guasti intendiamo ciò che abbiamo visto nell'esempio del drone: perde un attuatore ma deve comunque atterrare nel punto desiderato, e questo è un problema di fault-tolerant control. Quindi il controllo tollera il guasto andando a modificare il funzionamento della legge di controllo.
Queste sono forme che mi permettono di andare a risolvere il problema in fase operativa, andando a progettare un design fault-tolerant a livello di controllo.

A controllo non lineare si è visto che i controllori oltre ad essere progettati nel caso nominale, devono anche essere in grado di tollerare un certo tipo di disturbi: concetto di robustezza di un'azione di controllo. Robustezza significa tollerare un disturbo, un'incertezza. Il guasto se è moltiplicativo è un'incertezza su un parametro, ma se è additivo è qualcosa che si somma all'uscita o allo stato. Quindi è qualcosa che viene trattato dal controllore come un disturbo. Se si opera con un sistema in retroazione, quindi, è possibile che piccoli fault additivi o moltiplicativi possano essere tollerati dall'azione compensatrice dell'unita di controllo. Se io progetto una legge di controllo che è molto robusta, ad esempio ad un'incertezza paramentrica o ad un disturbo additivo, quella legge di controllo sarà in grado di tollerare il fault: in questo caso di parla di controllo tollerante ai guasti di **tipo passivo**. Significa che il guasto è trattato alla stregua di un disturbo e viene trattato dal sistema di controllo grazie alla sua robustezza. Questa è una delle tipologie di controllo che possono essere attuate per tollerare i guasti.
L'altra consiste nel mettere un modulo diagnostico che va a fare rilevamento, isolamento e diagnosi del guasto, che va a pilotare un modulo di riconfigurazione che mi switcha tra un controllore nominale e un controllore che è in grado di tollerare quella particolare tipologia di guasto. Nel momento in cui il controllore introduce una politica di switching, si parla di controllo tollerante ai guasti di **tipo attivo**.
![](https://i.imgur.com/QCwsjws.png)

### Confronto
Il controllo robusto ha il vantaggio che noi progettiamo un'unica legge di controllo che va bene sia nel caso di sistema nominale, sia nel caso di sistema funzionante con un guasto. Lo svantaggio è che le prestazioni medie del sistema a ciclo chiuso non sono ottimali perchè il sistema è progettato con una legge che non dà gli effetti desiderati massimi che si potrebbero ottenere. Questo perchè si tiene sempre un po' di margine per poter gestire il disturbo che entra nel sistema.
La logica attiva ha il vantaggio che, grazie allo switching, potrò customizzare un controllore ad-hoc per ogni tipologia di guasto, e quindi ottenere le massime prestazioni possibili per ogni tipologia di guasto. Lo svantaggio è che devo andare a garantire un numero di leggi pari al numero di guasti e dovrò garantire che il tempo di commutazione tra una legge e l'altra sia sufficientemente rapido da mantenere il sistema controllabile per tutta l'entità del tempo.
In conclusione, il controllo di tipo passivo vale solo per piccoli fault e richiede un buon trade-off tra prestazioni nel caso nominale e robustezza. 
Quando i guasti sono di entità maggiore non è più possibile compensarli con un approccio passivo: si passa ad un controllo attivo, accettando una degradazione limitata delle performance.

Questo aspetto è molto importante soprattutto per quanto riguarda la robotica perchè significa che il robot è in grado di portare avanti le proprie azioni anche quando succede qualcosa di imprevisto. Il robot che lavora su Marte deve essere tollerante ai guasti dato che non è possibile pianificare una manutenzione a distanza.

## Domande di riepilogo
* In quali modi è possibile progettare una struttura ridondante? *Abbiamo visto che ne esistono due, ovvero statica e dinamica, la quale può essere hot standby o cold standby.*
* Specificare quali sono le differenze tra gli stadi di degrazione (che valgono per entrambi i tipi di ridondanza). *Questi sono fail-safe, fail-operational e fail-silent. La ridondanza dinamica ha maggiore capacità di tolleranza ma questo si paga con una maggiore complessità dello schema di ridondanza.*
* Quando andiamo a controllare un sistema affinchè sia tollerante ai guasti abbiamo due possibilità: descrivere la differenza tra una struttura di controllo tollerante ai guasti di tipo passivo e una di tipo attivo. *Politica di switching del controllo attivo (più efficace ma con maggiore sforzo di design) vs. approccio robusto passivo che richiede meno sforzo di design ma è meno efficace.*
* Descrivere la differenza tra una struttura a ridondanza analitica e una a ridondanza hardware. *Nel caso della ridonzanza analitica, sfruttuamo la conoscenza del modello (euristica o quantitativa) per creare delle grandezze con cui confrontare le uscite reali con quelle virtuali. Questo può essere sfruttato per andare a fare rilevamento guasti, oppure per fare ridondanza di tipo analitico.*



![](https://i.imgur.com/7m8PzeD.png)
(Di questi non ne ha parlato, non so se possono essere esercizi che chiede all'esame).
