Trens operados pela RATP podem ser afetados pelo bug do ano 2038, e a Justiça francesa determinou que a Alstom corrija a falha.
Depois do famoso bug do ano 2000, volta a surgir a preocupação com um problema de data semelhante - desta vez ligado à forma como certos sistemas informáticos representam o tempo. E não se trata apenas de computadores: na França, esse risco também alcança sistemas embarcados em trens.
RATP, Alstom e o bug do ano 2038: como o problema veio à tona
De acordo com o jornal Le Parisien, citando uma reportagem do veículo L’Informé, a vulnerabilidade da RATP ao bug do ano 2038 foi descoberta por acaso em 2017. Na ocasião, funcionários tentaram inserir no software de um trem MI09 uma data posterior a 2037 - e o sistema não se comportou como deveria.
O caso, ainda segundo a mesma apuração, não seria pontual. Pelo menos 38 trens estariam envolvidos, e a exposição atingiria mais de um terço da rede operada pela RATP, incluindo o RER A e 8 linhas de metrô.
Disputa judicial: prazos, obrigações e recurso
A RATP teria pedido à Alstom que analisasse o problema a partir de 2018. Sem obter resultados práticos, a operadora levou a questão ao Judiciário em 2019.
Ainda conforme o L’Informé, o tribunal administrativo de Paris condenou a Alstom a corrigir o bug em uma decisão de 13 de novembro. O cronograma definido prevê:
- um diagnóstico/levantamento (estado da situação) a ser realizado em 12 meses;
- depois disso, um prazo de 5 anos para a empresa resolver o problema.
Citada pelo Le Parisien, a Alstom afirmou ter “tomado conhecimento da decisão do tribunal administrativo de Paris” e informou que decidiu recorrer.
Por que esse bug existe?
O bug do ano 2038 pode gerar impactos relevantes, em escala global, caso não seja corrigido nos sistemas afetados. A origem do problema está em softwares que representam o tempo como o número de segundos transcorridos desde 1º de janeiro de 1970, marco inicial do chamado tempo UNIX.
Como ilustração, um instante pode ser representado como o tempo UNIX 1765452748 - ou seja, 1.765.452.748 segundos após 1º de janeiro de 1970. O ponto crítico aparece porque, em programas e sistemas codificados em 32 bits, esse contador chega ao valor máximo em 19 de janeiro de 2038, às 03:14:07 (Tempo Universal), quando atinge o tempo UNIX 2.147.483.647.
O que Alstom alegou - e como o tribunal respondeu
Segundo o Le Parisien, a Alstom sustentou no processo que esse prazo-limite já era citado em publicações desde 1999 e que a própria RATP teria recomendado o uso de softwares de código aberto, que em geral seriam codificados em 32 bits.
Ainda assim, a decisão judicial teria destacado que “a RATP, que é responsável apenas pelos transportes em Paris e na Île-de-France, não dispõe de competências técnicas idênticas às da Alstom Transport, que é fabricante e projetista de material rodante”.
Boas práticas para reduzir o risco em sistemas ferroviários
Em sistemas embarcados de transporte, falhas de data podem afetar registros, agendamentos, diagnósticos e integrações com outras camadas de software. Por isso, além de corrigir o código, costuma ser necessário validar a solução com testes de regressão e simulações que avancem o relógio do sistema para além de 2038, garantindo que a operação permaneça estável.
Também é comum que projetos desse tipo exijam um inventário detalhado dos componentes afetados (computadores de bordo, módulos de comunicação, registradores e ferramentas de manutenção), já que o bug do ano 2038 pode estar tanto no software principal quanto em bibliotecas e dependências usadas internamente.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário