
Introduzione:
I prodotti (sistemi) critici dovrebbero essere sicuri, affidabili e di facile manutenzione. Infatti, gli standard relativi a RAMS (Reliability, Availability, Manutenibilità e Sicurezza) stabiliscono le analisi RAMS che dovrebbero essere condotte in ogni fase del processo di progettazione ingegneristica del sistema (modello V), a partire dall'allocazione dell'affidabilità nella fase di progettazione iniziale, fino a analisi delle modalità di guasto e degli effetti del progetto completo e analisi della sicurezza.
Ad esempio, MIL-STD-1629A afferma: "La modalità di guasto, gli effetti e l'analisi della criticità (FMECA) è una funzione essenziale nella progettazione, dall'ideazione allo sviluppo", e: "La tempestività è forse il fattore più importante nella differenziazione tra efficaci e l'attuazione inefficace del FMECA”.
Inoltre, le analisi RAMS sono richieste nella maggior parte delle gare d'appalto per sistemi mission e safety critical.
Problema:
Sebbene le analisi RAMS siano obbligatorie, spesso vengono rimandate a fasi di progettazione avanzate quando la loro efficacia sulla progettazione del sistema è notevolmente ridotta. Questa cattiva abitudine può essere compresa dal momento che i gestori di programma e gli ingegneri di sistema hanno abbastanza da fare senza dover occuparsi di RAMS.
Questo atteggiamento va bene fino a quando un problema RAMS critico non si presenta in una fase avanzata della progettazione o porta a guasti sul campo.
Ecco alcuni esempi che abbiamo incontrato durante molti anni di attività:
- Una scheda elettronica critica è risultata progettata in modo inadeguato: a un componente è stata applicata una potenza elevata, causando il guasto della scheda sul campo. Ciò avrebbe potuto essere evitato mediante l'analisi del declassamento dei componenti.
- Un sistema è stato progettato per avere il backup in standby a freddo, ma il tempo di attivazione dell'unità di backup era troppo lungo. Di conseguenza, la progettazione del sistema non è stata in grado di fornire la disponibilità richiesta ed è stata necessaria una profonda riprogettazione.
- La testabilità del sistema non era in linea con il concetto di manutenibilità: alcune parti dovevano essere sostituibili in loco, ma il test integrato non era in grado di identificare quale parte doveva essere sostituita.
Soluzione:
Il software di BQR riduce al minimo lo sforzo necessario per condurre analisi RAMS all'inizio della fase di progettazione e per aggiornare le analisi man mano che la progettazione procede. Ciò si ottiene utilizzando:
- Plug-in per ECAD (raccogliere i dati di progettazione per l'analisi RAMS):
- Rapida verifica ed esportazione della distinta base
- Assegnazione dello stress (potenza, tensione, corrente)
- Assegnazione delle funzioni e delle modalità di guasto
- Generatore di nomi standard di netlist
- Librerie per il riutilizzo dei dati:
- componenti
- Funzioni
- Modalità di fallimento
- Database RAMS di progetto centralizzato
- Software integrato per:
- Analisi del derating dei componenti
- Allocazione e previsione dell'MTBF
- FMEA / FMECA
- FMEDA / Analisi di testabilità
- FTA
- Assegnazione e previsione RBD
- Manutenibilità e analisi del supporto logistico