exameinformatica

Uma parceria VISÃO

Siga-nos nas redes

Perfil

Software

«Tenho dúvidas sobre quando será possível ter aviões autónomos»

Através da certificação de software, Luís Gargaté, da Critical Software, passou a ser responsável pelas vidas de milhares de pessoas que todos os dias viajam de avião. Em entrevista, o especialista recorda que, apesar das falhas ocasionais, a automatização existe precisamente para evitar os erros dos humanos

  • 333

Depois de garantir um papel de destaque na anállise do software de missões espaciais, a Critical Software baixou a rota em várias milhas de altitude para garantir contratos relacionados com a certificação de aplicações usadas nos aviões das linhas aéreas comerciais. E é a meio dessa missão que encontramos Luís Gargaté, doutorado em Física que tem um brevê para pilotar aviões particulares e comerciais, e que hoje lidera as equipas de programadores da Critical que analisam os múltiplos e diferentes softwares que hoje são usados num avião comercial. Ainda com o acidente do Boeing 737 Max 8 na Etiópia na memória, o especialista da tecnológica de Coimbra recorda que a automatização apresenta desafios que nem sempre são humanamente solucionáveis. «Na prática é sempre possível desligar o sistema e passar a ter o controlo manual do avião. Na prática, é sempre possível desligar qualquer sistema que não esteja a funcionar. O problema é se se consegue desligar um sistema a tempo sem conduzir a um acidente», recorda o especialista da Critical Software.

Sem software não haveria aviação na atualidade!

Não haveria aviação como a conhecemos, sem dúvida nenhuma. Não seria possível gerir escalas de pilotos, escalas de aviões, tratar da manutenção… seria completamente impossível ter todo o nível e automatismo que temos atualmente.

Como é que se garante o equilíbrio e a cooperação entre todos estes sistemas de um avião?

Dentro de um avião há muitos softwares a diferentes níveis. Temos o software que gere o entretenimento para os passageiros, que é menos crítico, mas temos também o software que controla o piloto automático ou que controla as superfícies de controlo ou trem de aterragem do avião. Em geral, todos os softwares têm níveis críticos diferentes. Todo o software que vai para dentro de um avião é sujeito a escrutínio. Se o software que gere o entretenimento falhar, a única coisa que acontece é as pessoas ficarem aborrecidas, mas se por acaso esse sistema estiver ligado a outro, e alguém tentar entrar nos sistemas, então já estaríamos a falar de algo bastante sério. Todo o software que vai para dentro de um avião é sujeito a um escrutínio; como é que é desenvolvido, como é que é testado; como é que é certificado… e é nesses domínios que a Critical Software trabalha.

Esses módulos de software têm de ser estanques ou podem comunicar entre eles?

Obviamente que esses softwares têm comunicar (entre eles). Por exemplo, o Flight Director, que faz parte do sistemas de controlo dos aviões modernos, está ligado ao piloto automático. São sistemas diferentes, mas têm de comunicar entre eles… O Flight Director recebe informação dos pilotos, mas o piloto automático usa os diferentes dados de maneira a controlar o avião e assim poder seguir a rota programada pelo Flight Director. Há muitos sistemas dentro de um avião que estão ligados uns aos outros. Tem de se garantir que os interfaces (desses softwares) estão bem definidos, para ter a certeza de que não há maneira nenhuma concebível de um sistema fazer falhar outro. Tudo isto tem ser visto sistema a sistema… e depois tem de ser analisado do ponto de vista integrado…

O que dará mais de milhões de linhas código!

Nos sistemas mais complexos, sim… Há que garantir que a parte que é certificada é também a mais pequena e previsível que seja possível. Obviamente, que um sistema de piloto automático é muito complexo. Talvez não tenha milhões de linhas de código, mas serão certamente milhares. Quanto mais complexo é o sistema, mais difícil é fazer testes e garantir que funciona. Estamos a falar de sistemas que, no fim, têm de estar completamente testados de uma ponta a outra. Se tivermos um ficheiro escrito em C++ ou C… sendo que, se for uma das coisas mais críticas, será escrito em C, temos de testar todos os “ifs” (da expressão “if… then…” dos algoritmos), e todas as condições e linhas de código são testadas…

… O que não evita acidentes como o registado com o despenhamento de um Boeing na Etiópia, cuja responsabilidade foi atribuída ao software…

