it
Contact US
it
DO Standards

Certificazione e Processi RTCA DO-254 & Fasi di Progettazione

RTCA DO-254, “Design Assurance Guidance For Airborne Electronic Hardware”, è la linea guida principale per produrre hardware elettronico aerotrasportato la cui versione più recente è stata pubblicata nel 2000. RTCA DO-254 specifica i requisiti del ciclo di vita di progettazione per i sistemi avionici e fornisce linee guida per l’aeronavigabilità dell’hardware elettronico degli aerei. DO-254, come DO-178, è stato rilasciato anche in collaborazione con RTCA e EUROCAE. DO-254, nel 2005, è stato formalmente accettato dalla FAA per rispondere all’uso crescente di varie apparecchiature elettroniche nei sistemi aerotrasportati.

La conformità a DO-254 aiuta a migliorare la sicurezza di passeggeri, equipaggio e operatore, rafforza il tuo business. Inoltre, offre alla tua azienda un vantaggio competitivo poiché alcuni progetti richiedono la conformità a DO-254, e avrai un vantaggio sugli altri produttori e sviluppatori che non la forniscono.

I principali processi per la certificazione DO-254 possono essere riassunti come

  1. Processo di Pianificazione (Planning Process)
  2. Processo di Sviluppo (Development Process)
  3. Processo di Correttezza (Correctness Process)

È importante notare che il processo di sviluppo dovrebbe iniziare dopo il completamento del processo di pianificazione, mentre il processo di correttezza dovrebbe essere eseguito in tutto il progetto.

Gli standard DO-254 devono essere soddisfatti da documenti come:

  • PHAC (Plan for Hardware Aspects of Certification)
  • HVP (Hardware Verification Plan)
  • HVP (Hardware Validation Plan)
  • HPAP (Hardware Process Assurance Plan)
  • HAS (Hardware Accomplishment Summary)

Alcuni documenti DO-254 possono assomigliare ai documenti DO-178. Le nostre checklist DO-178 sono disponibili per la revisione e l’acquisto qui.

Documenti DO254

PHAC

PHAC (Plan for Hardware Aspects of Certification) dovrebbe essere prodotto nel processo di pianificazione e approvato dall’autorità. PHAC riflette un accordo tra il richiedente la certificazione e l’autorità di certificazione sulle procedure e le azioni da svolgere, così come le prove risultanti da generare, al fine di soddisfare gli aspetti hardware della certificazione. Nel contesto di questo piano, lo sviluppatore descrive la sua strategia e come DO-254 è implementato. Per controllare il nostro documento PHAC, clicca qui.

Piano di Verifica & Validazione Hardware

Il Piano di Verifica Hardware verifica se l’hardware soddisfa le specifiche di progettazione. Il Piano di Validazione Hardware, d’altra parte, è utilizzato per verificare che l’hardware soddisfi le esigenze operative dell’utente. La distinzione fondamentale tra verifica e validazione, come indicato nelle definizioni precedenti, è l’ambiente in cui vengono eseguiti i test. L’accuratezza del progetto viene verificata rispetto alle specifiche di progettazione in un flusso di verifica. L’accuratezza del progetto viene valutata rispetto alle esigenze dell’utente previsto durante il flusso di validazione. Anche questi documenti dovrebbero essere preparati come parte del processo di pianificazione.

HPAP

HPAP (Hardware Process Assurance Plan) verifica se i processi del ciclo di vita di progettazione dell’hardware e i dati sono definiti e conformi anche ai piani approvati. I metodi per soddisfare gli obiettivi di assicurazione della progettazione dell’hardware, inclusi le strategie definite, vengono proposti all’autorità di certificazione. [Per controllare il nostro documento HPAP, clicca qui].

HAS

HAS (Hardware Accomplishment Summary) informa l’autorità di certificazione su ciò che è stato realizzato sul lato hardware. La differenza tra PHAC e HAS è che, con PHAC hai detto all’autorità di certificazione cosa avevi intenzione di fare, mentre con HAS dici loro cosa hai effettivamente fatto. HAS dovrebbe anche specificare eventuali deviazioni dal PHAC approvato. HAS dovrebbe comprendere informazioni sull’identificazione dell’hardware, lo stato dell’hardware, la cronologia delle versioni e la dichiarazione di conformità. Sembra anche Software Accomplishment Summary, che è una checklist per la conformità a DO-178. Dovrebbe contenere le seguenti sezioni; panoramica del sistema e dell’hardware, descrizione del ciclo di vita di progettazione dell’hardware, dati del ciclo di vita dell’hardware. Per controllare il nostro documento HAS, clicca qui.

Fasi di Progettazione

Fase di Progettazione Preliminare

La progettazione preliminare inizia con la baseline funzionale stabilita durante la progettazione concettuale e progredisce nel lavoro di tradurre le esigenze funzionali a livello di sistema in requisiti di progettazione per i sottosistemi che saranno uniti per formare il sistema. Questa traduzione richiede la continuazione dell’analisi dei requisiti iniziata nella progettazione concettuale. Devono essere definiti i bisogni specifici dell’hardware, del software e del personale del sistema. Vengono effettuate analisi di compromesso, e il lavoro di progettazione preliminare risulta nella costruzione di una baseline allocata, in cui i bisogni sono assegnati ai singoli sottosistemi che compongono il sistema.

Fase di Progettazione Critica

La fase di progettazione critica è un processo tecnico multidisciplinare che assicura che un sistema possa procedere alla fabbricazione, dimostrazione e test mentre soddisfa i criteri di prestazione dichiarati entro vincoli di costo, tempo e rischio. La baseline del prodotto viene inizializzata durante la fase di progettazione critica. L’obiettivo della progettazione critica è valutare il design finale di un sistema come definito nelle specifiche del prodotto per ogni elemento di configurazione nella baseline del prodotto del sistema e confermare che ogni elemento di configurazione sia stato incluso nella documentazione di progettazione dettagliata.

La fase di progettazione critica si completa conducendo la Revisione della Progettazione Critica. CDR assicura che il sistema possa procedere ai test e alla produzione. Esprime anche che i requisiti menzionati possono essere soddisfatti entro il budget e la tempistica. I disegni e le specifiche complessive che ne derivano forniscono una baseline iniziale del prodotto, con una baseline finale. CDR dovrebbe essere completo ed esaustivo.

Fase di Progettazione Finale

La Fase di Progettazione Finale include disegni architettonici e tecnici precisi di ogni componente del progetto. Potrebbe essere importante generare un rapporto di progettazione finale per alcuni progetti. Prima di completare il processo di progettazione finale, tutti i problemi di progettazione rilevati devono essere risolti. I disegni e il rapporto devono essere abbastanza dettagliati per fornire stime relativamente accurate dei costi di costruzione e operativi, nonché delle tempistiche di costruzione. Un calendario rivisto, stime dei costi e requisiti dovrebbero essere inclusi nel rapporto di progettazione finale. Dovrebbe anche essere autorizzato che il progetto sia finanziariamente fattibile. Qualsiasi modifica apportata durante la Fase di Progettazione Finale è più costosa rispetto a quelle effettuate durante le fasi precedenti. Di conseguenza, dovrebbe essere fatto con grande cura.

Can Önal ([email protected])

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound

For a Second Chance

Cart Overview