1

AVALIAÇÃO DO ERRO EM SISTEMAS DE TELEMÁTICA E

COBRANÇA ELECTRÓNICA

Rui Miguel Dias1

1 Brisa Inovação e Tecnologia, Departamento de Investigação e Inovação, Lagoas Park, Ed. 15, Piso 4

Porto Salvo, 2740-245 – Oeiras, Portugal

e-mail: rui.dias@brisa.pt; www.brisainnovation.com

Sumário

A recolha e tratamento dos dados gerados por equipamentos é hoje em dia um processo basilar para o setor

rodoviário. Em particular no que diz respeito à Operação e Manutenção de infraestruturas, este tipo de processo

pode ser encontrado sob várias formas e impactos diversos sobre exploração, receita ou manutenção. Quando

processos de negócio críticos dependem da qualidade dos dados gerados torna-se necessário ter à disposição

ferramentas integradas que permitam medir e controlar o erro dos sistemas que geram dados-base – um exemplo

claro são os sistemas de cobrança eletrónica de portagem ou os sistemas de contagem e classificação de veículos.

Palavras-chave: Quantificação e controlo do erro, ETC, contadores de tráfego, KPI.

1 INTRODUÇÃO

“Estarão os sistemas de cobrança eletrónica de portagem que opero a gerar dados dentro dos intervalos de falha

expectáveis? Estará a receita da minha exploração a ser devidamente controlada?”

“Estarei eu, como fornecedor de um serviço de manutenção, a garantir o nível de serviço com que me comprometi

com o meu cliente?”

“Estarão os níveis máximos de erro definidos contratualmente a ser cumpridos nas minhas concessões?”

Sendo certo que os dados-base gerados localmente alimentam processos de negócio e sistemas mais complexos,

com mecanismos de verificação de coerência próprios, a qualidade dos resultados nestes últimos depende sempre

da qualidade dos dados gerados na origem. Também relevante é a definição do erro e respetiva quantificação; a

mera existência de dados exatos sobre o desempenho, por si só, não garante uma correta quantificação do erro,

uma vez que sobre os mesmos é possível obter resultados distintos aplicando transformações matemáticas

diferentes – tal pode acontecer quando unidades operacionais com papéis distintos numa organização tomam como

base de cálculo os mesmos dados e a estes aplicam a sua “perspetiva” do negócio, inerente ao papel que têm no

mesmo. Se comummente esta divergência não é relevante, existem cenários onde tal não é o caso, como por

exemplo quando valores de erro no desempenho de equipamentos são indicadores de performance (KPI) e/ou

quando existem relações contratuais associadas a níveis máximos de erro como indicadores do nível do serviço

prestado (SLA) – e nestes dois exemplos, divergências no cálculo do erro ou na relevância estatística das amostras

consideradas podem ter impacto no negócio das partes envolvidas. É essencial uma visão única e consensual sobre

“o que é o erro”.

2 AVALIAÇÃO DO ERRO DE DESEMPENHO

O conceito de “erro de desempenho” aqui considerado está relacionado com as métricas que são consideradas,

quer para sistemas de cobrança eletrónica de portagem, sejam eles vias canalizadas ou pórticos Multilane Free

Flow (MLFF), quer para sistemas de contagem e classificação de veículos (“contadores de tráfego”),

independentemente da tecnologia ou propósito – portagem sombra (shadow tolling) ou recolha de informação em

tempo real ou estatística. Como métricas a considerar para este erro de desempenho definem-se:

1. Desempenho na “contagem”: de todos os veículos que passaram, quantos são detetados;

2. Desempenho na “classificação”: de todos os veículos detetados, quantos são corretamente classificados.

2

As possíveis abordagens na avaliação e quantificação do erro podem considerar procedimentos diversos, mas estes

consistem invariavelmente num processo que envolve os passos assinalados na Fig. 1:

Fig. 1. Processo genérico de avaliação e quantificação do erro

1. Recolha dos dados fonte cuja correção e precisão se pretende avaliar (o pórtico, o contador de tráfego);

