•
•
•
•
•
Premessa
Attività in corso, milestone e prossime azioni
Definizione delle metodologia e requisiti per la certificazione dei sistemi
Definizione delle specifiche e progettazione del modulo software
Contatti
Premessa
Al termine del mese in corso, Novembre 2014, sono
stati rilasciati i Deliverable "Indicatori, Step e Requisiti
per la Certificazione dei Sistemi" e
"Modulo di
Validazione/Certificazione
CERT&InfoMobilità
Specifiche e progettazione software" secondo quanto
previsto dal crono programma di Progetto.
Deliverable “Indicatori, Step e Requisiti per
la Certificazione dei Sistemi”
Lo sviluppo del prodotto è avvenuto con la
collaborazione del Laboratorio Logit, dell'Università di
Pisa, con il quale è stato stipulato un sotto contratto
mirato alla definizione della metodologia di
certificazione dei sistemi e consolidamento dei criteri di
verifica. Il documento redatto si riferisce a due dei
molteplici sistemi ITS "fornitori" di dati e analizzati
nell'ambito delle attività precedenti: il sistema di
gestione dei parcheggi e il sistema di monitoraggio e
controllo delle flotte bus (sistema SAE/AVM).
In questa fase sono stati individuati gli indicatori
secondo i quali è possibile definire un sistema
affidabile e tale da garantire informazioni in output
attendibili. Tale concetto è sicuramente fondamentale
affinché sia possibile, da parte delle Aziende Operatori
offrire un servizio di infoutenza preciso ed affidabile su
cui l'utenza possa riporre la propria fiducia per
l'organizzazione degli spostamenti ed ottimizzazione
dei tempi e distanze. In effetti, il raggiungimento di un
adeguato livello di qualità del dato risponde ad un
duplice obiettivo, non solo per l'erogazione
dell'informazione all'utenza, ma anche per lo
svolgimento di attività strettamente di interesse
aziendale come, ad esempio, la certificazione del
servizio TPL svolto e quindi da rendicontare agli Enti
Appaltanti. Il modulo CERT&Infomobilità, oggetto del
progetto, permette infatti, una volta stabilito che
quanto consuntivato sia coerente con quanto
realmente esercito, di produrre report, secondo le
esigenze aziendali, da presentare all'Ente Affidatario, a
dimostrazione del rispetto del contratto di servizio
stipulato.
L'esempio sopra citato è ovviamente riferito alle
aziende TPL ma analoga necessità di certificazione è di
interesse, facendo riferimento all'altro sistema ITS per
il quale sono stati definiti i criteri di verifica della
congruenza dei dati, anche per Soggetti Gestori della
sosta. Per essi è, infatti, fondamentale avere la
certezza che il dato elaborato dal sistema
implementato (che sia fuori struttura o in struttura) sia
affidabile e quindi indicativo per le stime e successive
elaborazioni effettuate dall'azienda stessa sulla base
degli incassi.
Un sistema correttamente funzionante e affidabile è di
aiuto anche per chi, come i controllori della sosta,
possono essere indirizzati verso le aree dove è più
probabile che via siano delle infrazioni (occupazione
dell'area di sosta in violazione).
L’insieme di questi concetti hanno portato alla
definizione dei criteri di verifica ed indici di
valutazione dei sistemi dei quali si riporta, di seguito,
un breve elenco, non esaustivo, rimandando al
complessivo
documento
nel
quale
vengono
ampiamente argomentati:
1. Sistema AVM - in questo caso sono state definite
le casistiche da considerare per l'individuazione di
eventuali
difformità
delle
informazioni
consuntivate rispetto a quanto esercito:
Regione
Toscana
Regione Toscana • POR CReO 2007-2013 • LINEA DI INTERVENTO 1.5.a - 1.6 • BANDO UNICO R&S ANNO 2012
2
1.1. Corse completamente non riconosciute;
1.2. Verifica corse riconosciute parzialmente;
1.3. Verifica congruenza partenze dai capolinea
rilevate come partenza anticipata rispetto
all’orario programmato;
1.4. Verifica
congruenza
durate
temporali
rilevate delle corse non conformi rispetto al
programmato;
1.5. Verifica congruenza lunghezze rilevate delle
corse non conformi rispetto alla lunghezza
programmata;
Verifica congruenza a campione di un numero di
corse significativo;
2. Sistema AVM - in questo caso sono state definite
le casistiche da considerare per l'individuazione di
eventuali
difformità
delle
informazioni
consuntivate rispetto a quanto esercito:
2.1. Corse completamente non riconosciute;
2.2. Verifica corse riconosciute parzialmente;
2.3. Verifica congruenza partenze dai capolinea
rilevate come partenza anticipata rispetto
all’orario programmato;
2.4. Verifica
congruenza
durate
temporali
rilevate delle corse non conformi rispetto al
programmato;
2.5. Verifica congruenza lunghezze rilevate delle
corse non conformi rispetto alla lunghezza
programmata;
2.6. Verifica congruenza a campione di un
numero di corse significativo;
3. Sistema di gestione e controllo dei parcheggi - in
questo caso sono stati definiti i criteri di verifica
ed i relativi indici significativi per la stima e
valutazione della congruità degli incassi e dello
stato di occupazione, sia per stalli su strada che
infrastrutture/aree delimitate da sbarre:
3.1. Transazioni e dati di pagamento;
3.2. Occupazione dello stallo;
3.3. Conteggi Ingresso e uscita
Sono stati definiti i requisiti dell'architettura del
modulo CERT&InfoMobilità che sarà progettato,
realizzato e validato per la certificazione dei dati
generati del sistema SAE/AVM. In particolare sono
state presentate le varie opzioni disponibili per
l'implementazione del modulo e motivate le scelte
effettuate. L’applicativo oggetto del progetto sarà un
applicativo client che risiederà su di un server virtuale
operativo su una macchina appartenente all'azienda
TPL stessa o comunque in un server dedicato.
Questo permette di avere l'applicativo sempre
disponibile da parte dell'operatore adibito all'attività
di certificazione dei dati consuntivati non risultando
strettamente legato alla propria postazione di lavoro
ma potendo usufruire di un qualsiasi PC aziendale o
comunque equipaggiato con apposita e necessaria
VPN per l'accesso alla infrastruttura di rete utilizzata
dai vari sistemi interessati.
L’aspetto della regolazione degli accessi non è di
minor importanza rispetto al contesto, in quanto è
fondamentale che vi sia la possibilità di definire i
diritti di visualizzazione e gestione dei dati, più o
meno sensibili, per ciascun profilo associato a sua
volta ad ogni account operatore definito per lo
svolgimento delle varie mansioni. È quindi
fondamentale la definizione di un ambiente di
gestione degli account in cui l'amministratore di
sistema possa gestire i vari account.
Deliverable “Modulo di Validazione e
Certificazione CerT&InfoMobilità
Specifiche e progettazione software”
L'attività
di
definizione
delle
specifiche
e
progettazione del modulo, avviata ed eseguita
pressoché in parallelo rispetto all'attività di
definizione dei criteri di verifica, presenta la
traduzione dei requisiti man mano definiti in
specifiche funzionali di prodotto relativamente al
Sistema SAE/AVM. Ovviamente la totalità delle
specifiche definite non riguardano solo la sezione
puramente di valutazione dell'affidabilità dei dati ma
anche altri aspetti come, ad esempio:
3.4.
Linguaggio di programmazione utilizzato;
3.5.
Architettura del sistema;
3.6.
Tipologia di database utilizzata;
3.7.
Modalità di accesso ai database;
3.8.
Definizione delle tabelle;
3.9.
Logiche di gestione dei dati;
3.10.
Configurabilità del sistema;
3.11.
Procedure di svolgimento analisi;
Per ciascuno dei precedenti punti sono state fornite
le varie strade percorribili e le scelte effettuate sulla
base
delle
esigenze
emerse
nel
corso
dell'avanzamento del progetto.
Uno dei concetti basilari per lo sviluppo e successivo
funzionamento del modulo CERT&InfoMobilità è
quello della reperibilità dei dati in input e della loro
gestione.
L'architettura
definita,
come
precedentemente accennato, è quella di un client (su
virtual server) interfacciato con i vari ambienti di
archiviazione dei dati, ossia il Database dedicato al
Sistema AVM (DB AVM) e quello dedicato al modulo
CERT&InfoMobilità (DB CERT&INFO). Ai fini
progettuali la scelta è stata dettata dal fatto che è
stato sufficiente disporre di un account di accesso al
DB AVM (con soli diritti di lettura) per poter
estrapolare
le
informazioni
necessarie
e
successivamente archiviarle all'interno del DB
3
CERT&INFO senza richiedere alcuno sviluppo al
fornitore del Sistema AVM interfacciato.
Flussi dati di popolamento delle tabelle del modulo
quali una corsa viene ritenuta consuntivata in
maniera anomala o meno. Ovviamente il cambio
dell'entità dei set di parametri effettuato non deve
influire sulle attività di analisi in corso, o già svolte.
Concetto questo rispettato grazie all'archiviazione dei
dati estrapolati ed elaborati all'interno del DB
CERT&INFO.
Le specifiche qui riportate si riferiscono, inoltre, alle
procedure operative che devono essere seguite
dall'operatore dedicato alla certificazione affinché
venga svolta un'analisi corretta e consona con
l'ambiente di verifica. Di seguito è riportato uno
schema raffigurante la sequenza logica con cui le
attività devono essere svolte:
In casi più generale, che possono presentare
caratteristiche e formato dati diverse da quelle
utilizzate, nel progetto, per la validazione, si prevede
un ambiente di interscambio, dei medesimi dati,
previa elaborazione da parte del fornitore del Sistema
AVM di apposite procedure di estrapolazione ed
archiviazione
delle
informazioni
puntualmente
richieste dal modulo. La struttura prevista è quindi la
seguente:
Ambienti di analisi e interconnessioni
Popolamento tabelle, con uso di interfacce di scambio dati
Entrambe le soluzioni sono comunque definite con
l’obiettivo di garantire la sicurezza necessaria per il
mantenimento
dell'integrità
delle
informazioni
inizialmente estrapolate. Tale obiettivo è raggiunto
tramite l’utilizzo di account con diritti di sola lettura
nel DB AVM e tramite la possibilità di gestione dei
dati relativi, ad esempio, ad un giorno sottoposto ad
analisi
solamente
dall'operatore
che
ha
precedentemente avviato l'attività di analisi stessa.
Questione altrettanto importante è quella della
configurabilità del sistema. Infatti gli operatori che
possono essere dedicati alla mansione di verifica
possono essere molteplici. Oltre alla differenziabilità
di profili utente, di cui è già fatto cenno
precedentemente, è necessaria una configurabilità
dei parametri di verifica utilizzati. Ad esempio, chi
possiede i diritti per effettuare la seguente
operazione, può modificare le "soglie" secondo le
È evidente come successivamente all'effettuazione
del Login, tramite le credenziali personali
dell'operatore, deve essere selezionata l'attività da
eseguire. Sulla base dei diritti relativi al profilo utente
associato vengono presentate le varie scelte
perseguibili.
Se i diritti posseduti lo permettono, è consentito
l’accesso a ciascun ambiente costituente il modulo
nel quale saranno già riportate o meno le
informazioni necessarie per lo svolgimento delle
attività
di verifica
sulla
base
degli step
precedentemente seguiti. Ad esempio: se la sezione
di partenza è quella dell'analisi delle corse, le
informazioni relative ad essa possono essere
direttamente esportate sia verso l'ambiente di analisi
degli eventi che verso quello di analisi dei transiti
senza avere necessità di reinserirle negli appositi
spazi. Questo si traduce in un numero di operazioni
ridotto per l'operatore certificatore ed in una minore
possibilità di errore.
Il risultato dell'attività di sviluppo sarà presentato
all'interno della prossima Newsletter). Inoltre una
dimostrazione del modulo implementato sarà svolta
all'interno del Workshop finale.
4
Per cortesia di MoM - Architettura del sistema tecnologico a supporto del servizio Trevisosta
Per maggiori informazioni contatta il Referente Scientifico del progetto:
DOTT. GIORGIO AMBROSINO
MemEx srl
Tel. +39 0586 211646
E-mail: [email protected]
oppure visita il sito web www.memexitaly.it/certinfomobilita
