L'avionica è dove l'aerospazio incontra il software, ed è l'esempio più chiaro in questa sezione di un campo dove la competenza adiacente non si trasferisce con la facilità che sembra.
Non software normale con qualche documento in più
Un'assunzione comune è che il software di bordo certificato sia software normale più un onere di conformità. Quell'assunzione produce assunzioni sbagliate e programmi falliti.
Quattro cose che differiscono in modo fondamentale.
Ogni riga risale a un requisito. Il codice esiste perché un requisito lo ha richiesto, e quel legame è documentato e revisionato. Codice che fa qualcosa di sensato ma non è tracciabile a un requisito è un rilievo di non conformità.
La copertura di verifica deve essere dimostrata. Il testing deve dimostrare di esercitare il codice a un livello di copertura strutturale definito, che sale con il livello di garanzia. Questo modella il modo in cui il codice viene scritto, perché i costrutti complessi diventano costosi da coprire.
Il determinismo è richiesto. La temporizzazione deve essere prevedibile e limitata. L'allocazione dinamica di memoria, i cicli non limitati e i percorsi di esecuzione imprevedibili sono evitati o vietati a seconda del livello.
Anche gli strumenti richiedono qualifica. Se l'output di uno strumento viene considerato affidabile senza revisione indipendente, lo strumento deve essere qualificato. Compilatori, generatori di test e strumenti di analisi rientrano tutti in questo.
Un bravo ingegnere software commerciale non è automaticamente un bravo ingegnere avionico. I vincoli ribaltano diverse abitudini che rendono qualcuno bravo nel software ordinario.
La conseguenza per le assunzioni è specifica: reclutare ingegneri software generici per ruoli certificati e aspettarsi un adattamento breve sottostima sistematicamente la transizione, e spesso gli stessi ingegneri la trovano frustrante prima che diventi soddisfacente.
Cosa copre la direzione
L'ambito: elettronica di bordo, GPS, controllo di volo, comunicazioni e sistemi di bordo.
Quattro aree.
Sistemi di controllo di volo. La catena dall'input del pilota o dell'autopilota al movimento delle superfici di controllo, incluse le architetture fly-by-wire e la loro ridondanza.
Sistemi di navigazione. Navigazione satellitare, sistemi inerziali, dati aria e la fusione di tutti e tre.
Comunicazioni e sorveglianza. Radio, datalink, transponder e i sistemi che permettono agli aeromobili di essere visti e coordinati.
Architetture integrate. Come le funzioni condividono l'hardware di calcolo con partizionamento garantito, in modo che un guasto in una non possa influenzarne un'altra.
Perché i requisiti sono così rigidi
Vale la pena spiegarlo invece che affermarlo soltanto, perché capirlo è ciò che rende un ingegnere bravo in questo, non solo conforme.
I requisiti di garanzia sono guidati dalla conseguenza. Una funzione il cui guasto sarebbe catastrofico porta gli obblighi più pesanti; una il cui guasto è solo scomodo ne porta molti meno.
Ciò produce tre realtà pratiche.
La stessa funzione può portare obblighi diversi. A seconda dell'aeromobile, dell'architettura e di cosa resterebbe disponibile se fallisse. Il livello di garanzia esce da una valutazione di sicurezza, non dal nome della funzione.
L'architettura può ridurre l'onere. Progettare in modo che un guasto venga rilevato e gestito da un percorso indipendente può abbassare il livello di garanzia richiesto a un componente, un vero compromesso ingegneristico e non un esercizio burocratico.
Il cambiamento è costoso. Modificare software certificato significa riverificare le parti interessate e ristabilire l'evidenza, motivo per cui cambiamenti apparentemente banali comportano costi sproporzionati e perché il software si congela molto prima di quanto si aspettino i team commerciali.
Dove si colloca nel dominio
Avionica, navigazione e sistemi aerospaziali è la quinta delle nove direzioni nel dominio Spazio, aerospazio e nuova mobilità di Astra Trainer, accanto a ingegneria aeronautica e operazioni aeronautiche, e collegata al dominio robotica, dove sistemi di controllo copre la teoria del controllo sottostante.
Si abbina anche a semiconduttori ed elettronica per l'hardware, e a IA, dati e calcolo per la pratica di ingegneria software, anche se i partner dovrebbero notare che la transizione dal software commerciale a quello certificato è la sostanza di questa direzione, non un dettaglio. Qui trovi le nove direzioni.
Navigazione, e una dipendenza da nominare
Un'osservazione fattuale con conseguenze ingegneristiche reali.
La navigazione satellitare è diventata una dipendenza condivisa per molto più che l'aviazione: trasporto marittimo, trasporto su strada, topografia, agricoltura, servizi di emergenza, e in particolare la temporizzazione precisa per reti di telecomunicazioni, sistemi finanziari e reti elettriche.
I segnali sono deboli quando raggiungono il suolo, il che li rende sensibili sia a interferenze non intenzionali sia a jamming o spoofing deliberati. Eventi di interferenza che hanno colpito la navigazione aeronautica sono stati segnalati in varie regioni, e il sistema dell'aviazione li gestisce tramite procedure, ausili di navigazione alternativi e sistemi inerziali.
Tre conseguenze per ingegneria e forza lavoro.
Il posizionamento alternativo e complementare è un'area attiva. Navigazione inerziale, navigazione basata su terreno e visione, e fonti di temporizzazione alternative ricevono tutte attenzione a causa di questa dipendenza.
La resilienza è un requisito di progettazione, non una funzionalità. I sistemi che presuppongono la disponibilità continua della navigazione satellitare fanno un'assunzione non sempre verificata.
Il bacino di competenze è di nicchia e in crescita. Gli ingegneri che capiscono sia l'elaborazione del segnale di navigazione satellitare sia i sistemi inerziali sono scarsi, e servono ben oltre l'aviazione.
Questo è presentato come una considerazione ingegneristica nota. Non è una previsione su nessuna regione o evento specifico.
I ruoli, uno per uno
Ingegneri software avionici. Software di bordo certificato. La scarsità centrale.
Ingegneri hardware avionici. Schede, interfacce, qualifica ambientale.
Ingegneri di sicurezza dei sistemi. Valutazione di sicurezza, analisi dei guasti e allocazione del livello di garanzia. Centrali e scarsi.
Ingegneri di verifica e validazione. Test basati sui requisiti e analisi di copertura. La popolazione più numerosa in un programma certificato.
Ingegneri dei sistemi di navigazione. Navigazione satellitare, inerziale e fusione sensoriale.
Ingegneri di integrazione e test. Banchi prova, iron bird e strumentazione per test di volo.
Specialisti di certificazione per software ed hardware elettronico complesso.
Tecnici di manutenzione avionica. Con licenza, in servizio, e una carenza separata e persistente.
Chi si può formare per farlo
Ingegneri di altri domini a sicurezza certificata. Segnalamento ferroviario, strumentazione e controllo nucleare, dispositivi medici, sicurezza funzionale automotive. Accettano già che l'evidenza sia parte del prodotto, l'atteggiamento più difficile da instillare, e hanno bisogno del quadro specifico dell'aviazione.
Ingegneri software embedded. Da contesti industriali o automotive, già abituati ad ambienti vincolati e deterministici. Un passo più breve rispetto a chi viene dallo sviluppo web o applicativo.
Ingegneri di test. Verso la verifica, il requisito più grande in qualsiasi programma certificato e il punto di ingresso più accessibile.
Tecnici di manutenzione avionica. Verso ruoli di supporto ingegneristico e integrazione, portando conoscenza di come si comportano i sistemi in servizio, che i team di progettazione spesso non hanno.
Ingegneri elettronici. Verso hardware e integrazione.
Personale avionico militare. Arrivano con la cultura dei sistemi e della navigabilità già incorporata.
Certificazione e licenza sono materia legale, non procedurale. I sistemi di bordo sono approvati tramite processi regolatori, e l'approvazione dell'organizzazione di progettazione, il credito di certificazione e il rilascio di navigabilità sono detenuti da organizzazioni approvate e firmatari qualificati. La manutenzione avionica richiede una licenza con le abilitazioni appropriate. La tecnologia aeronautica è anche soggetta a controllo delle esportazioni nella maggior parte delle giurisdizioni. La formazione costruisce comprensione ingegneristica e sostiene chi lavora verso questi percorsi. Non conferisce approvazione, credito di certificazione, licenza o autorità a rilasciare al servizio.
Cosa portare a casa
Il software certificato è un mestiere diverso, non software normale con documenti in più, e diverse abitudini che rendono bravo un ingegnere commerciale qui sono vincoli.
Il livello di garanzia segue la conseguenza, quindi le scelte di architettura possono davvero ridurre l'onere, il che rende la valutazione di sicurezza un'attività ingegneristica e non un passaggio di approvazione.
Il cambiamento è costoso perché l'evidenza deve essere ristabilita, motivo per cui il software si congela prima di quanto si aspettino i team commerciali.
La navigazione satellitare è una dipendenza condivisa ben oltre l'aviazione, e il posizionamento resiliente è un bacino di competenze di nicchia in crescita.
E gli ingegneri da ferroviario, nucleare, dispositivi medici o sicurezza funzionale automotive convertono molto meglio degli ingegneri software generici, perché trattano già l'evidenza come parte del prodotto.
Il software avionico certificato è solo software con più carte?
No. Ogni riga risale a un requisito, la copertura di verifica deve essere dimostrata a livello strutturale, la temporizzazione deve essere deterministica, e anche gli strumenti possono richiedere qualifica. Diverse abitudini che rendono bravo un ingegnere commerciale diventano vincoli.
Perché i requisiti di garanzia variano?
Perché seguono la conseguenza del guasto, determinata da una valutazione di sicurezza. La stessa funzione può portare obblighi molto diversi a seconda dell'architettura e di cosa resta disponibile se fallisce.
Perché cambiare software certificato è così costoso?
Perché l'evidenza di verifica interessata deve essere ristabilita. È il motivo per cui il software si congela molto prima in un programma aerospaziale di quanto si aspettino i team commerciali.
Chi si converte ai ruoli avionici?
Ingegneri da segnalamento ferroviario, strumentazione nucleare, dispositivi medici o sicurezza funzionale automotive, perché accettano già l'evidenza come parte del prodotto. Gli ingegneri software embedded sono un passo più breve rispetto agli sviluppatori applicativi.
Dove si colloca nel dominio?
Quinta delle nove direzioni nel dominio Spazio, aerospazio e nuova mobilità di Astra Trainer, collegata a sistemi di controllo in robotica e a elettronica nel dominio chip. Le trovi qui.