Estes “Dados de Sistema” devem evidenciar os parâmetros em análise (deteção e classificação);

2. Estabelecimento dos dados que representam o termo de comparação – “Dados de Referência”, ou dados

reais – que poderão ser:

a) O resultado de uma observação in loco do fenómeno que originou os Dados de Sistema, OU

b) Dados obtidos a partir de uma segunda fonte para a qual se conhece o erro intrínseco, que tornem

possível obter uma métrica comparável

3. Um processo de comparação entre os dois conjuntos de dados que permite identificar diferenças;

4. A estruturação dos resultados da comparação, incluindo:

a) As amostras consideradas para os “Dados de Sistema” e “Dados de Referência”;

b) Os resultados globais que permitem determinar o valor obtido para o erro.

É um facto que este processo é genérico e em função do cenário de aplicação, poderão ser necessários ajustes.

3 APLICAÇÃO EM SISTEMAS DE TELEMÁTICA E COBRANÇA ELETRÓNICA

Se considerarmos sistemas de cobrança eletrónica em autoestrada e sistemas de contagem de tráfego, constatamos

que na maioria dos casos a avaliação que se pretende fazer tem de ser precisa, quer por poder direta ou

indiretamente representar receita, quer por estar balizada por limites aceitáveis para o erro, sendo que em ambos

os casos o erro que se pretende avaliar é muito baixo, o que torna a aplicação dados de referência com erro

intrínseco (2.b)) pouco aconselhável. Em ambos os cenários, os dados de referência devem sempre derivar de uma

observação efetiva do fenómeno real (veículos), de preferência replicável e que possa constituir um elemento a

que se possa recorrer para memória futura.

3.1 Sistemas de cobrança eletrónica

Os sistemas de cobrança eletrónica de portagens possuem já um grau de sofisticação que permite efetuar múltiplas

verificações e validações em back-office. Contudo, a maioria dos dados base para essa análise provêm dos sistemas

no terreno e dependem da fiabilidade destes últimos; se, por exemplo, num site MLFF uma antena DSRC estiver

inoperacional e algum sensor chave tiver uma falha intermitente, podem ocorrer erros que afetam a receita –

comummente, os sistemas de monitorização endereçam a identificação de situações deste tipo e a respetiva

notificação às partes interessadas (tipicamente, áreas de Manutenção). No entanto, se existirem falhas que não

afetam de forma evidente a cobrança, estas podem passar despercebidas – mesmo que todos os sistemas críticos

estejam a funcionar, tal não significa que o façam com o desempenho esperado, podendo existir algum tipo de

degradação que possa afetar a receita e/ou processos associados à recuperação da mesma:

3

Se, por exemplo, o sistema de deteção e classificação não detetar todos os veículos sem exceção, a receita

pode ser afetada, pois o processo de enforcement estará degradado – eventual perda de exploração;

Da mesma forma, cenários de falha onde existem erros sistemáticos na classificação de veículos ou onde

a eficiência das capturas de matrícula não permite obter resultados automaticamente, fazem com que as

verificações manuais aumentem quer devido a excesso de falsos positivos nas discrepâncias de classe

quer por existirem transações sem matrícula – esforço adicional nos processos de recuperação de receita.

As auditorias/aferições a sistemas de cobrança eletrónica permitem detetar este tipo de situações e funcionar como

mecanismos auxiliares de diagnóstico, tão mais úteis quanto ricos forem os registos recolhidos. Não são elementos

chave na recuperação de receita, mas são ferramentas que permitem melhorar o controlo da mesma para as áreas

de Operação, ajudar no diagnóstico para as áreas de Manutenção, ou “medir” aspetos da eficiência da exploração.

Uma abordagem possível para este tipo de auditoria envolve:

1. O registo em vídeo dos veículos que passaram no ponto de cobrança para o período de análise;

2. A recolha dos dados transacionais para o mesmo período, evidenciando:

a. A classe detetada pelos sistemas de classificação roadside;

b. As capturas de matrícula efetuadas (descriminando entre Traseira e Frontal, quando aplicável).

