Funcionalidades de um SAE em 2026: lista de verificação

Um SAE (Sistema de Apoio à Exploração) para autocarros deve, no mínimo, localizar cada veículo em tempo real, associá-lo à viagem que está efetivamente a realizar, dar aos reguladores do Centro de Controlo de Operações ferramentas para agir sobre os atrasos e publicar esses dados em feeds GTFS-RT standard para a informação ao público. Em 2026, uma lista restrita séria verifica também os relatórios contratuais, o acesso aberto aos dados, a flexibilidade do equipamento e a cibersegurança, porque as regras da UE tornam agora os dados em tempo real uma obrigação e não uma opção.

As listas de funcionalidades dos fornecedores são todas parecidas. Esta lista de verificação organiza as funcionalidades de um SAE em três níveis: obrigatório (não assinar sem ele), desejável (a esperar no primeiro ano) e opcional (útil consoante a frota e o contrato).

É deliberadamente centrada nas funcionalidades. A abordagem global (cobertura da frota, equipamento, rapidez de implementação) é tratada no nosso guia Como escolher um SAE para operadores de autocarros.

Que funcionalidades base de um SAE são inegociáveis?

Localização e associação às viagens

Os dados de posição, por si só, são telemática. Um SAE sabe que viagem cada veículo está a realizar e qual o seu desvio face ao horário.

• Obrigatório: atualização das posições em intervalos curtos e configuráveis; associação automática de cada veículo à sua viagem programada a partir do horário GTFS importado; deteção de chegadas e partidas nas paragens; desvio ao horário calculado por paragem.
• Obrigatório: tratamento claro das viagens não associadas. Pergunte que percentagem de viagens é corretamente associada numa rede real e o que acontece quando um motorista se esquece de iniciar sessão ou um veículo é trocado a meio do serviço.
• Desejável: monitorização dos intervalos nas linhas de alta frequência, onde a regularidade conta mais do que o cumprimento do horário.
• Opcional: eventos por geofencing (saída da estação de recolha, paragem escolar) que disparam alertas.

Controlo e regulação

• Obrigatório: um mapa em tempo real e diagramas de linha com o desvio por veículo; alertas de adiantamento, atraso e veículos em falta; possibilidade de suprimir, acrescentar ou reatribuir viagens.
• Desejável: gestão de desvios de percurso que atualize as paragens servidas e passe diretamente para a informação ao público. É nos desvios que muitos feeds em tempo real falham (para a supervisão em tempo real, ver Pysae Operations; para o percurso dos dados do GPS até ao ecrã do passageiro, ver o artigo GTFS-RT na prática).
• Opcional: apoio à decisão para retenção de veículos ou inversão antecipada de marcha, proposto pelo sistema mas validado pelo regulador.

Aplicação do motorista e mensagens

• Obrigatório: início de sessão simples do motorista, ligado ao serviço e ao veículo; indicador de adiantamento ou atraso; mensagens bidirecionais entre motoristas e Centro de Controlo de Operações, com mensagens predefinidas para limitar a distração.
• Desejável: guia de percurso em linhas desconhecidas e desvios; registo de incidentes com localização.
• Opcional: chamadas de voz e alarmes de segurança para motoristas.

Que funcionalidades de informação ao público e dados abertos são agora exigidas?

É nesta área que a regulamentação mudou a lista. O Regulamento Delegado (UE) 2024/490 da Comissão, que reviu o quadro MMTIS e entrou em vigor a 4 de março de 2024, exige que os dados dinâmicos sobre transporte regular (perturbações, horas estimadas, atrasos, supressões) sejam disponibilizados através dos pontos de acesso nacionais. O prazo é 1 de dezembro de 2025 para a rede global da RTE-T e 1 de dezembro de 2028 para o resto da rede. Os dados históricos e observados, incluindo atrasos e supressões, deviam estar disponíveis em toda a rede a partir de 1 de dezembro de 2025.

Na prática, uma pequena rede interurbana que nunca publicou dados em tempo real terá de o fazer até ao final de 2028, e o SAE é a fonte natural.

