{"id":858,"date":"2022-05-10T11:14:39","date_gmt":"2022-05-10T09:14:39","guid":{"rendered":"https:\/\/compliance.toscana.it\/wordpress\/?post_type=scenario&p=858"},"modified":"2022-05-18T11:43:13","modified_gmt":"2022-05-18T09:43:13","slug":"miic-mobility-information-integration-center","status":"publish","type":"scenario","link":"https:\/\/compliance.toscana.it\/wordpress\/it\/scenari\/miic-mobility-information-integration-center\/","title":{"rendered":"Sistema Informativo Mobilit\u00e0"},"content":{"rendered":"\n
La Regione Toscana – Direzione Generale Politiche Territoriali e Ambientali, all\u2019interno della strategia \u201ci-mobility \u2013 Infrastruttura Geografica per l\u2019Accessibilit\u00e0 Territoriale On Demand\u201d ha individuato alcuni progetti esecutivi che concorrono alla realizzazione e alla gestione della stessa.<\/p>\n\n\n\n
Tra questi il progetto \u201cMobility Information Integration Center\u201d (MIIC d’ora in avanti) che ha il compito di realizzare una sala operativa dedicata:<\/p>\n\n\n\n
a) alla raccolta in tempo reale delle informazioni relative alle flotte TPL, alle emergenze sulla rete viaria, alle condizioni del traffico sulla rete viaria (Sensori Traffico), alla disponibilit\u00e0 di posti auto nei parcheggi, e al tracking di flotte di pubblico interesse (es. mezzi di trasporto rifiuti o merci pericolose) provenienti da enti federati al MIIC come produttori di informazioni<\/em>.<\/p>\n\n\n\n b) alla diffusione delle informazioni raccolte verso gli enti federati al MIIC come fruitori di informazioni<\/em>.<\/p>\n\n\n\n Il progetto MIIC ha anche il compito di definire le specifiche tecniche ed organizzative delle interfacce di integrazione<\/em> per la raccolta e redistribuzione delle informazioni relative all\u2019infomobilit\u00e0 sul territorio regionale.<\/p>\n\n\n\n Gli attori potenzialmente coinvolti nei flussi di informazioni da e verso il MIIC sono, di fatto, tutte le tipologie di fornitori\/fruitori previsti in i-mobility.<\/p>\n\n\n\n In particolare gli attori federati al MIIC come produttori di informazioni potranno essere:<\/p>\n\n\n\n Le interfacce di integrazione disponibili per gli enti federati come produttori di informazioni sono molteplici.<\/p>\n\n\n\n I servizi applicativi descritti rappresentano il canale di comunicazione esposto dal MIIC (Mobility Information Integration Center) per la gestione in ingresso ed in uscita dei dati relativi al TPL (Trasporto Pubblico Locale).<\/p>\n\n\n\n <\/p>\n\n\n\n Il servizio applicativo \u201cMIIC – DATEX II Supplier Push Service\u201d \u00e8 uno dei canali principali di comunicazione che hanno a disposizione gli enti federati al MIIC (Mobility Information Integration Center) per inviare dati relativi alla infomobilit\u00e0 alla sua sala operativa.<\/p>\n\n\n\n L’obiettivo generale del servizio “MIIC – DATEX II Supplier Push Service” \u00e8 quello di fornire una interfaccia comune e standardizzata secondo il formato internazionale DATEX II per l’invio dei dati in modalit\u00e0 “Push” dagli enti federati al MIIC come produttori di informazioni alla sala operativa MIIC.<\/p>\n\n\n\n L’obiettivo specifico della versione attuale del servizio “MIIC – DATEX II Supplier Push Service” \u00e8 quello di gestire l’invio dei dati in modalit\u00e0 \u201cPush\u201d limitatamente alle informazioni provenienti da:<\/strong><\/p>\n\n\n\n i file \u201cTemplate_censimento_Parcheggi.xls\u201d e \u201cTemplate_censimento_Siti_e_Sensori.xls\u201d sono disponibili nella scheda di dettaglio relativa a questo servizio.<\/p>\n\n\n\n <\/p>\n\n\n\n L’obiettivo generale del servizio “MIIC – DATEX II Client Pull Service” \u00e8 quello di fornire una interfaccia comune e standardizzata secondo il formato internazionale DATEX II per la esposizione di dati in modalit\u00e0 “Pull Exchange” dalla sala operativa MIIC agli enti federati.<\/p>\n\n\n\n Il servizio “MIIC – DATEX II Client Pull Service” espone i dati riferiti alle seguenti tipologie di informazioni:<\/p>\n\n\n\n In previsione di una necessaria filtratura dei dati esposti, il criterio di estrazione dei dati del servizio “MIIC – DATEX II Client Pull Service” \u00e8 basato sui concetti di Catalogo, <\/strong>di Utenza<\/strong> e di Sottoscrizione<\/strong>.<\/p>\n\n\n\n Un Catalogo<\/strong> \u00e8 una contenitore logico che raggruppa uno o pi\u00f9 entit\u00e0 oggetto di estrazione dei dati secondo un dato criterio di classificazione. Per esempio un Catalogo di Parcheggi pu\u00f2 raggruppare varie entit\u00e0 Parcheggio secondo il criterio della identit\u00e0 geografica (stesso Comune), di vicinanza (stesso area geografica), di importanza (i principali parcheggi cittadini, o quelli con il maggior numero di posti), ecc.<\/p>\n\n\n\n Una Utenza<\/strong> \u00e8 un identificativo univoco (Userid e Password) in possesso di un solo Ente<\/strong> fruitore al quale \u00e8 associato un determinato Catalogo<\/strong> attraverso una procedura di Sottocrizione<\/strong>.<\/p>\n\n\n\n La procedura di Sottoscrizione<\/strong> viene condotta off-line in collaborazione con l’amministrazione del sistema MIIC. Al termine della procedura, l’ente fruitore entra in possesso di una Utenza sottoscritta ad un particolare Catalogo<\/strong>.<\/p>\n\n\n\n Le relazioni tra le entit\u00e0 coinvolte sono le seguenti:<\/p>\n\n\n\n Utenza \/ Catalogo relazione 1 \u2013 1<\/strong><\/p>\n\n\n\n Ogni Utenza potr\u00e0 avere solo un Catalogo associato.<\/p>\n\n\n\n Ente\/Utenza relazione 1 – 1..*<\/strong><\/p>\n\n\n\n Un Ente potr\u00e0 avere a sua disposizione una o pi\u00f9 Utenze: ci\u00f2 equivale a dire che potr\u00e0 sottoscriversi a pi\u00f9 Cataloghi.<\/p>\n\n\n\n Catalogo \/ Utenze relazione 1 \u2013 0 …*<\/strong>Un Catalogo potr\u00e0 essere pubblicato per un numero indefinito di utenze.<\/p>\n\n\n\n Nel servizio “MIIC – DATEX II Client Pull Service” sono i web service sono suddivisi in due categorie a seconda del criterio di estrazione utilizzato:<\/p>\n\n\n\n La versione Catalogo Standard pu\u00f2 essere consumata da una Utenza generica poich\u00e9 il servizio non effettua controlli di autenticazione e riconoscimento. Il set di dati esposti corrisponde ad un Catalogo Standard. Nella versione Catalogo in Publish\/Subcribe il servizio effettua controlli di autenticazione e riconoscimento della Utenza che deve essere una utenza valida e sottoscritta ad un Catalogo esistente tramite procedura di Sottoscrizione. Il set di dati esposti corrisponde ad al Catalogo per il quale \u00e8 sottoscritta l’Utenza.<\/p>\n\n\n\n Elenco dei web services<\/strong><\/p>\n\n\n\n I web services che fanno parte del “MIIC – DATEX II Client Pull Service” sono quindi otto:<\/p>\n\n\n\n Prima di poter dare vita ad una interazione DATEX II \u00e8 necessario che gli enti federati al MIIC e la sala operativa MIIC stessa, condividano alcuni dati per referenziare univocamente le entit\u00e0 oggetto di informative via DATEX II.<\/p>\n\n\n\n Nello specifico \u00e8 necessaria una fase preliminare in cui la sala operativa MIIC fornisce agli enti federati interessati le anagrafiche di censimento e gli identificativi univoci delle entit\u00e0 (parcheggi e\/o sensori traffico) gestite. L’uso successivo dei dati di censimento delle entit\u00e0 e la gestione della loro persistenza sui sistemi destinatari \u00e8 a carico degli enti federati.<\/p>\n\n\n\n Per far fronte a queste operazioni preliminari \u00e8 ovvio che siano necessarie delle comunicazioni personali ma, per renderle pi\u00f9 agevoli e standardizzate, sono stati messi a punto due modelli per il censimento dei Parcheggi e per il censimento dei Sensori, siano essi i sensori del traffico o i sensori delle condizioni meterologiche, con le opportune spiegazioni.\u00a0 I file di censimento delle entit\u00e0 basati su questi template saranno forniti da MIIC agli enti federati.Nota<\/strong>: i file \u201cTemplate_censimento_Parcheggi.xls\u201d e \u201cTemplate_censimento_Siti_e_Sensori.xls\u201d sono disponibili nella scheda di dettaglio del servizio.<\/p>\n\n\n\n <\/p>\n\n\n\n I servizi applicativi \u201cMIIC \u2013 AVM Real-time Services\u201d rappresentano il canale di comunicazione esposto dal MIIC (Mobility Information Integration Center) per la gestione in ingresso e in uscita dei dati real-time relativi ai mezzi TPL (Trasporto Pubblico Locale) dotati di dispositivi AVM (Automatic Vehicle Monitoring).<\/p>\n\n\n\n L’obiettivo generale dei servizi “MIIC \u2013 AVM Real-time Services” \u00e8 quello di fornire una interfaccia comune per lo scambio dei dati TPL-AVM tra enti federati e MIIC.<\/p>\n\n\n\n In questa ottica, in “MIIC \u2013 AVM Real-time Services” vengono definite specifiche regole di interoperabilit\u00e0<\/em> (Protocollo) e uno specifico formato dei messaggi<\/em> (Modello Dati).<\/p>\n\n\n\n L’entit\u00e0 di riferimento di \u201cMIIC \u2013 AVM Real-time Services\u201d \u00e8 dunque la corsa<\/em> intesa come servizio TPL unitario realizzato da un mezzo attivo dotato di dispositivo AVM a bordo.<\/p>\n\n\n\n I servizi descritti sono due:<\/p>\n\n\n\n Il servizio AVM Supplier Push<\/em> \u00e8 implementato dal web service denominato avmsupplierPushService<\/strong> che espone un solo web method denominato putAvmMessage<\/strong>.<\/p>\n\n\n\n Il servizio AVM Client Pull<\/em> \u00e8 implementato dal web service denominato avmclientPullService<\/strong> che espone un solo web method denominato getAvmMessage<\/strong>.<\/p>\n\n\n\n <\/p>\n\n\n\n DB Corse<\/strong><\/p>\n\n\n\n Prima di poter dare vita ad una interazione MIIC \u2013 AVM Real-time \u00e8 necessario che gli enti produttori e\/o fornitori di dati e il sistema MIIC stesso, condividano i dati per il reperimento delle entit\u00e0 oggetto delle informazioni.<\/p>\n\n\n\n Nello specifico, trattandosi di servizi TPL programmati, \u00e8 necessario che i cosiddetti DB Corse <\/em>generati e pubblicati periodicamente dalle Aziende TPL, vengano recepiti dal sistema MIIC attraverso gli opportuni meccanismi di aggiornamento e modifica. Questo stesso requisito riguarda anche gli eventuali fruitori di dati AVM real-time che, per poter interpretare correttamente i dati ricevuti, dovranno acquisire preventivamente i dati dei DB Corse di proprio interesse.I meccanismi di condivisione dei DB Corse non sono oggetto delle specifiche MIIC \u2013 AVM Real-time, ma dovranno essere analizzati e programmati su specifici tavoli tecnici congiunti.<\/p>\n\n\n\n <\/p>\n\n\n\n La Regione Toscana utilizza uno strumento per la raccolta e comunicazione delle ordinanze temporanee sulla viabilit\u00e0 da parte degli enti responsabili, al fine di sviluppare un servizio capace di dare informazioni sullo stato del grafo di viabilit\u00e0 regionale.<\/p>\n\n\n\n Il servizio beneficia della partecipazione di enti gestori dell’infrastruttura viaria, i quali, attraverso lo strumento, pubblicano le ordinanze temporanee di viabilit\u00e0. In questo modo il servizio permette ai proprietari, ai gestori, ai controllori e agli utilizzatori delle strade, di prendere conoscenza di tutte le ordinanze temporanee che modificano lo stato del grafo viario regionale.<\/p>\n\n\n\n Scopo dello strumento qui presentato \u00e8, quindi, fornire un’interfaccia attraverso la quale un ente abilitato possa rendere pubblica un’ordinanza temporanea, rendendola disponibile tramite il servizio, e fornire un’interfaccia attraverso la quale chi \u00e8 interessato possa fruire del documento che rappresenta tale ordinanza.<\/p>\n\n\n\n Possono essere attori del servizio di Pubblicazione delle ordinanze temporali:<\/p>\n\n\n\n Il servizio “Ordinanze_Viabilit\u00e0” \u00e8 implementato dal web service denominato OrdinanzeViabilita.\u00a0 Il servizio espone due interfacce: publishOrdinanza e getOrdinanze.<\/p>\n\n\n\n PublishOrdinanza<\/strong><\/p>\n\n\n\n publishOrdinanza \u00e8 il web method che permette la pubblicazione di un’ordinanza tramite il servizio. Il metodo riceve in input un’ordinanza e ritorna un messaggio che indica l’esito di tale interazione.<\/p>\n\n\n\n La sua interfaccia \u00e8 la seguente:<\/p>\n\n\n\n publishOrdinanza (MessagePubOrdinanza ord), return Message msg<\/em><\/p>\n\n\n\n Dove:<\/p>\n\n\n\n ord<\/strong> = parametro di Input di tipo MessagePubOrdinanza. Il tipo MessagePubOrdinanza implementa la pubblicazione dell’ordinanza da parte dell’attore pubblicante. Il parametro incapsula le seguenti entit\u00e0: il codice ISTAT dell’attore pubblicante, un’entit\u00e0 di tipo Ordinanza (tale entit\u00e0 implementa l’ordinanza che si vuole pubblicare, nel pieno rispetto delle specifiche tecniche \u201cspecifiche_tecniche_per_la_trasmissione_delle_ordinanze_v1.2\u201d [1]), la data di emissione dell’ordinanza, una copia digitale del documento cartaceo che costituisce l’ordinanza, il nome e le relative dimensioni espresse in byte per ognuno dei due file inviati;<\/p>\n\n\n\n msg<\/strong> = parametro di ritorno di tipo Message del web method. Il tipo Message implementa l’esito dell’iterazione avvenuta tra l’attore pubblicante l’ordinanza e il servizio. Gli esiti previsti sono due: ordinanza pubblicata con successo, oppure, insuccesso, comprensivo di breve didascalia dell’evento sopravvenuto.<\/p>\n\n\n\n GetOrdinanze<\/strong><\/p>\n\n\n\n getOrdinanze \u00e8 il web method che offre il servizio di fruizione delle ordinanze. Il metodo riceve come input i seguenti parametri: codice ISTAT dell’ente pubblicante, data inizio periodo, data fine periodo. Il metodo ritorna tutte le ordinanze pubblicate dall’ente specificato tramite il codice ISTAT e comprese nel periodo indicato.<\/p>\n\n\n\n L’interfaccia del web method:<\/p>\n\n\n\n getOrdinanze(MessageReqOrdinanze got), return MessageOrdinanze msg<\/em><\/p>\n\n\n\n dove:<\/p>\n\n\n\n got<\/strong> = parametro di input di tipo MessageReqOrdinanze. Il tipo MessageReqOrdinanze incapsula le informazioni necessarie per richiedere al servizio una o pi\u00f9 ordinanze;msg<\/strong> = parametro di ritorno. In questo caso l’oggetto di tipo MessageOrdinanze, incapsula tutte le ordinanze che soddisfano i requisiti espressi tramite i parametri di input. In alternativa, nel caso di un evento inatteso sopravvenuto (errore), l’oggetto msg comunica l’insuccesso del servizio all’utente.<\/p>\n\n\n\n <\/p>\n\n\n\n Il progetto MIRTO, Mobilit\u00e0 Inter-operabile di Regione Toscana, \u00e8 finalizzato alla realizzazione di un sistema per la gestione dei contrassegni per i disabili e degli stalli di sosta emessi dai comuni della Regione Toscana.<\/p>\n\n\n\n L’obiettivo del progetto MIRTO \u00e8 facilitare la circolazione dei disabili nei Comuni della Regione Toscana attraverso l’interoperabilit\u00e0 dei singoli sistemi di riconoscimento dei contrassegni dei vari enti comunali.<\/p>\n\n\n\n L’interoperabilit\u00e0 \u00e8 garantita da una banca dati centralizzata con i dati del rilascio dei contrassegni, alimentata dai Comuni, da condividere con tutti i sistemi dei diversi Comuni, consultabile da tutti i Vigili.<\/p>\n\n\n\n I servizi Mirto, quindi, sono finalizzati alla consultazione ed all’archiviazione dei contrassegni e degli stalli in ambiente regionale in modo da garantire l’allineamento costante tra gli applicativi comunali e la banca dati centralizzata.<\/p>\n\n\n\n Gli attori coinvolti sono:<\/p>\n\n\n\n – Regione Toscana – UNCEM,\u00a0 ANCI e\u00a0 i\u00a0 Comuni di Regione Toscana<\/p>\n\n\n\n Nel dettaglio, i servizi esporti:<\/p>\n\n\n\n Fornisce i metodi per la ricerca in ambiente regionale dei dati di contrassegno e degli stalli associati.<\/p>\n\n\n\n Fornisce i metodi per l\u2019archiviazione e la movimentazione in ambiente regionale dei contrassegni e degli stalli associati.<\/p>\n\n\n\n Gli attori che prendono parte al processo sono i seguenti :<\/p>\n\n\n\n <\/p>\n\n\n\n Servizio RicercaContrassegni<\/strong><\/p>\n\n\n\n Permette di ottenere i dati di un contrassegno a partire dall\u2019identificativo del contrassegno.<\/p>\n\n\n\n Permette di ottenere lo storico dei contrassegni associato ad un soggetto a partire dal codice fiscale.<\/p>\n\n\n\n Permette di ottenere la lista degli stalli di sosta associati ad un contrassegno valido a partire dall\u2019identificativo del contrassegno.<\/p>\n\n\n\n <\/p>\n\n\n\n Servizio <\/strong>GestisciContrassegno<\/strong><\/p>\n\n\n\n Permette di censire in ambiente regionale i dati relativi ad un nuovo contrassegno<\/p>\n\n\n\n Permette di modificare i dati relativi ad un contrassegno esistente<\/p>\n\n\n\n Permette di censire in ambiente regionale un duplicato di un contrassegno scaduto o non pi\u00f9 valido.<\/p>\n\n\n\n Permette di esplicitare la cessazione di un contrassegno esistente.<\/p>\n\n\n\n Permette di censire uno stallo di sosta relativo ad un contrassegno esistente<\/p>\n\n\n\n Permette di notificare le modifiche agli stalli di sosta associato ad un contrassegno valido.<\/p>\n","protected":false},"excerpt":{"rendered":" I servizi applicativi descritti rappresentano il canale di comunicazione esposto dal MIIC (Mobility Information Integration Center) per la gestione in ingresso ed in uscita dei dati relativi al TPL (Trasporto Pubblico Locale).<\/p>\n","protected":false},"author":2,"featured_media":860,"template":"","meta":[],"_links":{"self":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/858"}],"collection":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario"}],"about":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/types\/scenario"}],"author":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":13,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/858\/revisions"}],"predecessor-version":[{"id":876,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/858\/revisions\/876"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media\/860"}],"wp:attachment":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media?parent=858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}MIIC – DATEX2 Supplier Push Service<\/h2>\n\n\n\n
MIIC – DATEX II Client Pull Service<\/h2>\n\n\n\n
MIIC – AVM Real-time Services<\/h2>\n\n\n\n
Ordinanze Viabilit\u00e0<\/h2>\n\n\n\n
Mobilit\u00e0 Inter-operabile di Regione Toscana<\/h2>\n\n\n\n