3. A disponibilização destes dados a um Operador para que este possa identificar todas as falhas (ausência

de deteção, deteção duplicada, erro de classe) da forma mais eficiente possível;

4. A apresentação do resultado através de mecanismos automáticos reconhecidos por todas as partes

interessadas no processo.

3.2 Sistemas de contagem e classificação de veículos

Ao longo dos anos, quer as estruturas de classe quer os erros aceitáveis associados a sistemas de contagem e

classificação de veículos foram variando. Em 2007, o Decreto-Lei n.º 380/2007 de 13 de Novembro ([1]), referente

ao Contrato de Concessão da então EP, que apresentou uma modificação no modelo de relacionamento da mesma

com o estado, atribuindo-lhe um papel de concessionária da rede rodoviária, veio estabelecer uma nova estrutura

de classes a ser aferida por estes equipamentos (Base 39). Já em 2008, no âmbito da definição dos requisitos

mínimos para sistemas de telemática rodoviária ([2]), a EP estabeleceu que este tipo de sistemas deveria ter um

erro máximo de 1% no que diz respeito à deteção de veículos (“contagem”) e que o erro no apuramento da respetiva

classe (“classificação”) não deveria exceder os 8%. Estes requisitos de desempenho (entre outros) foram assim

passados para as diversas subconcessões que desde então operam este tipo de equipamentos; o cumprimento destes

limites de erro é assim mais um fator a considerar para a excelência no serviço prestado ao concedente, e

monitorizar os níveis de erro e intervir para os controlar passou a ser uma atividade corrente das áreas de Operação

e Manutenção nestas subconcessões.

Por outro lado, contadores de tráfego a funcionar em regime de shadow tolling representam de facto receita e erros

na contagem e na classificação podem afetar a exploração – por exemplo, dependendo do regime contratual,

veículos a menos podem representar uma perda para a Operação e veículos a mais uma oneração extra para o

concedente.

A avaliação de desempenho de contadores de tráfego é talvez o cenário mais clássico de “aferições manuais” ao

respetivo desempenho. Estas auditorias ganham uma maior relevância para estes sistemas uma vez que são de

facto a ferramenta mais eficaz na medição do erro efetivo nos sistemas no terreno. Apesar da natureza destes

sistemas ser diferente da dos de cobrança, a abordagem para este tipo de auditorias não tem que diferir muito.

3.3 Processo de identificação de anomalias e falhas

A identificação de falhas num período de média a longa duração (30 a 60 minutos, por exemplo) nem sempre é

um processo fácil, em particular quando o objeto de análise envolve tráfego intenso e múltiplas vias. É comum a

existência de erros nas metodologias mais simples, onde um operador “anota numa folha” as falhas que identifica

ao longo do visionamento de um troço de vídeo ou mesmo no terreno – nestas abordagens pode até ocorrer que

dois ou mais operadores tenham resultados distintos sobre as falhas que identificam para a mesma amostra ou

4

período. Desta forma, e considerando que um único erro nesta avaliação pode afetar o resultado final (devido ao

thresholds de erro baixos), devem proporcionar-se as melhores condições possíveis para os operadores

identificarem inequivocamente as potenciais anomalias, o que implica:

Possibilitar a um operador ajustar a velocidade de reprodução do vídeo ao tráfego (mais lento para tráfego

intenso, mais rápido para baixo tráfego);

Permitir uma análise frame a frame para despiste de situações mais ambíguas;

Indicar na própria stream de vídeo as transações detetadas de forma a permitir que o operador se foque

num único objeto de análise (interface) e assinale univocamente as transações anómalas no mesmo;

Permitir uma navegação entre transações e entre anomalias;

Possibilitar a revisão das anomalias identificadas e respetiva edição, pelo próprio operador ou por outrem.

3.4 Cálculo do erro

O cálculo do desempenho nas vertentes de contagem e classificação traduz-se em taxas de erro inferidas a partir

de um período de observação. Para que essas taxas possam ser representativas do erro torna-se necessária uma

amostra considerável de veículos, uma vez que, como referido, se tratam tipicamente de valores de erro bastante

