Nessuno dei sistemi avionici su cui ho lavorato ha utilizzato Linux o qualsiasi sistema operativo di tipo consumer. Ci sono alcuni problemi principali.

Il primo è il pratico. La maggior parte dell'avionica critica per la sicurezza coinvolge un circuito di controllo e quindi ha un requisito in tempo reale. Ciò significa che non è solo importante eseguire un processo e ottenere una risposta, ma è necessario ottenere la risposta entro un vincolo di tempo strettamente controllato. Ogni processo software critico su un aereo è programmato per garantire un ciclo di controllo stabile. Per farlo, hai bisogno di un sistema operativo in tempo reale e Linux non lo è.

Il secondo è la necessità della certificazione. Il software utilizzato su un aeromobile deve essere sviluppato per soddisfare il livello di garanzia di sviluppo (DAL) appropriato per il livello di pericolo associato. I sistemi critici per la sicurezza devono soddisfare il livello DAL "A". Qualsiasi sistema operativo utilizzato deve soddisfare lo stesso DAL della funzione in esecuzione su di esso. Questi requisiti sono definiti in RTCA DO-178C. Linux non è stato sviluppato secondo questo standard. Esistono solo poche piattaforme di sviluppo di sistemi operativi / software che possono essere certificate. Green Hills, Wind River e LynxOS sono i pochi sistemi che conosco che soddisfano i requisiti.

C'è anche un altro vincolo in quanto la certificazione richiede un controllo della versione molto rigoroso. L'avionica esisterà sul campo per molti anni e anche qualsiasi modifica ad essa dovrà essere certificata. In generale, non c'è alcun motivo valido per aggiornare il sistema operativo su una vecchia unità e in molti casi non è possibile senza aggiornare l'hardware (che è una spesa maggiore che nessuno vuole). Quindi, nell'aggiornamento di una vecchia unità, devo creare il "nuovo" software da eseguire su qualsiasi versione del sistema operativo attualmente presente nel prodotto. Potrebbe essere una piattaforma di 15 o 20 anni (o più vecchia). Un sistema operativo in rapida evoluzione come Linux avrebbe un impatto negativo sul supporto del prodotto a lungo termine.

La risposta breve è che nessun sistema avionico critico per la sicurezza di cui sono a conoscenza usa Linux, e i sistemi con la più alta criticità spesso non usano affatto un sistema operativo commerciale. Tuttavia, Linux è utilizzato in altre applicazioni critiche per la sicurezza come Space X Falcon 9 e applicazioni mediche. Una spiegazione più dettagliata è difficile da fare senza entrare troppo in profondità, poiché la domanda è un po 'come chiedere "le cellule moderne sono realizzate con nanomateriali?", Dove una spiegazione dettagliata dovrebbe coprire i pro ei contro del materiale, luoghi dove il suo utilizzo ha più o meno senso, differenze nei produttori e una panoramica di ciò che viene utilizzato al suo posto, ecc. Cercherò di coprire tutti questi punti in modo succinto con collegamenti ad ulteriori informazioni.

Secondo questo rapporto FAA del 2001, alcuni dei principali sistemi operativi per l'avionica certificata erano VRTX, LynxOS, PSOS, VxWorks e l'OSE di Enea, sebbene l'avionica non critica a volte utilizzi altri sistemi come Windows NT. (Sì, LynxOS è basato su Unix e Linux è considerato "Unix-like", ma ci sono molte differenze tra i due, proprio come un Linux non è simile al Mac OS X basato su BSD). Tuttavia, i sistemi più critici non utilizzano affatto un sistema operativo commerciale. Notano "Con le prove disponibili oggi, in generale, si può affermare che i prodotti COTS in genere non soddisfano i requisiti per il software di criticità di livello A." In parole povere, ciò significa che la maggior parte dell'avionica sviluppata con software di terze parti, da VxWorks a Linux, non veniva testata e analizzata abbastanza da essere inserita in qualcosa di critico come un sistema di atterraggio, un'unità TCAS o un'unità di visualizzazione critica. Tuttavia, probabilmente è cambiato negli ultimi 10 anni da quando il rapporto è stato scritto. Ecco un articolo più recente sull'utilizzo del sistema operativo in tempo reale nell'avionica.

