Aereo software di bordo

Lo scopo principale dei documenti e degli standard normativi è fornire materiale guida da utilizzare nei processi di creazione del software per i sistemi di bordo degli aeromobili, che deve svolgere funzioni appropriate con un livello di sicurezza che soddisfi i requisiti per l'aeronavigabilità degli aeromobili.

Tra gli strumenti internazionali che prevedono requisiti software AT è il documento più importante DO-178, prima formulata nel 1978 Attualmente viene utilizzato versioni migliorate: DO-I78A, in vigore dal citta 1985, e DO-I78B, in vigore dal 1993 , in cui grande attenzione è rivolta alla questione della qualifica di strumenti software.

In Ucraina e in Russia, ci sono analoghi di questi documenti: rispettivamente CT 178A con la città 1998 e CT 178V con 2004, l'aggiunta a questi requisiti di idoneità sono documenti 178A RM e RM-178V.

Tra la serie di norme ISO, attiva in Ucraina e relativo software, è dominata da due: DSTU ISO 9000-3-98 e DSTU 3918-1999 (ISO / IEC 12207: 1995). Il primo è dedicato alla organizzazione e le attività del sistema qualità in relazione al software, il software di ciclo di vita del secondo processo. I requisiti delle norme ISO direttamente correlate a sole procedure di certificazione e dei suoi componenti, comprese le procedure di certificazione software.

Inoltre, la certificazione delle imprese industria aeronautica, in questo caso, i processi di produzione di creazione e applicazione software utilizzato Armak documento cioè punto "Elemento 21.2" orientamenti 3S ". La garanzia della qualità del software ", che è diviso in due parti:" Parte A. Il software a bordo "e" Parte B:. Software per l'accettazione dei prodotti "

Software si riferisce al software di bordo dei sistemi elettronici delle Forze Armate, che comprende parte della base di certificazione delle forze armate di un certo tipo e installato a bordo al fine di svolgere le funzioni necessarie per il funzionamento delle Forze Armate. Sistemi software progettati, ad esempio, per testare il Sole, anche se installato a bordo del velivolo non è in volo, e si riferisce al processo di creazione di strumenti di AT.

Dal momento che le funzioni dei sistemi digitali onboard sono implementati via software, quest'ultimo è oggetto di particolare attenzione dell'organismo di certificazione a causa del suo impatto diretto sulla sicurezza della navigazione aerea.

Criticità dei sistemi di bordo funzionali e livello software. L'obiettivo principale delle procedure di certificazione - è, prima di tutto, per ottenere determinate garanzie di sicurezza: prevenzione della morte, infortunio, malattia, perdita di proprietà. L'inizio di certificazione per qualsiasi sistema tecnico complesso è quello di analizzare le possibili implicazioni della perdita (impairment) delle funzioni del sistema sulla sicurezza del suo funzionamento o utilizzare per l'uomo e la proprietà. E non importa cosa ha causato la disfunzione - errore dell'utente, guasti hardware o errori di progettazione del software. Importanti sono sistema di controllo della profondità, l'identificazione e la capacità di parare mezzi rimbalzo del sistema o il sistema di un livello più alto della gerarchia, la necessità di ridondanza, riconfigurazione. Per analizzare le conseguenze della violazione delle funzioni del sistema, di regola, si deve andare indietro più volte, dopo le seguenti operazioni, come la corretta definizione della categoria di gravità dipende dai requisiti di rigidità per il software.

Documento CT 178V definisce cinque categorie di gravità dei sistemi funzionali e, quindi, cinque livelli di software. Nonostante il fatto che per alcune categorie di sistemi critici e livello software sono rigidamente collegati, il processo di stabilire livelli di tolleranze ammesse in uno o l'altro lato.

Software livello di classificazione categorie come segue criticità:

