domingo, 21 de junho de 2015

Análise de riscos - o software que por vezes mata, menos mal que raramente

Colega atento enviou-me um interessante texto com a análise do acidente de Santiago, evidenciando a omissão de uma análise de riscos correta pela ADIF e RENFE relativamente á ausencia de automatismo de segurança para o caso de falha de atenção do maquinista à aproximação da curva (o comboio tinha o ATP/ERTMS desligado devido a deficiencias anteriores de software), e insistindo que não pode assacar-se a culpa principal ao maquinista que é o elo mais fraco, sempre que há um acidente:
http://ccaa.elpais.com/ccaa/2015/06/18/galicia/1434644914_903917.html

Ocorreu-me, ao ler o texto em que a senhora analisa a provável causa da falha de atenção, que o software, apesar das suas maravilhosas potencialidades, por vezes mata, menos mal que raramente. Neste caso da curva de Santiago, por não ter sido convenientemente desenvolvido e testado e por isso ter sido desligado.
Mas há outros exemplos recentes, de análise de riscos deficiente e de software como causa de acidentes fatais.

Já foi divulgada a causa provável da queda do Airbus 400M, ao descolar em Sevilha, num voo de testes à saída da fábrica. De assinalar a cultura de divulgação das causas de acidentes para contribuir para que eles não se repitam, em contraste com a cultura do respeito em vigor em Portugal, que deixa cair os inquéritos no esquecimento ou tem  o descaramento de apresentar como causa principal (não foi causa, foi circunstancia) do acidente de Alfarelos em 2013 o mau tempo.

O A-400M caiu porque houve um erro de procedimento relativamente aos ficheiros de consulta pelos computadores de controle e comando dos motores. A admissão de combustível a cada motor é comandada por um computador, duplicado por razões de segurança (os FADEC), que faz o mesmo que os cabos dos aceleradores nos antigos automóveis, mediante a informação recebida do piloto. Só que esta é comparada com os valores armazenados nos referidos ficheiros, os quais tinham por erro sido apagados, reduzindo a potencia em 3 dos 4 motores a valores insuficientes para  descolagem.
Sem prejuizo da engenharia da Airbus ser notável, e admitindo que decisores possam aceitar correr este nível de riscos (risco é a conjugação da probabilidade de um acidente com a gravidade das consequencias da sua ocorrencia, competindo aos decisores aceitar o risco se os custos da sua mitigação forme superiores aos prejuizos em função da sua probabilidade, isto é, se aceitam que, em milhões de voos, um ou outro caia por deficiencia da análise de riscos da componente software), conviria ampliar a divulgação das deficiencias de software responsáveis pelos, felizmente poucos, acidentes dos Airbus.
Recordo que o voo da Air France acidentado no Brasil teve origem em sondas de velocidade suscetiveis a avarias induzindo o software em erro, e sendo complicado ultrapassar o controle do computador pela tripulação (ver os comentários na altura dos pilotos da Boeing, em que os automatismos não têm essa predominancia, e dos pilotos da Qantas, que primeiro detetaram as deficiencias das sondas de velocidade).
Também o avião da Air Asia caiu porque o computador de controle do  leme   estava com intermitencias. Ao desligá-lo, o comandante provocou uma subida intempestiva e perda de sustentação que o copiloto não conseguiu evitar.

Aconteceu ainda, nos primórdios da informática na aviação, a queda de um avião de passageiros em Barcelona e de outro avião em demonstrações num festival aéreo, porque os dados armazenados nos ficheiros de altitude estavam errados.
Será que os atuais informáticos da Airbus têm memória do que se passou há 30 anos, não conseguindo evitar a mesma causa no acidente do A-400M?
 Seria interessante informar a opinião pública.

Sem comentários:

Enviar um comentário