Sim, um SAE (Sistema de Apoio à Exploração) pode integrar-se com praticamente qualquer equipamento de bordo, mas apenas se o caderno de encargos o exigir explicitamente. Na prática, «independente do hardware» significa um software que funciona em equipamentos normalizados e comunica com o equipamento de bordo existente através de interfaces abertas e documentadas, em vez de vir acoplado à caixa proprietária de um único fornecedor. Cinco cláusulas nas peças do procedimento fazem a maior parte do trabalho: especificar resultados, exigir interfaces abertas, separar o hardware, garantir a propriedade dos dados e a saída, e testar as promessas antes da adjudicação.
A razão é estrutural. Num artigo publicado na revista especializada Mass Transit em fevereiro de 2026, Gabriel Lopez-Bernal defendeu que muitos fornecedores de software para transportes públicos não conseguem vender apenas software e têm de fornecer hardware para recolher os dados de que precisam, porque o setor carece de plataformas de hardware abertas e normalizadas. O autor representa um fornecedor de soluções de conectividade, pelo que o texto deve ser lido como uma opinião do setor, mas o mecanismo que descreve é familiar a qualquer comprador que já tenha tentado alargar um projeto-piloto.
Porque é que os concursos de SAE acabam presos ao hardware de um único fornecedor?
A dependência raramente nasce de uma única cláusula mal escrita. Constrói-se a partir de vários hábitos.
- Especificações com a forma de um produto. O caderno de encargos descreve exatamente o equipamento do fornecedor atual, acrescenta «ou equivalente» e parte do princípio de que a concorrência fica assegurada. O direito europeu da contratação pública é mais exigente: nos termos do artigo 42.º, n.º 4, da Diretiva 2014/24/UE (e do artigo 60.º, n.º 4, da Diretiva 2014/25/UE, relativa aos setores especiais, que abrange muitos operadores de transportes), as especificações técnicas não podem fazer referência a um fabrico, marca, patente ou tipo determinados, salvo se tal for justificado pelo objeto do contrato e, apenas a título excecional, quando não for possível uma descrição suficientemente precisa, acompanhada da menção «ou equivalente». Na prática, uma marca seguida de «ou equivalente» continua a moldar as propostas em torno de um produto.
- Fornecimento agregado. O software só é oferecido em conjunto com routers, computadores de bordo ou outros equipamentos, pelo que substituir o software implica substituir o hardware.
- Pilotos que nunca terminam. Testar um produto já disponível no mercado é avaliação, não inovação, e os operadores que mantêm pilotos longos muitas vezes não os conseguem alargar.
- Dados fechados. Os dados recolhidos a bordo só estão acessíveis através das ferramentas do próprio fornecedor.
Quais são as 5 cláusulas de um concurso de SAE independente do hardware?
1. Especificar resultados e dados, não produtos
Descreva o que o sistema tem de medir e com que qualidade, em vez de indicar que equipamento deve medir. Por exemplo: intervalo de atualização da posição, percentagem de viagens corretamente associadas a um veículo, precisão da deteção de chegadas e partidas nas paragens, disponibilidade do serviço. São os mesmos fatores de qualidade que determinam se as ferramentas de planeamento são fiáveis: intervalos de atualização longos degradam a deteção de chegadas e partidas, e taxas baixas de identificação dos motoristas deixam muitas viagens sem veículo associado. O nosso artigo sobre como a IA está a mudar o planeamento de redes de autocarros mostra porque esta qualidade dos dados é a base de tudo o resto. São precisamente estes dados reais que o módulo de supervisão da exploração em tempo real, Operations, fornece.
2. Exigir interfaces abertas e documentadas
Peça documentação pública da API, um ambiente de teste e saídas normalizadas: GTFS e GTFS-RT para horários e dados em tempo real, SIRI e NeTEx quando a rede ou o país os exigem (veja que norma de dados em tempo real se aplica em cada país). Peça a lista das interfaces que já estão em produção, por exemplo com painéis de informação ao público, contagem de passageiros ou software de planeamento, em vez de interfaces que seriam apenas possíveis. A Pysae, por exemplo, tem integrações publicadas com o Hastus ou o ABC Planning, com a solução de contagem de passageiros Iris e com a informação ao público da Hanover Displays através de uma ligação IP.
3. Separar o hardware do software
Aceite equipamentos normalizados, como smartphones ou tablets, como opção de bordo conforme, e escreva uma especificação mínima de equipamento em vez de um modelo. Quando o veículo já tem um computador de bordo, peça ao concorrente que explique como o software se liga a ele. Na Europa, a associação ITxPT, cuja missão é permitir a interoperabilidade entre sistemas informáticos nos transportes públicos, publica especificações que abrangem as interfaces de hardware, os protocolos de comunicação e os serviços a bordo, e atribui um selo a veículos, software e equipamentos conformes. Segundo o artigo da Mass Transit, Helsínquia, Paris, Estocolmo e Dubai encomendam autocarros com computadores de bordo certificados ITxPT para poderem escolher o software sem ficarem presos a um fornecedor. A Ruter, em Oslo, evoluiu para uma arquitetura de bordo aberta baseada no ITxPT. Para a parte do hardware, veja o módulo de telemática de bordo, Fleet.
4. Garantir a propriedade dos dados, a exportação e a saída
Estabeleça no contrato que os dados reais (posições, viagens realizadas, pontualidade, quilómetros) pertencem à autoridade de transportes ou ao operador. Exija a exportação integral num formato documentado a qualquer momento, um plano de saída com apoio à transição e clareza sobre se a exportação tem custos. Um sistema cujos dados não podem ser extraídos não pode ser substituído, o que torna qualquer mudança de fornecedor demasiado cara para ser uma posição negocial credível.
5. Exigir o custo do ciclo de vida, a receção com base em resultados e um teste antes da adjudicação
Peça aos concorrentes o custo total durante o prazo do contrato, tratando os serviços por subscrição como custos de exploração, para que as propostas possam ser comparadas: um preço de aquisição inicial mais baixo pode tornar-se a opção mais cara quando se somam a substituição do hardware, a manutenção e as atualizações ao longo de dez anos. Baseie a receção em resultados mensuráveis como os da cláusula 1. Por fim, antes da adjudicação, faça uma demonstração curta num conjunto variado dos seus próprios veículos: ligar a um equipamento existente, chamar a API, exportar um dia de dados. A recomendação do artigo de tratar os produtos já comprovados no mercado como demonstrações e não como pilotos segue a mesma lógica.
Como verificar uma promessa de «independência do hardware» antes de assinar?
Quatro testes rápidos separam a abertura real do marketing.
- Demonstração com frota mista: execute o software em dois ou três tipos de veículos e configurações de bordo diferentes da sua própria rede.
- Teste da API: peça acesso a uma sandbox e teste diretamente os endpoints documentados.
- Teste de exportação: peça uma exportação completa de um dia de viagens num formato documentado.
- Verificação de referências: fale com um cliente que migrou de outro sistema, e não apenas com um que começou do zero.
Para o processo de seleção no seu conjunto, consulte o nosso guia sobre como escolher um SAE para operadores de autocarros e a nossa lista de verificação de funcionalidades SAE 2026.
A Pysae é uma plataforma SaaS de apoio à exploração que funciona em equipamentos normalizados e disponibiliza saídas normalizadas. É tarifada por veículo, adaptada a cada rede. Se quiser rever o seu caderno de encargos connosco, entre em contacto.
Perguntas frequentes
O que significa independente do hardware num SAE?
Significa que o software não depende do equipamento de bordo proprietário de um único fornecedor. Funciona em equipamentos normalizados, como smartphones ou tablets, e liga-se ao equipamento de bordo existente através de interfaces abertas e documentadas.
Que normas deve um caderno de encargos referir?
GTFS e GTFS-RT para horários e dados em tempo real, SIRI e NeTEx quando exigidos pela rede ou pelo país, e ITxPT para a interoperabilidade a bordo na Europa. A combinação certa depende da sua rede e dos requisitos nacionais.
Como evitar a armadilha do «ou equivalente»?
Redija os requisitos como resultados e interfaces e não como nomes de produtos, tal como as diretivas europeias de contratação pública já exigem, salvo em casos justificados. Fixe limiares mensuráveis para a qualidade dos dados, especifique interfaces abertas e exija um teste nos seus próprios veículos antes da adjudicação.
Fontes: Gabriel J. Lopez-Bernal, «The Hardware Trap: Why Transit Can't Buy Tomorrow's Software», Mass Transit (17 de fevereiro de 2026); Diretiva 2014/24/UE, artigo 42.º, e Diretiva 2014/25/UE, artigo 60.º (EUR-Lex); ITxPT, «What is ITxPT?», FAQ e «A Common Vision for a Cost-effective and Sustainable IT Architecture» (itxpt.org); HERE, «What Oslo's buses can teach us about data collection» (Ruter); especificações ITxPT (itxpt.org).