AZIONE 3 Studio della compatibilità tecnologica nel settore ICT e TLC

Transcript

1 Programma Operativo di Cooperazione Transfrontaliera Italia Svizzera PROGETTO STRATEGICO PTA PIATTAFORMA TECNOLOGICA ALPINA: UNO STRUMENTO TRANSFRONTALIERO PER LA CONDIVISIONE DI INFRASTRUTTURE E SERVIZI AZIONE 3 Studio della compatibilità tecnologica nel settore ICT e TLC Francesco Bruschi Alberto Marinelli Gianpaolo Cugola Marco Marcon Mariagiovanna Sami

2 INDICE Indice 1 Introduzione 1 2 Riferimenti accordo-documenti Distinzione tra aspetti di IT e aspetti di TCL Definizione della normativa vigente IT e TLC Studio della normativa esistente Mappatura dell attuale dotazione tecnologica Standard e best practices esistenti Verifica di compatibilità in termini tecnologici e normativi Possibili proposte per lo sviluppo di indicazioni normative Attività di analisi e mappatura dell esistente Analisi della normativa a livello transnazionale, nazionale e regionale, per quanto riguarda le varie tecnologie afferenti all ICT Aspetti considerati Identificazione dei punti di cerniera Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti nel progetto La compatibilità e le best practices: risultanze complessive Le soluzioni attualmente utilizzate (installato, strumenti hardware-software, metodologie): aspetti che impattano sulla compatibilità Le buone pratiche adottate Prospettive per soluzioni e best practices adottabili in un prossimo futuro 15 4 Hardware Piattaforme elaborative Analisi risultati questionari Consumo energetico dei sistemi di elaborazione Sistemi notebook Personal computer Sistemi server e workstation Supporto hardware a processi di virtualizzazione Continuità operativa Analisi risultati questionari Soluzioni attuabili in base agli obiettivi Backup su nastro Backup su disco Replica in remoto Infrastrutture di rete per i sistemi di storage Direct Attached Storage Storage Area Network Network Attached Storage i

3 INDICE 4.3 Sistemi Embedded Telecomunicazioni Analisi risultati questionari Soluzioni per il controllo dei flussi di mobilità Dispositivi a Corto Raggio per applicazioni non specifiche Banda ,5 MHz Banda ,6 MHz Banda 433,05-434,79 MHz Sistemi di identificazione a radio frequenza (RFID) Banda MHz Banda MHz Sistemi di trasporto intelligenti (STI) Banda MHz Software e dati Analisi risultati questionari Software proprietario vs. libero Software e dati GIS Sistemi operativi real-time e per le WSN Sicurezza ICT Analisi risultati questionari Tecniche per la sicurezza ICT Confidenzialità, integrità e autenticazione Sistemi crittografici Funzioni di hash Identificazione e autenticazione Sicurezza architetturale Firewall Architettura a due zone Virtual Private Network (VPN) Sicurezza nelle Wireless Sensor Networks (WSN) WebGIS Analisi risultati questionari Riferimenti I ii

4 1 INTRODUZIONE 1 Introduzione Il presente studio che fa seguito al rapporto consegnato in forma definitiva nel marzo 2011 e riguardante la compatibilità normativa si focalizza sulla compatibilità tecnologica e sulle best practices adottate nei campi d interesse per il progetto PTA; esso è innanzi tutto basato sui questionari preparati nei mesi scorsi dal Politecnico di Milano con la collaborazione dei partner, in seguito approvati e compilati dai partner medesimi. L analisi delle informazioni così ottenute ha permesso di presentare, analizzare e confrontare le soluzioni attualmente utilizzate o previste dai partner, mettendo in evidenza eventuali incompatibilità o punti critici, su cui porre particolare attenzione. A tali informazioni sullo stato dei fatti, lo studio aggiunge informazioni e riferimenti sullo stato dell arte, ovvero su tecnologie esistenti e best practices, limitatamente ai settori rilevanti per il progetto PTA e sulla base delle scelte già effettuate nelle altre azioni del progetto. Questi due aspetti affrontati e presentati per ognuno dei campi di interesse per il progetto PTA, dallo hardware alle applicazioni. In particolare, il presente documento è suddiviso nelle seguenti sezioni: Sezione relativa allo hardware, in cui sono presentati i risultati dei questionari inerenti le piattaforme elaborative e la continuità operativa e vengono affrontati i temi dei consumi energetici, del supporto hardware ai sistemi di virtualizzazione, delle soluzioni per il backup e delle infrastrutture di rete per i sistemi di storage; infine sono anche presi in considerazione i sistemi embedded. Sezione relativa alle telecomunicazioni, in cui sono presenti i risultati dei questionari riguardanti questa tematica e le soluzioni per il controllo dei flussi di mobilità. Sezione riguardante software e dati, contenente l analisi dei risultati della parte di questionario sul software, alcune considerazioni sul software libero e proprietario, una sezione relativa al software e ai dati GIS e un ultima parte sui sistemi real-time e per wireless sensor networks. Sezione relativa alla sicurezza ICT, dove sono raccolti i risultati dei questionari relativi all accesso e la condivisione dei dati e alle tecniche di sicurezza; sono quindi presentate una serie di tecniche per la sicurezza informatica e una panoramica sulla sicurezza nelle wireless sensor networks. Infine, una breve sezione relativa a WebGIS, che raccoglie i risultati della sezione di questionario sui sistemi WebGIS (fermo restando che - per gli approfondimenti su questo filone - si rimanda al rapporto proprio dell azione 5). Prima di affrontare in maniera estesa gli argomenti sopra introdotti si è ritenuto necessario introdurre due sezioni: la prima, titolata Riferimenti accordo-documenti, esplicita i riferimenti tra l accordo stipulato tra la Regione Lombardia e il Politecnico di Milano e i vari documenti prodotti all interno dell azione 3 del progetto PTA; la seconda invece riassume i risultati principali presentati in questo secondo documento. 1