Cosa significano RTOS e COTS?

Un concetto importante qui è un sistema operativo in tempo reale, o RTOS. Un RTOS in poche parole fornisce garanzie che il software non esaurisca il tempo di elaborazione programmato, i messaggi tra le parti del software vengono passati in un breve lasso di tempo, la memoria non si esaurirà e altre attività importanti sono garantite invece di funzionare bene in condizioni normali, quindi rompersi in condizioni insolite. I normali sistemi operativi non possono fornire tali garanzie. Queste garanzie, o sostituti accettabili, sono necessari per la certificazione della maggior parte dei prodotti avionici.

Un altro concetto importante è la differenza tra i sistemi interni e quelli commerciali (COTS). I sistemi commerciali standard sono disponibili pubblicamente e non sono personalizzati molto per ogni produttore. Questo articolo fornisce un buon riepilogo dei pro e dei contro dei sistemi operativi commerciali e interni. Molti avionici ad alta criticità hanno ancora il software principale sviluppato internamente a causa dei vantaggi coinvolti.

Linux soddisfa i requisiti di certificazione?

Sì, Linux non è "certificato FAA" ma in realtà nessun RTOS è "certificato FAA" o "soddisfa DO-178C". DO-178C fornisce obiettivi che gli ingegneri del sistema avionico devono soddisfare per certificare il loro intero software avionico (gli obiettivi comprendono audit, test, analisi di sicurezza e scrittura dei requisiti, tra le altre cose). Quindi il meglio che il fornitore di sistemi operativi può fare è fornire software "pronto per DO-178C" o seguire le linee guida DO-178C. Si noti che DO-178C riconosce vari livelli di sicurezza, quindi ciò che è certificabile in DO-178C per un sistema di manutenzione potrebbe non essere certificabile in DO-178C per un'unità di visualizzazione critica. Il problema con Linux non è che Linux non sia "certificato sotto DO-178C", è che è difficile da certificare a causa delle sfide indicate di seguito. È possibile certificare un sistema usando Linux, ma farlo potrebbe essere proibitivamente difficile a causa dell'analisi extra, delle misure di sicurezza e della documentazione che sarebbero necessarie, specialmente per l'avionica più critica. Alcune di queste sfide e metodi alternativi di conformità sono delineati in questo rapporto FAA.

Vantaggi e svantaggi di Linux

Ci sono vantaggi nell'utilizzo di Linux, che sono in parte condivise con altri sistemi commerciali. Più dipendenti avranno già esperienza con Linux e il sistema operativo è stato progettato con più esperienza e tempo di quanto la maggior parte delle organizzazioni abbia a disposizione. I sistemi commerciali hanno anche un prezzo delle etichette molto più basso rispetto al software interno. I sistemi commerciali sono anche più adattabili e consentono modifiche all'hardware e spazio per la crescita futura senza tornare al tavolo da disegno. Gli strumenti per lavorare con il software sono più sviluppati e possono anche avere una cronologia di servizio più lunga che fornisce fiducia nel software.

Ecco alcuni dei problemi che Linux deve affrontare in un sistema avionico quando compete con un RTOS , da questo rapporto FAA:

• partizionamento: se si suppone che due programmi vengano eseguiti in modo indipendente, è necessario provare che un programma non può interferire con un altro attraverso la struttura della memoria condivisa, le cache, il supporto della scheda e il firmware, gli errori, le interruzioni, ecc.

• tempo di esecuzione nel caso peggiore: nel computer desktop va bene se impantanano il mio PC con troppe richieste o condizioni insolite contemporaneamente e il sistema rallenta o salta alcuni passaggi del programma. In avionica questo non è accettabile per ovvie ragioni. Il fornitore avrebbe bisogno di verificarlo tramite modelli di CPU, memoria, ecc. O rigorosi test di laboratorio e analisi dei tempi. Entrambi sono più difficili quanto più complessi sono l'hardware e il software.

