Architettura dei sistemi di telepedaggio

Pubblicato: lunedì, 15 giugno 2020 in Focus

di Fausto Caneschi, Presidente Commissione UNINFO ITS Editor di UNI 10607, ETSI ES 200674, ISO CEN UNI 17573, ISO CEN 12855, CEN TS 16986 e CEN TS 17154

La proliferazione di sistemi di pedaggio elettronico (EFC – Electronic Fee Collection) e delle tecnologie che ne sono alla base ha posto da molti anni il problema dell’interoperabilità, che può riassumersi parafrasando il motto fatto proprio dalla Commissione europea, con la frase “un solo contratto per circolare all’interno dell’Unione”. Questo significa, per sistemi di pedaggio basati sull’uso di un apparato a bordo dei veicoli, che tali apparati siano tecnicamente interoperabili nei vari domini di pedaggio. La Direttiva 2004/52, riformulata nel 2019, favorisce tale interoperabilità limitando il numero e tipo di tecnologie e, nell’ultima formulazione, specificando alcune delle norme tecniche da usare. D’altro canto, i singoli standard tecnici non bastano: c’è bisogno di un’architettura generale che, fra le altre cose, normalizzi i termini e i concetti, per ridurre il rischio di fraintendimenti nell’interpretazione delle specifiche, definisca i ruoli e le responsabilità in un sistema di pedaggio, identifichi gli oggetti del sistema e le loro interazioni specificandone le norme tecniche. La norma ISO 17573:2010 “Electronic fee collection - Systems architecture for vehicle-related tolling - Reference model” definì un’architettura concettuale che inquadrò le norme tecniche esistenti, individuò la necessità di ulteriori norme e soprattutto definì il ben noto "schema a quattro entità". La norma di conseguenza definisce:

• la vista “enterprise” di un sistema di pedaggio elettronico (si faccia riferimento alla norma ISO/IEC 10746 Open Distributed Processing - Reference model), che riguarda gli intenti, il campo di applicazione e le politiche che governano le attività globali del sistema;

• una decomposizione del sistema nei suoi componenti principali;

• i ruoli e le responsabilità dei suoi attori; • i servizi forniti, intesi come sottoservizi del servizio principale (pedaggio elettronico), descritti per mezzo di diagrammi di azione (action diagrams) che evidenziano le interazioni fra gli attori del sistema;

• le interfacce di interoperabilità e gli standard necessari. In una visione enterprise, un sistema di pedaggio (elettronico o meno) è rappresentabile come un oggetto enterprise all’interno di una comunità di altri oggetti.

L’architettura non pretende di descrivere gli oggetti esterni, ma solo di riconoscerne l’esistenza e il ruolo rispetto a un sistema di pedaggio. Quello che è interessante è invece la descrizione degli oggetti interni, che è il tema vero e proprio della norma. La nuova versione della norma (ISO 17573-1:2018) è divisa in due parti, di cui la parte 1 è l’architettura vera e propria, che è integrata con l’architettura generale dei sistemi di Cooperative ITS (C-ITS), definita in ISO 17427-1 (Cooperative ITS - Part 1: Roles and responsibilities in the context of co-operative ITS architecture(s)), e da questa ha preso i concetti di ruoli gestionali e ruoli funzionali. L’Interoperability Manager ha un ruolo gestionale, avendo la responsabilità di definire e fare osservare le regole, certificare e abilitare entità a operare nel sistema di pedaggio, e risolvere eventuali dispute. Questo ruolo, nei casi reali, difficilmente può essere svolto da un attore singolo. L’architettura non entra in dettagli specifici, limitandosi a specificare le interazioni che gli altri oggetti del sistema hanno con l’Interoperability manager. Ben diverso è il caso dei ruoli funzionali, per i quali sono indicati in dettaglio le interazioni, ma anche i comportamenti attesi. I ruoli funzionali sono quelli coinvolti nelle attività operative di un sistema di pedaggio. Tralasciando per brevità di trattazione il ruolo di utente (User), è interessante descrivere i due ruoli chiave di Service Provider e di Toll Charger. Leggi l'articolo intero pubblicato su U&C n.5 Maggio 2020