baixos. Se considerarmos que o erro máximo esperado para a contagem se situa em 1%, seria empiricamente

desejável ter uma amostra de 1000 veículos, por exemplo, embora valores inferiores possam também ser

representativos. Mais uma vez empiricamente, pode-se considerar que amostras inferiores a 500 são apenas

indicativas do desempenho que amostras inferiores a 200 veículos representam grosseiramente o desempenho e

não são de todo representativas. Este critério pode ser ajustado em função da confiança desejada para a avaliação.

Recordando a definição de desempenho na contagem apresentada acima, este consiste em avaliar “de todos os

veículos que passaram, quantos são detetados”. Para se conseguir efetuar este cálculo apenas é necessário conhecer

duas grandezas: o total de veículos detetados pelo sistema e o total de veículos que realmente passaram no ponto

de medida. Define-se assim o Erro de Contagem como a diferença entre o número de veículos considerados pelo

sistema e os que realmente passaram no ponto de contagem, expressa em percentagem, e definido pela expressão

𝒆𝑪𝒐𝒏𝒕𝒂𝒈𝒆𝒎 = |𝟏 −𝑵𝑺𝒊𝒔𝒕𝒆𝒎𝒂

𝑵𝑹𝒆𝒂𝒍| (1)

Onde:

𝑁𝑆𝑖𝑠𝑡𝑒𝑚𝑎 representa o total de veículos detetados pelo sistema para o período de avaliação;

𝑁𝑅𝑒𝑎𝑙 representa o total de veículos que passaram no ponto de medida no período de avaliação.

Esta métrica representa assim a “Taxa de Erro de Contagem”, contendo o efeito de erros que se anulam

(contagens a mais, ou duplicados, versus falhas de contagem, ou não detetados). Note-se que para obter este

resultado não é necessário avaliar as transações individuais, podendo assim ser usados para o efeito dados

agregados. Se, contudo, se quiser identificar os erros que se anulam, então será necessária uma análise transação

a transação.

No que diz respeito ao desempenho na classificação, tínhamos já estabelecido que esta medição envolve avaliar

“de todos os veículos detetados, quantos são corretamente classificados”. Para se conseguir fazer esta análise já se

torna absolutamente necessário efetuar uma avaliação individual de cada passagem, sendo portanto impossível

evitar erros grosseiros quendo se recorre a dados agregados. De forma resumida, é necessário identificar para todos

os veículos de determinada classe que passaram no ponto de medida, quantos foram corretamente classificados, e

que classes foram erradamente atribuídas aos restantes.

Define-se assim o Erro de Classificação como sendo representado pela soma dos erros de classificação registados

para cada classe, ponderados pela amostra total de veículos – e expresso também em percentagem.

Este erro pode ser representado pela expressão:

𝒆𝒄𝒍𝒂𝒔𝒔𝒊𝒇𝒊𝒄𝒂çã𝒐 = ∑ 𝑬𝒄𝒍𝒂𝒔𝒔𝒆𝒊

𝑵𝒓𝒆𝒂𝒍 (2)

Onde:

5

𝐸𝑐𝑙𝑎𝑠𝑠𝑒𝑖 representa o total de registos de veículos realmente pertencentes à classe i aos quais foi atribuída

outra classe (erros de classificação para a classe i), ou seja:

𝐸𝑐𝑙𝑎𝑠𝑠𝑒𝑖= ∑ 𝑅𝑒𝑔𝑖𝑠𝑡𝑜𝑠𝑉𝑒í𝑐𝑢𝑙𝑜𝑠 𝑐𝑙𝑎𝑠𝑠𝑒 𝑖 𝑐𝑜𝑚 𝑑𝑒𝑡𝑒𝑐çã𝑜 ≠𝑖 (3)

∑ 𝐸𝑐𝑙𝑎𝑠𝑠𝑒𝑖 representa o total de erros de classificação ocorrido no período de análise (a soma dos erros de

classificação para cada classe);

𝑁𝑅𝑒𝑎𝑙 representa o total de veículos que passaram no ponto de medida no período de avaliação.