• Copertura MCDC: i test sull'avionica più critica (Livello A) richiedono l'esecuzione di righe di codice e condizioni decisionali sufficienti per raggiungere l'MCDC standard di copertura del codice, che rientra tra "eseguire ogni riga di codice" e test esaustivi di ogni combinazione di condizioni. Alcuni sistemi operativi come Linux possono essere estremamente difficili da testare in modo sufficientemente approfondito da soddisfare questo standard.
• documentazione: analisi rigorose e stress test richiedono molta documentazione sul funzionamento interno del sistema operativo
• considerazioni sulla sicurezza: Linux in base alla progettazione ha più problemi di sicurezza di un'applicazione snella e interna. Questi problemi di sicurezza stanno diventando sempre più importanti, specialmente nel codice militare
• morto e irraggiungibile: disabilitare attentamente le molte funzioni inutilizzate di Linux e garantire che non possano interferire con il tuo software è solitamente richiesta per la certificazione

Altri settori critici per la sicurezza

Che dire di settori simili critici per la sicurezza? Lo Space X Falcon utilizza Linux in alcuni dei suoi computer di volo ( fonti). Sulla base di questa intervista, Space X sembra dare la priorità alla crescita futura, alla disponibilità, ai tempi di ciclo brevi e alle competenze rispetto alla semplicità e alla robustezza dello sviluppo interno in quest'area. Si noti che i computer di controllo del volo sullo Space X Falcon non sono direttamente analoghi a un LRU nella tipica avionica moderna, quindi è probabile che sia necessario un lavoro extra o un'architettura insolita per far funzionare Linux per le tipiche applicazioni avioniche.

Linux è utilizzato anche in molte applicazioni mediche critiche per la sicurezza, ma non senza problemi simili a quelli affrontati nell'aviazione. Ti consiglio di leggere "Choosing Linux for Medical Devices" di Wind River o questo articolo sugli svantaggi di Linux nelle applicazioni mediche critiche per la sicurezza.

Suppongo che tu stia parlando dei principali elementi avionici come la guida di volo, il pilota automatico, il fly-by-wire o i display. Altri sistemi di aeroplani potrebbero vagamente essere considerati critici per la sicurezza, ma non sono esempi tipici di dispositivi critici per la sicurezza, come borse di volo elettroniche certificate, soluzioni di connettività e software di manutenzione. A volte sono più adatti per un'applicazione Linux a causa dell'elevata complessità e di considerazioni di sicurezza meno rigorose.

Nota che non sono un esperto in questo campo e il mio consiglio non sostituisce il consiglio di uno specialista di certificazione.

Sembra che i piloti ora almeno a volte utilizzino i tablet per le liste di controllo.

Se questi tablet sono dispositivi Android ( la maggior parte), eseguono il kernel Linux. Android utilizza meno dello stack Linux standard ma utilizza ancora il kernel Linux. Le liste di controllo sono fondamentali per la sicurezza, credo. I tablet Apple e Windows utilizzano kernel diversi, non Linux.

Esistono molte app con elenchi di controllo per dispositivi Android. Presumo che qualcuno li usi.

Il kernel è il cuore del sistema operativo di un computer che mantiene il controllo completo su tutte le altre parti. Come il cablaggio di un aereo di linea.

Linux viene utilizzato per applicazioni critiche per la sicurezza? No sì. Forse. Abbi pazienza ...

La USS Umwalt utilizza Linux per i suoi ampi requisiti di dati e LynxOS per applicazioni hard real-time incorporate , descritto in questo articolo.

Laptop standard Linux è un sistema operativo in spazio utente: attende che un utente faccia clic con il mouse, prema un tasto o generi un output, quindi agisce. Potrebbero essere aperti o meno molti programmi. L'input dell'utente è un evento statistico per quanto riguarda l'O / S: può o non può accadere nel prossimo minuto.

Confrontalo con un loop di controllo digitale. Funziona su un processore e utilizza la memoria, solo l'hardware standard del computer. Ma differiscono dal software desktop in quanto:

• Sono incorporati;
• Hanno una serie di attività predefinite;
• Avere rigidi vincoli temporali;
• Corri in un ciclo infinito. Alla fine del programma torna all'inizio e ripete la routine, questo sarebbe un frame di iterazione.