In un livello - su tale funzionali condizioni di errore di sistema, emersa a causa di un errore del software potrebbe portare ad una situazione catastrofica per il sole quando è praticamente impossibile impedire la morte del sole e le persone. La probabilità di una tale situazione, un'ora di volo da essere quasi incredibile, t E. Meno 10 ~ 9.;
I livelli nel software di un sistema funzionale tale, cui esenzione stato, sorto a causa di un errore del software, può portare ad una situazione di emergenza per il sole situazione di emergenza caratterizzata da un significativo deterioramento delle caratteristiche del sole o superamento delle limitazioni limite, così come tale stress fisico dell'equipaggio di volo, in cui non può accuratamente ed integralmente svolgere le sue funzioni. Una situazione di emergenza può portare a gravi danni al sole, o le lesioni personali singole vittime. La probabilità di una tale situazione, un'ora di volo per essere altamente improbabile, per esempio, essere nel range di 10 M0 ~ 9 ..;
ON livello da - a un sistema funzionale tale, cui esenzione stato, sorto a causa di un errore del software, può portare ad una situazione difficile per il sole La situazione complessa caratterizzata da un caratteristiche deterioramento sole marcate, l'uscita di uno o più parametri delle limitazioni operative, ma senza raggiungere i vincoli limite e una diminuzione della capacità del personale per far fronte a questa situazione causa della maggiore carico di lavoro e causa di condizioni sfavorevoli che riducono l'efficienza azioni tecnico . Situazione difficile può causare disagio ai passeggeri, anche eventualmente lesioni. La probabilità di una situazione difficile per un'ora di volo è poco probabile, cioè, essere nel range di 10 5-10-7 ..;
Secondo il livello D - in modo funzionale condizioni di errore di sistema, emersa a causa di un errore del software potrebbe portare ad una complicazione delle condizioni di volo per aeromobili. Questa situazione è caratterizzata da un lieve peggioramento del sole o un leggero aumento del carico di lavoro dell'equipaggio. Questa situazione può essere evitata, per esempio cambiando il piano di volo, e per i passeggeri, non dovrebbe portare a più di alcuni inconvenienti;
A seconda del livello di E - su questo sistema funzionale, che l'esenzione Stato, sorto a causa di un errore nel software non influenza le capacità operative delle Forze Armate e non aumenta il carico sulla equipaggio. Ottenere dal ente di certificazione per confermare che il software appartiene al livello E, ciò significa che le disposizioni del documento CT 178V non si applicano a lui.

Documento CT 178A definisce tre categorie di funzioni critiche di bordo sistemi aeronautici:

essenziale se una situazione particolare che potrebbe sorgere nello svolgimento di violazione di almeno una delle funzioni delle Forze Armate, è caratterizzata come catastrofica o di emergenza;
È importante sottolineare che, se una situazione particolare che potrebbe sorgere nello svolgimento di violazione di almeno una delle funzioni delle Forze Armate, sono complesse;
insignificanti se una situazione particolare che potrebbe sorgere nello svolgimento di violazione di almeno una delle funzioni delle Forze Armate, è complicare le condizioni di volo o implicazioni.

Di conseguenza, ci sono tre livelli di software:

Livello 1 per la categoria di "critica" per il software più esigente e la quantità massima di lavoro che devono essere soddisfatti al fine di dimostrare la conformità con i requisiti di certificazione e l'importo massimo della documentazione di supporto;
livello 2 - per la categoria "sostanziale" con i requisiti più bassi;
livello 3 - per la categoria dei "non essenziali", con i requisiti minimi.

software di livello dipende non solo la categoria di funzioni critiche. importante ruolo svolto dalla architettura del sistema e la struttura del suo software. Ad esempio, il sistema può essere analizzato standby canale analogico che duplicare l'intera funzione canale digitale. In determinate circostanze, questo può essere sufficiente per diminuire il livello. Viceversa, se analizzate su un unico sistema Sun viene utilizzato in modo tale che il rifiuto di rispondere una categoria critica, e le altre forze armate della stessa guasto del sistema porta ad una condizioni operative più critiche, il progettista del sistema può determinare un livello superiore. Un'influenza importante nel determinare il livello del software sono anche metodi della sua progettazione. per esempiomisure, il metodo di isolamento o di controllo come un metodo di protezione contro determinate condizioni di guasto da convalida continua della funzione o multi-versioned metodo, la cui attuazione prevede la creazione di due o più componenti software che eseguono una funzione in modi diversi e per diversi software fornisce la capacità di separare funzionalmente indipendente componenti software per isolare i guasti.