Esta métrica consubstancia assim a “Taxa de Erro de Classificação”, que quantifica o desempenho do sistema

em termos de classificação.

As duas definições apresentadas e respetiva aceitação pelas partes interessadas são essenciais para o cálculo correto

do desempenho dos sistemas e visam eliminar abordagens alternativas que acarretam erros de avaliação – talvez o

mais comum seja a tentativa de quantificar os erros de classificação recorrendo a dados agregados (i.e., volumes

por classe num determinado período de tempo):

Nesta abordagem não é possível excluir as falhas de contagem e duplicações, que não devem ser

consideradas neste cálculo;

Não é possível determinar que erros de contagem ocorreram ao certo – se, por exemplo, num determinado

período de tempo passarem 2 veículos da classe A e 2 da classe B, ocorrendo em todos erros de

classificação (os 2 A foram classificados como B e vice versa):

o O erro de classificação é de 100% (todos os veículos foram mal classificados);

o Recorrendo a agregados, somos tentados a crer que o erro é 0, uma vez que passaram dois

veículos de cada classe e foram detetados 2 veículos de cada classe.

3.5 Estruturação de resultados

A estruturação dos resultados, como já foi referido, deve apresentar duas vertentes: a caracterização da amostra

considerada (Dados de Sistema e Dados de Referência) e a sistematização dos valores base e cálculo do erro.

Idealmente, na caracterização da amostra:

Devem estar identificados os erros de deteção ocorridos – falhas de contagem e contagens a mais;

Deve ser apresentada a distribuição dos Dados de Sistema e Referência em termos de classe;

Devem perceber-se que “migrações de classe” ocorreram por erro;

Devem ser contabilizados e evidenciados os erros ocorridos.

Também idealmente, na sistematização dos resultados, para além da indicação das taxas de erro:

Devem ser apresentados os dados base para as taxas de erro (total de veículos reais, total de erros, etc.);

Para o caso da classificação, deve ser apresentada a taxa de erro por classe;

Podem ser apresentados cálculos “alternativos” (por exemplo, erros relativos na classificação, ou

quantificação dos erros de deteção como soma – erros acumulados), mas nesses casos as taxas de erro

que se devem considerar terão de estar devidamente assinaladas para não causar ambiguidade na leitura

dos resultados.

4 A PLATAFORMA AUDIT

Para apoiar as soluções de cobrança eletrónica de portagem e de aquisição de dados de tráfego que fornece, a Brisa

Inovação e Tecnologia (BIT) desenvolveu uma plataforma aplicacional versátil para controlo do erro, que não só

pode ser integrada com sistemas já em exploração como também produz quantificações do erro claras e gera

evidências das avaliações de desempenho e respetivos resultados, proporcionando com as mesmas meios de

diagnóstico para algumas das falhas detetadas ([3]). Esta plataforma segue os preceitos enumerados na secção

6

anterior no que diz respeito à identificação de anomalias, cálculo do erro e estruturação de resultados, e com ela

todas as partes interessadas no apuramento das métricas de desempenho beneficiam do processo – participando de

forma ativa (fazendo agendamentos ou verificações), ou recebendo os relatórios que atestam o bom desempenho

dos sistemas no terreno (ou identificam anomalias que deverão ser corrigidas). Na sua forma atual, a plataforma

Audit incorporou o feedback resultante de cinco anos utilização e o know-how detido pela BIT sobre os sistemas

suportados – sistemas de cobrança eletrónica de portagem e contadores de tráfego.

As funções da plataforma estão enumeradas na Fig. 2. De forma resumida, temos:

Um servidor aplicacional com acesso aos sistemas no terreno, que gere todos os processos, consolida e

trata os dados, e disponibiliza interfaces sobre um browser – multilingue, locale configurável;

Sistemas no terreno: os equipamentos sob análise (cobrança ou contadores de tráfego) e câmaras de vídeo.

Estes sistemas recolhem a informação necessária (transações) e as imagens que suportam as auditorias;

A interface web da plataforma, que disponibiliza operações em função do tipo de perfil:

o Perfis de Administração, com capacidade de gestão de configurações e validações diversas, e de

agendamento de ações de auditoria;

o Perfis de Operação, mais focados na execução da auditoria propriamente dita e de validação e

fecho da mesma (produção do relatório final).

Fig. 2. Plataforma Audit - funções disponíveis

Fig. 3. Plataforma Audit - Atores no processo de auditoria

Na Fig. 3 estão assinalados os atores envolvidos nos processos de auditoria, que recorrem às funções disponíveis

para representarem o seu papel:

Na criação de administração da entidade “site” (conjugação de elementos roadside correspondentes a um

conjunto de uma ou mais vias/sensores);

7

No agendamento de auditorias em linha com as necessidades do negócio;

No processo de auditoria propriamente dito, e respetiva revisão e confirmação;

Na gestão e execução do processo de recolha de dados de Sistema e de Referência, e disponibilização de

serviços de auditoria e relatórios.

4.1 Processo de auditoria

Fig. 4. Processo de auditoria na plataforma Audit

A Fig. 4 ilustra o processo de auditoria sobre a plataforma Audit, que se descreve de forma resumida:

1. Um utilizador com privilégios para tal agenda uma auditoria na plataforma via interface web,

caracterizando-a através de tipo de auditoria, site alvo, data/hora de início e de fim;

2. O agendamento é processado, são geridos potenciais conflitos com outros agendamentos e chegada a hora

definida, as câmaras são ajustadas para o preset ideal para o registo em vídeo;

3. Os sistemas no terreno procedem ao registo de dados e imagens – no caso do objeto de avaliação (contador

de tráfego, sistema cobrança eletrónica), nenhuma interação prévia é realizada, garantindo-se que o

funcionamento é o normal e não afeta o comportamento que se pretende avaliar;

4. Chegada a data/hora de fim da auditoria, os dados gerados localmente são recolhidos e é produzido o

vídeo composto que servirá de base ao processo de auditoria;

5. A identificação de anomalias (“verificação”) fica disponível na plataforma aos utilizadores autorizados.

Ao executá-la, os utilizadores devem tipificar cada falha identificada (contagem a mais, falha na deteção,

erro de classe) e indicar qual a transação em concreto que incorre na dita, sendo que a plataforma inclui

ainda mecanismos de verificação interna que alertam para potenciais falhas não identificadas (por

exemplo, veículos sem classe definida devem sempre ter associada uma anomalia). O processo de

verificação é passível de revisão até à respetiva confirmação/fecho, a partir da qual fica imutável;

6. Quando a auditoria é fechada, é gerado um relatório com os resultados e todos os dados relevantes,

ficando disponíveis para consulta: o relatório de auditoria e o registo de vídeo composto que o originou.

8

O aspeto da interface de consulta da plataforma Audit é apresentada na Fig. 5.

1

2

3

4

6

87

5

1 Contagem absoluta e distribuição por

classe/via dos veículos já detetados

2 Via 3 (inativa)

3 Via 2 (inativa)

4 Via 1 (ativa - classe B)

5 Controlo da velocidade de reprodução

6 Comando de vídeo e navegação entre

transações

7 Marcador de Anomalia

8 Indicador de progresso do vídeo

Fig. 5. Plataforma Audit - Interface de Consulta

A interface de verificação de auditoria, em tudo similar à de consulta, permite ao operador visionar o período de

auditoria da forma mais adequada ao volume de tráfego, bem como navegar entre transações e anomalias já criadas,

minimizando o erro humano – um conjunto rico de comandos através do rato complementa a interface intuitiva.

A plataforma permite que mais do que um utilizador contribua para o resultado final, podendo diferentes

utilizadores assumir papéis diferentes: por exemplo, um primeiro operador pode realizar a verificação inicial, e

um segundo pode rever a auditoria e confirmar a correção da mesma. No fundo, a organização que recorre à

plataforma pode definir os procedimentos que julga mais adequados.

4.2 Sistematização dos resultados de auditoria