Uma pessoa pode testar o que quiser, mas se o sistema for usado fora dos limites… vai falhar. Isso é certo. Obviamente, que estamos a falar de acidentes de aviação – e mesmo nestes casos badalados e conhecidos é difícil dizer com toda a certeza o que aconteceu; aliás, é para isso que existem as investigações como aquela que está a ser levada a cabo pela Administração Federal da Aviação (FAA), porque (no acidente na Etiópia) se trata de um avião americano. Há uma parte dessas investigações que é preliminar e cujas conclusões conhecidas passados alguns meses, e há uma segunda parte da investigação que pode demorar um ou dois anos até dar a conhecer todas as conclusões de um relatório. Esses relatórios não existem para determinar culpados, mas sim para determinar causas. Em Portugal, há o Gabinete de Prevenção e Investigação de Acidentes com Aeronaves (GPIAA) para fazer esse tipo de relatórios sempre que há um acidente. Não é um trabalho trivial. Para qualquer acidente há um sem número de causas possíveis – nunca é só uma. Estes sistemas estão tão bem montados, que não chega uma coisa falhar para haver um acidente.

O acidente foi ou não gerado por um único bug de software?

Segundo algumas notícias, o problema daquele modelo de avião tem a ver com o sensor de ângulo de ataque, que permite saber se um avião está ou não em risco de entrar em perda. Pode acontecer uma falha com um sensor e já aconteceu noutras circunstâncias que não deram origem a acidentes. Obviamente, é algo que está dependente da ação dos pilotos ou da fase do voo. Numa fase crítica do voo, qualquer problema, por mais pequeno que seja pode originar um acidente. Se uma pessoa estiver a aterrar ou a levantar voo, e falhar um motor… é um cenário muito diferente um motor falhar na descolagem, a 100 metros do chão, de um cenário em que o motor falha quando estamos a 3000 metros de altitude, em que temos tempo para reagir, para declarar emergência… há sempre muitos fatores que contribuem para um acidente. Sabe-se que o software que contribuiu para esse caso em particular, mas não foi o único fator. Há também nas companhias aéreas procedimentos operacionais que os pilotos têm de seguir, também variam consoante as empresas e companhias… o treino dado aos pilotos também pode contribuir positiva ou negativamente para os acidentes. É muito fácil chegar a conclusões precipitadas sobre o que aconteceu num acidente.

Portanto, ainda temos de esperar pelo relatório final para ter uma ideia mais precisa do que aconteceu com o voo que se despenhou na Etiópia…

Para se perceber tudo o que se passou, o mais prudente é esperar pelo relatório final. É muito fácil tirar conclusões precipitadas sobre uma coisa que é complexa e até pode parecer simples. Houve um sensor que falhou e que levou a que o avião apontasse o nariz para baixo quando não deveria estar a fazê-lo… e isso aconteceu porque estava a receber instruções erradas do sensor. Isso é mais ou menos claro – mas daí até chegar a um acidente, muita coisa tem de acontecer.

Um Boeing 737 Max 8 parado na pista do Aeroporto Rainha Sofia, em Tenerife, Espanha, depois de aplicada a interdição de voo destes modelos pelas autoridades europeias

Um Boeing 737 Max 8 parado na pista do Aeroporto Rainha Sofia, em Tenerife, Espanha, depois de aplicada a interdição de voo destes modelos pelas autoridades europeias

NurPhoto

Não era suposto o piloto poder inverter essa manobra? O software do avião teve prevalência sobre as ações do piloto?

Claro que é suposto os pilotos conseguirem controlar um avião e sobreporem-se aos sistemas de automação e ao software. Mas, por outro lado, – e aqui é que está o busílis da questão – os sistemas de automação existem precisamente para evitar os erros dos pilotos.

… também são esses sistemas que podem evitar manobras típicas de um atentado!

