Sistemas Críticos e Ada
Por Daniel Bento para Pplware!
Um computador precisa de instruções para funcionar, qualquer que seja o seu tipo. É necessária uma linguagem legível para o ser humano mas, que possa ser interpretada pela máquina. Define-se como um conjunto de regras sintácticas e semânticas que são criadas para construir um programa. Este lê, executa, processa, transmite e/ou armazena os resultados dessas instruções.
Actualmente, existem diversos paradigmas de programação, bem como linguagens, cada uma com especificidades diferentes. Os programadores e engenheiros conseguem, deste modo, construir programas (aplicações) organizados, rápidos e eficientes na execução da tarefa para que foram destinados. Por vezes, este código é traduzido para uma outra linguagem onde, finalmente, é compilado numa sequência lógica inteligível pela máquina. Diz-se ser sistema crítico todo aquele que, em caso de falha, pode resultar em danos materiais, ambientais e ainda, morte ou lesões graves em pessoas.
O primeiro trabalho numa linguagem de programação foi realizado por Ada Lovelace, a melhor amiga de Charles Babbage, a primeira pessoa a idealizar um projecto de computador mas, que nunca viu a luz do dia. Mais tarde, nasceu a linguagem de programação ADA, em homenagem a esta programadora.
Ada é um tipo de linguagem de programação estruturada, imperativa, tipificada, orientada a objectos e uma linguagem de alto nível. Teve na sua origem outras linguagens, como Pascal. Foi construída por uma equipa no Departamento de Defesa dos Estados Unidos, durante a década de 70, com o objectivo de substituir várias centenas de outras linguagens usadas nesse mesmo departamento. Neste sentido, Ada foi idealizada para uso em sistemas críticos, como software aeronáutico, aeroespacial, bancário, clínico... Damos especial destaque neste artigo aos sistemas aeroespaciais. Com um alto nível de confiabilidade, esta linguagem é usada em variadíssimos foguetões, como no Ariane ou, até mesmo, no Space Shuttle.
O Ariane é um foguetão descartável, usado para colocar satélites artificiais em órbitas geoestacionarias ou de baixa-altitude. São operados pela Arianespace e usados, fundamentalmente, sob supervisão da ESA. Actualmente, na sua versão V, com uma capacidade de carga na ordem das 20000kg em órbitas de baixa altitude e de 10000kg em órbitas geoestacionarias, é um dos foguetões com maior taxa de sucesso mundial (cerca de 94%).
Aquando do primeiro lançamento do Ariane 5 (4 de Julho 1996), houve uma falha que resultou na perda total do foguetão. Em consequência desta falha, após averiguação técnica, verificou-se que o problema ocorreu durante uma conversão de valores numéricos.
Este foguetão tem um software interno que permite, através dos dados oriundos dos sensores, saber exactamente a trajectória que está a tomar. Apesar da evolução de hardware e sistema de propulsão no Ariane 5, o software era o mesmo do modelo anterior.
Este pequeno excerto de código foi responsável pela falha técnica:
L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * _M_INFO_DERIVE(T_ALG.E_BV)); if L_M_BV_32 > 32767 then P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#; elsif L_M_BV_32 < -32768 then P_M_DERIVE(T_ALG.E_BV) := 16#8000#; else P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32)); end if; P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));
Do ponto de vista técnico, estas linhas de código significam que o sistema faz um cálculo dos valores de aceleração e que deveriam ser guardados num espaço limitado em memória de 16 bits. Mas, uma vez que a propulsão do sistema era maior, o valor que foi obtido necessitava de mais espaço reservado, contrariando a ideia que os engenheiros tinham.
Assim, o sistema deu um erro que, ao não ser tratado, o obrigou a mudar para o modo de backup. Por outro lado, dado o paralelismo entre execuções contínuas do programa, este sistema de backup já tinha sido activado e, como esperado, bloqueado. Deste modo, o foguetão ficou sem informação sobre a sua posição relativa e saiu da trajectória correcta.
Em suma, é possível assumir que, até última instância, o erro é humano. Apesar de um foguetão ser um engenho de tecnologia de ponta verifica-se que é extremamente sensível a erros humanos. A complexidade da máquina/sistema determina a complexidade dos algoritmos que são usados para que esta funcione mas, consequentemente, os programas têm de ter autonomia para definir um plano de emergência quando determinados problemas acontecem, evitando o pior.
Este artigo tem mais de um ano
Muito bom artigo.
Será natural que o espírito inventivo/criativo do homem possa gerar maravilhas ou horrores.
Bom Ano e continuem o bom trabalho que é este site.
Cump’s
A única diferença entre um louco e um génio, é o sucesso das suas ideias…
Gostei imenso do artigo! Não é sempre que se vê destes por cá e há que apreciar ao máximo! 🙂
interesante
Muito bom. É de mais informação como está que faz falta aqui neste forum
Se em vez de 16#7FFF# tivessem posto 16#7FFH#, teria sido ainda pior 🙂
Porque??? Podes-me explicar? (eu nao percebo nada disso xD)
numeros hexadecimais so vao [0 ao 9] e [a ao f]
Bom artigo e boa iniciativa…Só um preciosismo não é ADA mas sim Ada :)… Relativamente à linguagem Ada, ela tem na sua base especificações que a tornam uma boa ferramenta para sistemas críticos, mas o que dita a sua aplicação a tais sistemas é o compilador que por sua vez este pode não ter uma certificação para tais sistemas. Por exemplo os compiladores de Ada83 tinham algumas falhas que punham em causa a sua utilização em tais sistemas
Muito bom!
Muito interessante!
Agora uma coisa de um gajo que não percebe nada disto:
Como neste exemplo se lidam com coisas extremamente complexas e caras, aconteceu uma falha grave em que o erro que a originou foi detectado, quantas vezes este código “malicioso” foi visto revisto ou verificado? Se foi descoberto o erro concerteza sabem quem foi a pessoa que escreveu o código… como é que se lida com estas coisas em termos de responsabilidades? É o programador que é “queimado” ou será quem verificou ou quem supervisiona?
Interessante não?
Por exemplo, sabemos que a Critical Software tem andado a desenvolver software para a área militar, serão os clientes finais (Usa, Uk, Itália…) que irão validar as linhas de código? De quem será a responsabilidade se um dia destes um helicóptero se “lembrar” de apontar as metralhadoras contra civis? Erro humano? erro de software?
Como será o estado de espírito de um programador que se venha a descobrir que se enganou numa linha de código?
Falo em termos militares, mas situações destas acontecem em qualquer área da vida moderna, por exemplo quantos “bugs” haverá na área da Saúde nos equipamentos que por ai andam?
Foi apenas uma pequena reflexão…
tens que ver que no caso hipotetico que deste do helicoptero nao eh o mesmo que vai apontar, é o ser humano que escolhe o alvo, obviamente que o sistema executa a ordem do controlador, pelo que existirao sempre esses casos que falas. quanto a validaçao do codigo penso que se de facto se determinar que a causa de certa situaçao ter sido do software o governo/empresa ira pedir responsabilidades á empresa que o desenvolveu. mas la esta, penso eu.
cumps, e um bom ano =D
uau, grande artigo, parabens ao autor
Gostei do artigo. Venham mais como este 🙂
Basicamente o fogetão rebentou por causa de um “segmentation fault”. Esperto.
Muito interessante , de referir que estes foguetões por questões de segurança quando se desviam da rota estão programados para destruir-se , excelente artigo , queremos mais destes .
Cumprimentos
Serva
Dizes que estão programados para se destruírem, essa programação é que nunca falha! lol…
Quanto ao resto da programação… é que vão aparecendo uns bugs…