Gli standard di certificazione software DO-178B e DO-178C fungono da linea guida per produrre sistemi aerotrasportati idonei al volo. DO-178B (Considerazioni Software nei Sistemi e nell’Attrezzatura Aerotrasportati per la Certificazione), pubblicato per la prima volta nel 1992, era il documento predominante preso in considerazione per ottenere la certificazione da autorità come l’EASA (Agenzia Europea per la Sicurezza Aerea) e la FAA (Federal Aviation Administration) per i sistemi aerotrasportati basati su software commerciale. Tuttavia, i Regolamenti Federali dell’Aviazione hanno riconosciuto DO-178C come un metodo per dimostrare la conformità all’aeronavigabilità nel 2013. Per ulteriori informazioni generali sugli standard DO-178B e DO-178C, puoi leggere questo articolo.
Gli standard DO-178B o DO-178C devono essere soddisfatti da documenti come:
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
uesti non sono gli unici documenti richiesti per soddisfare gli standard DO-178B e DO-178C. Ci sono un gran numero di altri documenti per arricchire l’aeronavigabilità. Puoi controllare e acquistare questi documenti da qui.
Documenti DO178
Documento PSAC – Plan for Software Aspects of Certification
Il documento PSAC descrive gli standard, i processi, i protocolli e le metodologie necessari da seguire, oltre a illustrare i dati del ciclo di vita. In questo modo, possono essere raggiunti gli obiettivi dei documenti DO-178. PSAC specifica anche il programma di sviluppo software e la panoramica del sistema. Sia l’autorità certificante che il richiedente utilizzano questo documento. PSAC dovrebbe essere prodotto nel processo iniziale di pianificazione del software e approvato dall’autorità. Per verificare il nostro Documento PSAC, clicca qui.
Documento SDP – Software Development Plan
Il documento SDP (Piano di Sviluppo Software) mira a verificare se sono specificate informazioni necessarie come procedure di sviluppo software, protocolli, standard, cicli di vita e ambiente di sviluppo. Il documento SDP è una parte essenziale del periodo di pianificazione del software. Per verificare il nostro Documento SDP, clicca qui.
Documento SVP – Software Verification Plan
Il documento SVP (Piano di Verifica Software) specifica i casi di test necessari e le coperture, procedure, protocolli, verifica dei requisiti, verifica del codice sorgente con un adeguato controllo delle versioni. Anche SVP è un elemento chiave del processo di pianificazione. Per verificare il nostro Documento SVP, clicca qui.
Documento SCMP – Software Configuration Management Plan
Il documento SCMP (Piano di Gestione della Configurazione Software) è un altro aspetto fondamentale del periodo di pianificazione. Durante il processo di sviluppo del software, spesso accade che il piano iniziale cambi. SCMP ci aiuta a rilevare, controllare, mantenere e tracciare questi cambiamenti. Viene applicato durante tutto il processo di sviluppo del software. SCMP mira a minimizzare gli errori e massimizzare la produttività. I membri del team devono impegnarsi a segnalare e notificare i cambiamenti. Per verificare il nostro Documento SCMP, clicca qui.
Documento SQAP – Software Quality Assurance Plan
Il documento SQAP (Piano di Assicurazione della Qualità Software) include strumenti, metodi e tecniche utilizzati per garantire che un prodotto o servizio soddisfi le specifiche date nell’SRS (Specifiche dei Requisiti Software). SQAP spiega come verranno condotte le Attività di Assicurazione della Qualità Software nel progetto. Il team SQA stabilisce traguardi e valuta la qualità del progetto ad ogni traguardo. L’SQA viene condotta durante tutto il ciclo di vita del software. Per verificare il nostro Documento SQAP, clicca qui.
Documento SAS – Software Accomplishment Summary
Il documento SAS (Riepilogo dei Risultati Software) riassume ogni fase dei componenti software durante lo sviluppo e la verifica. SAS dovrebbe includere il riassunto dei risultati della qualificazione degli strumenti di verifica. La FAA deve essere informata del SAS. Ciò consente all’autorità di certificazione di validare i risultati dei dati di verifica e funge da prova dello stato di qualificazione dello strumento. Per verificare il nostro Documento SAS, clicca qui.
Gli Standard ARP4754 e Gli Standard DO178
ARP4754 sta per “Prassi Consigliata nell’Aerospazio ARP4754A Linee Guida per lo Sviluppo di Aerei Civili e Sistemi”. Gli Standard ARP4754 forniscono indicazioni per sistemi aerei completi, mentre gli Standard DO178 sono utilizzati per il software di volo. Entrambi gli standard sono accettati da autorità come la FAA e l’EASA.
ARP4754 è stato sviluppato e pubblicato dalla SAE (Society of Automotive Engineers) nel 1996. Nel 2010 la SAE ha pubblicato ARP4754A che sta per Linee Guida per lo Sviluppo di Aerei Civili e Sistemi. ARP4754A amplia l’idea dell’assicurazione della progettazione per l’utilizzo ai livelli di aereo e sistema, nonché standardizza l’uso del termine assicurazione dello sviluppo. ARP4754 è stato riconosciuto dalla FAA nel novembre 2011.
Dal requisito all’integrazione e alla verifica, ARP4754 copre l’intero ciclo di sviluppo dell’aereo. ARP4754 fornisce un’astrazione per aereo, sistema e componente. Per la progettazione del componente, ARP4754 fa riferimento esplicito a DO-178 e DO-254. ARP4754 si concentra sulla valutazione della sicurezza attraverso diversi processi come lo sviluppo, la progettazione e la verifica. Tuttavia, va notato che ARP4754 non include l’ambito specifico dello sviluppo di software o hardware elettronico, le attività di sicurezza in servizio e lo sviluppo strutturale dell’aereo.
Fasi di Progettazione
Revisione Preliminare della Progettazione- Preliminary Design Review (PDR)
La progettazione preliminare è una fase essenziale del processo di sviluppo del software. Durante la progettazione preliminare, vengono specificati requisiti di alto livello e casi d’uso per costruire l’architettura del sistema. Documenti per interfaccia, database, architettura e diagrammi per le relazioni tra componenti possono essere utilizzati nella progettazione. La progettazione preliminare offrirà una rappresentazione visiva del sistema all’inizio del progetto basata su questi input. La progettazione preliminare crea anche le basi per le seguenti fasi di progettazione più dettagliate. Può essere vista come un progetto.
La Revisione Preliminare della Progettazione (PDR) conclude la fase di progettazione preliminare del progetto. Per procedere con la progettazione dettagliata, la PRD dovrebbe offrire sufficiente assicurazione. Lo scopo della PDR è garantire che la progettazione preliminare e l’architettura di base del sistema siano complete, che ci sia fiducia tecnica che i requisiti possano essere soddisfatti entro il budget e la tempistica.
Revisione della Progettazione Critica – Critical Design Review (CDR)
La Revisione della Progettazione Critica (CDR) conclude la fase di progettazione critica del progetto. I progetti finali vengono presentati con CDR attraverso analisi approfondite, simulazioni, schemi, codice software e dati di test. CDR assicura che il sistema possa procedere con i test e la 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 base di prodotto iniziale, con una base finale. CDR dovrebbe essere completo ed esaustivo.
Fase di Progettazione Finale – Final Design Phase
La Fase di Progettazione Finale fornisce disegni architettonici e ingegneristici dettagliati di ogni componente nel progetto. Per alcuni progetti, potrebbe essere necessario creare un rapporto di progettazione finale. I problemi di progettazione rilevati devono essere risolti prima di concludere la fase di progettazione finale. I disegni e il rapporto devono offrire dettagli sufficienti per consentire stime ragionevolmente accurate dei costi di costruzione e di esercizio, nonché della tempistica di costruzione. Il rapporto di progettazione finale dovrebbe includere una tempistica aggiornata, stime dei costi e specifiche. Inoltre, dovrebbe essere approvato che il progetto sia economicamente fattibile. Qualsiasi cambiamento durante la Fase di Progettazione Finale è più costoso rispetto ad altre fasi. Pertanto, dovrebbe essere effettuato con molta attenzione.
SOI (Stages of Involvement)
Le valutazioni degli Stadi di Coinvolgimento (SOI) vengono effettuate dalle autorità di aviazione dei paesi rilevanti in varie fasi del progetto come pianificazione, sviluppo e verifica per valutare la conformità dei progetti DO-178B. In casi ideali, sono previste un totale di quattro revisioni SOI.
La valutazione iniziale, che è il primo SOI, include la fase di pianificazione degli studi di conformità alla certificazione del progetto. La seconda revisione SOI si concentra sulle fasi di sviluppo del progetto. A partire dallo sviluppo dei requisiti software di fascia alta, si interroga se la progettazione, i requisiti software di basso livello e il codice sorgente siano prodotti in conformità con DO178B. La terza revisione SOI si concentra sulle fasi di validazione. Non solo le attività di test, ma tutte le attività svolte a fini di verifica vengono esaminate. Il quarto SOI, invece, è la valutazione finale condotta vicino alla fine del progetto, domandando se ci sia qualche attività rimasta aperta e se sia emerso un nuovo problema dalle valutazioni precedenti.
L’aspettativa di DO-178B dai prodotti software prodotti durante la fase di pianificazione è di concordare un insieme di regole comune tra l’autorità e l’azienda che lo realizza e di attenersi a questo insieme di regole per tutto il progetto. In altre parole, quando si scrivono piani e standard, l’azienda non solo determina i propri processi ma scrive anche le regole per come l’autorità valuterà se stessa durante il processo di certificazione.
Autore: Can Önal ([email protected])
Mor Teknoloji