I valori numerici sopra citate della probabilità del verificarsi di situazioni particolari non si riferiscono alla probabilità di errori rilevati nel software. Il software non può essere applicata all'apparato matematico sviluppato della teoria delle statistiche, che abbaia possibile calcolare la probabilità di eventi, dal momento che non v'è alcun legame diretto tra la probabilità di verificarsi di situazioni particolari e non sono suscettibili di rilevare gli errori nel software. Pertanto, i livelli di indicatori ON o affidabilità, basate su un livello software, non possono essere usati nella valutazione della sicurezza del sistema, per esempio, come usato tasso di guasto hardware.

Tuttavia, le norme raccomandano l'uso di questi o altri criteri quantitativi per la valutazione della qualità del software o per raggiungere un certo livello di qualità, tenendo conto del fatto che l'industria del software ha accumulato una vasta collezione di modelli e metriche che consentono di valutare diverse caratteristiche del software. Inoltre, durante lo sviluppo e la verifica di software si raccomanda vivamente di tenere un registro degli errori rilevati e gli svantaggi, nonché le misure adottate per porvi rimedio.

I processi di sviluppo, la verifica e la validazione del software

Il passo principale per la creazione di un prodotto tecnico è il suo design, tra cui la prototipazione, testarlo per verificare il rispetto dei requisiti e, alla fine, l'approvazione della sua manutenzione. La creazione di un prodotto software risponde pienamente a questi processi.

Presenta il processo di creazione di un prodotto software di interesse dal punto di vista di ottenere determinati garanzie di sicurezza. Qui, ogni evento associato con lo sviluppo di (P) ha un evento di verifica corrispondente (B). Ed entrambi producono i relativi documenti (D).

Il materiale iniziale per l'avvio dei processi di sviluppo software sono i requisiti dichiarati per il sistema, che devono essere formalizzati sotto forma di un documento appropriato (DF <"zero">), e che devono essere convertiti in requisiti software (D1), proprio per il fatto che l'implementazione le funzioni dei sistemi elettronici digitali, come già accennato, sono svolte tramite software. Il processo di sviluppo dei requisiti software (P1) è il processo di trasformazione dei requisiti di sistema in requisiti software.

Per facilitare la comprensione del procedimento di trasformazione, sia durante lo sviluppo e la sua procedura di verifica è raccomandato per dividere in almeno due parti: a requisiti di progettazione di alto livello e necessità di sviluppo successive bassi.

requisiti di alto livello direttamente derivate dall'analisi dei requisiti di sistema in vista delle caratteristiche della sua costruzione. È necessario osservare le seguenti condizioni: ogni richiesta per il sistema dovrebbe essere trasferita ad uno o più dei requisiti di un alto livello, e viceversa, ciascuno per un alto livello di software - in uno o più dei requisiti di sistema, ad eccezione dei crediti derivati non derivano direttamente dei requisiti di sistema (per esempio, la domanda interrupt, a seconda delle caratteristiche della calcolatrice bersaglio selezionato). Derivati di requisiti di alto livello per essere trasmessi in processo di valutazione della sicurezza del sistema. Per di alto livello requisiti includono requisiti funzionali e tecnici, interoperabilità e requisiti di sicurezza richiesta.

Requisiti di basso livello sono espressi in termini di ingegneria del software e sono ottenuti attraverso l'analisi e dettagli requisiti di alto livello. Requisiti bassi livelli sono direttamente correlati alle procedure di codifica e software di aggregazione, t. E. è i requisiti per l'applicabile linguaggi di programmazione, compilatori, architetture e middleware, alla struttura dei suoi componenti, la classificazione di oggetti software alla base all'operatore, l'ambiente, lo sviluppo e la verifica nonché allo stile di programmazione.

