PROGETTO STRATEGICO PTA PIATTAFORMA TECNOLOGICA ALPINA: UNO STRUMENTO TRANSFRONTALIERO PER LA CONDIVISIONE DI INFRASTRUTTURE E SERVIZI AZIONE 3
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Programma Operativo di Cooperazione Transfrontaliera
Italia – Svizzera 2007–2013
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 SamiINDICE
Indice
1 Introduzione 1
2 Riferimenti accordo-documenti 2
2.1 Distinzione tra aspetti di IT e aspetti di TCL . . . . . . . . . . . . . . . 2
2.2 Definizione della normativa vigente IT e TLC . . . . . . . . . . . . . . . 2
2.2.1 Studio della normativa esistente . . . . . . . . . . . . . . . . . . . 2
2.2.2 Mappatura dell’attuale dotazione tecnologica . . . . . . . . . . . . 3
2.2.3 Standard e best practices esistenti . . . . . . . . . . . . . . . . . . 3
2.2.4 Verifica di compatibilità in termini tecnologici e normativi . . . . 4
2.2.5 Possibili proposte per lo sviluppo di indicazioni normative . . . . 4
2.2.6 Attività di analisi e mappatura dell’esistente . . . . . . . . . . . . 4
2.3 Analisi della normativa a livello transnazionale, nazionale e regionale, per
quanto riguarda le varie tecnologie afferenti all’ICT . . . . . . . . . . . . 4
2.3.1 Aspetti considerati . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Identificazione dei punti di “cerniera” . . . . . . . . . . . . . . . . 5
2.3.3 Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti
nel progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 La compatibilità e le best practices: risultanze complessive 6
3.1 Le soluzioni attualmente utilizzate (installato, strumenti hardware-software,
metodologie): aspetti che impattano sulla compatibilità . . . . . . . . . . 6
3.2 Le buone pratiche adottate . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Prospettive per soluzioni e “best practices” adottabili in un prossimo futuro 15
4 Hardware 16
4.1 Piattaforme elaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . 16
4.1.2 Consumo energetico dei sistemi di elaborazione . . . . . . . . . . 18
4.1.2.1 Sistemi notebook . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2.2 Personal computer . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.3 Sistemi server e workstation . . . . . . . . . . . . . . . . 21
4.1.3 Supporto hardware a processi di virtualizzazione . . . . . . . . . . 22
4.2 Continuità operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Soluzioni attuabili in base agli obiettivi . . . . . . . . . . . . . . . 27
4.2.2.1 Backup su nastro . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2.2 Backup su disco . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2.3 Replica in remoto . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Infrastrutture di rete per i sistemi di storage . . . . . . . . . . . . 30
4.2.3.1 Direct Attached Storage . . . . . . . . . . . . . . . . . . 30
4.2.3.2 Storage Area Network . . . . . . . . . . . . . . . . . . . 30
4.2.3.3 Network Attached Storage . . . . . . . . . . . . . . . . . 32
iINDICE
4.3 Sistemi Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Telecomunicazioni 38
5.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Soluzioni per il controllo dei flussi di mobilità . . . . . . . . . . . . . . . 40
5.2.1 Dispositivi a Corto Raggio per applicazioni non specifiche . . . . . 40
5.2.1.1 Banda 2400 - 2483,5 MHz . . . . . . . . . . . . . . . . . 40
5.2.1.2 Banda 868 - 868,6 MHz . . . . . . . . . . . . . . . . . . 41
5.2.1.3 Banda 433,05 - 434,79 MHz . . . . . . . . . . . . . . . . 41
5.2.2 Sistemi di identificazione a radio frequenza (RFID) . . . . . . . . 41
5.2.2.1 Banda 2446 - 2454 MHz . . . . . . . . . . . . . . . . . . 41
5.2.2.2 Banda 865 - 868 MHz . . . . . . . . . . . . . . . . . . . 42
5.2.3 Sistemi di trasporto intelligenti (STI) . . . . . . . . . . . . . . . . 42
5.2.3.1 Banda 5855 - 5905 MHz . . . . . . . . . . . . . . . . . . 43
6 Software e dati 44
6.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 Software proprietario vs. libero . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Software e dati GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Sistemi operativi real-time e per le WSN . . . . . . . . . . . . . . . . . . 52
7 Sicurezza ICT 55
7.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Tecniche per la sicurezza ICT . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1 Confidenzialità, integrità e autenticazione . . . . . . . . . . . . . . 61
7.2.1.1 Sistemi crittografici . . . . . . . . . . . . . . . . . . . . . 61
7.2.1.2 Funzioni di hash . . . . . . . . . . . . . . . . . . . . . . 62
7.2.1.3 Identificazione e autenticazione . . . . . . . . . . . . . . 63
7.2.2 Sicurezza architetturale . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.2.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.2.2 Architettura a due zone . . . . . . . . . . . . . . . . . . 65
7.2.2.3 Virtual Private Network (VPN) . . . . . . . . . . . . . . 67
7.3 Sicurezza nelle Wireless Sensor Networks (WSN) . . . . . . . . . . . . . . 67
8 WebGIS 69
8.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Riferimenti I
ii1 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à tecno-
logica 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 con-
frontare 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 ine-
renti 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.
12 RIFERIMENTI ACC-DOC
2 Riferimenti accordo-documenti
Questa sezione del documento è pensata al fine di chiarificare l’organizzazione del lavo-
ro 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.
2.2.1 Studio della normativa esistente
Lo studio della normativa esistente ha coperto numerose aree di interesse, che sono ri-
portate 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)
22.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 separa-
tamente 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.
2.2.2 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.
2.2.3 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 esplici-
tamente 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 4.2.2 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à
32.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 ac-
quisizione 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 2011”. 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 6.2.
2.2.4 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” pre-
sente 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 map-
patura tecnologica effettuata (es. per ciò che riguarda i navigatori satellitari e i sistemi
per il pagamento autostradale, sottosezione 4.3).
2.2.5 Possibili proposte per lo sviluppo di indicazioni normative
Nel documento integrativo titolato “Progetto Interreg PTA - (Accordo fra Regione Lom-
bardia 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.
2.2.6 Attività di analisi e mappatura dell’esistente
Per queste attività si rimanda ai punti 2.2.2 e 2.2.4.
2.3 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 2.2.1.
42.3 Analisi dei livelli normativi 2 RIFERIMENTI ACC-DOC
2.3.1 Aspetti considerati
Gli argomenti considerati nell’analisi normativa sono riportati in elenco al punto 2.2.1.
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.
2.3.2 Identificazione dei punti di “cerniera”
Per quanto riguarda lo studio normativo, presente nel primo documento, i punti di “cer-
niera”, sotto forma di compatibilità o incompatibilità rilevate, sono evidenziati sia di-
rettamente 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 sottose-
zione, 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à digita-
le”, cosı̀ come precisato sia al termine del paragrafo 5.2.1.3 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”.
2.3.3 Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti nel
progetto
Per la presentazione di queste attività si rimanda ai punti 2.2.2 e 2.2.4. Il discorso della
transizione tra generazioni differenti è stato soprattutto considerato dal punto di vista
software, che si ritiene sia più rilevante (cfr. sottosezione 6.2.
53.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE
3 La compatibilità e le best practices: risultanze com-
plessive
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 incompa-
tibilità possono essere potenzialmente numerosi, in quanto esistono molti sistemi
operativi differenti che supportano diverse architetture hardware e su cui posso-
no girare applicativi di vari tipi. Oltre a questa eterogeneità di soluzioni bisogna
anche considerare il fatto che molti software proprietari utilizzano anche forma-
ti 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 riguar-
danti 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 5.
3.1 Le soluzioni attualmente utilizzate (installato, strumenti
hardware-software, metodologie): aspetti che impattano sul-
la compatibilità
Nei questionari, per quanto riguarda le piattaforme elaborative si è data particolare at-
tenzione 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 questio-
nario 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 archi-
tetturale del servizio che deve essere erogato. Si evidenzia che, per quanto riguarda alcune
63.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 co-
municazioni 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 que-
stionario. 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 diffe-
renti 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 fornitu-
ra 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 pro-
vincia 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). Sola-
mente 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 emer-
genze 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 questiona-
rio aveva come obiettivo lo studio della capacità di comunicazione, intesa come larghezza
73.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 risul-
tano 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 conside-
razione 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 trasmissio-
ne, 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’am-
pia gamma di apparecchiature quali strumenti di telemetria, telecomandi, allar-
mi e sistemi di comunicazione locale). In tale ambito (per le bande, rispettiva-
mente, 2400–2483,5 MHz, 868–868,6 MHz e 433,05–434,79 Mhz) sia la legislazio-
ne italiana sia quella svizzera si basano su quanto indicato nell’Allegato 1 della
Raccomandazione ERC 70-03 “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 — 2446–2454 MHz — si evidenziano differenze sostanziali nei parametri
fondamentali, per questa tipologia di sistemi di comunicazione, riportati nella le-
gislazione in vigore nei due paesi (essenzialmente per quanto riguarda la potenza
massima di trasmissione), derivanti dal fatto che il Piano Nazionale Svizzero di
83.1 Le soluzioni attualmente utilizzate 3 RISULTANZE COMPLESSIVE
Allocazione delle Frequenze fa riferimento alla Raccomandazione ERC 70-03 Al-
legato 11, mentre la legislazione italiana in materia si basa sulla Decisione della
Commissione Europea 2010/368/CE (che prevede in particolare limiti più stringen-
ti alla potenza emessa). Per quanto riguarda la seconda — 865–868 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 70-03 Allegato 11.
3. Sistemi di Trasporto Intelligenti - categoria che include tutte le tecnologie dell’in-
formazione 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 vei-
colo, da veicolo ad infrastruttura e da infrastruttura a veicolo per la trasmissioni
di informazioni in tempo reale). La banda predisposta è quella 5855–505 MHz. Le
norme in vigore in Italia e in Svizzera, che definiscono ed armonizzano questa ban-
da per questo particolare campo di applicazione, si basano entrambe sullo standard
europeo ETSI EN 302 571.2: 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 si-
curamente arginato da alcune scelte implementative effettuate. Una di queste prevede
che a ogni partner sia lasciata la responsabilità di gestire i propri dati geografici, fornen-
done 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 Prox-
mox [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 norma-
tiva 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
93.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 co-
stituisce 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 questio-
nario 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 addi-
rittura tra due soluzioni differenti, qualora risultasse necessaria, non è cosı̀ scontata, ma
generalmente viene supportata da appositi strumenti forniti dalla software house. Fortu-
natamente, 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 ag-
giunge il supporto per dati geografici al database PostgreSQL [SW5]. Anche in questo
caso, sulla base delle scelte implementative dell’architettura della piattaforma PTA, l’u-
tilizzo 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 so-
luzioni 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’intro-
duzione 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, è sicu-
ramente 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 del-
la 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
103.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 sicurez-
za 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 fa-
cente 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 disomo-
geneità 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 pro-
grammazione 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 ognu-
no 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 fat-
to 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.
113.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 tec-
nici 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’assegnazio-
ne del marchio di qualità ecologica (Ecolabel UE) per i server nel 2009 e per notebook e
personal computer nel giugno 2011. 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 rac-
comandazioni citate.
Sotto il profilo del supporto alla virtualizzazione (lasciando l’analisi di dettaglio al rap-
porto 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 dimen-
sionamento 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 particola-
re, 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 presta-
zioni.
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 riferi-
mento 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 ba-
sate 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
123.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 pre-
so 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 telepedag-
gio, 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: localizza-
zione 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 elet-
tronico 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 15509 e ETSI ES 200674-1. 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 12813
[HW2], che consente di controllare numerosi attributi presenti e passati dell’appa-
recchiatura 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 15722 [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
133.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, ripro-
duzione 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;
143.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 rias-
suntive: 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 identifi-
care 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 internazio-
nali; 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.
154 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.
4.1.1 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
164.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 In funzione Standard de Si basa su un N.D.
una proget- dell’entità delle facto con regolamento in-
tazione archi- forniture ci si obiettivo di terno.
tetturale del affida a gare ottimizzazione
servizio. d’appalto o ad delle risorse
acquisti tramite utilizzate.
CONSIP.
3. Quale o quali architetture per CPU sono presenti nei server per servizi WebGIS? Indicare
anche la percentuale rispetto al totale.
x86 64 bit x86 64 bit i386 (50%) e x86 x86 64 bit N.D.
(100%) (100%) 64 bit (50%) (100%)
4. Riportare la configurazione tipica dei server per applicazioni WebGIS?
2 CPU; 4 GB di 2 CPU; 2 GB di 1 CPU con 2 CPU; 8 GB di N.D.
memoria RAM. memoria RAM; frequenza di memoria RAM;
120 GB di funzionamento 400 GB di
memoria HDD; a 3,4 GHz; 2 memoria HDD;
collegamento GB di memoria collegamento
di rete a 100 RAM; 2 HDD di rete a 1000
Mbps. per uno spazio Mbps.
totale di 72 GB;
collegamento
di rete a 1000
Mbps.
5-6. All’interno dei server utilizzati sono presenti elementi ridondanti? Nel caso siano
presenti elementi ridondanti, indicare in cosa consistono.
Sı̀, alimentatori Sı̀, alimentatori Sı̀, alimentatori Sı̀, alimentatori Sı̀.
e dischi RAID. e dischi. e dischi. 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- FC, NFS e FC. N.D. N.D.
SI. FcoE.
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 prevedo-
no una politica per la fornitura di piattaforme elaborative. In gran parte dei casi questa
174.1 Piattaforme elaborative 4 HARDWARE
politica è definita mediante buone pratiche al fine di ottimizzare la progettazione archi-
tetturale del servizio che deve essere erogato. Si evidenzia che, per quanto riguarda alcune
regioni italiane, viene anche sfruttato il Consip per la gestione delle gare d’appalto per
la fornitura e gli acquisti in genere.
A riguardo delle piattaforme per l’elaborazione, questa analisi si è concentrata principal-
mente sulla struttura dei server per applicazioni WebGIS. Si è deciso di dare particolare
rilevanza a questa tematica, perchè ricopre una delle principali attività di questo pro-
getto. 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 archi-
tettura 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.
La configurazione minima e comune, per questa tipologia di sistemi, presenta almeno due
processori, 2 GB di memoria RAM, un hard disk con almeno 70 GB di spazio e una
connessione di rete LAN a 100 Mbps. Inoltre, 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. Queste piattaforme sono connesse ai sistemi di storage del centro di
calcolo. Il protocollo FC (Fibre Channel ) è quello che risulta maggiormente utilizzato per
queste tipologie di comunicazioni. Comunque vengono anche utilizzati NFS e FcoE dal
CSI Piemonte e NFS e iSCSI da Lombardia Informatica.
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 que-
stionario. 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. I server considerati presentano processori con architettura x86 com-
patibile, configurazioni di elementi di memoria molto prossime come spazio di allocazione.
Analizzando i sistemi per il trasferimento di dati tra server e dispositivi di storage non si
evidenziano differenze critiche, perchè tutti gli enti coinvolti utilizzano quasi unicamente
il medesimo protocollo (Fibre Channel ).
4.1.2 Consumo energetico dei sistemi di elaborazione
Nell’ultimo periodo si è assistito ad una crescente sensibilità e preoccupazione a riguardo
dei consumi energetici associati ai dispositivi elettronici. Questo ha determinato la defi-
nizione 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.
4.1.2.1 Sistemi notebook
Il 6 giugno 2011 la Commissione europea ha emanato la Decisione 2011/330/UE [HW3]
al fine di stabilire i criteri per l’assegnazione del marchio di qualità ecologica dell’Unio-
ne europea (Ecolabel UE) ai computer portatili. Per computer portatili vengono intesi
18Puoi anche leggere
