Todos os operadores que publicam dados em tempo real acabam por enfrentar a mesma pergunta: com que norma se deve comprometer a rede? A resposta costuma ser apresentada como um pormenor técnico, decidido por quem configura o fluxo. Não é um pormenor técnico. A escolha determina que plataformas podem consumir os seus dados, que autoridades de transportes os vão aceitar e quanto trabalho de integração cada novo parceiro vai exigir durante a próxima década.
Este artigo compara as duas normas ao nível da arquitetura. Para ver como os fluxos de tempo real são gerados diretamente a partir da exploração, consulte o nosso módulo Operations.
As duas normas num parágrafo cada
GTFS-Realtime é uma extensão da especificação estática GTFS. Foi concebida pela Google para alimentar planeadores de viagem destinados ao público e herda a maior qualidade do GTFS: a simplicidade. Três tipos de fluxo cobrem quase tudo o que um operador precisa de publicar, nomeadamente atualizações de viagens (Trip Updates), posições de veículos (Vehicle Positions) e alertas de serviço (Service Alerts). O modelo de dados é deliberadamente restrito, o que torna os fluxos rápidos de produzir e rápidos de consumir.
SIRI, o Service Interface for Real Time Information, é uma norma europeia do CEN. Foi concebida por e para autoridades de transportes, e isso nota-se: um modelo de dados mais rico, mais tipos de serviço e suporte explícito para trocas negociadas entre sistemas, em vez de uma publicação num só sentido. Exprime conceitos que o GTFS-RT não consegue exprimir, como a proteção detalhada de correspondências entre serviços ou descrições estruturadas de perturbações.
Onde cada norma ganha realmente
A comparação só se torna útil quando se olha para quem consome os dados.
O GTFS-RT ganha no alcance junto do público. O Google Maps, o Moovit, o Transit e a maioria dos planeadores de viagem de terceiros consomem GTFS-RT de forma nativa. Se o seu objetivo é a visibilidade junto dos passageiros, este é o caminho mais curto, e não há alternativa realista.
O SIRI ganha na integração institucional. Os pontos de acesso nacionais e regionais em toda a Europa estão construídos em torno de perfis SIRI. Se uma autoridade de transportes regional agrega dados de vinte operadores, vai quase certamente exigir SIRI, porque a norma foi concebida exatamente para esse problema de agregação. Isto é particularmente verdade nos países nórdicos, onde as infraestruturas nacionais de dados são maduras e as especificações são impostas e não apenas sugeridas.
O SIRI ganha na expressividade. A informação estruturada sobre perturbações, a distinção entre ocorrências planeadas e não planeadas e os conceitos de correspondência entre serviços não têm equivalente limpo no GTFS-RT. Se a sua rede depende de correspondências garantidas entre serviços, o GTFS-RT vai obrigá-lo a simplificar informação de que realmente precisa.
O GTFS-RT ganha no custo total de propriedade. Menos tipos de mensagem, menos negociação de perfis, mensagens mais leves, mais ferramentas disponíveis. Numa rede pequena ou média, a diferença no esforço de implementação e de manutenção é real.
A questão não é qual, mas qual primeiro
Tratar isto como uma escolha exclusiva é o erro mais comum. Na prática, a maioria dos operadores europeus acaba por publicar as duas, porque as duas normas servem dois públicos diferentes que não se substituem um ao outro.
A pergunta certa é, portanto, sobre sequência e arquitetura. De que fluxo precisa primeiro, tendo em conta as suas obrigações imediatas e os seus objetivos de visibilidade? E o seu sistema consegue produzir o segundo mais tarde sem ser reconstruído?
É esta segunda pergunta que conta ao longo de dez anos. Se o estado em tempo real for mantido num único modelo interno e as normas forem tratadas como formatos de saída, acrescentar um fluxo é uma tarefa de configuração. Se a norma estiver embutida no núcleo do sistema, acrescentar a segunda torna-se um projeto.
As cinco perguntas a fazer a um fornecedor
Faça estas perguntas antes de comparar listas de funcionalidades.
Que fluxos estão hoje em produção, e para que clientes? Suportado não é o mesmo que em funcionamento. Peça o URL de um fluxo ativo e o nome de um operador que o utilize.
Que perfil SIRI, e em que versão? O SIRI é uma família de especificações, e os perfis nacionais diferem. Um fornecedor que suporte SIRI em geral pode não suportar o perfil que a sua autoridade de transportes regional realmente exige.
Os dois fluxos podem funcionar em simultâneo a partir dos mesmos dados? Se produzir GTFS-RT e SIRI exigir dois processos separados, vai manter dois conjuntos de incoerências.
Qual é a latência de ponta a ponta? Meça desde o evento no veículo até ao momento em que o fluxo pode ser lido por um consumidor, e não a partir da escrita na base de dados interna. A diferença entre os dois valores é muitas vezes onde está o verdadeiro problema.
Como são tratados os alertas de serviço? É aqui que as implementações mais divergem. Um regulador que regista uma perturbação uma vez deve produzir um alerta válido nas duas normas sem o voltar a escrever.
O que isto significa para o seu caderno de encargos
Não escreva que a solução tem de ser conforme com GTFS-RT e SIRI. Todos afirmam a conformidade e ninguém a verifica.
Especifique antes comportamentos observáveis. Indique os fluxos exatos exigidos e a versão de perfil de cada um. Defina uma latência máxima de ponta a ponta e a forma como será medida nos testes de receção. Exija que uma única ação do regulador produza resultados coerentes em todos os fluxos publicados. Exija que os dados históricos dos fluxos possam ser exportados.
Estes quatro requisitos são verificáveis na receção. As declarações de conformidade não são.
Para onde caminha o setor
As duas normas estão a convergir em âmbito, mas não se vão fundir. As plataformas destinadas ao público não mostram sinais de adotar o SIRI, e as autoridades europeias não mostram sinais de o abandonar. Partir do princípio de que uma vai absorver a outra, e construir sobre esse pressuposto, é a decisão que envelhece mal.
A posição duradoura é de arquitetura e não de preferência: manter o estado em tempo real num único modelo interno, tratar cada norma como uma saída e fazer com que acrescentar a seguinte seja uma alteração de configuração. Com essa arquitetura, acrescentar SIRI a um fluxo GTFS-RT existente é uma tarefa de configuração. Sem ela, a mesma alteração torna-se um projeto à parte, com o seu próprio orçamento.
Perguntas frequentes
Qual é a diferença entre SIRI e GTFS-RT?
O GTFS-Realtime é uma extensão da especificação estática GTFS, concebida pela Google para alimentar planeadores de viagem destinados ao público, com três tipos de fluxo e um modelo de dados deliberadamente restrito. O SIRI é uma norma europeia do CEN concebida para autoridades de transportes, com um modelo de dados mais rico, mais tipos de serviço e suporte para trocas negociadas entre sistemas.
Que norma usam o Google Maps e as apps de planeamento de viagens?
O GTFS-RT. O Google Maps, o Moovit, o Transit e a maioria dos planeadores de viagem de terceiros consomem-no de forma nativa, o que faz dele o caminho mais curto para a visibilidade junto dos passageiros.
Um operador deve publicar SIRI ou GTFS-RT?
Na prática, a maioria dos operadores europeus acaba por publicar as duas, porque as normas servem públicos que não se substituem um ao outro. As verdadeiras decisões são de que fluxo precisa primeiro, tendo em conta as suas obrigações e objetivos de visibilidade, e se o seu sistema consegue produzir o segundo mais tarde sem ser reconstruído.
Como se devem redigir os requisitos de tempo real num caderno de encargos?
Especifique comportamentos observáveis em vez de conformidade: os fluxos exatos e a versão de perfil de cada um, uma latência máxima de ponta a ponta e a forma como será medida na receção, resultados coerentes em todos os fluxos a partir de uma única ação do regulador e dados históricos dos fluxos exportáveis.
Quer saber que fluxo a sua rede deve publicar primeiro? A equipa da Pysae pode analisar consigo as suas obrigações e a sua configuração de dados atual.