Documenti correlati sono le norme e altri documenti normativi (D2) sulle specifiche tecniche per la progettazione, codifica, il supporto. L'esercizio di verifica, completando la prima fase di sviluppo, - un confronto tra i requisiti per i requisiti di sistema software per verificare la compatibilità della distribuzione delle funzioni tra hardware e software e interfacce, completezza o adeguatezza dei requisiti per il software. La forma raccomandata di documentazione - una tabella di riferimenti incrociati, che può essere emesso da una verifica documento separato, o essere parte di un documento generale che descrive tutte le fasi delle procedure di verifica e dei loro risultati, nonché le questioni emergenti e misure per affrontarle.

Le prossime fasi di sviluppo - pianificazione dei processi di sviluppo del software e la gestione della sua qualità. Lo scopo principale di pianificazione - identificazione delle risorse e sequenze d'azione, assicurando il raggiungimento degli obiettivi. C'è ancora determinata dai processi organizzativi (di relazione). Di conseguenza, essi dovrebbero essere emessi cinque documenti (che è consentito una combinazione ragionevole): progetti per la certificazione (DZ), il piano di sviluppo del software, la verifica piano e piani di gestione della configurazione (D6) e garantiscono la qualità. attività di verifica (V2, VZ) si riferiscono principalmente al coordinamento delle procedure sulla fase di approvazione dei piani, nonché la loro correzione dai commenti emersi nelle fasi successive dell'operazione, e anche il software. Il contenuto dei documenti considerati ulteriormente.

Prosecuzione del processo di sviluppo è un processo di progettazione software. Qui, i requisiti software di alto livello sono specificati per un certo numero di iterazioni del processo di progettazione per formare l'architettura software di algoritmi di funzionamento, tenendo conto del basso livello di requisiti a tal punto che su di essi è stato possibile rendere il codice sorgente. Per soddisfare i requisiti di sicurezza dovrebbe fornire un controllo di controllo e il flusso di dati, per esempio, per fornire un timer watchdog, controllo di coerenza e cross confronto scorrono naturalmente con la corrispondente reazione allo stato "rifiuto". risultati del progetto sono registrati in un documento che descrive il progetto.

L'esercizio di verifica V4 - controlli di progetto su requisiti di conformità per il software e le norme per la progettazione, tra cui la verifica delle algoritmi di funzionamento del sistema. Lo scopo principale della verifica del progetto è quello di fornire la sua "verificabilità". Questo dovrebbe essere preso in considerazione almeno i seguenti fattori: la sequenza di esecuzione del programma, flussi di dati e possibili distorsioni del loro potenziale impatto sulle funzioni di isolamento e integrità hardware. Il documento D13 verifica dovrebbe essere una tabella di conformità del progetto su richiesta di un software in forma di analisi trasversale. Ritirata dagli standard e requisiti deve essere notato e giustificato.

Tutte le fasi finora, Lager fase di progettazione del software può essere definito preliminare. Solo come risultato del processo di programmazione (R5), comunicante componenti software (R6) e l'integrazione del software con l'hardware (R7) appare prodotti software nella loro forma finale.

Il primo risultato del processo di attuazione una requisiti di basso livello, sempre un codice sorgente (D9), che dovrebbe essere trasformato nel progetto. Contabilità architettura software nel processo di progettazione è implementato nelle procedure di software multi-componente e software di integrazione al computer di destinazione sarà definitiva codice eseguibile oggetto (DOJ) e il software di configurazione directory appropriata (D11). dati di ingresso errati o insufficienti identificati in questi processi, è necessario ritornare alle precedenti lavorazioni di rettifica o chiarezza. Inoltre, l'ambiente di sviluppo software (che è, il più delle volte, e l'ambiente del suo supporto) devono essere chiaramente e accuratamente definita e fissa (D12).

