Uma ferrovia é um grande sistema distribuído: ativos em movimento, infraestrutura compartilhada, tempo rigoroso, restrições de segurança e vários operadores. A lição de engenharia não é colocar o controle do trem em um backend web, mas entender coordenação, dados antigos, operação degradada e fronteiras de segurança claras.
A alta velocidade ferroviária europeia depende de sinalização interoperável, comunicação por rádio, gestão de tráfego, material rodante e infraestrutura. A Agência Ferroviária da União Europeia descreve o ERTMS como sistema harmonizado de sinalização e controle de velocidade, incluindo ETCS, comunicação móvel ferroviária e regras operacionais. A nova Telematics TSI, em vigor desde março de 2026, trata também de troca de dados, APIs, gestão de tráfego, informação ao passageiro e cibersegurança. Não é uma única pilha de software: são sistemas conectados com requisitos distintos de garantia e tempo.
Este é um paralelo de arquitetura, não orientação operacional ferroviária. A proteção do trem ligada à segurança é governada por normas e componentes certificados. Backend de uso geral, cloud ou modelo de IA não deve ser apresentado como controlador de frenagem ou autoridade de movimento.
Horário é plano, não verdade absoluta. Posição do trem, estado da infraestrutura e restrições chegam de modo assíncrono; podem atrasar, duplicar ou divergir. Toda atualização deveria carregar origem, instante da observação, intervalo de validade, sequência/versão e qualidade. O consumidor precisa saber se lê estado atual, evento atrasado ou plano revisado.
Cada dado tem prazo diferente. Painel de passageiros pode tolerar atraso curto se indicar incerteza; despacho operacional precisa de frescor e confirmação mais rigorosos; funções de segurança usam comunicação determinística própria e comportamento certificado. Defina orçamento ponta a ponta, sincronização de relógios, limite de dado vencido e ação quando a garantia temporal falha.
| Classe de dado | Propriedade técnica | Modo degradado |
|---|---|---|
| Informação ao passageiro | Frescor, origem e consistência de plataforma/horário. | Exibir “estimativa” ou último valor confirmado; não inventar precisão. |
| Operação de tráfego | Ordenação de mudanças, detecção de conflito, confirmação e auditoria. | Manter plano conhecido seguro, sinalizar incerteza e pedir revisão operacional. |
| Restrição da infraestrutura | Versão, validade, emissor autorizado e propagação. | Não descartar silenciosamente; escalar dado vencido ou conflitante. |
| Controle ligado à segurança | Garantia, limites determinísticos e comportamento de subsistema aprovado. | Seguir o modo seguro/degradado certificado, não fallback de cloud. |
Mudanças operacionais lembram streams: avisos de atraso, troca de plataforma, restrições, passagem de trem entre operadores e ações de recuperação. Use IDs imutáveis, consumidores idempotentes, eventos explícitos de correção e histórico reproduzível. Separe fatos observados de previsões e decisões do operador. Se fontes divergirem, preserve ambas e encaminhe o conflito à autoridade definida, em vez de sobrescrever pela data mais recente.
Estado distribuído precisa considerar partições de rede e fronteiras nacionais. Uma visão central pode estar incompleta temporariamente; sistemas locais podem ter informação mais recente. Defina propriedade e regras de conciliação por domínio. Evite um campo mutável “status do trem” que apague procedência e esconda a razão da mudança.
Ferrovias distinguem safety (risco inaceitável a pessoas/ambiente) de cybersecurity (proteção contra acesso, alteração ou perda indevidos ou acidentais). Incidente cibernético pode afetar segurança ou disponibilidade, mas controles e casos de garantia não são idênticos. Segmente OT, autentique fontes, proteja acesso de manutenção, governe mudanças de fornecedores e ensaie coordenação entre gestores de infraestrutura e operadoras. Pentest não comprova safety case; aprovação de segurança também não cobre todo serviço IT conectado.
Na camada operacional não relacionada à segurança, construiria uma plataforma de eventos versionada com identificador canônico de trem/viagem, horário da fonte e observação, janela de validade, sequência, procedência e vínculo de correção. Consumidores usariam chaves idempotentes e contratos de schema; uma projeção serviria o melhor estado conhecido com indicadores de frescor e incerteza. Um worker conciliaria horários, posição e avisos da infraestrutura, emitindo conflitos para revisão operacional.
Objetivos de serviço seriam específicos por produto de dados: atraso de entrega de eventos, frescor da projeção, tempo de resolução de conflitos, perda/duplicação e ponto de recuperação. Painéis mostrariam qualidade e procedência, não só uptime de API. Comandos críticos e autoridade de movimento permaneceriam fora desta plataforma geral, dentro da arquitetura ferroviária certificada.
Ferrovias oferecem um estudo valioso de sistemas distribuídos: tempo, estado compartilhado, interoperabilidade e degradação segura são visíveis no mundo real. Separe planos de observações, mantenha procedência e validade em cada evento, torne conflitos explícitos e teste partições de rede. Acima de tudo, mantenha orquestração IT geral distinta do controle ferroviário certificado.
Nota editorial: Este artigo é uma analogia de engenharia, não orientação operacional nem certificação de segurança. Consulte TSI, ERA, gestor de infraestrutura e especialistas ferroviários para implantação real.