Il software deve leggere gli input e generare output, ogni iterazione e un frame di iterazione viene eseguito per un periodo di tempo fisso. Un sistema hard real time è un sistema in cui le risposte a tempo devono essere deterministiche: qualunque cosa faccia deve essere terminata in un'unica iterazione software. Se il ciclo di controllo viene eseguito a 100 Hz, un ciclo di iterazione richiede 10 msec e l'hardware deve essere abbastanza veloce da garantire che l'intero processo possa finire nel tempo, ogni volta.

Questi cicli di controllo sono generalmente non è enorme, e generalmente non ha un numero di finestre aperte compreso tra 1 e 100. Programmi piccoli e veloci e un numero limitato di finestre, ecco come vengono creati O / S per programmi critici per la sicurezza e loop in tempo reale. Il che è fantastico, ai vecchi tempi non c'era un O / S per questo e il codice doveva essere scritto in assembler o peggio. Le chiamate I / O erano specifiche dell'hardware e quindi non portabili da un chipset a un altro.

È qui che entrano in gioco gli O / S in tempo reale come VxWorks, LynxOS e pochi altri. Sono O / S basati su Unix e compatibili POSIX. Il livello hardware è reso invisibile per il programmatore, che dispone di una serie di strumenti di sviluppo per l'utilizzo di linguaggi per computer di alto livello con chiamate I / O standard e routine di temporizzazione. Sono scalabili: puoi iniziare con un O / S che si avvia e quindi esegue immediatamente il tuo file binario cross-compilato a una velocità impostata sull'interfaccia del timer. Oppure puoi riconfigurare il kernel e includere un paio di interrupt utente che guardano le tastiere oi dati RS-232 in arrivo, tutto fino al programmatore, che ha anche un ampio kit di strumenti per temporizzazione e I / O.

VxWorks può essere costoso (ma è ben supportato) e ora sono disponibili alcune alternative open source basate sul kernel Linux come Xenomai, RTLinux e Xilinx. Alcuni di questi tentano di avere tutti i servizi disponibili per le applicazioni desktop e hanno solo un timer di interruzione che fa del suo meglio per mantenere l'attività in esecuzione in modo uniforme, anche se un elaboratore di testi avvia un controllo ortografico. Altri sono scalabili in tempi difficili, proprio come VxWorks, ma sono open source e il supporto può essere una sfida. Per quanto ne so non sono ancora stati su Marte, VxWorks sì.

Può essere utilizzato per l'avionica critica per la sicurezza: sì, se scalabile in tempo reale e testato secondo gli standard applicabili a tutti gli avionici . Per quanto mi riguarda ora non c'è ancora niente a bordo di un aereo, ma potrebbe essere solo una questione di tempo.

Non c'è davvero bisogno di avere un sistema operativo commerciale sull'avionica.

Il software avionico tende ad essere progettato per hardware specifico: non esiste una piattaforma hardware generica realizzata in un mercato di massa da molti fornitori.

Gli avionici non interagiscono con molti altri sistemi o hardware.

L'avionica di solito viene eseguita come un'unica applicazione, quindi non è necessario il timesharing o, nel caso di RTOS, una pianificazione del ciclo di clock garantita.

Questi sono gli scopi principali di un sistema operativo rispetto a un semplice caricatore di bootstrap che carica e avvia un'applicazione: il sistema operativo facilita più piattaforme hardware, più driver e utilità per l'archiviazione su disco / flash, la condivisione del tempo con altre applicazioni e dispositivi periferici come il networking. Cosa deve fare l'avionica: interagire con il display, sensori esterni e pulsanti di controllo - non è necessario coinvolgere un sistema operativo.

Un sistema operativo incorporato è utile per un dispositivo dedicato, specialmente se l'applicazione incorporata pubblicherà servizi web per l'accesso e il controllo esterni. Tuttavia, è più lento da caricare (potrebbe essere un fattore per l'avionica) e consuma più risorse di un'app dedicata che viene avviata da un caricatore di bootstrap.

A causa dell'ampio ciclo di certificazione, l'avionica non tende a eseguire l'ultima e la migliore, né ha un breve ciclo di aggiornamento sull'hardware.