Architettura del sistema

  Lo schema logico del Sistema è riportato nella prossima Figura 1

foto1

 

Il Sistema è in grado di:

  • monitorare l’area di preimbarco e di imbarco di una darsena traghetti (o più in generale di un’area portuale) attraverso la visualizzazione di telecamere di videosorveglianza e di riconoscimento targhe
  • di prevedere i tempi di attesa medi presso i parcheggi di preimbarco in funzione di una serie di dati di input
  • di comunicare attraverso strumenti multimediali (es. banner audiovisivi) i tempi di attesa nel parcheggio di preimbarco e di suggerire eventuali azioni per ridurli quanto più possibile (apertura varchi aggiuntivi quando disponibili)       I dati di input sono, di norma:
  • dati di prenotazione derivanti dalle compagnie di navigazione ed orari di partenza delle navi
  • immagini provenienti dalle telecamere di videosorveglianza
  • immagini e dati provenienti dalle telecamere di riconoscimento targhe
  • immagini e dati provenienti dal sistema di videoanalisi (people count)
  • livelli MARSEC adottati
  • informazioni sull’attracco e sulla partenza effettive delle navi, provenienti da operatori situati nei pressi delle varie banchine e dotati di palmare o tablet.

Tali dati, oltre a consentire il monitoraggio fisico dell’area portuale, consentiranno, attraverso un algoritmo previsionale, il calcolo del tempo di attesa per l’ imbarco per le navi in partenza dai vari moli.

Architettura fisica 

Dal punto di vista strettamente informatico, il Prototipo si può descrivere come riportato in Figura 2

foto2

 

Si riconoscono i seguenti componenti previsti dal Progetto:

a) Server in cluster: Web Server, Data Server e Application Server. Essi provvedono rispettivamente a garantire:

    - il controllo dell’accesso alla applicazione da parte degli utenti abilitati

    - l’accesso ai dati

    - la fruizione dei servizi applicativi implementati

sono basati su Hardware SUN MicroSystems in architettura Blade. Il cluster è ottenuto sollevando su due lame distinti i servizi di clustering mediante l’utilizzo della piattaforma VMware esistente in azienda.
  • S.A.N. (Storage Area Network): è lo storage in rete contenente i dati del sistema
  • Videosorveglianza: è il server dedicato al servizio di videosorveglianza ed analisi video
  • P.R. (Plate Recognition): è il server dedicato al servizio di riconoscimento targhe ed ai servizi ad esso connessi (risponde alle voci Infrastruttura di lettura targhe: Hardware - Sensori - Licenze SW e Infrastruttura riconoscimento del veicolo)

Architettura software

componenti software base del Sistema sono i seguenti:

A) Software di base

- S.O. Application Server: CentOS

- S.O. Application Server: CentOS

- S.O. Server videosorveglianza

- Application Server: GlassFish

-DBMS: MySQL

B) Software di ambiente

Videosorveglianza-Motion Detection-Video Analytics: NICE Alpha Silver NVR K3000 e relativi SDK (insieme all’hw dedicato risponde alle voci Sistema di video analisi + infrastruttura e Sistema di motion detection & video analytics)

- Plate Recognition: CitySync ANPR (insieme all’hw dedicato risponde alle voci Infrastruttura di lettura targhe: Hardware - Sensori - Licenze SW e Infrastruttura riconoscimento del veicolo)

C) Software applicativo
Il software applicativo è stato progettato e realizzato in architettura J2EE three layer:
- Presentazione e Accesso (presentation): lo strato applicativo/funzionale attraverso il quale l’Utenza, variamente diversificata sulla base di adeguate politiche di profilazione, fruisce degli strumenti e delle funzionalità operative e di consultazione.
- Logica Funzionale (business logic): lo strato che racchiude al proprio interno le cosiddette regole di business, ovvero la logica attraverso la quale l’applicazione gestisce il dato e ne decide le regole di persistenza.
- Persistenza: lo strato, comunemente detto Data layer, attraverso il quale, secondo le regole della business logic, il dato viene memorizzato e storicizzato.
Tale scelta tecnologica comporta numerosi vantaggi:
  1. l’accesso ai servizi applicativi avviene semplicemente attraverso un browser (ed una connessione di rete, internet o intranet), senza la necessità di installare (ed aggiornare) applicazioni sulla postazione di lavoro dell’operatore
  2. l’interfaccia utente ed in generale la business logic (ossia ciò che in fase di formulazione del Progetto è stato definito come SCADA - Supervisory Control And Data Acquisition), può essere sviluppata mediante strumenti molto più potenti e flessibili (es. Java) di un prodotto industriale
  3. esiste una separazione netta tra la logica elaborativa/funzionale ed i dati, con benefici evidenti sulla sicurezza e sulla gestibilità degli stessi. 

Un ulteriore vantaggio offerto dalla architettura J2EE è rappresentato dal fatto che non occorre sviluppare applicativi “client” per gli operatori portuali che devono poter interagire con il Sistema: è sufficiente disporre di un dispositivo con browser e di una connessione di rete di adeguata capacità trasmissiva (iPad, tablet, palmari, ecc.) per poter utilizzare l’Applicazione (naturalmente il profilo dell’utente ne definirà le funzioni cui è abilitato). In prospettiva si potrebbe anche ipotizzare di sviluppare apposite App per smartphone.
 

Il modello previsionale è stato invece derivato dal simulatore Rockwell Automation Arena®: gli algoritmi specifici per il progetto, per motivi di flessibilità ed efficienza, stati “migrati” in Java” ed implementato nella business logic del Sistema.
 

Inoltre è fin troppo evidente come i dati derivanti dalle ipotesi di simulazione elaborate dal sistema possono essere condivisi con altri stakeholder (tra i quali, ad esempio, lo stesso Sistema Metrocargo di cui al prossimo Cap. 3 - Progetto Metrocargo): infatti il simulatore Rockwell Automation Arena® utilizzato per il Progetto Metrocargo, oltre a poter risiedere sugli stessi server Windows-based previsti il sistema di Governo dei Flussi, può accedere allo stesso database su cui vengono registrati i dati prodotti dagli algoritmi di simulazione.
 

Il middleware di comunicazione tra i vari moduli applicativi del Sistema utilizza diversi SDK e protocolli standard tra i quali WSDL (Web Service Description Language) e JNI (Java Native Interface).
 

In questo modo è stata realizzata una piattaforma che riesce ad integrare sistemi di diversi player basati su differenti tecnologie (videosorveglianza, riconoscimento targhe, video analytics) e che può gestire ed elaborare dati di qualunque natura provenienti da varie fonti (es. flussi di prenotazioni dalla Compagnie di Navigazione, orari di partenze ed arrivo delle navi, notifiche degli operatori di banchina, ecc.) che concorrono a fornire un sistema unico di monitoraggio e controllo.
 

L’architettura e le principali funzioni del Sistema ed il modello previsionale sono stati testati e validati dalla Università La Sapienza.