• Obrigatório: feeds GTFS-RT com atualizações de viagens, posições dos veículos e alertas de serviço, gerados automaticamente a partir da exploração, com um URL público estável.
• Obrigatório: importação do GTFS estático e coerência entre o horário estático e o feed em tempo real (mesmos identificadores de viagens e paragens).
• Desejável: feeds aceites pelos principais planeadores de viagem. Em Lisboa, a Carris Metropolitana colocou no Google Maps, em janeiro de 2024, as horas de passagem em tempo real de mais de 1700 autocarros e cerca de 12 000 paragens (TML). Na Bélgica, a De Lijn publica um feed GTFS Realtime atualizado a cada minuto em transportdata.be.
• Desejável: ecrãs a bordo e nas paragens alimentados pela mesma fonte que a aplicação.
• Opcional: dados de ocupação. Segundo o Regulamento 2024/490, a ocupação continua a ser facultativa, ao critério de cada Estado-Membro.

Alguns países esperam também SIRI ou NeTEx, por isso confirme o que o fornecedor exporta hoje de facto. O quadro operacional completo está no nosso guia de gestão de frota em tempo real para o transporte público; a informação ao público em tempo real é o domínio do Pysae Passenger.

Que funcionalidades de relatórios e integração contam para os contratos?

Relatórios e indicadores contratuais

As autoridades de transportes pagam e penalizam os operadores com base nos dados do serviço realizado, por isso os relatórios são contratuais, não cosméticos.

• Obrigatório: viagens realizadas face às programadas, com códigos de motivo para viagens não realizadas ou parciais; pontualidade com janelas de tolerância configuráveis (por exemplo, os limites exatos de adiantamento e atraso previstos no seu contrato); quilómetros comerciais e em vazio.
• Obrigatório: exportações em formatos abertos (CSV, Excel) e conservação do histórico durante o tempo suficiente para cobrir um ano completo de contrato e auditorias.
• Desejável: pontualidade por paragem, troço e período horário, que é a matéria-prima para rever os tempos de percurso; relatórios por subcontratado quando parte do serviço é subcontratada.
• Opcional: relatórios programados enviados à autoridade de transportes.

Integração de horários e serviços

• Obrigatório: importação do horário e dos serviços de veículos e motoristas, com um processo claro para as alterações sazonais.
• Desejável: alterações no próprio dia de exploração (troca de motorista, troca de veículo) refletidas de imediato na associação às viagens.

E quanto ao equipamento, à propriedade dos dados e à implementação?

Flexibilidade do equipamento

• Obrigatório: equipar toda a frota, incluindo veículos mais antigos e subcontratados, na primeira fase.
• Desejável: suporte de smartphones e tablets comuns como unidades de bordo, com substituição que não exija um técnico especializado.
• Desejável em frotas integradas: conformidade ITxPT. A ITxPT, uma associação sem fins lucrativos, publica especificações para uma arquitetura informática de bordo aberta e certifica os produtos conformes, o que limita a dependência de um fornecedor de equipamento.

Propriedade dos dados e API

• Obrigatório: uma cláusula contratual que estabeleça que os dados de exploração pertencem ao operador ou à autoridade de transportes, com exportação integral no fim do contrato.
• Desejável: uma API documentada para dados brutos e históricos (posições, viagens, pontualidade, quilómetros), para que as suas ferramentas de BI ou a autoridade de transportes os possam usar sem exportações manuais.

Implementação e suporte

• Obrigatório: alojamento na cloud com atualizações incluídas e horário de suporte adequado ao seu horário de exploração, fins de semana incluídos.
• Desejável: um piloto numa ou duas linhas; formação de reguladores e motoristas incluída.

Que funcionalidades são novas na lista de 2026?

Três temas passaram de “futuro” a “perguntar já”.

Tempos de percurso assistidos por IA. A ideia não é nova: o módulo HASTUS-ATP da GIRO, documentado em 2011 e desenvolvido com a Transports Metropolitans de Barcelona, calcula tempos de percurso e de paragem nos terminais a partir de registos históricos de localização dos veículos (TRID). A aprendizagem automática torna hoje isto rotineiro, mas qualquer modelo precisa de dados do serviço realizado limpos, por troço e período horário. O ponto da lista para o SAE é a qualidade e o acesso aos dados, não um rótulo de “IA”.

