Le attività svolte durante le fasi T1.1 e T1.2 sono state fondamentali per la definizione dell’architettura di alto livello della piattaforma Emer-GO e per delineare le interazioni, in termini di responsabilità e scambio di dati, tra i principali componenti individuati. Le attività del T1.3 si sono concentrate principalmente sulla definizione di un diagramma di architettura di alto livello della piattaforma Emer-GO e sull’identificazione dei componenti necessari a soddisfare le User Stories del progetto.
L’architettura del sistema Emer-GO è suddivisa in tre macro-ambienti: infrastruttura stradale, veicolo di emergenza e centro operativo. L’infrastruttura stradale è dotata di RSU (Road Side Units) ed è responsabile della comunicazione di informazioni al centro operativo e della ricezione di informazioni dal centro. La centrale operativa è responsabile della raccolta dei dati dal veicolo e dall’infrastruttura stradale e dell’esposizione dei servizi Emer-GO per la generazione e la rappresentazione di mappe dinamiche relative alla qualità del manto stradale. Il veicolo di emergenza ospita la logica aziendale principale del sistema Emer-GO ed è responsabile della raccolta dei dati dal componente TRICK, della comunicazione con l’infrastruttura stradale/veicoli tramite messaggi ETSI e del trasferimento dei dati all’HMI (tablet Android). Il tablet Android o l’HMI sono responsabili della comunicazione delle informazioni al conducente del veicolo di emergenza.
In termini di comunicazione, il dispositivo Emer-GO aftermarket a bordo del veicolo di emergenza comunica con la centrale operativa tramite interfacce REST e con la RSU tramite messaggi ETSI EN C-ITS. La centrale operativa comunica con il veicolo di emergenza e le RSU rispettivamente tramite messaggi REST e ETSI EN.
Le interfacce di comunicazione specifiche saranno specificate nel documento di implementazione (D2.2) utilizzando UML e OpenAPI. Il progetto Emer-GO segue una metodologia Agile e le interfacce saranno standardizzate durante la fase di implementazione.
Il dispositivo hardware RSU è utilizzato per l’elaborazione dei messaggi C-ITS nell’infrastruttura stradale ed è suddiviso in due livelli architettonici: Servizi e Runtime. La sua responsabilità principale è quella di gestire e orchestrare i messaggi C-ITS ricevuti da altre RSU o OBU, o di crearne di nuovi quando necessario. In situazioni di emergenza, la RSU può anche inviare richieste di configurazione dei semafori per consentire il passaggio dei veicoli di emergenza.
Tutti i dispositivi Emer-GO e le informazioni trasmesse attraverso RSU/OBU convergono nel Centro Operativo, costituito da un’interfaccia utente (HMI/cruscotto) e dai servizi Emer-GO attraverso i quali i dispositivi tablet richiedono informazioni da visualizzare su una mappa. Il software della centrale operativa è suddiviso in quattro livelli architettonici: View, Runtime, Services e Data Storage. Il livello View comprende tutti i componenti dell’interfaccia utente accessibili attraverso il cruscotto, come la schermata di accesso e la MapView per monitorare la flotta di veicoli e visualizzare mappe di calore dei loro percorsi e della qualità delle strade. Il livello Service comprende tutta la logica di raccolta delle informazioni e di gestione della flotta, con i servizi Emer-GO accessibili attraverso un gateway API e implementati da vari componenti come User Manager, Vehicle Manager, Road Manager, Emergency Manager, C-ITS Service, Alert Manager, Stats e Geospatial Info Manager. Il livello Servizi gestisce l’accesso degli utenti, il tracciamento dei veicoli, i percorsi stradali, gli interventi di emergenza, i servizi stradali, le notifiche, le statistiche e i dati geospaziali.
Il dispositivo Emer-GO recupera i dati del veicolo attraverso il componente Emer-GO Services sull’OBU, che vengono poi raccolti dal componente CAN e filtrati prima di essere inviati alla Centrale Operativa per l’analisi. Se viene rilevato un guasto, la Centrale Operativa viene immediatamente informata, altrimenti viene aggiornato lo stato operativo del veicolo. Gli aggiornamenti delle condizioni del veicolo vengono richiesti tramite un’API esposta dal componente API Gateway della Centrale Operativa. I servizi TRICK recuperano le informazioni necessarie dal componente CAN e le inoltrano a TRICK per l’utilizzo.