Inutile dire che, in questa fase dello sviluppo effettuato il più voluminoso, il più complesso nel contenuto e le più importanti misure di verifica (V5, V6, V7) sotto il titolo - Software Testing (test) per rilevare errori contenuti nel software. Il problema qui è che gli errori rilevati vengono di solito eliminati, non identificato può anche non essere previsto.

Il contenuto di tutte e tre le misure di verifica.

Questo processo consiste di un certo numero di iterazioni, e comprende tutte le posizioni in ogni iterazione e per ciascun evento. I risultati del processo vengono registrati in un D13 documento.

Processi di revisione dello sviluppo del software sarebbe incompleta senza menzione dei piani e UKPO GKPO. essere attuata entro audit interni ed esterni della configurazione, nonché adeguate procedure organizzative e tecnologiche, e si riflettono nei processi verbali e D14 D15.

Attuazione del software del piano documento di certificazione D16 fisso.

Il ciclo di sviluppo del software è completato i test confermano l'idoneità operativa del sistema di bordo funzionale digitale (V9). Questi test sono effettuati come parte del certificato ufficiale (certificazione) che il sistema sul velivolo nelle condizioni di esercizio indicate funziona correttamente.

La documentazione per la certificazione del software. Negli Stati Uniti, si è ufficialmente 1987 metodo dell'Istituto SEI (Software Engineering Institute), che permette di determinare il livello di maturità tecnologica delle aziende che sviluppano software e migliorare il processo di sviluppo. Capability Maturity Originariamente

Model (CMM), e più tardi - Capability Maturity Model Integration (CMMI). In conformità con il modello del più alto ( "ottimizzazione") livello di maturità tecnologica - il quinto - risponde completamente processo automatizzato produzione sulla base di un modello matematico utilizzando i metodi di ottimizzazione parametrica e strutturale e l'organizzazione concentra sul miglioramento dei processi. Uno dei segni di minore tra il primo ( "primario") il livello è l'organizzazione dipendente dei singoli programmatori, e una delle condizioni per il passaggio dal secondo ( "repliche") livello per un terzo ( "Definizioni") - i processi che documentano sotto controllo servizio appropriato guidato dal responsabile dalla direzione dell'organizzazione.

Tutte le fasi del ciclo di vita del software hanno un inizio e una fine alla documentazione possono esistere per sempre. Pertanto, per formulare i requisiti per la documentazione - significa formulare i requisiti per tutto il suddetto processo di creazione di software. La documentazione è il fattore molto materiale con cui software certificato. La documentazione è anche un elemento chiave nelle indagini ha analizzato con attenzione i requisiti di disastri o emergenze.

Una forma molto importante e il contenuto del documento, l'inclusione delle caratteristiche quantitative e qualitative del prodotto, la profondità del suo monitoraggio e analisi, la presenza della possibilità di registrazione e memorizzazione, il livello di responsabilità delle persone firma del documento. L'anello più debole nella documentazione - visione completa della dichiarazione per le sue esigenze.

Un elenco specifico di documenti richiesti per la certificazione di software dipende dal software (sulla criticità del sistema) ed è determinato nel processo di approvazione del piano di certificazione con l'autorità di certificazione. Di seguito una breve mostra l'essenza ei documenti già menzionati.