Atenção aos autocarros elétricos. Em 2025, seis em cada dez novos autocarros urbanos vendidos na UE eram de emissões zero, com 56% elétricos a bateria e 4% a pilha de combustível (Transport & Environment, fevereiro de 2026). As quotas ultrapassaram 90% nos Países Baixos e na Bélgica, chegaram a 56% em Espanha e a 42% em França. Com frotas mistas, pergunte se o SAE identifica os veículos elétricos, ajuda os reguladores a não atribuir um autocarro de autonomia reduzida a um serviço longo e regista os quilómetros por veículo. A apresentação do estado de carga depende do acesso aos dados do veículo.

Cibersegurança. A NIS2 inclui no setor dos transportes (Anexo I) os operadores de sistemas de transporte inteligentes e as autoridades rodoviárias, mas não menciona os operadores de autocarros enquanto tal; estar ou não abrangido depende da transposição nacional e das suas atividades. As entidades abrangidas têm de gerir a segurança da cadeia de abastecimento, o que implica perguntas ao fornecedor do SAE. Além disso, as obrigações de comunicação de vulnerabilidades do Regulamento de Ciber-Resiliência aplicam-se desde 11 de setembro de 2026, e os principais requisitos para produtos com elementos digitais, como os equipamentos de bordo, aplicam-se a partir de 11 de dezembro de 2027. Obrigatórios em qualquer caso: cifragem, acessos por perfil, contas individuais, registos de acesso e um processo de gestão de incidentes.

A tabela da lista de verificação

O que significa isto para um operador que prepara um concurso ou uma mudança?

Use a tabela como grelha de avaliação. Peça aos fornecedores que respondam a cada linha com “disponível hoje”, “no roteiro com data” ou “não previsto”, e peça uma demonstração com os seus próprios dados GTFS. A falta de um requisito obrigatório desqualifica a proposta.

Depois, faça um piloto: compare durante várias semanas as viagens realizadas, a pontualidade e os quilómetros com os seus próprios registos, e verifique se um planeador de viagens recebe o feed GTFS-RT.

A Pysae, por exemplo, é um SAE na cloud que funciona em smartphones e tablets, com exportações GTFS e GTFS-RT. Seja qual for o fornecedor, o objetivo é o mesmo: dados em tempo real exatos, abertos e seus.

Perguntas frequentes

Qual é a funcionalidade mais importante de um SAE?

Uma associação fiável às viagens. As posições não servem para o controlo, os relatórios ou a informação ao público se o sistema não souber que viagem cada veículo está a realizar. Peça a taxa de viagens associadas numa rede em funcionamento.

Uma pequena rede de autocarros precisa de GTFS-RT em 2026?

Segundo o Regulamento Delegado (UE) 2024/490, os dados dinâmicos têm de estar disponíveis nos pontos de acesso nacionais até 1 de dezembro de 2028 fora da rede global da RTE-T. Começar já dá tempo para corrigir a qualidade dos dados antes do prazo.

As funcionalidades de IA devem influenciar a escolha de um SAE?

Apenas indiretamente. As ferramentas de IA para tempos de percurso dependem de dados do serviço realizado limpos, por troço e período horário. Dê prioridade à qualidade dos dados, ao histórico e ao acesso por API; as ferramentas de análise podem ser acrescentadas depois.

Fontes: Regulamento Delegado (UE) 2024/490 da Comissão, EUR-Lex; Diretiva (UE) 2022/2555 (NIS2), Anexo I, via Advisera; McCann FitzGerald, “Cyber Resilience Act: Reporting Obligations apply from 11 September 2026”; Transport & Environment, “Past the inflection point: electric now clearly dominates the city bus market” (20/02/2026); Transportes Metropolitanos de Lisboa, comunicado sobre os dados em tempo real da Carris Metropolitana no Google Maps (janeiro de 2024); transportdata.be, conjunto de dados GTFS Realtime da De Lijn; TRID, “ATP: Run-time analysis and improved punctuality” (GIRO, 2011); ITxPT, itxpt.org.