Em linha com os princípios já referidos, a plataforma Audit produz um relatório de auditoria que inclui, 4 secções

base:

1. “Cabeçalho”, que apresenta informação geral para caracterizar e contextualizar a auditoria (e.g., data,

tipo, site, período, síntese de resultados, etc.)

2. “Dados da Auditoria”, onde a amostra considerada se encontra descriminada e distribuída (Fig. 6). A

forma como a amostra está representada permite identificar os vários tipos de erro identificados e em que

classes ocorreram ou se refletiram – veículos não detetados, contagens em excesso (“Falsas deteções”,

ou duplicações) e erros de classe;

3. “Resultados”, onde são apresentados os resultados propriamente ditos, acompanhados pelos valores base

que os originaram e por outros resultados acessórios, como por exemplo o erro de classificação para

determinada classe em particular. No exemplo apresentado na Fig. 7, os resultados estão estruturados em

3 tabelas – “Erros de Contagem”, “Erros de Classificação” e “Erros de Classificação LP” (ligeiros e

pesados);

9

4. “Imagens”, onde todas as anomalias identificadas são ilustradas pela imagem vídeo correspondente. Estas

evidências de falha podem constituir um auxiliar de diagnóstico útil às áreas de Manutenção (Fig. 8 a Fig.

10).

Fig. 6. Relatório de auditoria - secção "Dados da Auditoria" – contador de tráfego

Fig. 7. Relatório de auditoria - secção "Resultados" – contador de tráfego

Fig. 8. "Imagens" - Contagem a mais

Fig. 9. " Imagens " - Falha de contagem

10

Fig. 10. " Imagens " - Erros de Classificação

A plataforma mantém um histórico de todas as auditorias realizadas e respetivos resultados, permitindo a geração

de reports consolidados por site e infraestrutura (e.g., autoestrada, EN. IC), ou indicadores mensais consolidados

de desempenho. Este histórico constitui um bem precioso no que diz respeito ao desempenho dos equipamentos

em exploração e a plataforma assume um papel de relevo para atividades de Operação e Manutenção, assim como

para as próprias Concessionárias.

5 CONCLUSÕES

A verificação do desempenho dos sistemas no terreno é uma vertente importante na avaliação de uma Operação,

em particular quando esse desempenho está relacionado com a receita de exploração. A auditoria regular aos

sistemas de cobrança eletrónica ou de contagem de tráfego no terreno é uma boa prática que permite monitorizar

e controlar o erro nos mesmos. A definição do conceito de erro assim como a relevância da dimensão da amostra

são aspetos particularmente importantes quando existem diversas partes interessadas na vigilância do desempenho

e foram propostas definições claras, já largamente aceite em operações em curso, para as métricas de Erro de

Contagem e Erro de Classificação. Foi apresentada uma plataforma aplicacional que permite minimizar o erro

humano, produzir relatórios de desempenho detalhados e consolidar de forma centralizada a informação de

desempenho de uma rede de equipamentos deste tipo. Uma ferramenta destas constitui uma peça essencial quer

para unidades funcionais de Operação e de Manutenção, quer para as Concessionárias que necessitem de avaliar

o serviço que lhes é prestado – um exemplo claro é a excelência operacional conseguida na rede operada pela Brisa

Operação e Manutenção, onde a plataforma Audit é usada para controlo do erro – por exemplo, através da medição

de dois dos KPIs relevantes para sistemas de contagem e classificação de veículos: as taxas de erro de Contagem

e de Classificação. Estas avaliações regulares permitem atestar o cumprimento dos níveis de serviço

contratualizados.

6 AGRADECIMENTOS

À equipa de desenvolvimento da plataforma Audit e à Brisa Operação e Manutenção.

7 REFERÊNCIAS

[1] Decreto-Lei n.º 380/2007 de 13 de Novembro, Diário da República

[2] Instrução Técnica sobre requisitos técnicos mínimos para os sistemas de telemática rodoviária, EP,

Gabinete de Telemática, Fevereiro de 2008

[3] http://www.brisainnovation.com/en/activity/building-solutions/audit-platform