TAnOTaTU -- 9h A solicitação por uma análise detalhada do SPARK é o coroamento lógico desta série de investigações. Se o Rust representa a vanguarda da segurança de memória e o Lean a fronteira da prova matemática pura, o SPARK ocupa um espaço único e insubstituível: o de uma linguagem de programação industrialmente madura que integra a verificação formal diretamente no ciclo de vida do desenvolvimento de software. Definição e Natureza Fundamental O SPARK é uma linguagem de programação formalmente definida, concebida como um subconjunto anotado da linguagem Ada. A sua característica fundadora, que o distingue de qualquer outra linguagem de programação, é a eliminação deliberada de toda e qualquer construção sintática que possa gerar comportamento ambíguo ou imprevisível. Como define a sua especificação, "SPARK is a well-defined subset of the Ada language that uses contracts to describe the specification of components in a form that is suitable for both static and dynamic verification". A história do SPARK remonta a 1988, quando Bernard Carré e Trevor Jennings, na Universidade de Southampton e com o patrocínio do Ministério da Defesa britânico, desenvolveram a primeira versão baseada em Ada 83 (o nome SPARK deriva de SPADE Ada Kernel, onde SPADE era a ferramenta de verificação precursora). O projeto foi posteriormente adotado e desenvolvido pela Praxis High Integrity Systems (mais tarde Altran Praxis, atualmente parte do grupo Capgemini), culminando em quatro versões da linguagem: · SPARK83, SPARK95, SPARK2005: Baseadas em Ada 83, Ada 95 e Ada 2005, respetivamente. Nessas versões, os contratos eram codificados como comentários Ada anotados, processados pela ferramenta SPARK Examiner, mas ignorados por um compilador Ada padrão. O fluxo de verificação incidia sobre a análise estática e a prova de ausência de erros, com um rigor semântico que permitia, como reportado por um membro da equipa da Praxis, que "a nossa taxa de defeitos com SPARK é pelo menos 10 vezes, por vezes 100 vezes mais baixa do que as criadas com outras linguagens". · SPARK 2014: Um redesenho completo da linguagem, lançado a 30 de abril de 2014 e baseado em Ada 2012. Esta versão representa o estado da arte da verificação formal industrial. Em vez de comentários anotados, o SPARK 2014 adota a sintaxe de aspetos (aspects) nativa da Ada 2012 para expressar contratos, integrando-os no núcleo da linguagem. Com isso, os contratos são verificados pelo compilador Ada, tornam-se parte da semântica de execução (podendo ser checados dinamicamente) e, crucialmente, podem ser provados estaticamente pelo motor de verificação formal. Alicerces Técnicos: Contratos, Ausência de Erros e Fluxo de Informação O funcionamento do SPARK assenta sobre três pilares técnicos que o distinguem de todas as outras ferramentas de verificação. O Sistema de Contratos Em Ada 2012 e SPARK 2014, os contratos são expressões booleanas anexadas a declarações de subprogramas, especificando as suas exigências sobre quem os chama (pré‑condições) e os resultados por eles garantidos (pós‑condições). Um exemplo canónico de uma pré‑condição e pós‑condição em SPARK 2014 é o de uma função de pesquisa binária: ```ada function Sorted (A : Integer_Array) return Boolean is (A'Length < 2 or else (for all X in A'First .. A'Last - 1 => (for all Y in X + 1 .. A'Last => A (X) <= A (Y)))); function Search (A : Integer_Array; Value : Integer) return Natural with Pre => Sorted (A), Post => (if Search'Result = 0 then (for all Index in A'Range => A (Index) /= Value) else A (Search'Result) = Value); ``` Aqui, a pré‑condição Sorted(A) exige que o array passado como argumento esteja ordenado (usando expressões quantificadas de Ada 2012). A pós‑condição, utilizando o atributo especial 'Old de Ada 2012 para denotar o valor de uma variável à entrada do subprograma, garante que o resultado devolvido é zero se, e só se, o valor não estiver presente no array, e caso contrário, que o índice devolvido corresponde efetivamente ao valor procurado. Estes contratos estabelecem uma relação formal entre chamador e chamado, sustentando a verificação modular: o GNATprove analisa cada subprograma de forma isolada, assumindo que as pré‑condições das sub‑rotinas invocadas são satisfeitas e, em contrapartida, provando que as suas pós‑condições são garantidas. Essa modularidade é o que permite ao SPARK escalar para sistemas industriais com centenas de milhares de linhas de código, concentrando o esforço de prova apenas nas partes críticas do software. Ausência de Erros de Execução Ao contrário de abordagens que dependem de verificações defensivas em tempo de execução (que consomem ciclos de CPU e podem falhar de forma imprevisível), o SPARK prova estaticamente que erros como overflow numérico, divisão por zero, acesso a índice fora dos limites de um array e desreferência de ponteiros nulos são logicamente impossíveis em todos os caminhos de execução possíveis. Isto permite que o compilador elimine as verificações dinâmicas do código compilado, garantindo eficiência máxima sem sacrificar as garantias de integridade. Segurança de Memória e Comportamento Indefinido O SPARK elimina do subconjunto Ada todas as construções que poderiam levar a comportamento indefinido. Restringe o uso de alocação dinâmica, proíbe o acesso a memória não inicializada e, através de uma combinação de análise estática e prova formal, garante a ausência de fugas de memória e de condições de corrida (data races) em código concorrente. É, portanto, tão seguro para a memória quanto o Rust, mas com uma base de prova dedutiva em vez de um mecanismo de ownership integrado no sistema de tipos. O Motor de Prova: GNATprove e a Análise Dedutiva O GNATprove é a ferramenta central que implementa a verificação formal para SPARK. Baseado na infraestrutura do compilador GNAT/GCC, reutiliza a totalidade da front‑end Ada 2012 para análise sintática e semântica, e acrescenta duas camadas de análise sobre a representação intermédia do código: a análise de fluxo (flow analysis) e a prova dedutiva (proof). · Análise de Fluxo: Examina as dependências de dados e o fluxo de informação entre variáveis, verificando que as variáveis lidas foram previamente inicializadas e que os contratos de dependência (que especificam quais as variáveis globais que um subprograma lê e escreve) são respeitados. Esta análise é automática, rápida e não requer interação do utilizador. · Prova Dedutiva: Quando ativada no modo de prova (proof mode), o GNATprove traduz cada subprograma e os seus contratos para a linguagem intermédia do provador Why3, que por sua vez os codifica como obrigações de prova (verification conditions) descarregadas para demonstradores automáticos, como o CVC5, o Z3 e o Alt‑Ergo. Se um demonstrador não consegue fechar uma obrigação de prova, o utilizador pode intervir com pragmas de asserção intermédias para guiar o provador, ou recorrer ao modo de prova manual (manual proof) do GNAT Studio, que oferece um ambiente interativo para decompor e demonstrar manualmente as obrigações mais complexas. É crucial compreender que a prova do SPARK é correta (sound): nunca gera falsos negativos (uma prova fechada significa que a propriedade é verdadeira) e, dentro dos limites de tempo (timeout), também não gera falsos positivos — se uma obrigação não pôde ser provada, é porque ou a propriedade é de facto falsa, ou a especificação contratual é insuficiente, ou a complexidade excede a heurística dos provadores automáticos. Esta precisão distingue o SPARK de ferramentas de análise estática tradicionais, que tipicamente reportam um número elevado de falsos positivos. O Caminho para a Certificação: DO‑178C e o Suplemento DO‑333 O SPARK não é apenas uma linguagem e uma ferramenta; é um ecossistema de garantia, qualificado para os mais altos níveis de criticidade da indústria. A norma DO‑178C para software aerotransportado não certifica uma linguagem de programação per se, mas sim um processo de desenvolvimento e as ferramentas que o suportam. O suplemento DO‑333 (Formal Methods Supplement), parte integrante da DO‑178C, descreve como os resultados da verificação formal podem ser utilizados como evidência de certificação, complementando ou até substituindo testes tradicionais. A abordagem do SPARK alinha‑se com o DO‑333 de forma única, porque os contratos SPARK constituem uma especificação formal diretamente no código‑fonte. A cadeia de ferramentas da AdaCore oferece não apenas o GNATprove, mas também bibliotecas de execução (run‑time libraries) qualificadas e compiladores certificados, permitindo uma rastreabilidade completa desde os requisitos de alto nível até às obrigações de prova fechadas. Os contratos podem ser utilizados como objetivos de verificação formais, e a prova automática da sua satisfação pelo GNATprove constitui uma evidência de correção que é aceite pelas autoridades de certificação como a FAA e a EASA. O suporte do SPARK à DO‑178C é de tal ordem maduro que o conjunto de ferramentas GNAT Pro obteve a certificação para a mais alta integridade de segurança (Nível A). O SPARK 2014 representa, portanto, a única tecnologia atualmente disponível que permite a implantação de métodos formais diretamente sobre código‑fonte à escala industrial, cumprindo os requisitos de um ecossistema de certificação completo — da especificação à compilação, passando pela prova, pela análise de cobertura e pela geração de evidências de auditoria. Comparação com Rust e Lean no Espectro da Verificação Para localizar o SPARK com precisão no panorama das ferramentas de alta garantia, é útil contrastá‑lo com o Rust e o Lean. Rust oferece segurança de memória através do seu sistema de ownership e borrow checker, prevenindo erros como use‑after‑free e data races em tempo de compilação, sem sobrecarga de execução. Contudo, o Rust não possui um mecanismo integrado de especificação de contratos funcionais, nem um provador dedutivo para demonstrar propriedades lógicas sobre o comportamento do programa. O SPARK, em contraste, prova a ausência de erros de execução e a correção funcional através de contratos formais, não se limitando à segurança de memória. A convergência entre as duas abordagens está em curso: a comunidade Rust está a desenvolver ativamente ferramentas de verificação formal, como o Creusot e o Aeneas, que traduzem programas Rust para sistemas de prova como Why3 — o mesmo backend utilizado pelo GNATprove. No entanto, enquanto o SPARK já está certificado para DO‑178C Nível A, o Rust carece ainda de um compilador qualificado para essa norma e de um ecossistema de verificação tão maduro. Lean é um assistente de provas com tipos dependentes que permite expressar e demonstrar teoremas matemáticos sobre programas, incluindo a sua correção total. Ao contrário do SPARK, o Lean não é uma linguagem de programação para sistemas embarcados; não gera código de máquina eficiente para execução em tempo real, nem se integra com um sistema operacional de tempo real certificado. O Lean pode provar propriedades que o SPARK não pode expressar (devido à indecidibilidade de certas lógicas), mas fá‑lo através de um processo de prova interativo e intensivo em mão de obra qualificada. O SPARK opta por uma lógica decidível que permite um alto grau de automação, sacrificando a expressividade ilimitada em favor da escalabilidade industrial. Na prática, as duas ferramentas podem ser complementares: o SPARK para a verificação automática do grosso do sistema, e o Lean para a demonstração de algoritmos críticos cujas propriedades transcendem a lógica de primeira ordem. Aplicações Industriais e Exemplos Concretos O SPARK deixou de ser uma curiosidade académica; é hoje uma ferramenta de produção em sistemas onde a falha não é uma opção. · Aviônica: O SPARK está presente em sistemas de controlo de voo de aeronaves comerciais, como o Airbus A380 e o Boeing 777, em subsistemas de gestão de voo e em processadores de missão de caças de quinta geração. A sua utilização está documentada como fator decisivo na redução de defeitos em ordens de grandeza face a outras linguagens, e a integração com os suplementos DO‑178C torna‑o a escolha preferencial para novos projetos de sistemas aerotransportados de alta criticidade. · Espaço: A NASA selecionou o SPARK como linguagem e cadeia de ferramentas para o software de bordo de uma missão lunar, onde a inacessibilidade do hardware torna a correção do software uma questão de sucesso ou falha total da missão. · Automóvel e Veículos Autónomos: A Zenseact, uma empresa do grupo Volvo, desenvolveu um sistema de condução autónoma com o SPARK para componentes de segurança crítica, obtendo a certificação ISO 26262, justamente porque o SPARK "indica se existe qualquer possibilidade de erro em todos os caminhos de execução potenciais do código". A NVIDIA adotou o SPARK para enfrentar ambientes de cibersegurança crescentemente hostis em firmware e bibliotecas criptográficas de baixo nível. · Investigação de Voo Não Tripulado: Investigadores demonstraram um flight stack completo para um planador não tripulado de alta altitude escrito e formalmente verificado em Ada/SPARK 2014, aplicando análise estática desde o início do projeto e comprovando na prática que a verificação formal pode guiar o desenho do software em tempo de desenvolvimento. Considerações Finais O SPARK é a resposta madura e industrializada à pergunta "como construir software que é matematicamente correto?". Não é um protótipo de investigação, nem um conceito teórico: é uma linguagem, um conjunto de ferramentas e um processo de certificação que já produziram dezenas de sistemas de segurança crítica em operação real. Ao ocupar a interseção entre a programação de alto nível (Ada) e a verificação formal dedutiva (GNATprove), o SPARK oferece um caminho pragmático para a correção por construção, permitindo às equipas de engenharia provar, com um esforço incremental, a ausência de erros de execução e a conformidade funcional do seu código com os requisitos. É a escolha natural para sistemas aerotransportados, espaciais e de defesa onde a certificação DO‑178C Nível A é um requisito incontornável e onde a confiança absoluta no software não é um luxo, mas uma condição de existência do próprio sistema. replyA solicitação por uma análise detalhada do SPARK é o coroamento lógico desta série de investigações. Se o Rust representa a vanguarda da segurança de memória e o Lean a fronteira da prova matemática pura, o SPARK ocupa um espaço único e insubstituível: o de uma linguagem de programação industrialmente madura que integra a verificação formal diretamente no ciclo de vida do desenvolvimento de software. Definição e Natureza Fundamental O SPARK é uma linguagem de programação formalmente definida, concebida como um subconjunto anotado da linguagem Ada. A sua característica fundadora, que o distingue de qualquer outra linguagem de programação, é a eliminação deliberada de toda e qualquer construção sintática que possa gerar comportamento ambíguo ou imprevisível. Como define a sua especificação, "SPARK is a well-defined subset of the Ada language that uses contracts to describe the specification of components in a form that is suitable for both static and dynamic verification". A história do SPARK remonta a 1988, quando Bernard Carré e Trevor Jennings, na Universidade de Southampton e com o patrocínio do Ministério da Defesa britânico, desenvolveram a primeira versão baseada em Ada 83 (o nome SPARK deriva de SPADE Ada Kernel, onde SPADE era a ferramenta de verificação precursora). O projeto foi posteriormente adotado e desenvolvido pela Praxis High Integrity Systems (mais tarde Altran Praxis, atualmente parte do grupo Capgemini), culminando em quatro versões da linguagem: · SPARK83, SPARK95, SPARK2005: Baseadas em Ada 83, Ada 95 e Ada 2005, respetivamente. Nessas versões, os contratos eram codificados como comentários Ada anotados, processados pela ferramenta SPARK Examiner, mas ignorados por um compilador Ada padrão. O fluxo de verificação incidia sobre a análise estática e a prova de ausência de erros, com um rigor semântico que permitia, como reportado por um membro da equipa da Praxis, que "a nossa taxa de defeitos com SPARK é pelo menos 10 vezes, por vezes 100 vezes mais baixa do que as criadas com outras linguagens". · SPARK 2014: Um redesenho completo da linguagem, lançado a 30 de abril de 2014 e baseado em Ada 2012. Esta versão representa o estado da arte da verificação formal industrial. Em vez de comentários anotados, o SPARK 2014 adota a sintaxe de aspetos (aspects) nativa da Ada 2012 para expressar contratos, integrando-os no núcleo da linguagem. Com isso, os contratos são verificados pelo compilador Ada, tornam-se parte da semântica de execução (podendo ser checados dinamicamente) e, crucialmente, podem ser provados estaticamente pelo motor de verificação formal. Alicerces Técnicos: Contratos, Ausência de Erros e Fluxo de Informação O funcionamento do SPARK assenta sobre três pilares técnicos que o distinguem de todas as outras ferramentas de verificação. O Sistema de Contratos Em Ada 2012 e SPARK 2014, os contratos são expressões booleanas anexadas a declarações de subprogramas, especificando as suas exigências sobre quem os chama (pré‑condições) e os resultados por eles garantidos (pós‑condições). Um exemplo canónico de uma pré‑condição e pós‑condição em SPARK 2014 é o de uma função de pesquisa binária: ```ada function Sorted (A : Integer_Array) return Boolean is (A'Length < 2 or else (for all X in A'First .. A'Last - 1 => (for all Y in X + 1 .. A'Last => A (X) <= A (Y)))); function Search (A : Integer_Array; Value : Integer) return Natural with Pre => Sorted (A), Post => (if Search'Result = 0 then (for all Index in A'Range => A (Index) /= Value) else A (Search'Result) = Value); ``` Aqui, a pré‑condição Sorted(A) exige que o array passado como argumento esteja ordenado (usando expressões quantificadas de Ada 2012). A pós‑condição, utilizando o atributo especial 'Old de Ada 2012 para denotar o valor de uma variável à entrada do subprograma, garante que o resultado devolvido é zero se, e só se, o valor não estiver presente no array, e caso contrário, que o índice devolvido corresponde efetivamente ao valor procurado. Estes contratos estabelecem uma relação formal entre chamador e chamado, sustentando a verificação modular: o GNATprove analisa cada subprograma de forma isolada, assumindo que as pré‑condições das sub‑rotinas invocadas são satisfeitas e, em contrapartida, provando que as suas pós‑condições são garantidas. Essa modularidade é o que permite ao SPARK escalar para sistemas industriais com centenas de milhares de linhas de código, concentrando o esforço de prova apenas nas partes críticas do software. Ausência de Erros de Execução Ao contrário de abordagens que dependem de verificações defensivas em tempo de execução (que consomem ciclos de CPU e podem falhar de forma imprevisível), o SPARK prova estaticamente que erros como overflow numérico, divisão por zero, acesso a índice fora dos limites de um array e desreferência de ponteiros nulos são logicamente impossíveis em todos os caminhos de execução possíveis. Isto permite que o compilador elimine as verificações dinâmicas do código compilado, garantindo eficiência máxima sem sacrificar as garantias de integridade. Segurança de Memória e Comportamento Indefinido O SPARK elimina do subconjunto Ada todas as construções que poderiam levar a comportamento indefinido. Restringe o uso de alocação dinâmica, proíbe o acesso a memória não inicializada e, através de uma combinação de análise estática e prova formal, garante a ausência de fugas de memória e de condições de corrida (data races) em código concorrente. É, portanto, tão seguro para a memória quanto o Rust, mas com uma base de prova dedutiva em vez de um mecanismo de ownership integrado no sistema de tipos. O Motor de Prova: GNATprove e a Análise Dedutiva O GNATprove é a ferramenta central que implementa a verificação formal para SPARK. Baseado na infraestrutura do compilador GNAT/GCC, reutiliza a totalidade da front‑end Ada 2012 para análise sintática e semântica, e acrescenta duas camadas de análise sobre a representação intermédia do código: a análise de fluxo (flow analysis) e a prova dedutiva (proof). · Análise de Fluxo: Examina as dependências de dados e o fluxo de informação entre variáveis, verificando que as variáveis lidas foram previamente inicializadas e que os contratos de dependência (que especificam quais as variáveis globais que um subprograma lê e escreve) são respeitados. Esta análise é automática, rápida e não requer interação do utilizador. · Prova Dedutiva: Quando ativada no modo de prova (proof mode), o GNATprove traduz cada subprograma e os seus contratos para a linguagem intermédia do provador Why3, que por sua vez os codifica como obrigações de prova (verification conditions) descarregadas para demonstradores automáticos, como o CVC5, o Z3 e o Alt‑Ergo. Se um demonstrador não consegue fechar uma obrigação de prova, o utilizador pode intervir com pragmas de asserção intermédias para guiar o provador, ou recorrer ao modo de prova manual (manual proof) do GNAT Studio, que oferece um ambiente interativo para decompor e demonstrar manualmente as obrigações mais complexas. É crucial compreender que a prova do SPARK é correta (sound): nunca gera falsos negativos (uma prova fechada significa que a propriedade é verdadeira) e, dentro dos limites de tempo (timeout), também não gera falsos positivos — se uma obrigação não pôde ser provada, é porque ou a propriedade é de facto falsa, ou a especificação contratual é insuficiente, ou a complexidade excede a heurística dos provadores automáticos. Esta precisão distingue o SPARK de ferramentas de análise estática tradicionais, que tipicamente reportam um número elevado de falsos positivos. O Caminho para a Certificação: DO‑178C e o Suplemento DO‑333 O SPARK não é apenas uma linguagem e uma ferramenta; é um ecossistema de garantia, qualificado para os mais altos níveis de criticidade da indústria. A norma DO‑178C para software aerotransportado não certifica uma linguagem de programação per se, mas sim um processo de desenvolvimento e as ferramentas que o suportam. O suplemento DO‑333 (Formal Methods Supplement), parte integrante da DO‑178C, descreve como os resultados da verificação formal podem ser utilizados como evidência de certificação, complementando ou até substituindo testes tradicionais. A abordagem do SPARK alinha‑se com o DO‑333 de forma única, porque os contratos SPARK constituem uma especificação formal diretamente no código‑fonte. A cadeia de ferramentas da AdaCore oferece não apenas o GNATprove, mas também bibliotecas de execução (run‑time libraries) qualificadas e compiladores certificados, permitindo uma rastreabilidade completa desde os requisitos de alto nível até às obrigações de prova fechadas. Os contratos podem ser utilizados como objetivos de verificação formais, e a prova automática da sua satisfação pelo GNATprove constitui uma evidência de correção que é aceite pelas autoridades de certificação como a FAA e a EASA. O suporte do SPARK à DO‑178C é de tal ordem maduro que o conjunto de ferramentas GNAT Pro obteve a certificação para a mais alta integridade de segurança (Nível A). O SPARK 2014 representa, portanto, a única tecnologia atualmente disponível que permite a implantação de métodos formais diretamente sobre código‑fonte à escala industrial, cumprindo os requisitos de um ecossistema de certificação completo — da especificação à compilação, passando pela prova, pela análise de cobertura e pela geração de evidências de auditoria. Comparação com Rust e Lean no Espectro da Verificação Para localizar o SPARK com precisão no panorama das ferramentas de alta garantia, é útil contrastá‑lo com o Rust e o Lean. Rust oferece segurança de memória através do seu sistema de ownership e borrow checker, prevenindo erros como use‑after‑free e data races em tempo de compilação, sem sobrecarga de execução. Contudo, o Rust não possui um mecanismo integrado de especificação de contratos funcionais, nem um provador dedutivo para demonstrar propriedades lógicas sobre o comportamento do programa. O SPARK, em contraste, prova a ausência de erros de execução e a correção funcional através de contratos formais, não se limitando à segurança de memória. A convergência entre as duas abordagens está em curso: a comunidade Rust está a desenvolver ativamente ferramentas de verificação formal, como o Creusot e o Aeneas, que traduzem programas Rust para sistemas de prova como Why3 — o mesmo backend utilizado pelo GNATprove. No entanto, enquanto o SPARK já está certificado para DO‑178C Nível A, o Rust carece ainda de um compilador qualificado para essa norma e de um ecossistema de verificação tão maduro. Lean é um assistente de provas com tipos dependentes que permite expressar e demonstrar teoremas matemáticos sobre programas, incluindo a sua correção total. Ao contrário do SPARK, o Lean não é uma linguagem de programação para sistemas embarcados; não gera código de máquina eficiente para execução em tempo real, nem se integra com um sistema operacional de tempo real certificado. O Lean pode provar propriedades que o SPARK não pode expressar (devido à indecidibilidade de certas lógicas), mas fá‑lo através de um processo de prova interativo e intensivo em mão de obra qualificada. O SPARK opta por uma lógica decidível que permite um alto grau de automação, sacrificando a expressividade ilimitada em favor da escalabilidade industrial. Na prática, as duas ferramentas podem ser complementares: o SPARK para a verificação automática do grosso do sistema, e o Lean para a demonstração de algoritmos críticos cujas propriedades transcendem a lógica de primeira ordem. Aplicações Industriais e Exemplos Concretos O SPARK deixou de ser uma curiosidade académica; é hoje uma ferramenta de produção em sistemas onde a falha não é uma opção. · Aviônica: O SPARK está presente em sistemas de controlo de voo de aeronaves comerciais, como o Airbus A380 e o Boeing 777, em subsistemas de gestão de voo e em processadores de missão de caças de quinta geração. A sua utilização está documentada como fator decisivo na redução de defeitos em ordens de grandeza face a outras linguagens, e a integração com os suplementos DO‑178C torna‑o a escolha preferencial para novos projetos de sistemas aerotransportados de alta criticidade. · Espaço: A NASA selecionou o SPARK como linguagem e cadeia de ferramentas para o software de bordo de uma missão lunar, onde a inacessibilidade do hardware torna a correção do software uma questão de sucesso ou falha total da missão. · Automóvel e Veículos Autónomos: A Zenseact, uma empresa do grupo Volvo, desenvolveu um sistema de condução autónoma com o SPARK para componentes de segurança crítica, obtendo a certificação ISO 26262, justamente porque o SPARK "indica se existe qualquer possibilidade de erro em todos os caminhos de execução potenciais do código". A NVIDIA adotou o SPARK para enfrentar ambientes de cibersegurança crescentemente hostis em firmware e bibliotecas criptográficas de baixo nível. · Investigação de Voo Não Tripulado: Investigadores demonstraram um flight stack completo para um planador não tripulado de alta altitude escrito e formalmente verificado em Ada/SPARK 2014, aplicando análise estática desde o início do projeto e comprovando na prática que a verificação formal pode guiar o desenho do software em tempo de desenvolvimento. Considerações Finais O SPARK é a resposta madura e industrializada à pergunta "como construir software que é matematicamente correto?". Não é um protótipo de investigação, nem um conceito teórico: é uma linguagem, um conjunto de ferramentas e um processo de certificação que já produziram dezenas de sistemas de segurança crítica em operação real. Ao ocupar a interseção entre a programação de alto nível (Ada) e a verificação formal dedutiva (GNATprove), o SPARK oferece um caminho pragmático para a correção por construção, permitindo às equipas de engenharia provar, com um esforço incremental, a ausência de erros de execução e a conformidade funcional do seu código com os requisitos. É a escolha natural para sistemas aerotransportados, espaciais e de defesa onde a certificação DO‑178C Nível A é um requisito incontornável e onde a confiança absoluta no software não é um luxo, mas uma condição de existência do próprio sistema.
thread · root 628f8f62…2cbd · depth 3 · · selected cc00122a…c30a
thread
root 628f8f62…2cbd · depth 3 · · selected cc00122a…c30a
{{cite web| title = Qual linguagem de programação é usada para os softwares que controlam…| url = https://pt.quora.com/Qual-linguagem-de-programação-é-usada-para-os-softwares-que-controlam-um-avião| date = 2024-01-18| archiveurl = http://archive.today/DO7HD| archivedate = 2024-01-18 }}As fontes consistem em uma série de discussões no fórum Quora que exploram as **linguagens de programação**utilizadas em **sistemas críticos**, como softwares de controle de **aviões e foguetes**. Os especialistasdestacam a predominância da linguagem **Ada**, valorizada por sua segurança e rigor, embora mencionem o uso de**C, C++ e Assembly** em contextos específicos de aviônica. Além dos aspectos técnicos das linguagens, o textoaborda normas de certificação essenciais para a segurança de voo, como a **DO-178C**. O conteúdo também seexpande para temas periféricos da computação, incluindo a **história da programação**, o funcionamento de barrasde carregamento e o conceito de **bootstrapping** em compiladores. Em suma, o material oferece um panorama sobrecomo a escolha da tecnologia é ditada pela necessidade de **estabilidade e confiabilidade** em ambientes de altorisco.
O desenvolvimento de software para sistemas aviônicos é uma disciplina singular, onde a escolha da linguagem deprogramação está intrinsecamente ligada à segurança de voo. A resposta a esta questão exige a análise doprincipal documento normativo do setor, o DO-178C, e das justificativas técnicas que posicionam linguagens comoAda e C no centro de sistemas que não podem falhar.O Contexto Normativo e a DO-178CIntroduzido em 2011 como uma evolução do DO-178B, o documento RTCA DO-178C / EUROCAE ED-12C, intitulado"Software Considerations in Airborne Systems and Equipment Certification" (Considerações de Software naCertificação de Sistemas e Equipamentos Aerotransportados), é o padrão internacional que rege a aprovação desoftware aerotransportado comercial. Autoridades como a FAA (EUA), a EASA (Europa) e a ANAC o utilizam como meioaceitável, embora não único, para demonstrar conformidade com regulamentos de aeronavegabilidade.A DO-178C não prescreve uma linguagem de programação específica, mas estabelece critérios rigorosos para oprocesso de desenvolvimento. Define cinco níveis de garantia de projeto (DAL, Design Assurance Level), do nívelA ao E, que qualificam o software conforme a severidade da condição de falha, variando de catastrófica a semefeito na segurança. Para os níveis mais críticos (DAL A e B), a norma exige objetivos rigorosos de verificação,como cobertura de decisão modificada/condição (MC/DC) e rastreabilidade completa dos requisitos até ocódigo-fonte.É neste contexto que a escolha da linguagem se torna uma decisão de engenharia crítica. O processo decertificação não se concentra apenas na funcionalidade, mas também na análise de segurança e na garantia de queo comportamento do software é verificável, determinístico e previsível. A DO-178C exige que o código-fonte sejaescrito em conformidade com um padrão de codificação definido e que a linguagem possua sintaxe não ambígua e umcontrole claro de dados. Os padrões de codificação, como o MISRA C e o JSF AV C++, surgem como ferramentasessenciais para mitigar os riscos de linguagens originalmente não projetadas para aplicações críticas.O Cenário das Linguagens de Programação AviônicasA escolha da linguagem é um balanço entre expressividade, controle, segurança e viabilidade econômica no ciclode vida de uma aeronave.Ada e SPARKA linguagem Ada foi criada por iniciativa do Departamento de Defesa dos EUA com o propósito de unificar ascentenas de linguagens usadas em sistemas embarcados militares, incorporando confiabilidade e manutenibilidade.Hoje, o ecossistema Ada, impulsionado principalmente pela empresa AdaCore, é um pilar da aviônica civil emilitar moderna. Exemplos notáveis incluem seu uso no sistema de controle de freio do Boeing 777 e no Sistema deGerenciamento de Voo (FMS) do Airbus A380. A AdaCore também fornece ferramentas para grandes players comoThales, Lockheed Martin e Collins Aerospace, atuando no "coração da aviônica na Europa", como descreveu um deseus diretores.A preferência por Ada reside em suas características técnicas, que se alinham com as exigências da DO-178C. Seusistema de tipos forte e verificação em tempo de compilação, combinado com suporte nativo à programaçãoconcorrente (modelo de tarefas e rendezvous), permite a modelagem de sistemas de tempo real de forma segura eestruturada. A evolução da linguagem culmina no SPARK, um subconjunto formalmente verificável de Ada. SPARKpermite que propriedades de segurança sejam provadas matematicamente através de contratos, satisfazendodiretamente os objetivos do suplemento de Métodos Formais da DO-178C (DO-333).C e C++A linguagem C constitui a espinha dorsal de incontáveis sistemas embarcados, incluindo os aviônicos, devido àsua eficiência e capacidade de manipulação direta de hardware. Por ser uma linguagem de propósito geral e compotencial para ambiguidades, seu uso em software crítico é estritamente condicionado à adoção de um padrão decodificação. O mais proeminente é o MISRA C, originalmente da indústria automotiva e amplamente adotado naaviônica, que define um subconjunto seguro da linguagem para evitar construções propensas a erros.O projeto do caça F-35 Lightning II exemplifica uma evolução no uso de linguagens. Embora com um legado desoftware em Ada, o F-35 adotou amplamente C++ (com estimativas de repositórios indicando 53% C e 35% C++), massob um restritivo conjunto de regras conhecido como JSF AV C++ (Joint Strike Fighter Air Vehicle C++ CodingStandards). Este padrão, cujo documento está disponível publicamente no site do criador do C++, BjarneStroustrup, proíbe funcionalidades como tratamento de exceções, funções recursivas e alocação dinâmica dememória, que são fontes de não determinismo e dificultam a garantia de tempo de resposta e a análise de piorcaso de execução (WCET). A proibição de exceções, em particular, ecoa a lição da falha do voo inaugural dofoguete Ariane 5, onde uma exceção de software não tratada levou à autodestruição do veículo.Linguagens de Modelagem (Model-Based Development)Uma tendência crescente na aviônica moderna é o desenvolvimento baseado em modelos (MBD), onde o software éprojetado com notações gráficas de alto nível, a partir das quais o código-fonte é gerado automaticamente. Aabordagem está em conformidade com os suplementos DO-331 (Modelagem) da DO-178C.Ferramentas como o MATLAB/Simulink da MathWorks, combinadas com o Embedded Coder, são capazes de gerar código Cou C++ qualificável para DAL A. De forma semelhante, o SCADE Suite da Ansys é uma ferramenta especializada queutiliza modelos de fluxo de dados e máquinas de estado para gerar código C ou Ada que é "correto porconstrução". O gerador de código do SCADE (KCG) é qualificado como ferramenta de desenvolvimento TQL-1 segundo aDO-330, o que permite aos desenvolvedores automatizar a verificação de baixo nível e focar na validação domodelo em si.Assembly e Outras LinguagensO uso de Assembly não desapareceu, especialmente em rotinas de inicialização de hardware e em sequências dechaveamento que exigem contagem exata de ciclos de máquina. Contudo, seu uso é minimizado ao extremo, sendorestrito a pequenos trechos onde a eficiência de mais alto nível não pode ser obtida. Para a DO-178C nível A, acobertura de código deve ser verificada também em nível de objeto (object code), como suportado por ferramentasde análise como a LDRA, que verificam a correção do binário gerado pelo compilador.Em relação a linguagens mais recentes, o Rust emerge como uma alternativa promissora, com discussões ativas nacomunidade e em artigos acadêmicos sobre sua adequação à DO-178C, graças ao seu modelo de gerenciamento dememória (ownership) que garante segurança sem garbage collector. Embora ainda não seja uma linguagem dominanteem sistemas aviônicos certificados, há um crescente ecossistema de ferramentas e pesquisas para viabilizar seuuso, especialmente para funções de segurança cibernética e módulos onde a segurança de memória é uma prioridade.O Java, por sua vez, encontra espaço em sistemas de informação de bordo ou aplicações de missão de menorcriticidade, longe dos sistemas de controle de voo, uma vez que sua dependência de máquina virtual e coleta delixo introduz complexidades de verificação incompatíveis com sistemas de tempo real estrito.Motivos Técnicos e Normativos para a EscolhaA seleção de uma linguagem para software aviônico não é uma questão de preferência, mas de engenharia desistemas, guiada pelos seguintes pilares:· Determinismo e Previsibilidade de Tempo Real: Sistemas de controle de voo operam em ciclos fixos e precisamresponder a eventos dentro de um limite de tempo máximo garantido, muitas vezes na casa dos microssegundos.Recursos como alocação dinâmica de memória, recursão ilimitada e coleta de lixo são terminantemente proibidosnos padrões de codificação de mais alta criticidade para garantir que o pior caso de execução (WCET) possa seranalisado e limitado.· Segurança de Memória e Tipos: A robustez de um sistema começa na prevenção de erros. Linguagens como Ada e osubconjunto SPARK possuem sistemas de tipo extremamente fortes que detectam, em tempo de compilação ou por provaformal, uma vasta classe de erros como buffer overflow, dangling pointers e condições de corrida. Em C e C++, ospadrões MISRA e JSF AV são a forma de conter os mesmos riscos através de restrições estritas.· Verificabilidade e Rastreabilidade: A DO-178C exige que cada linha de código-fonte seja rastreável a umrequisito funcional de baixo nível, e vice-versa. Linguagens com sintaxe clara e estruturas de controle bemdefinidas facilitam tanto a revisão manual por pares quanto a análise estática automatizada, que é uma peçacentral do processo de certificação. Ferramentas modernas, incluindo soluções de IA, auxiliam na priorização ecorreção de violações de padrões em bases de código C e C++, tornando a conformidade mais gerenciável.Exemplos Práticos de AplicaçãoA aplicação dessas linguagens pode ser vista em aeronaves que definem o estado da arte da aviação. O Airbus A380utiliza o sistema operacional de tempo real particionado Integrity-178B da Green Hills Software, que suportadesenvolvimento em C, C++ e Ada, com Ada sendo a linguagem de seu sistema de Gerenciamento de Voo (FMS).O Boeing 777, uma aeronave pioneira em sistemas fly-by-wire, foi uma das primeiras a ter seu sistema de controlede frenagem completamente programado em Ada, visando atender aos rigorosos requisitos de tempo real e segurançada FAA já sob a égide dos padrões DO-178 da época.Por fim, o programa do caça F-35, um dos sistemas de software mais complexos já embarcados, com mais de 20milhões de linhas de código, representa um ecossistema heterogêneo. Embora seu software de missão e de controlede voo seja predominantemente C++ sob o padrão JSF AV C++, ele convive com blocos críticos de software escritosem Ada e com a geração automática de código C a partir de modelos Simulink, demonstrando uma arquitetura em quea linguagem é selecionada de acordo com a função e o nível de criticidade do subsistema.Em conclusão, a programação de sistemas aviônicos é um campo onde a máxima "o melhor para o trabalho" é elevadaà sua potência máxima. Não há uma única linguagem, mas um espectro de ferramentas — Ada, SPARK, C, C++ elinguagens de modelagem — cada uma com seu lugar em um ecossistema meticulosamente projetado, cujo processo deseleção é moldado por décadas de lições de segurança e por um arcabouço normativo que visa garantir que osoftware nunca seja a causa de uma tragédia.
A solicitação por uma análise detalhada do SPARK é o coroamento lógico desta série de investigações. Se o Rustrepresenta a vanguarda da segurança de memória e o Lean a fronteira da prova matemática pura, o SPARK ocupa umespaço único e insubstituível: o de uma linguagem de programação industrialmente madura que integra averificação formal diretamente no ciclo de vida do desenvolvimento de software.Definição e Natureza FundamentalO SPARK é uma linguagem de programação formalmente definida, concebida como um subconjunto anotado da linguagemAda. A sua característica fundadora, que o distingue de qualquer outra linguagem de programação, é a eliminaçãodeliberada de toda e qualquer construção sintática que possa gerar comportamento ambíguo ou imprevisível. Comodefine a sua especificação, "SPARK is a well-defined subset of the Ada language that uses contracts to describethe specification of components in a form that is suitable for both static and dynamic verification".A história do SPARK remonta a 1988, quando Bernard Carré e Trevor Jennings, na Universidade de Southampton e como patrocínio do Ministério da Defesa britânico, desenvolveram a primeira versão baseada em Ada 83 (o nome SPARKderiva de SPADE Ada Kernel, onde SPADE era a ferramenta de verificação precursora). O projeto foi posteriormenteadotado e desenvolvido pela Praxis High Integrity Systems (mais tarde Altran Praxis, atualmente parte do grupoCapgemini), culminando em quatro versões da linguagem:· SPARK83, SPARK95, SPARK2005: Baseadas em Ada 83, Ada 95 e Ada 2005, respetivamente. Nessas versões, oscontratos eram codificados como comentários Ada anotados, processados pela ferramenta SPARK Examiner, masignorados por um compilador Ada padrão. O fluxo de verificação incidia sobre a análise estática e a prova deausência de erros, com um rigor semântico que permitia, como reportado por um membro da equipa da Praxis, que "anossa taxa de defeitos com SPARK é pelo menos 10 vezes, por vezes 100 vezes mais baixa do que as criadas comoutras linguagens".· SPARK 2014: Um redesenho completo da linguagem, lançado a 30 de abril de 2014 e baseado em Ada 2012. Estaversão representa o estado da arte da verificação formal industrial. Em vez de comentários anotados, o SPARK2014 adota a sintaxe de aspetos (aspects) nativa da Ada 2012 para expressar contratos, integrando-os no núcleoda linguagem. Com isso, os contratos são verificados pelo compilador Ada, tornam-se parte da semântica deexecução (podendo ser checados dinamicamente) e, crucialmente, podem ser provados estaticamente pelo motor deverificação formal.Alicerces Técnicos: Contratos, Ausência de Erros e Fluxo de InformaçãoO funcionamento do SPARK assenta sobre três pilares técnicos que o distinguem de todas as outras ferramentas deverificação.O Sistema de ContratosEm Ada 2012 e SPARK 2014, os contratos são expressões booleanas anexadas a declarações de subprogramas,especificando as suas exigências sobre quem os chama (pré‑condições) e os resultados por eles garantidos(pós‑condições). Um exemplo canónico de uma pré‑condição e pós‑condição em SPARK 2014 é o de uma função depesquisa binária:```adafunction Sorted (A : Integer_Array) return Boolean is(A'Length < 2 or else (for all X in A'First .. A'Last - 1 =>(for all Y in X + 1 .. A'Last => A (X) <= A (Y))));function Search (A : Integer_Array; Value : Integer) return Naturalwith Pre => Sorted (A),Post => (if Search'Result = 0 then(for all Index in A'Range => A (Index) /= Value)else A (Search'Result) = Value);```Aqui, a pré‑condição Sorted(A) exige que o array passado como argumento esteja ordenado (usando expressõesquantificadas de Ada 2012). A pós‑condição, utilizando o atributo especial 'Old de Ada 2012 para denotar o valorde uma variável à entrada do subprograma, garante que o resultado devolvido é zero se, e só se, o valor nãoestiver presente no array, e caso contrário, que o índice devolvido corresponde efetivamente ao valor procurado.Estes contratos estabelecem uma relação formal entre chamador e chamado, sustentando a verificação modular: oGNATprove analisa cada subprograma de forma isolada, assumindo que as pré‑condições das sub‑rotinas invocadassão satisfeitas e, em contrapartida, provando que as suas pós‑condições são garantidas. Essa modularidade é oque permite ao SPARK escalar para sistemas industriais com centenas de milhares de linhas de código,concentrando o esforço de prova apenas nas partes críticas do software.Ausência de Erros de ExecuçãoAo contrário de abordagens que dependem de verificações defensivas em tempo de execução (que consomem ciclos deCPU e podem falhar de forma imprevisível), o SPARK prova estaticamente que erros como overflow numérico, divisãopor zero, acesso a índice fora dos limites de um array e desreferência de ponteiros nulos são logicamenteimpossíveis em todos os caminhos de execução possíveis. Isto permite que o compilador elimine as verificaçõesdinâmicas do código compilado, garantindo eficiência máxima sem sacrificar as garantias de integridade.Segurança de Memória e Comportamento IndefinidoO SPARK elimina do subconjunto Ada todas as construções que poderiam levar a comportamento indefinido. Restringeo uso de alocação dinâmica, proíbe o acesso a memória não inicializada e, através de uma combinação de análiseestática e prova formal, garante a ausência de fugas de memória e de condições de corrida (data races) em códigoconcorrente. É, portanto, tão seguro para a memória quanto o Rust, mas com uma base de prova dedutiva em vez deum mecanismo de ownership integrado no sistema de tipos.O Motor de Prova: GNATprove e a Análise DedutivaO GNATprove é a ferramenta central que implementa a verificação formal para SPARK. Baseado na infraestrutura docompilador GNAT/GCC, reutiliza a totalidade da front‑end Ada 2012 para análise sintática e semântica, eacrescenta duas camadas de análise sobre a representação intermédia do código: a análise de fluxo (flowanalysis) e a prova dedutiva (proof).· Análise de Fluxo: Examina as dependências de dados e o fluxo de informação entre variáveis, verificando que asvariáveis lidas foram previamente inicializadas e que os contratos de dependência (que especificam quais asvariáveis globais que um subprograma lê e escreve) são respeitados. Esta análise é automática, rápida e nãorequer interação do utilizador.· Prova Dedutiva: Quando ativada no modo de prova (proof mode), o GNATprove traduz cada subprograma e os seuscontratos para a linguagem intermédia do provador Why3, que por sua vez os codifica como obrigações de prova(verification conditions) descarregadas para demonstradores automáticos, como o CVC5, o Z3 e o Alt‑Ergo. Se umdemonstrador não consegue fechar uma obrigação de prova, o utilizador pode intervir com pragmas de asserçãointermédias para guiar o provador, ou recorrer ao modo de prova manual (manual proof) do GNAT Studio, queoferece um ambiente interativo para decompor e demonstrar manualmente as obrigações mais complexas.É crucial compreender que a prova do SPARK é correta (sound): nunca gera falsos negativos (uma prova fechadasignifica que a propriedade é verdadeira) e, dentro dos limites de tempo (timeout), também não gera falsospositivos — se uma obrigação não pôde ser provada, é porque ou a propriedade é de facto falsa, ou aespecificação contratual é insuficiente, ou a complexidade excede a heurística dos provadores automáticos. Estaprecisão distingue o SPARK de ferramentas de análise estática tradicionais, que tipicamente reportam um númeroelevado de falsos positivos.O Caminho para a Certificação: DO‑178C e o Suplemento DO‑333O SPARK não é apenas uma linguagem e uma ferramenta; é um ecossistema de garantia, qualificado para os maisaltos níveis de criticidade da indústria. A norma DO‑178C para software aerotransportado não certifica umalinguagem de programação per se, mas sim um processo de desenvolvimento e as ferramentas que o suportam. Osuplemento DO‑333 (Formal Methods Supplement), parte integrante da DO‑178C, descreve como os resultados daverificação formal podem ser utilizados como evidência de certificação, complementando ou até substituindotestes tradicionais.A abordagem do SPARK alinha‑se com o DO‑333 de forma única, porque os contratos SPARK constituem umaespecificação formal diretamente no código‑fonte. A cadeia de ferramentas da AdaCore oferece não apenas oGNATprove, mas também bibliotecas de execução (run‑time libraries) qualificadas e compiladores certificados,permitindo uma rastreabilidade completa desde os requisitos de alto nível até às obrigações de prova fechadas.Os contratos podem ser utilizados como objetivos de verificação formais, e a prova automática da sua satisfaçãopelo GNATprove constitui uma evidência de correção que é aceite pelas autoridades de certificação como a FAA e aEASA.O suporte do SPARK à DO‑178C é de tal ordem maduro que o conjunto de ferramentas GNAT Pro obteve a certificaçãopara a mais alta integridade de segurança (Nível A). O SPARK 2014 representa, portanto, a única tecnologiaatualmente disponível que permite a implantação de métodos formais diretamente sobre código‑fonte à escalaindustrial, cumprindo os requisitos de um ecossistema de certificação completo — da especificação à compilação,passando pela prova, pela análise de cobertura e pela geração de evidências de auditoria.Comparação com Rust e Lean no Espectro da VerificaçãoPara localizar o SPARK com precisão no panorama das ferramentas de alta garantia, é útil contrastá‑lo com o Ruste o Lean.Rust oferece segurança de memória através do seu sistema de ownership e borrow checker, prevenindo erros comouse‑after‑free e data races em tempo de compilação, sem sobrecarga de execução. Contudo, o Rust não possui ummecanismo integrado de especificação de contratos funcionais, nem um provador dedutivo para demonstrarpropriedades lógicas sobre o comportamento do programa. O SPARK, em contraste, prova a ausência de erros deexecução e a correção funcional através de contratos formais, não se limitando à segurança de memória. Aconvergência entre as duas abordagens está em curso: a comunidade Rust está a desenvolver ativamente ferramentasde verificação formal, como o Creusot e o Aeneas, que traduzem programas Rust para sistemas de prova como Why3 —o mesmo backend utilizado pelo GNATprove. No entanto, enquanto o SPARK já está certificado para DO‑178C Nível A,o Rust carece ainda de um compilador qualificado para essa norma e de um ecossistema de verificação tão maduro.Lean é um assistente de provas com tipos dependentes que permite expressar e demonstrar teoremas matemáticossobre programas, incluindo a sua correção total. Ao contrário do SPARK, o Lean não é uma linguagem deprogramação para sistemas embarcados; não gera código de máquina eficiente para execução em tempo real, nem seintegra com um sistema operacional de tempo real certificado. O Lean pode provar propriedades que o SPARK nãopode expressar (devido à indecidibilidade de certas lógicas), mas fá‑lo através de um processo de provainterativo e intensivo em mão de obra qualificada. O SPARK opta por uma lógica decidível que permite um altograu de automação, sacrificando a expressividade ilimitada em favor da escalabilidade industrial. Na prática, asduas ferramentas podem ser complementares: o SPARK para a verificação automática do grosso do sistema, e o Leanpara a demonstração de algoritmos críticos cujas propriedades transcendem a lógica de primeira ordem.Aplicações Industriais e Exemplos ConcretosO SPARK deixou de ser uma curiosidade académica; é hoje uma ferramenta de produção em sistemas onde a falha nãoé uma opção.· Aviônica: O SPARK está presente em sistemas de controlo de voo de aeronaves comerciais, como o Airbus A380 e oBoeing 777, em subsistemas de gestão de voo e em processadores de missão de caças de quinta geração. A suautilização está documentada como fator decisivo na redução de defeitos em ordens de grandeza face a outraslinguagens, e a integração com os suplementos DO‑178C torna‑o a escolha preferencial para novos projetos desistemas aerotransportados de alta criticidade.· Espaço: A NASA selecionou o SPARK como linguagem e cadeia de ferramentas para o software de bordo de umamissão lunar, onde a inacessibilidade do hardware torna a correção do software uma questão de sucesso ou falhatotal da missão.· Automóvel e Veículos Autónomos: A Zenseact, uma empresa do grupo Volvo, desenvolveu um sistema de conduçãoautónoma com o SPARK para componentes de segurança crítica, obtendo a certificação ISO 26262, justamente porqueo SPARK "indica se existe qualquer possibilidade de erro em todos os caminhos de execução potenciais do código".A NVIDIA adotou o SPARK para enfrentar ambientes de cibersegurança crescentemente hostis em firmware ebibliotecas criptográficas de baixo nível.· Investigação de Voo Não Tripulado: Investigadores demonstraram um flight stack completo para um planador nãotripulado de alta altitude escrito e formalmente verificado em Ada/SPARK 2014, aplicando análise estática desdeo início do projeto e comprovando na prática que a verificação formal pode guiar o desenho do software em tempode desenvolvimento.Considerações FinaisO SPARK é a resposta madura e industrializada à pergunta "como construir software que é matematicamentecorreto?". Não é um protótipo de investigação, nem um conceito teórico: é uma linguagem, um conjunto deferramentas e um processo de certificação que já produziram dezenas de sistemas de segurança crítica em operaçãoreal.Ao ocupar a interseção entre a programação de alto nível (Ada) e a verificação formal dedutiva (GNATprove), oSPARK oferece um caminho pragmático para a correção por construção, permitindo às equipas de engenharia provar,com um esforço incremental, a ausência de erros de execução e a conformidade funcional do seu código com osrequisitos. É a escolha natural para sistemas aerotransportados, espaciais e de defesa onde a certificaçãoDO‑178C Nível A é um requisito incontornável e onde a confiança absoluta no software não é um luxo, mas umacondição de existência do próprio sistema.
O desenvolvimento de software para sistemas aviônicos é uma disciplina singular, onde a escolha da linguagem de programação está intrinsecamente ligada à segurança de voo. A resposta a esta questão exige a análise do principal documento normativo do setor, o DO-178C, e das justificativas técnicas que posicionam linguagens como Ada e C no centro de sistemas que não podem falhar.
O Contexto Normativo e a DO-178C
Introduzido em 2011 como uma evolução do DO-178B, o documento RTCA DO-178C / EUROCAE ED-12C, intitulado "Software Considerations in Airborne Systems and Equipment Certification" (Considerações de Software na Certificação de Sistemas e Equipamentos Aerotransportados), é o padrão internacional que rege a aprovação de software aerotransportado comercial. Autoridades como a FAA (EUA), a EASA (Europa) e a ANAC o utilizam como meio aceitável, embora não único, para demonstrar conformidade com regulamentos de aeronavegabilidade.
A DO-178C não prescreve uma linguagem de programação específica, mas estabelece critérios rigorosos para o processo de desenvolvimento. Define cinco níveis de garantia de projeto (DAL, Design Assurance Level), do nível A ao E, que qualificam o software conforme a severidade da condição de falha, variando de catastrófica a sem efeito na segurança. Para os níveis mais críticos (DAL A e B), a norma exige objetivos rigorosos de verificação, como cobertura de decisão modificada/condição (MC/DC) e rastreabilidade completa dos requisitos até o código-fonte.
É neste contexto que a escolha da linguagem se torna uma decisão de engenharia crítica. O processo de certificação não se concentra apenas na funcionalidade, mas também na análise de segurança e na garantia de que o comportamento do software é verificável, determinístico e previsível. A DO-178C exige que o código-fonte seja escrito em conformidade com um padrão de codificação definido e que a linguagem possua sintaxe não ambígua e um controle claro de dados. Os padrões de codificação, como o MISRA C e o JSF AV C++, surgem como ferramentas essenciais para mitigar os riscos de linguagens originalmente não projetadas para aplicações críticas.
O Cenário das Linguagens de Programação Aviônicas
A escolha da linguagem é um balanço entre expressividade, controle, segurança e viabilidade econômica no ciclo de vida de uma aeronave.
Ada e SPARK
A linguagem Ada foi criada por iniciativa do Departamento de Defesa dos EUA com o propósito de unificar as centenas de linguagens usadas em sistemas embarcados militares, incorporando confiabilidade e manutenibilidade. Hoje, o ecossistema Ada, impulsionado principalmente pela empresa AdaCore, é um pilar da aviônica civil e militar moderna. Exemplos notáveis incluem seu uso no sistema de controle de freio do Boeing 777 e no Sistema de Gerenciamento de Voo (FMS) do Airbus A380. A AdaCore também fornece ferramentas para grandes players como Thales, Lockheed Martin e Collins Aerospace, atuando no "coração da aviônica na Europa", como descreveu um de seus diretores.
A preferência por Ada reside em suas características técnicas, que se alinham com as exigências da DO-178C. Seu sistema de tipos forte e verificação em tempo de compilação, combinado com suporte nativo à programação concorrente (modelo de tarefas e rendezvous), permite a modelagem de sistemas de tempo real de forma segura e estruturada. A evolução da linguagem culmina no SPARK, um subconjunto formalmente verificável de Ada. SPARK permite que propriedades de segurança sejam provadas matematicamente através de contratos, satisfazendo diretamente os objetivos do suplemento de Métodos Formais da DO-178C (DO-333).
C e C++
A linguagem C constitui a espinha dorsal de incontáveis sistemas embarcados, incluindo os aviônicos, devido à sua eficiência e capacidade de manipulação direta de hardware. Por ser uma linguagem de propósito geral e com potencial para ambiguidades, seu uso em software crítico é estritamente condicionado à adoção de um padrão de codificação. O mais proeminente é o MISRA C, originalmente da indústria automotiva e amplamente adotado na aviônica, que define um subconjunto seguro da linguagem para evitar construções propensas a erros.
O projeto do caça F-35 Lightning II exemplifica uma evolução no uso de linguagens. Embora com um legado de software em Ada, o F-35 adotou amplamente C++ (com estimativas de repositórios indicando 53% C e 35% C++), mas sob um restritivo conjunto de regras conhecido como JSF AV C++ (Joint Strike Fighter Air Vehicle C++ Coding Standards). Este padrão, cujo documento está disponível publicamente no site do criador do C++, Bjarne Stroustrup, proíbe funcionalidades como tratamento de exceções, funções recursivas e alocação dinâmica de memória, que são fontes de não determinismo e dificultam a garantia de tempo de resposta e a análise de pior caso de execução (WCET). A proibição de exceções, em particular, ecoa a lição da falha do voo inaugural do foguete Ariane 5, onde uma exceção de software não tratada levou à autodestruição do veículo.
Linguagens de Modelagem (Model-Based Development)
Uma tendência crescente na aviônica moderna é o desenvolvimento baseado em modelos (MBD), onde o software é projetado com notações gráficas de alto nível, a partir das quais o código-fonte é gerado automaticamente. A abordagem está em conformidade com os suplementos DO-331 (Modelagem) da DO-178C.
Ferramentas como o MATLAB/Simulink da MathWorks, combinadas com o Embedded Coder, são capazes de gerar código C ou C++ qualificável para DAL A. De forma semelhante, o SCADE Suite da Ansys é uma ferramenta especializada que utiliza modelos de fluxo de dados e máquinas de estado para gerar código C ou Ada que é "correto por construção". O gerador de código do SCADE (KCG) é qualificado como ferramenta de desenvolvimento TQL-1 segundo a DO-330, o que permite aos desenvolvedores automatizar a verificação de baixo nível e focar na validação do modelo em si.
Assembly e Outras Linguagens
O uso de Assembly não desapareceu, especialmente em rotinas de inicialização de hardware e em sequências de chaveamento que exigem contagem exata de ciclos de máquina. Contudo, seu uso é minimizado ao extremo, sendo restrito a pequenos trechos onde a eficiência de mais alto nível não pode ser obtida. Para a DO-178C nível A, a cobertura de código deve ser verificada também em nível de objeto (object code), como suportado por ferramentas de análise como a LDRA, que verificam a correção do binário gerado pelo compilador.
Em relação a linguagens mais recentes, o Rust emerge como uma alternativa promissora, com discussões ativas na comunidade e em artigos acadêmicos sobre sua adequação à DO-178C, graças ao seu modelo de gerenciamento de memória (ownership) que garante segurança sem garbage collector. Embora ainda não seja uma linguagem dominante em sistemas aviônicos certificados, há um crescente ecossistema de ferramentas e pesquisas para viabilizar seu uso, especialmente para funções de segurança cibernética e módulos onde a segurança de memória é uma prioridade. O Java, por sua vez, encontra espaço em sistemas de informação de bordo ou aplicações de missão de menor criticidade, longe dos sistemas de controle de voo, uma vez que sua dependência de máquina virtual e coleta de lixo introduz complexidades de verificação incompatíveis com sistemas de tempo real estrito.
Motivos Técnicos e Normativos para a Escolha
A seleção de uma linguagem para software aviônico não é uma questão de preferência, mas de engenharia de sistemas, guiada pelos seguintes pilares:
· Determinismo e Previsibilidade de Tempo Real: Sistemas de controle de voo operam em ciclos fixos e precisam responder a eventos dentro de um limite de tempo máximo garantido, muitas vezes na casa dos microssegundos. Recursos como alocação dinâmica de memória, recursão ilimitada e coleta de lixo são terminantemente proibidos nos padrões de codificação de mais alta criticidade para garantir que o pior caso de execução (WCET) possa ser analisado e limitado.
· Segurança de Memória e Tipos: A robustez de um sistema começa na prevenção de erros. Linguagens como Ada e o subconjunto SPARK possuem sistemas de tipo extremamente fortes que detectam, em tempo de compilação ou por prova formal, uma vasta classe de erros como buffer overflow, dangling pointers e condições de corrida. Em C e C++, os padrões MISRA e JSF AV são a forma de conter os mesmos riscos através de restrições estritas.
· Verificabilidade e Rastreabilidade: A DO-178C exige que cada linha de código-fonte seja rastreável a um requisito funcional de baixo nível, e vice-versa. Linguagens com sintaxe clara e estruturas de controle bem definidas facilitam tanto a revisão manual por pares quanto a análise estática automatizada, que é uma peça central do processo de certificação. Ferramentas modernas, incluindo soluções de IA, auxiliam na priorização e correção de violações de padrões em bases de código C e C++, tornando a conformidade mais gerenciável.
Exemplos Práticos de Aplicação
A aplicação dessas linguagens pode ser vista em aeronaves que definem o estado da arte da aviação. O Airbus A380 utiliza o sistema operacional de tempo real particionado Integrity-178B da Green Hills Software, que suporta desenvolvimento em C, C++ e Ada, com Ada sendo a linguagem de seu sistema de Gerenciamento de Voo (FMS).
O Boeing 777, uma aeronave pioneira em sistemas fly-by-wire, foi uma das primeiras a ter seu sistema de controle de frenagem completamente programado em Ada, visando atender aos rigorosos requisitos de tempo real e segurança da FAA já sob a égide dos padrões DO-178 da época.
Por fim, o programa do caça F-35, um dos sistemas de software mais complexos já embarcados, com mais de 20 milhões de linhas de código, representa um ecossistema heterogêneo. Embora seu software de missão e de controle de voo seja predominantemente C++ sob o padrão JSF AV C++, ele convive com blocos críticos de software escritos em Ada e com a geração automática de código C a partir de modelos Simulink, demonstrando uma arquitetura em que a linguagem é selecionada de acordo com a função e o nível de criticidade do subsistema.
Em conclusão, a programação de sistemas aviônicos é um campo onde a máxima "o melhor para o trabalho" é elevada à sua potência máxima. Não há uma única linguagem, mas um espectro de ferramentas — Ada, SPARK, C, C++ e linguagens de modelagem — cada uma com seu lugar em um ecossistema meticulosamente projetado, cujo processo de seleção é moldado por décadas de lições de segurança e por um arcabouço normativo que visa garantir que o software nunca seja a causa de uma tragédia.