Aviônica é onde o aeroespacial encontra o software, e é o exemplo mais claro desta seção de um campo em que a habilidade adjacente não transfere tão facilmente quanto parece.
Não é software comum com mais documentos
Uma suposição comum é que software embarcado certificado é software normal mais sobrecarga de conformidade. Essa suposição produz contratações e programas que falham.
Quatro coisas que são fundamentalmente diferentes.
Toda linha remete a um requisito. O código existe porque um requisito o exigiu, e esse elo é documentado e revisado. Código que faz algo sensato mas não é rastreável a um requisito é um apontamento de não conformidade.
A cobertura de verificação precisa ser demonstrada. É preciso mostrar que os testes exercitam o código até um nível de cobertura estrutural definido, que sobe com o nível de garantia. Isso molda como o código é escrito, porque construções complexas ficam caras de cobrir.
O determinismo é obrigatório. A temporização precisa ser previsível e limitada. Alocação dinâmica de memória, laços sem limite e caminhos de execução imprevisíveis são evitados ou proibidos, dependendo do nível.
As próprias ferramentas exigem qualificação. Se a saída de uma ferramenta é confiada sem revisão independente, a ferramenta precisa ser qualificada. Compiladores, geradores de teste e ferramentas de análise entram todos nessa categoria.
Um engenheiro de software comercial habilidoso não é automaticamente um engenheiro de aviônica habilidoso. As restrições invertem vários hábitos que fazem alguém bom em software comum.
A consequência para a contratação é específica: recrutar engenheiros de software em geral para funções certificadas e esperar um ajuste curto subestima consistentemente a transição, e os próprios engenheiros frequentemente acham isso frustrante antes de acharem satisfatório.
O que a trilha cobre
O escopo: eletrônica de aeronave, GPS, controle de voo, comunicações e sistemas de bordo.
Quatro áreas.
Sistemas de controle de voo. A cadeia da entrada do piloto ou piloto automático até o movimento da superfície de controle, incluindo arquiteturas fly-by-wire e sua redundância.
Sistemas de navegação. Navegação por satélite, sistemas inerciais, dados de ar e a fusão dos três.
Comunicações e vigilância. Rádio, datalink, transponders e os sistemas que permitem que aeronaves sejam vistas e coordenadas.
Arquiteturas integradas. Como funções compartilham hardware de computação com particionamento garantido, para que uma falha numa não afete outra.
Por que os requisitos são tão rígidos quanto são
Vale explicar em vez de apenas afirmar, porque entender isso é o que torna um engenheiro bom no ofício, não apenas conforme.
Os requisitos de garantia são definidos pela consequência. Uma função cuja falha seria catastrófica carrega as obrigações mais pesadas; uma cuja falha é apenas inconveniente carrega muito menos.
Isso produz três realidades práticas.
A mesma função pode carregar obrigações diferentes. Dependendo da aeronave, da arquitetura e do que mais estaria disponível se ela falhasse. O nível de garantia vem de uma avaliação de segurança, não do nome da função.
A arquitetura pode reduzir a carga. Projetar de forma que uma falha seja detectada e tratada por um caminho independente pode diminuir o nível de garantia exigido de um componente, uma troca de engenharia genuína, não um exercício de papelada.
A mudança é cara. Modificar software certificado significa reverificar as partes afetadas e restabelecer evidências, o que explica por que mudanças aparentemente triviais carregam custo desproporcional e por que o software congela muito antes do que equipes comerciais esperam.
Onde isso se encaixa no domínio
Aviônica, navegação e sistemas aeroespaciais é a quinta de nove trilhas do domínio de espaço, aeroespacial e nova mobilidade da Astra Trainer, ao lado de engenharia aeronáutica e operações de aviação, e conectando com o domínio de robótica, onde sistemas de controle cobre a teoria de controle subjacente.
Também combina com semicondutores e eletrônica para o hardware, e com IA, dados e computação para a prática de engenharia de software, embora os parceiros devam notar que a transição de software comercial para certificado é o conteúdo desta trilha, não um detalhe dela. Você pode ver as nove trilhas aqui.
Navegação, e uma dependência que vale nomear
Uma observação factual com consequências reais de engenharia.
A navegação por satélite se tornou uma dependência compartilhada por muito mais do que aviação: transporte marítimo, transporte rodoviário, topografia, agricultura, serviços de emergência e, notavelmente, temporização precisa para redes de telecomunicações, sistemas financeiros e redes elétricas.
Os sinais chegam fracos ao solo, o que os torna suscetíveis tanto a interferência não intencional quanto a bloqueio ou falsificação deliberados. Eventos de interferência afetando a navegação da aviação já foram relatados em várias regiões, e o sistema de aviação lida com eles por meio de procedimentos, auxílios de navegação alternativos e sistemas inerciais.
Três consequências para engenharia e força de trabalho.
Posicionamento alternativo e complementar é uma área ativa. Navegação inercial, navegação por terreno e visual, e fontes alternativas de temporização recebem atenção por causa dessa dependência.
Resiliência é um requisito de projeto, não um recurso. Sistemas que pressupõem disponibilidade contínua de navegação por satélite estão fazendo uma suposição nem sempre válida.
O conjunto de habilidades é de nicho e está crescendo. Engenheiros que entendem tanto o processamento de sinal de navegação por satélite quanto sistemas inerciais são escassos, e são necessários bem além da aviação.
Isso é dito como uma consideração de engenharia conhecida. Não é uma previsão sobre nenhuma região ou evento específico.
As funções, uma a uma
Engenheiros de software de aviônica. Software embarcado certificado. A escassez central.
Engenheiros de hardware de aviônica. Placas, interfaces, qualificação ambiental.
Engenheiros de segurança de sistemas. Avaliação de segurança, análise de falhas e alocação de nível de garantia. Central e escassa.
Engenheiros de verificação e validação. Testes baseados em requisitos e análise de cobertura. A maior população num programa certificado.
Engenheiros de sistemas de navegação. Navegação por satélite, inercial e fusão de sensores.
Engenheiros de integração e teste. Bancadas, iron birds e instrumentação de teste em voo.
Especialistas em certificação para software e hardware eletrônico complexo.
Técnicos de manutenção de aviônica. Licenciados, em serviço, e uma escassez separada e persistente.
Quem pode ser treinado para isso
Engenheiros de outros domínios de segurança certificada. Sinalização ferroviária, instrumentação e controle nuclear, dispositivos médicos, segurança funcional automotiva. Já aceitam que evidência faz parte do produto, a atitude mais difícil de incutir, e precisam do arcabouço específico da aviação.
Engenheiros de software embarcado. De origem industrial ou automotiva, já acostumados a ambientes restritos e determinísticos. Um passo mais curto do que vindo de desenvolvimento web ou de aplicações.
Engenheiros de teste. Para verificação, o maior requisito em qualquer programa certificado e a porta de entrada mais acessível.
Técnicos de manutenção de aviônica. Para funções de suporte de engenharia e integração, trazendo conhecimento de como os sistemas se comportam em serviço, que as equipes de projeto frequentemente não têm.
Engenheiros eletrônicos. Para hardware e integração.
Pessoal militar de aviônica. Chegam com a cultura de sistemas e aeronavegabilidade já incorporada.
Certificação e licenciamento são legais, não procedimentais. Sistemas embarcados são aprovados por processos regulatórios, e a aprovação de organização de projeto, o crédito de certificação e a liberação de aeronavegabilidade são detidos por organizações aprovadas e signatários qualificados. A manutenção de aviônica exige licença com as habilitações apropriadas. A tecnologia de aviação também está sujeita a controle de exportação na maioria das jurisdições. O treinamento constrói entendimento de engenharia e apoia quem trabalha em direção a essas rotas. Ele não confere aprovação, crédito de certificação, licença ou autoridade para liberar qualquer coisa para serviço.
O que levar disso
Software certificado é outro ofício, não software comum com documentos, e vários hábitos que fazem um bom engenheiro comercial são restrições aqui.
O nível de garantia segue a consequência, então escolhas de arquitetura podem realmente reduzir a carga, o que torna a avaliação de segurança uma atividade de engenharia, não uma etapa de aprovação.
A mudança é cara porque evidências precisam ser restabelecidas, o que explica por que o software congela antes do que equipes comerciais esperam.
A navegação por satélite é uma dependência compartilhada bem além da aviação, e o posicionamento resiliente é um conjunto de habilidades de nicho e crescente.
E engenheiros de ferroviário, nuclear, dispositivos médicos ou segurança funcional automotiva se convertem muito melhor do que engenheiros de software em geral, porque já tratam evidência como parte do produto.
Software de aviônica certificado é só software com mais papelada?
Não. Toda linha remete a um requisito, a cobertura de verificação precisa ser demonstrada estruturalmente, a temporização precisa ser determinística, e as próprias ferramentas podem exigir qualificação. Vários hábitos que fazem um bom engenheiro comercial viram restrições.
Por que os requisitos de garantia variam?
Porque seguem a consequência da falha, determinada por uma avaliação de segurança. A mesma função pode carregar obrigações muito diferentes dependendo da arquitetura e do que permanece disponível se ela falhar.
Por que mudar software certificado é tão caro?
Porque a evidência de verificação afetada precisa ser restabelecida. É por isso que o software congela muito antes num programa aeroespacial do que equipes comerciais esperam.
Quem se converte para funções de aviônica?
Engenheiros de sinalização ferroviária, instrumentação nuclear, dispositivos médicos ou segurança funcional automotiva, porque já aceitam evidência como parte do produto. Engenheiros de software embarcado dão um passo mais curto do que desenvolvedores de aplicações.
Onde isso se encaixa no domínio?
Quinta de nove trilhas do domínio de espaço, aeroespacial e nova mobilidade da Astra Trainer, conectando com sistemas de controle na robótica e com eletrônica no domínio de chips. Você pode ver aqui.