O propósito essencial de todos os sistemas a bordo de um avião é garantir melhor segurança. E isso tem sido conseguido. A aviação é uma das indústrias mais seguras de todas! Se olharmos para os números, verificamos que a automação tem contribuído positivamente para a segurança aeronáutica. Nesse caso em particular (do despenhamento do avião na Etiópia), o sistema em causa existe para evitar que o avião entre em perda. Trocado por miúdos: evitar que o avião perca sustentação nas asas e comece a cair. É uma coisa que qualquer piloto treina para recuperar manualmente, a um nível básico. A questão é se queremos ter um sistema automático que evita que os aviões entrem em perda… o que pode ser excelente para voos comerciais, porque não queremos ter as pessoas a vomitar ou a bater com a cabeça no teto e etc.. Realmente é um sistema que dá mais segurança, assim como o piloto automático. A questão é que os sistemas e os aviões estão a ficar cada vez mais complexos… e é por isso que os pilotos têm de treinar com diferentes modelos de aviões. Os sistemas estão tão complexos que para conhecer os comportamentos, detetar falhas, e saber como agir não é trivial. É o reverso da medalha da automação dos aviões. No somatório de tudo, o software tem garantido a segurança da aviação…

Mas até que ponto o software se pode sobrepor às decisões de um piloto?

Depende de como é que os sistemas funcionam… e de quem se sobrepõe a quem. Vai depender dos modelos e dos fabricantes. A Airbus e a Boeing são dois dos maiores fabricantes e têm filosofias um pouco diferentes do assunto. Na prática é sempre possível desligar o sistema e passar a ter o controlo manual do avião. Na prática, é sempre possível desligar qualquer sistema que não esteja a funcionar. O problema é se se consegue desligar um sistema a tempo sem conduzir a um acidente. Os pilotos têm à disposição o manual operacional do avião e, para qualquer situação prevista, como uma falha do motor, do sistema hidráulico, ou no sistema primário do trem de aterragem, há procedimentos que os pilotos têm de seguir para resolver o problema. Mas para isso é necessário poder diagnosticar esse problema. Se houver muito pouco tempo para resolver o problema… por exemplo porque o avião começa a apontar o “nariz” para o chão quando está a descolar, em casos de stress ou perigo como estes não há muito tempo para perceber o que está a acontecer. Vai depender muito do treino dos pilotos, dos manuais operacionais da companhia aérea, ou de como é que os sistemas foram desenhados. Outro exemplo: o próprio piloto automático vai buscar informação a sensores, como o tubo de Pitot, que mede a velocidade. O piloto automático tem de ir buscar essa informação para saber o que está a fazer. Estes sistemas estão desenhados para operar dentro de certos limites; se o tubo de Pitot falha, congela e deixa medir a velocidade, o piloto automático, num caso desses, emite tipicamente um aviso sonoro dentro do cockpit e desliga-se, porque indica que a velocidade é zero… é assim que estes sistemas funcionam.

Nesse caso, são os humanos que asseguram a redundância!

Existe redundância ao nível do software e dos computadores de bordo; tipicamente o piloto automático corre em mais do que um computador e os resultados são sempre comparados. Mas tem de haver uma solução – e se essa solução estiver bem desenhada, pode levar o piloto automático a desligar-se e o voo passa a ser controlado pelo piloto. Há um aviso sonoro, o controlo passa para o piloto – e não há problema. Mas já houve casos no passado que têm a ver com isto. O piloto automático controla os três eixos de movimento do avião. Houve casos em que o piloto automático se desligou num dos eixos, os pilotos não se aperceberam, e houve um acidente. Isso aconteceu com um avião Aeroflot (da Rússia) há muitos anos… o desligamento do piloto automático foi um dos fatores, mas não foi o principal. O fator principal, neste caso, deveu-se ao facto de o desligamento do piloto automático ter sido provocado pelo filho do comandante, que estava a brincar com os controlos. Os pilotos não se aperceberam; o avião começou a rolar para um dos lados; o piloto automático tentou compensar, mas não impediu que o avião entrasse em perda. Hoje, não é possível um piloto automático desligar-se sem haver um aviso sonoro. A investigação que é feita em cada acidente tem por objetivo a melhorar estes sistemas ao longo do tempo.

Já há quem fale em aviões que voam de forma totalmente autónoma, como acontece com os carros… É viável ou mesmo ficção científica?

Tenho as minhas sérias dúvidas sobre quando é que isso será possível. Há sistemas para aterrar aviões que permitem aterrar um avião de forma completamente automática dentro de certas condições. Em certas condições, algumas pistas e alguns modelos de aviões, os pilotos automáticos conseguem aterrar um avião automaticamente. É algo que existe e está a funcionar. Voar lá em cima, e descolar também são coisas tecnicamente triviais. Tecnicamente, é possível construir um avião que faça tudo sozinho, sem intervenção humana. O problema começa quando há falhas ou imprevistos. É muito complicado prever todas essas situações, assim como será complicado chegar a um ponto em que poderemos dizer que o humano nada está a fazer (no cockpit) e que é muito mais seguro ter os computadores a tomar conta (do voo)…