D1 "Requisiti software" - contiene una descrizione della trasformazione dei requisiti di sistema alle esigenze software con il rilascio dei requisiti di livelli alti e bassi e con particolare attenzione alla sicurezza e le eventuali condizioni di guasto. Da definire caratteristiche criteri di rendimento e le possibili limitazioni, come la memoria, tempo-frequenza, per l'interazione. Particolare attenzione è rivolta alla isolamento dei componenti software.
D2 - "Norme di sviluppo software" - lista plurale. Almeno - questa è una lista di norme formali, sviluppo requisiti, progettazione, codifica, test del software. Insieme con gli standard - alcuni documenti.
Il loro contenuto - metodi per la creazione, le regole di strutturazione, le restrizioni sul progetto (per esempio, l'esclusione di ricorsione, oggetti dinamici, simboli alternativi di dati), limiti di complessità (per esempio, la nidificazione delle chiamate, l'uso del luppolo) sul linguaggio ed il compilatore, l'ambiente e gli strumenti.
CLE - "Piano certificazione software" è servito per l'approvazione di certificazione dello Stato, definisce le procedure, i metodi di conformità con i requisiti del prodotto a lui ad un sistema per le Forze Armate e la documentazione richiesta.
D4 "piano di sviluppo software" - definisce il ciclo di vita di sviluppo del software, l'interazione degli interpreti e l'ambiente di sviluppo.
D5 - "Piano verifica del software" - definisce le fasi (la posizione del processo di sviluppo e di criteri per il passaggio alle procedure di verifica), le tecniche, le procedure, l'ambiente e gli strumenti di verifica, inclusi strumenti software, le istruzioni sul raggiungimento dei parametri necessari di qualità (sicurezza) e le istruzioni su nuova scansione e il test dopo aver apportato modifiche al software, che garantiscono l'eliminazione degli errori rilevati.
D6 - "Software di Piano di Gestione Configurazione" - stabilisce le regole per l'individuazione di software e attrezzature unità, la versione base e tracciabilità sulle versioni derivate delle regole di gestione del cambiamento, le regole dell'ordine e la contabilità stato di configurazione, l'archiviazione, il monitoraggio e la protezione del software dell'unità di trattamento dei dati.
D7 - "Il software di garanzia della qualità Plan" imposta l'ambito, le responsabilità ei poteri di ispezione e di controllo e altre attività legate al processo di ottenimento di garanzie, comprese le segnalazioni di problemi, il loro monitoraggio e le azioni correttive.
D8 - "Descrizione del software di progetto" - contiene una descrizione dettagliata di come il software soddisfi i requisiti dei requisiti di alto livello, tra cui algoritmi, strutture dati, e come requisiti software assegnate a compiti e processi. Inoltre, una descrizione dell'architettura software, librerie, mi flussi di I / O di dati e controllare l'allocazione delle risorse e le relative restrizioni, le procedure, la programmazione, schemi tra processi e la condivisione tra le applicazioni, interruzioni, componenti software, i metodi per il loro isolamento.
D9 "codice sorgente" - contiene il codice sorgente, le istruzioni di compilazione per la generazione di codice, la modifica dei dati e link per il download.
D10 - "Object codice eseguibile" - contiene il codice che è adatto per l'applicazione diretta del processore target, calcolatrice, t E. Uno che viene caricato nel sistema di apparati avionici..
D11 - "software di configurazione del prodotto" - definisce la configurazione del prodotto fornito come unità. Essa deve identificare il software nel suo complesso, ogni componente corrispondente ai documenti e supporti.
D12 - "Ambiente Prodotto Software" - contiene una descrizione dell'ambiente di ciclo di vita del software, dalla fase di specificare i requisiti e finitura fase di storno di utilizzo del prodotto. Nel catalogo identificato da strumenti di sviluppo, la verifica, il software di monitoraggio, fornisce dati a qualificarsi strumenti.
D13 - "Le procedure ei risultati della verifica" può essere suddiviso in due o tre documenti, che devono essere descritte procedure di revisione, analisi, test in tutte le fasi di sviluppo, esempi applicativi e risultati di prova delle procedure componenti del software identificati. Tutti i problemi e le azioni correttive devono essere descritte nel dettaglio.
D14 - "Protocolli UKPO".
D15 - "Protocolli GKPO".
D16 - "La conclusione finale sul software" - è il documento principale che assicura l'attuazione del "Piano di certificazione software" e la misura in cui i "Requisiti software". Essa deve contenere una breve descrizione del sistema e del software, certificazione condizioni (accordi), le caratteristiche, l'identificazione e lo stato di documentazione del software per una lista di software e una dichiarazione la misura in cui i requisiti software.