5 2 RIFERIMENTI ACC-DOC 2 Riferimenti accordo-documenti Questa sezione del documento è pensata al fine di chiarificare l organizzazione del lavoro svolto e rendere maggiormente espliciti i punti che legano l accordo stipulato tra la Regione Lombardia e il Politecnico di Milano e i documenti prodotti da quest ultimo nell ambito del progetto PTA. In particolare si prendono in considerazione i vari punti del suddetto accordo relativi all azione 3 e si forniscono i riferimenti alle varie parti dei documenti in cui ognuno di essi è trattato. 2.1 Distinzione tra aspetti di IT e aspetti di TCL Entrambi i documenti presentati sono suddivisi per aree tematiche. Il primo, con titolo Studio della compatibilità normativa nel settore ICT e TLC, riporta lo studio effettuato sulla normativa esistente e presenta sia una serie di tematiche fondamentali, quali lo hardware, le telecomunicazioni, il software, sia numerose tematiche trasversali come la privacy, il copyright, la sicurezza informatica e l accessibilità. Inoltre sono state considerate anche altre aree di particolare interesse per il progetto, ossia il WebGIS, l infomobilità e la sicurezza nelle gallerie stradali e ferroviarie. Nel secondo documento, il cui titolo è Studio della compatibilità tecnologica e delle best practices nel settore ICT e TLC, è stata mantenuta la suddivisione per tematiche principali, ovvero hardware, telecomunicazioni, software e sicurezza ICT. 2.2 Definizione della normativa vigente IT e TLC Parte dell attività svolta, riportata principalmente nel primo documento, è consistita nell esame della normativa vigente in ambito IT e TLC e nell estrapolazione delle parti inerenti il progetto PTA Studio della normativa esistente Lo studio della normativa esistente ha coperto numerose aree di interesse, che sono riportate in elenco con l indicazione della sezione del primo documento in cui vengono trattate: Hardware (2.1) Piattaforme elaborative (2.1.1) Continuità operativa (2.1.2) Telecomunicazioni (2.2) Bande di frequenze assegnate (2.2.1) Inquinamento elettromagnetico e potenze di emissione (2.2.2) Software (2.3) 2

6 2.2 Definizione della normativa vigente IT e TLC 2 RIFERIMENTI ACC-DOC Privacy (3.1) Copyright (3.2) Riuso dei dati (3.3) Sicurezza - Settore ICT (3.4) Accessibilità (3.5) WebGIS (4.1) Infomobilità (4.2) Sicurezza nelle gallerie stradali (4.3) Sicurezza nelle gallerie ferroviarie (4.4) Ognuna di queste sezioni è suddivisa in più parti, in modo da considerare separatamente i vari livelli normativi; in particolare le sottosezioni, comuni a tutte le sezioni, sono: Legislazione, accordi e standard sovranazionali Legislazione italiana Legislazione svizzera Principali somiglianze e differenze Si noti che all interno della legislazione nazionale è stata presa in considerazione, in un opportuno paragrafo, anche quella regionale o cantonale Mappatura dell attuale dotazione tecnologica Una delle attività principali effettuate per la realizzazione di questo secondo documento è quella di mappatura della tecnologia in dotazione e utilizzata dai partner partecipanti al progetto. Lo strumento di cui ci siamo avvalsi per raccogliere i dati è un questionario appositamente realizzato per lo scopo con la collaborazione dei partner stessi Standard e best practices esistenti La presentazione e l analisi degli standard e delle best practices esistenti, che in parte è già stata anticipata nel documento inerente lo studio della normativa, è stata effettuata argomento per argomento, in questo caso senza essere inclusa in alcuna sezione esplicitamente dedicata: ad esempio sono stati prese in considerazione varie soluzioni mirate a supportare l affidabilità dei sistemi informatici e la salvaguardia dei dati (si vedano le sezioni e 4.2.3) e la sicurezza dei sistemi informatici e informativi (sezione 7.2). Inoltre sono anche state presentate varie soluzioni per il controllo dei flussi di mobilità 3

7 2.3 Analisi dei livelli normativi 2 RIFERIMENTI ACC-DOC (sezione 5.2). Per quanto riguarda i sistemi hardware una serie di vincoli a livello di acquisizione sono presentati nella sezione 4.1.2, mentre qualche suggerimento è incluso nella sezione 3.a Piattaforme elaborative del documento integrativo Progetto Interreg PTA - (Accordo fra Regione Lombardia e Politecnico di Milano del 22/3/2010) - Rapporto al 30 giugno In campo software alcuni standard e best practices di rilievo per l ambito del progetto sono stati indicati nella sezione 6.3 (software e dati GIS), mentre un confronto tra software proprietario e libero si trova nella sezione Verifica di compatibilità in termini tecnologici e normativi Oltre all analisi della normativa esistente sono stati effettuati anche i confronti tra le varie soluzioni adottate a livello europeo, nazionale (Italia e Svizzera) e locale (nelle regioni e nei cantoni interessati dal progetto). Essi sono stati utilizzati per verificare la compatibilità, dal punto di vista normativo, sia tra la legislazione europea e quelle nazionali dei due Paesi coinvolti nel progetto, sia tra le legislazioni di questi ultimi e infine anche prendendo in considerazione la normativa locale; inoltre è anche stata verificata la presenza e l eventuale rispetto di standard internazionali. In ambito tecnologico la compatibilità è stata valutata analizzando principalmente i risultati dei questionari, presentati nella sottosezione Analisi risultati questionari presente in ognuna delle sezioni principali di questo secondo documento. Inoltre lo studio di standard e best practices esistenti e utilizzati nelle aree di interesse per il progetto ha anche permesso di evidenziare possibili incompatibilità in ambiti non coinvolti dalla mappatura tecnologica effettuata (es. per ciò che riguarda i navigatori satellitari e i sistemi per il pagamento autostradale, sottosezione 4.3) Possibili proposte per lo sviluppo di indicazioni normative Nel documento integrativo titolato Progetto Interreg PTA - (Accordo fra Regione Lombardia e Politecnico di Milano del 22/3/2010) - Rapporto al 30 giugno 2011 è stato anche inserito, nel punto 2, un approfondimento relativo ai limiti definiti dalla normativa per quanto riguarda il tracciamento di autoveicoli (in particolare i mezzi pesanti considerati nell azione 6 del progetto) e un suggerimento nel caso sia necessario ampliare tali limiti Attività di analisi e mappatura dell esistente Per queste attività si rimanda ai punti e Analisi della normativa a livello transnazionale, nazionale e regionale, per quanto riguarda le varie tecnologie afferenti all ICT Lo studio della normativa nei suoi vari livelli è stato condotto come riportato nella sottosezione