Não acredita que seja possível?

É uma evolução difícil. Vai levar tempo. Se calhar, no caso dos carros, também vai ser necessário mais tempo do que aquele que tem sido previsto. Os aviões estão num ambiente mais ou menos controlado, com rotas predeterminadas e é mais fácil de controlar o ambiente à volta de um avião do que dum carro… há pessoas na rua, há animais, há nevoeiro, há buracos na estrada, há neve. Desenvolver um sistema até chegarmos a um ponto em que não é necessário alguém a controlá-lo ainda é capaz de demorar algum tempo.

O software de um avião deve estar sujeito a certificações e requisitos técnicos bastante exigentes… o software pode ou não ser reaproveitado?

Isto funciona muito na base de reutilização de partes de software e dos sistemas (do passado). É algo que não é tão visível no software, mas o próprio hardware tem de ser certificado. O que faz com que o processo de certificação seja tão complexo e oneroso. E por isso tenta-se reutilizar ao máximo software entre os diferentes modelos. Quando se lança uma nova funcionalidade em cima daquilo que já existe, tornando a certificação mais simples. É um mercado em que é muito difícil de penetrar por novos concorrentes, porque exige um investimento inicial muito grande.

A qualidade do software influencia os ganhos alcançados em termos de desempenho de um avião?

A maneira como as companhias aéreas fazem esse tipo de coisas já é muito eficiente. As margens de lucro já são muito baixas e a competição é muito grande. Já são utilizados sistemas computorizados para fazerem o planeamento de voo, e selecionar a velocidade mais indicada para o avião chegar a horas ao destino, ou pelo menos não falhar “slot” disponível, caso contrário terá de ficar à espera e consumir mais combustível. Esse género de considerações já é feito pelas empresas. As companhias aéreas precisam de saber qual a quantidade de combustível para um determinado voo. Obviamente, que há requisitos legais mínimos. Se um avião estiver a preparar-se para aterrar num local com uma grande tempestade, possivelmente é posto em espera… e logo é preciso ter isso em consideração. É necessário software para fazer cálculos de combustível, de desempenho, e etc. etc.. As coisas já são muito eficientes. Eventualmente, a parte de Inteligência Artificial (IA) poderá ter um papel que ainda não foi explorado. A IA e a aprendizagem das máquinas estão a ser usadas em muitos domínios e poderão ser usadas também na eficiência ou na manutenção aeronáutica. Ter um avião parado custa dinheiro. Pôr combustível a mais também custa dinheiro.

Possivelmente, os diferentes profissionais da aviação civil terão de passar a receber mais formação na área da informática…

Tipicamente, o pessoal de manutenção, operação e ainda os pilotos são os utilizadores destes sistemas. Há alguns componentes desenvolvidos pelas companhias aéreas, mas a maior parte destes sistemas é desenvolvida elos fabricantes ou por empresas que trabalham com a indústria aeronáutica.

Que tipo de clientes tem a Critical Software nesta área?

Não trabalhamos para os operadores, mas para os fabricantes de aviões ou de componentes para aviões. Por exemplo, o trem de aterragem usa software de controlo. Além de controlar se o trem de aterragem desce ou sobe, este sistema tem de garantir que lê os sensores e que o avião está a aterrar ou descolar, emite alarmes se o trem não estiver em baixo na aterragem. Desenvolvemos este software para alguns destes sistemas, mas noutros casos validamos o software desenvolvido pelos fabricantes. É esse o nosso papel na maior parte destes casos. Já trabalhámos, possivelmente, com aviões de todos os fabricantes. A Airbus, Boeing, a Bombardier… Também trabalhamos a parte da documentação usada na certificação.

É um segmento em crescimento?

Sim. Obviamente, que está sujeito a ciclos económicos. Quanto mais as pessoas viajam, mais as companhias precisam de aviões e pilotos e mais trabalho há para fazer. É um setor de alta inovação. Uma pequena mudança na forma da asa ou nas pás do motor pode representar um ganho no consumo de combustível que dá uma vantagem económica às companhias aéreas que comprarem esse avião. Há muita investigação em torno da eficiência, mas todos os desenvolvimentos têm de ser certificados. E é aí que nós entramos.

  • 333