8 2.3 Analisi dei livelli normativi 2 RIFERIMENTI ACC-DOC Aspetti considerati Gli argomenti considerati nell analisi normativa sono riportati in elenco al punto Per quanto riguarda gli esempi maggiormente relativi alla tecnologia in uso nelle diverse regioni, tali questioni sono soprattutto affrontate nel presente documento, in quanto è stato necessario prima effettuare la mappatura tecnologica Identificazione dei punti di cerniera Per quanto riguarda lo studio normativo, presente nel primo documento, i punti di cerniera, sotto forma di compatibilità o incompatibilità rilevate, sono evidenziati sia direttamente all interno della presentazione delle soluzioni normative adottate (una serie, non esaustiva, di esempi si trova alle pagine 11, 19, 37, 40, 41, 46, 52 all interno delle sottosezioni Legislazione italiana o Legislazione svizzera ) sia in un apposita sottosezione, che si trova al termine di ognuna delle sezioni del documento, chiamata Principali somiglianze e differenze. Nel presente documento invece i risultati dei questionari e la conseguente analisi sono stati presentati nella sottosezione Analisi risultati questionari presente in ognuna delle sezioni principali, in cui sono anche state evidenziate eventuali incompatibilità o criticità. Per quanto riguarda la parte inerente l identità digitale (e quindi anche l inserimento di strumenti quali la carta d identità elettronica o altre smart card) si è deciso di trattare l argomento in un terzo documento che integra i risultati dell attività 4.5 Identità digitale, così come precisato sia al termine del paragrafo sia nel documento integrativo Progetto Interreg PTA - (Accordo fra Regione Lombardia e Politecnico di Milano del 22/3/2010) - Rapporto al 30 giugno 2011, sezione 6 Identità digitale Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti nel progetto Per la presentazione di queste attività si rimanda ai punti e Il discorso della transizione tra generazioni differenti è stato soprattutto considerato dal punto di vista software, che si ritiene sia più rilevante (cfr. sottosezione

9 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE 3 La compatibilità e le best practices: risultanze complessive Gli aspetti presi in considerazione riguardano: per gli aspetti hardware: sistemi di calcolo, sistemi per la gestione della continuità operativa e sistemi embedded; dal punto di vista delle telecomunicazioni, oltre ad aspetti inerenti i sistemi per le telecomunicazioni, si presentano e confrontano alcune soluzioni per la gestione dei flussi di mobilità; dal punto di vista del software, l analisi porta a osservare che i rischi di incompatibilità possono essere potenzialmente numerosi, in quanto esistono molti sistemi operativi differenti che supportano diverse architetture hardware e su cui possono girare applicativi di vari tipi. Oltre a questa eterogeneità di soluzioni bisogna anche considerare il fatto che molti software proprietari utilizzano anche formati proprietari dei dati e ciò può limitare notevolmente l interoperabilità e rendere particolarmente onerosa la migrazione a una diversa soluzione software; dal punto di vista della sicurezza, dopo l analisi dei risultati dei questionari riguardanti accesso ai dati e sicurezza, si introducono varie tecniche per la sicurezza in ambito informatico e si apre il discorso sulla sicurezza nelle reti di sensori wireless; infine, si presentano le risposte dei partner riguardanti i supporti per WebGIS, pur essendo ben chiaro che la tematica WebGIS viene trattata in modo approfondito nel rapporto relativo all azione Le soluzioni attualmente utilizzate (installato, strumenti hardware-software, metodologie): aspetti che impattano sulla compatibilità Nei questionari, per quanto riguarda le piattaforme elaborative si è data particolare attenzione ai sistemi appartenenti alla categoria server e all organizzazione dei data center in generale. In questa analisi non sono stati presi in esame aspetti inerenti piattaforme da ufficio o comunque utilizzate da utenti in genere, come computer desktop e notebook. Sono state inoltre presentate anche domande per indagare quali motivazioni, politiche di acquisizione o strategie progettuali sono alla base delle scelte effettuate per la dotazione di un particolare sistema (si rimanda alla successiva sezione 3 per il dettaglio del questionario e l analisi puntuale dei risultati). Tutte le istituzioni associate a regioni o cantoni coinvolti in questo progetto prevedono una politica per la fornitura di piattaforme elaborative. In gran parte dei casi questa politica è definita mediante buone pratiche al fine di ottimizzare la progettazione architetturale del servizio che deve essere erogato. Si evidenzia che, per quanto riguarda alcune 6

10 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE regioni italiane, viene anche sfruttato il Consip per la gestione delle gare d appalto per la fornitura e gli acquisti in genere. Per quanto riguarda le piattaforme per l elaborazione, questa analisi si è concentrata principalmente sulla struttura dei server per applicazioni WebGIS. Si è deciso di dare particolare rilevanza a questa tematica, perché ricopre una delle principali attività di questo progetto. Gran parte dei server utilizzati dai vari partner del progetto presentano CPU con architettura Intel x86 a 64 bit. Solo la regione Valle d Aosta possiede dei server con architettura per CPU Intel x86 a 32 bit. Per applicazioni generiche, il CSI Piemonte utilizza elaboratori server che presentano, in uguale percentuale, CPU con architettura x86 32 bit, x86 64 bit e Sun SPARC. Per ottenere un buon livello di affidabilità e sicurezza, sono presenti in tutti i casi alcuni elementi ridondanti come gli alimentatori e i dischi RAID. Il protocollo FC (Fibre Channel) è quello che risulta maggiormente utilizzato per le comunicazioni col centro di calcolo; CSI Piemonte utilizza anche NFS e e FcoE, Lombardia Informatica utilizza anche NFS e iscsi. L analisi effettuata a riguardo di sistemi di calcolo non ha evidenziato grandi differenze tra le soluzioni adottate dalle varie società ed organizzazioni che hanno compilato il questionario. Questo buon livello di compatibilità, prendendo in considerazione server per applicazioni WebGIS, è dovuto al fatto che in tutti i casi analizzati vengono impiegati sistemi molto simili. Anche sotto il profilo della continuità operativa, vengono analizzate e confrontate le differenti modalità di gestione della business continuity, da parte dei vari soggetti interessati dal progetto PTA. Tutti i partner del progetto, per garantire la continuità di servizio a seguito di eventi dannosi, prevedono una politica gestionale al fine di minimizzare i danni e presentano degli accorgimenti tecnologici inerenti alla continuità operativa. Le soluzioni più comunemente adottate per far fronte a eventuali ed imprevisti eventi dannosi sono l utilizzo di sistemi UPS e il backup dei dati. Per garantire la continuità nella fornitura dell alimentazione ai sistemi, oltre all utilizzo di gruppi di continuità (eventualmente ridondanti), in alcuni casi vengono anche utilizzate doppie linee di alimentazione con la fornitura proveniente da differenti gestori. Per consentire il backup dei dati, la soluzione più comunemente adottata consiste nell utilizzo dei nastri magnetici LTO. Questa non è l unica soluzione prevista; in gran parte dei casi essa viene affiancata da altre tecnologie come: la replica in linea sincrona ed asincrona (regione Piemonte), nastri virtuali (virtual tape) e copia locale (regione Lombardia), backup remoto (regione Valle d Aosta e provincia di Bolzano). La comunicazione tra i vari sistemi e i dispositivi di memorizzazione del centro di elaborazione dati avviene su di una rete Storage Area Network (SAN). Solamente la Lombardia prevede anche l utilizzo, in aggiunta, di una rete Network Attached Storage (NAS). Tranne la Valle d Aosta e il Ticino (che non ha fornito l informazione relativa), risulta che tutti gli altri partner possiedono un sito secondario per gestire emergenze di continuità di servizio. All interno di questo sito vengono adottati cluster remoti e sistemi virtuali, come soluzioni per la gestione di eventuali emergenze. Passando agli aspetti tipici delle telecomunicazioni, l analisi fatta mediante il questionario aveva come obiettivo lo studio della capacità di comunicazione, intesa come larghezza 7

11 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE di banda, dell architettura della rete, protezione delle trasmissioni e la definizione delle politiche attuali, da parte dei vari organi appartenenti al progetto, per la gestione di tale infrastruttura. In quasi tutti i casi analizzati, tranne per la provincia autonoma di Bolzano, è prevista una forma di autenticazione al dominio della rete da parte dell utente per potervi accedere, principalmente mediante la classica forma di autenticazione basata sull inserimento di nome utente e parola chiave. Il Piemonte e il Ticino prevedono inoltre una qualche modalità di protezione delle trasmissioni mediante algoritmo di crittografia. Questa protezione è prevista per le comunicazioni senza fili e dove le informazioni risultano in un qualche modo riservate. L ampiezza della banda, a disposizione dei vari enti appartenenti a questo progetto, per le comunicazioni interne e per quelle verso l esterno è molto variegata. Infatti, in base ai dati ricevuti, questa capacità di comunicazione si estende dai 20 Gbps, nel caso della regione Lombardia, agli 80 Mbps per la regione Valle d Aosta. Per poter comprendere se e come questa differenza possa influire in qualche modo nelle comunicazioni tra le varie organizzazioni bisognerebbe prendere in considerazione l intera struttura di rete a livello nazionale. Infatti si potrebbe riscontrare che il collo di bottiglia nelle comunicazioni tra i vari enti non risieda nella banda a disposizione, ma nella infrastruttura di rete che collega le due realtà. A livello di architettura di rete, tutti i partner sfruttano bilanciatori di carico, al fine di ottenere una migliore scalabilità e affidabilità nella fornitura di un servizio, e collegamenti UTP (Unshielded Twisted Pair) come principale supporto per i collegamenti tra i server e gli switch. Su richiesta dei soggetti coinvolti nell Azione 6 Sistema di precisione open source per il rilevamento di flussi di mobilità del progetto Interreg PTA, si è effettuato un confronto tra le varie soluzioni e tecnologie applicabili per il controllo dei flussi di mobilità, allo scopo di evidenziare eventuali punti in comune ed identificare discrepanze tra quanto prevede la legislazione dei due paesi a riguardo di tali tecnologie. In particolare, per ogni soluzione considerata, sono stati presi in esame parametri come la potenza di trasmissione, la modulazione e le regole di accesso ed occupazione dello spettro radio. Si sono presi in considerazione i dispositivi di effettivo interesse in questo ambito, e cioè: 1. Dispositivi a Corto Raggio per applicazioni non specifiche (corrispondenti a un ampia gamma di apparecchiature quali strumenti di telemetria, telecomandi, allarmi e sistemi di comunicazione locale). In tale ambito (per le bande, rispettivamente, ,5 MHz, ,6 MHz e 433,05 434,79 Mhz) sia la legislazione italiana sia quella svizzera si basano su quanto indicato nell Allegato 1 della Raccomandazione ERC Relating to the use of Short Range Device (SRD). 2. Sistemi di Identificazione a radio frequenza (RFID). Dispositivi di questo genere hanno una crescente penetrazione nella vita quotidiana, dai documenti di identità alla tracciatura dei prodotti nella grande distribuzione, dalla logistica alla gestione del flusso di processo. Le bande in uso sono essenzialmente due: per quanto riguarda la prima MHz si evidenziano differenze sostanziali nei parametri fondamentali, per questa tipologia di sistemi di comunicazione, riportati nella legislazione in vigore nei due paesi (essenzialmente per quanto riguarda la potenza massima di trasmissione), derivanti dal fatto che il Piano Nazionale Svizzero di 8

12 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE Allocazione delle Frequenze fa riferimento alla Raccomandazione ERC Allegato 11, mentre la legislazione italiana in materia si basa sulla Decisione della Commissione Europea 2010/368/CE (che prevede in particolare limiti più stringenti alla potenza emessa). Per quanto riguarda la seconda MHz non si evidenziano differenze tra quanto indicato dalla legislazione dallo stato italiano e dalla confederazione svizzera. Le norme in materia, emanate dai due paesi, fanno entrambe riferimento al documento ERC/REC Allegato Sistemi di Trasporto Intelligenti - categoria che include tutte le tecnologie dell informazione e delle comunicazioni, introdotte nell infrastruttura di trasporto e nei veicoli, volte ad evitare situazioni potenzialmente pericolose e a ridurre il numero di incidenti (comprendono i sistemi cooperativi di comunicazione da veicolo a veicolo, da veicolo ad infrastruttura e da infrastruttura a veicolo per la trasmissioni di informazioni in tempo reale). La banda predisposta è quella MHz. Le norme in vigore in Italia e in Svizzera, che definiscono ed armonizzano questa banda per questo particolare campo di applicazione, si basano entrambe sullo standard europeo ETSI EN : risulta quindi garantita la compatibilità. Per quanto riguarda il software e i dati, a riguardo della piattaforma tecnologica da realizzare per il progetto PTA, il problema della compatibilità software risulta essere sicuramente arginato da alcune scelte implementative effettuate. Una di queste prevede che a ogni partner sia lasciata la responsabilità di gestire i propri dati geografici, fornendone l accesso attraverso opportuni servizi standard, invece di creare un unico sistema integrato; ciò elimina la necessità di uniformare ogni aspetto relativo al software per la memorizzazione e il trattamento di tali dati, nonché al formato dei dati stessi. Si è inoltre scelto di realizzare i servizi richiesti facendo uso di una piattaforma virtualizzata comune, basata sull architettura hardware x86 a 64 bit e sull ambiente di virtualizzazione Proxmox [SW1]. Si nota innanzitutto che le pubbliche amministrazioni prese in esame in questo documento acquisiscono il software seguendo una strategia che, pur seguendo i dettami della normativa vigente, può tenere in conto obiettivi quali l ottimizzazione delle risorse utilizzate e standard interni alle singole amministrazioni. Ne conseguono scelte di acquisizione anche notevolmente differenti, per esempio influenzate da specifiche acquisizioni dell hardware oppure di una determinata famiglia di prodotti software, con cui si vuole mantenere la compatibilità. Nonostante ciò, la predominante diffusione dell architettura x86 ha posto un limite alla diversificazione delle soluzioni adottate, coadiuvata anche dalla presenza, almeno in principio, di un limitato numero di possibili prodotti, generalmente di natura proprietaria. Le considerazioni appena fatte vedono un primo riscontro nella dotazione software, per quanto riguarda i sistemi operativi: tutte e tre le regioni italiane considerate e la provincia di Bolzano fanno uso di sistemi operativi Microsoft, in ambito sia desktop sia server. Ciò è soprattutto vero per la regione Valle d Aosta e la provincia di Bolzano, che utilizzano principalmente tali sistemi operativi, mentre le regioni Lombardia e Piemonte adottano, ormai in misura praticamente pari alle soluzioni proprietarie, anche sistemi operativi open 9

13 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE source in particolare Red Hat Enterprise Linux [SW1] soprattutto in ambito server. Si noti che, quantomeno in ambito Microsoft Windows, la presenza di differenti versioni del sistema operativo (per esempio si va da Windows 2000 fino a Windows 7) non costituisce un particolare problema, così come l utilizzo misto di sistemi a 32 e 64 bit, in quanto la compatibilità tra le varie versioni è pressoché completa e sono piuttosto rari i casi in cui un software può essere eseguito correttamente su un sistema operativo più vecchio mentre non funziona su uno più recente. Più probabile invece e da tener conto è la compatibilità tra versione di sistema operativo e periferiche hardware, in quanto può accadere che la casa produttrice dell hardware abbandoni il supporto a prodotti ormai datati, non fornendo i drivers per il funzionamento con i sistemi operativi più recenti. Per quanto riguarda i sistemi di gestione delle basi di dati generici le risposte al questionario hanno evidenziato come sia generalizzato, sempre restringendo il campo ai partner del progetto, l utilizzo di sistemi proprietari e in particolare di Oracle Database [SW2]. La migrazione tra differenti versioni di DBMS (DataBase Management System) o addirittura tra due soluzioni differenti, qualora risultasse necessaria, non è così scontata, ma generalmente viene supportata da appositi strumenti forniti dalla software house. Fortunatamente, per il progetto PTA non si prevede la necessità di effettuare simili operazioni, in quanto si è deciso che i dati rimangano ospitati nelle basi di dati dei singoli partner, che li rendono accessibili attraverso opportuni servizi. Per la gestione dei dati geografici Lombardia, Valle d Aosta e provincia di Bolzano si affidano a ESRI ArcGIS [SW3], una suite di prodotti per la creazione di un sistema GIS. Regione Piemonte invece si appoggia a PostGIS [SW4], un software open source che aggiunge il supporto per dati geografici al database PostgreSQL [SW5]. Anche in questo caso, sulla base delle scelte implementative dell architettura della piattaforma PTA, l utilizzo di diverse soluzioni per la gestione dei dati geografici non dovrebbe comportare alcun problema di compatibilità, in quanto ogni partner dovrebbe essere responsabile della gestione e della fornitura dei dati geografici di competenza. L ultimo dato rilevato attraverso la parte di questionario relativa al software riguarda le piattaforme di virtualizzazione utilizzate. Tutti i partner si affidano uniformemente a soluzioni VMware [SW6]; la regione Piemonte utilizza anche tecnologie Xen [SW7], mentre il Canton Ticino sfrutta pure Microsoft Hyper-V [SW8]. Si ritiene importante sottolineare nuovamente che, per la realizzazione della piattaforma PTA, all interno dell azione 4 del progetto è stata scelta una piattaforma di virtualizzazione comune nominata nell introduzione della presente sezione che dovrà essere utilizzata dai singoli partner per erogare i servizi della piattaforma tecnologica. Il software GIS, cioè quello che si occupa dell elaborazione dei dati georeferenziati, è sicuramente uno dei punti di interesse all interno del progetto PTA. Le scelte che sono state effettuate per l implementazione della piattaforma tecnologica eliminano il problema della compatibilità a questo livello: ognuno dei partner infatti è libero di utilizzare il proprio database GIS, la propria struttura di server e i propri programmi di manipolazione, a patto di esporre i dati che, ricordiamo, sono liberamente e pubblicamente consultabili secondo lo schema previsto per la base di dati federata, progettata all interno dell azione 5 del progetto PTA, utilizzando Web Map Service (WMS) [SW9] e Web Coverage Service 10

14 3.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE (WCS) [SW10]. Questi servizi sono standard dell Open Geospatial Consortium (OGC) [SW11], un consorzio internazionale che ha l obiettivo di produrre standard pubblici a supporto di soluzioni interoperabili per servizi geografici e cartografici. Infine relativamente alla sicurezza, si sono analizzate le risposte ai questionari sia per la parte relativa all accesso e alla condivisione dei dati sia per ciò che riguarda la sicurezza degli stessi. L informazione più rilevante che emerge, in maniera piuttosto evidente, dall analisi delle risposte a questa parte del questionario è che tutti i partner, escluso il canton Ticino che non si è pronunciato in merito, sono concordi nell affermare che i dati geografici che saranno messi a disposizione attraverso la piattaforma PTA sono pubblici e quindi non è previsto l utilizzo di alcuno strumento di identificazione e autenticazione per l accesso a tali dati. In particolare si fa riferimento a dati riguardanti: limiti amministrativi; toponomastica; centri abitati; rete dei trasporti; idrografia. La posizione di tutti i partner sul versante italiano su questo argomento non è in alcun modo influenzata dalla provenienza dell accesso ai dati: infatti il libero accesso a tali dati continua a sussistere anche se il richiedente non è un altra pubblica amministrazione facente parte della stessa nazione, ma è una pubblica amministrazione estera o un generico utente privato. Un discorso a parte deve essere fatto per la gestione e l accesso ai dati relativi al sistema per il rilevamento di flussi di mobilità (azione 6 del progetto PTA), in quanto tali dati possono contenere informazioni che sono protette dal Codice in materia di protezione dei dati personali [SICT1], per esempio la targa dei veicoli in transito, e quindi non possono essere rese arbitrariamente pubbliche. L accesso e l utilizzo di dati di questo tipo deve sottostare alle limitazioni d impiego stabilite attraverso un accordo privato con i soggetti che si intende tracciare oppure con un apposita legge regionale che garantisca la tracciabilità anche al di fuori di un esplicito accordo. Un ultima nota riguarda WebGIS: innanzitutto è interessante notare una certa disomogeneità negli strumenti che saranno utilizzati per la creazione della piattaforma PTA: in particolare si fa riferimento DBMS per la gestione dei dati GIS e ai linguaggi di programmazione per gli applicativi GIS. Ciò rappresenta un indicazione del fatto che, per la realizzazione della piattaforma PTA, si voglia appoggiarsi a un architettura in cui ognuno dei partner realizza autonomamente i servizi da fornire e li mette a disposizione con una modalità standard, per esempio il Web Map Service (WMS), una specifica tecnica definita dall Open Geospatial Consortium. Si rileva invece un generale accordo sul fatto che non è prevista tutta una serie di vincoli: per esempio tra software applicativo e architettura hardware, tra dispositivi esterni collegati ai sistemi di calcolo e in merito alle latenze e ai tempi di risposta dell applicativo che sarà ospitato sulla piattaforma tecnologica virtualizzata. 11

15 3.2 Le buone pratiche adottate 3 RISULTANZE COMPLESSIVE 3.2 Le buone pratiche adottate Sotto il profilo delle buone pratiche già adottate, ci si è concentrati: per quanto riguarda lo hardware, sugli aspetti relativi al consumo energetico, alla continuità operativa, al supporto alla virtualizzazione; nell ambito del software, in particolare sugli aspetti riguardanti l uso di software libero e open source, e su quelli più prossimi alle problematiche inerenti il WebGIS; telecomunicazioni e sicurezza, essendo settori fortemente normati a livello nazionale e internazionale, sono meno toccati dagli aspetti delle buone pratiche. Considerando per primo il punto dello hardware e del consumo energetico, ultimamente si è vista una crescente sensibilità a riguardo dei consumi energetici associati ai dispositivi elettronici. Questo ha determinato la definizione di nuove norme legislative, standard tecnici e progetti di studio, analisi e ricerca per porre un limite al sempre crescente consumo di elettricità e per cercare di migliorare l efficienza energetica di tali sistemi. I principali sistemi su cui viene posta l attenzione sono: notebook, personal computer e server. La Commissione Europea ha emanato recentemente decisioni al fine di stabilire l assegnazione del marchio di qualità ecologica (Ecolabel UE) per i server nel 2009 e per notebook e personal computer nel giugno Sebbene tali norme (che verranno analizzate a fondo più avanti) non siano state ancora recepite a livello normativo dalle due nazioni, dal lato italiano il ricorso a CONSIP per le acquisizioni prefigura la prossima adozione delle raccomandazioni citate. Sotto il profilo del supporto alla virtualizzazione (lasciando l analisi di dettaglio al rapporto della corrispondente azione), il comune, esteso ricorso ad architetture x86 fornisce già un indicazione di comune supporto alla virtualizzazione; sia Intel sia AMD forniscono oggi processori con architetture che facilitano il processo di virtualizzazione, e il dimensionamento dei server (come emerge dai questionari) è tale da supportare i meccanismi software di virtualizzazione. Le soluzioni architetturali recenti mirano anche a ridurre il divario a livello di prestazioni tra un sistema normale ed uno virtualizzato; in particolare, mirano a evitare il ricorso alla paravirtualizzazione, e quindi alla traduzione binaria, semplificando l implementazione di VMM che possano supportare una vasta gamma di sistemi operativi non modificati ed al tempo stesso mantenendo un alto livello di prestazioni. Come già indicato in precedenza, la continuità operativa costituisce un punto rilevante per tutti i partner; le predisposizioni già oggi attuate costituiscono un punto di riferimento per lo sviluppo di successive soluzioni ancora più robuste e con compatibilità non minore. Le soluzioni oggi adottate sono essenzialmente locali, con ridondanze e backup risolti a livello del singolo partner; potrà essere interessante, in uno sviluppo successivo, esplorare soluzioni alternative basate su tecnologie emergenti (ad esempio, soluzioni basate su cloud computing). Nell ambito dei sistemi embedded, fino ad ora la compatibilità è implicitamente garantita dal ricorso, ad esempio, a tecniche quali GPS per la localizzazione, etc. In particolare per 12

16 3.2 Le buone pratiche adottate 3 RISULTANZE COMPLESSIVE quanto riguarda gli aspetti di mobilità, cresce a livello europeo la preoccupazione per definire soluzioni standardizzate e con compatibilità garantita. Ad esempio dal 2001, con la pubblicazione del Libro Bianco della Commissione sulla politica europea dei trasporti, hanno avuto inizio alcune iniziative in merito alla sicurezza stradale e alla realizzazione di veicoli intelligenti. Tra le varie attività previste, alcune già attive ed altre ancora in fase di sviluppo, si evidenziano: sistema S.E.T. Con l entrata in vigore della Decisione 2009/750/CE [HW1], ha preso avvio l attuazione della Direttiva 2004/52/CE in merito alla realizzazione del Servizio Europeo di Telepedaggio (S.E.T.). Questo servizio permette agli utenti di pagare il pedaggio stradale, ovunque siano presenti e previsti sistemi di telepedaggio, avvalendosi di una singola apparecchiatura di bordo e di un unico contratto, stipulato con un operatore qualificato di propria scelta. Secondo tali norme, i nuovi sistemi di bordo dovranno basarsi su una o più delle seguenti tecnologie: localizzazione satellitare (GNSS, Global Navigation Satellite System), comunicazioni mobili GSM-GPRS e dispositivi a corto raggio DSRC operanti nella banda di frequenze 5,8 GHz. Dove necessario questi sistemi possono essere collegati al tachigrafo elettronico del veicolo. I dispositivi a corto raggio vengono principalmente utilizzati per il trasferimento delle informazioni tra l unità a bordo del veicolo e il sistema fisso o mobile al suolo di un esattore di pedaggi. Questi sistemi vengono regolamentati secondo gli standard EN e ETSI ES Allo stesso modo può essere sfruttata la tecnologia GNSS. Per i sistemi di localizzazione satellitare, gli esattori dei pedaggi e i fornitori del servizio possono basarsi sulla norma CEN ISO/TS [HW2], che consente di controllare numerosi attributi presenti e passati dell apparecchiatura di bordo nonché i parametri dell utente e del veicolo. Mentre l interfaccia tra l apparecchiatura di bordo con i sistemi di back-office dei fornitori del servizio può essere gestita mediante sistemi GSM-GPRS (GSM TS 03.60/23.060). Questo scambio di dati include la configurazione a distanza dell apparecchiatura di bordo secondo il contratto o i parametri del veicolo, l invio dei dati relativi all addebito e l aggiornamento del sistema di bordo con i dati contestuali del pedaggio. sistema ecall : Questa azione prevede la realizzazione di un servizio paneuropeo di chiamate d emergenza da installare a bordo dei veicoli. In caso di grave incidente, i sensori a bordo del mezzo avvieranno automaticamente una chiamata ecall. Una volta attivato, il sistema a bordo del veicolo stabilisce un collegamento vocale con il 112 ed allo stesso tempo viene inviato un messaggio di emergenza appoggiandosi alla rete GPRS. Questo messaggio, definito dallo standard CEN/TS [HW8], include informazioni chiave (MSD, Minimum Set of Data) sull incidente, quali l ora, il luogo, la direzione di guida (ricavate da dati satellitari) e la descrizione del veicolo. A questo progetto partecipano tutti gli stati membri dell Unione Europea, le aziende produttrici di autoveicoli ed alcuni stati non appartenenti alla UE, come la Norvegia e la Svizzera, che hanno sottoscritto un memorandum d intesa (MoU). RDS-TMC: Il sistema RDS-TMC (Radio Data System-Traffic Message Channel) è un servizio di radiodiffusione che trasmette agli automobilisti informazioni sulle 13

17 3.2 Le buone pratiche adottate 3 RISULTANZE COMPLESSIVE condizioni del traffico. Le unità installate sui veicoli possono fornire tali informazioni mediante messaggi vocali o visivi, con la possibilità di scegliere la lingua utilizzata e avere accesso ad informazioni relative a tragitti specifici. Ogni informazione sul traffico ricevuta contiene una descrizione dell evento, la località a cui fa riferimento, la direzione, l entità dell evento, la durata stimata ed eventuali consigli su percorsi alternativi. Ad ogni evento è associato un messaggio, codificato secondo lo standard Alert C/ISO 14819, che viene tradotto da un opportuno decoder sfruttando un database per l associazione dei codici ricevuti con la tipologia di evento e il luogo. Passando al software, dall analisi della parte di questionario inerente il software è emerso che i vari partner utilizzano sia software di tipo proprietario sia software libero, oppure open-source. Il software proprietario è così chiamato perchè il suo utilizzo, modifica, riproduzione e distribuzione sono sottoposti a restrizioni, che tipicamente vengono stabilite dal proprietario del software sotto forma di vincoli tecnici (per esempio non viene rilasciato il codice sorgente) oppure legali (copyright, licenze...). Il software libero invece è quello che viene pubblicato con una licenza che generalmente ne permette un libero utilizzo e consente modifiche e personalizzazioni, nonché la sua ridistribuzione. Si noti che libero e open source non significano esattamente la stessa cosa, nonostante la disponibilità del codice sorgente sia alla base del software libero [SW12]; alle spalle del software libero c è la Free Software Foundation [SW13] mentre è la Open Source Initiative [SW14] a spingere per il software open source. Secondo Richard Stallman, fondatore della Free Software Foundation, il software può essere definito libero se garantisce quattro libertà fondamentali: eseguire il software per qualsiasi scopo; studiare il software e modificarlo; ridistribuire copie del software in modo da aiutare il prossimo; migliorare il software e di distribuire pubblicamente i miglioramenti, così che tutta la comunità ne tragga beneficio. Una delle licenze più utilizzate per la distribuzione del software libero, che garantisce le quattro libertà sopraelencate, è la GNU General Public License [SW15]. Questa licenza è particolarmente restrittiva, nel senso che obbliga chi modifica un programma distribuito sotto questa licenza a ridistribuirlo con la medesima licenza e vieta l utilizzo del codice in programmi proprietari. Esiste anche una licenza un po meno restrittiva, la GNU Lesser General Public License [SW16]. Secondo i sostenitori del software libero, esso presenta numerosi vantaggio rispetto a quello proprietario. Sono elencati, di seguito, quelli più significativi: il codice sorgente è sottoposto alla revisione di moltissime persone ed quindi più diffcile che sfuggano errori e bug; inoltre, quando questi vengono trovati solitamente vengono corretti molto rapidamente; 14

18 3.3 Prospettive future 3 RISULTANZE COMPLESSIVE il software libero non utilizza standard proprietari (e segreti) per protocolli e dati e quindi è più facile scrivere software compatibile e interoperabile; è possibile modificare il software libero e adattarlo alle proprie esigenze. Probabilmente il principale difetto del software libero è che non è sempre disponibile: in alcuni ambiti infatti, soprattutto se di nicchia, può essere piuttosto difficile trovare un alternativa valida a un software proprietario. 3.3 Prospettive per soluzioni e best practices adottabili in un prossimo futuro Sotto questo profilo, non è facile (e forse nemmeno opportuno) ricorrere a conclusioni riassuntive: per quanto riguarda le tecnologie dell informazione, ci si trova in un momento di evoluzione molto rapida e verso direzioni notevolmente diverse da quelle tradizionali, al punto che fra le molte best practices che si vanno delineando può essere difficile identificare quelle che con maggiore probabilità avranno successo. Nelle sezioni individuali per i diversi filoni tecnologici, si approfondiscono le linee di sviluppo che oggi appaiono meglio assestati, eventualmente già base di nuove direttive internazionali o standard internazionali; per il resto (ad esempio, l orientamento verso il ricorso al cloud computing, l emergere di terminali light di tipo universale basati su software open source tipo Android, etc.) si intende sviluppare opportuni approfondimenti nel terzo rapporto. 15

19 4 HARDWARE 4 Hardware All interno di questa sezione vengono prese in considerazione alcune tematiche riguardanti diversi aspetti del mondo hardware, quali: sistemi di calcolo, sistemi per la gestione della continuità operativa e sistemi embedded. Per ogni contesto considerato vengono discussi aspetti tecnologici, che in qualche modo impattano sui vari ambiti del progetto, non soltanto per presentare le soluzioni attualmente in atto ma anche per comprendere in che direzione stanno evolvendo i vari sistemi per far fronte a necessità pratiche o a regole dettate da normative nazionali od internazionali. 4.1 Piattaforme elaborative In merito ai sistemi computazionali lo studio effettuato viene suddiviso in tre parti. Nella prima sotto sezione vengono discusse ed analizzate le risposte al questionario inerenti a tale tematica, per identificare l eventuale presenza di incongruenze, somiglianze, punti di forza o di debolezza nelle soluzioni adottate dai sogetti coinvolti nel progetto. Mentre nelle restanti due parti vengono presentati alcuni aspetti tecnologici, a livello di sistema e di singolo dispositivo, per far fronte ad esigenze e necessità inerenti la riduzione dei consumi energetici e la riduzione delle prestazioni in ambienti virtualizzati Analisi risultati questionari Nella sezione Piattaforme Elaborative presente nel questionario venivano poste, ai vari partner del progetto, domande generiche sulla struttura dei sistemi informativi presenti nella loro organizzazione. Viene posta particolare attenzione ai sistemi appartenenti alla categoria server e all organizzazione dei data center in generale. In questa analisi non sono stati presi in esame aspetti inerenti piattaforme da ufficio o comunque utilizzate da utenti in genere, come computer desktop e notebook. Sono state inoltre presentate anche domande per indagare quali motivazioni, politiche di acquisizione o strategie progettuali sono alla base delle scelte effettuate per la dotazione di un particolare sistema. Nella seguente tabella sono indicate le domande in merito alle piattaforme elaborative e le risposte date dai soggetti coinvolti in questo progetto. Lombardia Piemonte Valle d Aosta Bolzano Ticino 1. Nella sua organizzazione è stata seguita una particolare politica a riguardo della fornitura di piattaforme elaborative? Sì Sì Sì Sì Sì Tabella 1: continua nella prossima pagina 16

20 4.1 Piattaforme elaborative 4 HARDWARE Tabella 1: continua dalla pagina precedente Lombardia Piemonte Valle d Aosta Bolzano Ticino 2. In caso di risposta affermativa, in cosa consiste questa politica? Si basa su qualche normativa locale o regolamento interno? É stata fatta una progettazione architetturale del servizio. In funzione dell entità delle forniture ci si affida a gare d appalto o ad acquisti tramite CONSIP. Standard de facto con obiettivo di ottimizzazione delle risorse utilizzate. Si basa su un regolamento interno. N.D. 3. Quale o quali architetture per CPU sono presenti nei server per servizi WebGIS? Indicare anche la percentuale rispetto al totale. x86 64 bit (100%) x86 64 bit (100%) i386 (50%) e x86 64 bit (50%) x86 64 bit (100%) 4. Riportare la configurazione tipica dei server per applicazioni WebGIS? 2 CPU; 4 GB di memoria RAM. 2 CPU; 2 GB di memoria RAM; 120 GB di memoria HDD; collegamento di rete a 100 Mbps. 1 CPU con frequenza di funzionamento a 3,4 GHz; 2 GB di memoria RAM; 2 HDD per uno spazio totale di 72 GB; collegamento di rete a 1000 Mbps. 2 CPU; 8 GB di memoria RAM; 400 GB di memoria HDD; collegamento di rete a 1000 Mbps. N.D. N.D All interno dei server utilizzati sono presenti elementi ridondanti? Nel caso siano presenti elementi ridondanti, indicare in cosa consistono. Sì, alimentatori e dischi RAID. Sì, alimentatori e dischi. Sì, alimentatori e dischi. Sì, alimentatori e dischi RAID. 7. Quale o quali protocolli di comunicazione verso sistemi di storage sono disponibili nel Centro di Elaborazione Dati? FC, NFS e isc- SI. FC, NFS e FcoE. Sì. FC. N.D. N.D. Tabella 1: si conclude dalla pagina precedente Tabella 1: Risposte al questionario, sezione piattaforme elaborative Tutte le istituzioni associate a regioni o cantoni coinvolti in questo progetto prevedono una politica per la fornitura di piattaforme elaborative. In gran parte dei casi questa 17