- Piattaforma Tecnologica Alpina

Transcript

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 compatibilità tecnologica
nel settore ICT e TLC
Francesco Bruschi
Gianpaolo Cugola
Alberto Marinelli
Marco Marcon
Mariagiovanna Sami
INDICE
Indice
1 Introduzione
1
2 Riferimenti accordo-documenti
2.1 Distinzione tra aspetti di IT e aspetti di TCL . . . . . . . . . . . . . . .
2.2 Definizione della normativa vigente IT e TLC . . . . . . . . . . . . . . .
2.2.1 Studio della normativa esistente . . . . . . . . . . . . . . . . . . .
2.2.2 Mappatura dell’attuale dotazione tecnologica . . . . . . . . . . . .
2.2.3 Standard e best practices esistenti . . . . . . . . . . . . . . . . . .
2.2.4 Verifica di compatibilità in termini tecnologici e normativi . . . .
2.2.5 Possibili proposte per lo sviluppo di indicazioni normative . . . .
2.2.6 Attività di analisi e mappatura dell’esistente . . . . . . . . . . . .
2.3 Analisi della normativa a livello transnazionale, nazionale e regionale, per
quanto riguarda le varie tecnologie afferenti all’ICT . . . . . . . . . . . .
2.3.1 Aspetti considerati . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Identificazione dei punti di “cerniera” . . . . . . . . . . . . . . . .
2.3.3 Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti
nel progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2
3
3
4
4
4
4
5
5
5
3 La compatibilità e le best practices: risultanze complessive
6
3.1 Le soluzioni attualmente utilizzate (installato, strumenti hardware-software,
metodologie): aspetti che impattano sulla compatibilità . . . . . . . . . .
6
3.2 Le buone pratiche adottate . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3 Prospettive per soluzioni e “best practices” adottabili in un prossimo futuro 15
4 Hardware
4.1 Piattaforme elaborative . . . . . . . . . . . . . . . . . .
4.1.1 Analisi risultati questionari . . . . . . . . . . .
4.1.2 Consumo energetico dei sistemi di elaborazione
4.1.2.1 Sistemi notebook . . . . . . . . . . . .
4.1.2.2 Personal computer . . . . . . . . . . .
4.1.2.3 Sistemi server e workstation . . . . . .
4.1.3 Supporto hardware a processi di virtualizzazione
4.2 Continuità operativa . . . . . . . . . . . . . . . . . . .
4.2.1 Analisi risultati questionari . . . . . . . . . . .
4.2.2 Soluzioni attuabili in base agli obiettivi . . . . .
4.2.2.1 Backup su nastro . . . . . . . . . . . .
4.2.2.2 Backup su disco . . . . . . . . . . . .
4.2.2.3 Replica in remoto . . . . . . . . . . . .
4.2.3 Infrastrutture di rete per i sistemi di storage . .
4.2.3.1 Direct Attached Storage . . . . . . . .
4.2.3.2 Storage Area Network . . . . . . . . .
4.2.3.3 Network Attached Storage . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
18
18
19
21
22
25
25
27
27
28
29
30
30
30
32
INDICE
4.3
Sistemi Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Telecomunicazioni
5.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . .
5.2 Soluzioni per il controllo dei flussi di mobilità . . . . . . . . . . .
5.2.1 Dispositivi a Corto Raggio per applicazioni non specifiche .
5.2.1.1 Banda 2400 - 2483,5 MHz . . . . . . . . . . . . .
5.2.1.2 Banda 868 - 868,6 MHz . . . . . . . . . . . . . .
5.2.1.3 Banda 433,05 - 434,79 MHz . . . . . . . . . . . .
5.2.2 Sistemi di identificazione a radio frequenza (RFID) . . . .
5.2.2.1 Banda 2446 - 2454 MHz . . . . . . . . . . . . . .
5.2.2.2 Banda 865 - 868 MHz . . . . . . . . . . . . . . .
5.2.3 Sistemi di trasporto intelligenti (STI) . . . . . . . . . . . .
5.2.3.1 Banda 5855 - 5905 MHz . . . . . . . . . . . . . .
33
.
.
.
.
.
.
.
.
.
.
.
38
38
40
40
40
41
41
41
41
42
42
43
.
.
.
.
44
44
49
50
52
.
.
.
.
.
.
.
.
.
.
.
55
55
61
61
61
62
63
64
64
65
67
67
8 WebGIS
8.1 Analisi risultati questionari . . . . . . . . . . . . . . . . . . . . . . . . . .
69
69
6 Software e dati
6.1 Analisi risultati questionari . . .
6.2 Software proprietario vs. libero
6.3 Software e dati GIS . . . . . . .
6.4 Sistemi operativi real-time e per
. . . . .
. . . . .
. . . . .
le WSN
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Sicurezza ICT
7.1 Analisi risultati questionari . . . . . . . . . . . . .
7.2 Tecniche per la sicurezza ICT . . . . . . . . . . .
7.2.1 Confidenzialità, integrità e autenticazione .
7.2.1.1 Sistemi crittografici . . . . . . . .
7.2.1.2 Funzioni di hash . . . . . . . . .
7.2.1.3 Identificazione e autenticazione .
7.2.2 Sicurezza architetturale . . . . . . . . . . .
7.2.2.1 Firewall . . . . . . . . . . . . . .
7.2.2.2 Architettura a due zone . . . . .
7.2.2.3 Virtual Private Network (VPN) .
7.3 Sicurezza nelle Wireless Sensor Networks (WSN) .
Riferimenti
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
ii
1 INTRODUZIONE
1
Introduzione
Il presente studio — che fa seguito al rapporto consegnato in forma definitiva nel marzo
2011 e riguardante la compatibilità normativa — si focalizza sulla compatibilità tecnologica e sulle best practices adottate nei campi d’interesse per il progetto PTA; esso è
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 incompatibilità 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 già 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 è suddiviso nelle seguenti sezioni:
• Sezione relativa allo hardware, in cui sono presentati i risultati dei questionari inerenti le piattaforme elaborative e la continuità 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 mobilità.
• 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 è 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
2 RIFERIMENTI ACC-DOC
2
Riferimenti accordo-documenti
Questa sezione del documento è 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 è 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 compatibilità 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’accessibilità. Inoltre
sono state considerate anche altre aree di particolare interesse per il progetto, ossia il
WebGIS, l’infomobilità e la sicurezza nelle gallerie stradali e ferroviarie.
Nel secondo documento, il cui titolo è “Studio della compatibilità tecnologica e delle
best practices nel settore ICT e TLC”, è 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’attività svolta, riportata principalmente nel primo documento, è 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 riportate in elenco con l’indicazione della sezione del primo documento in cui vengono
trattate:
• Hardware (2.1)
– Piattaforme elaborative (2.1.1)
– Continuità 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
2.2 Definizione della normativa vigente IT e TLC
• Privacy (3.1)
• Copyright (3.2)
• Riuso dei dati (3.3)
• Sicurezza - Settore ICT (3.4)
• Accessibilità (3.5)
• WebGIS (4.1)
• Infomobilità (4.2)
• Sicurezza nelle gallerie stradali (4.3)
• Sicurezza nelle gallerie ferroviarie (4.4)
Ognuna di queste sezioni è suddivisa in più 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 è stata presa in considerazione, in
un opportuno paragrafo, anche quella regionale o cantonale.
2.2.2
Mappatura dell’attuale dotazione tecnologica
Una delle attività principali effettuate per la realizzazione di questo secondo documento
è 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 è 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 è
già stata anticipata nel documento inerente lo studio della normativa, è 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’affidabilità 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 mobilità
3
2.3 Analisi dei livelli normativi
(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 è 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 compatibilità 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 compatibilità,
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 è anche stata verificata la presenza e l’eventuale
rispetto di standard internazionali.
In ambito tecnologico la compatibilità è 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 incompatibilità in ambiti non coinvolti dalla mappatura tecnologica effettuata (es. per ciò 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 Lombardia e Politecnico di Milano del 22/3/2010) - Rapporto al 30 giugno 2011” è 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
Attività di analisi e mappatura dell’esistente
Per queste attività 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 è stato condotto come riportato nella
sottosezione 2.2.1.
4
2.3 Analisi dei livelli normativi
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 è
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 “cerniera”, sotto forma di compatibilità o incompatibilità 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 incompatibilità o criticità.
Per quanto riguarda la parte inerente l’identità digitale (e quindi anche l’inserimento
di strumenti quali la carta d’identità elettronica o altre smart card) si è deciso di trattare
l’argomento in un terzo documento che integra i risultati dell’attività 4.5 “Identità digitale”, 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 “Identità digitale”.
2.3.3
Mappatura e analisi delle soluzioni esistenti presso gli enti coinvolti nel
progetto
Per la presentazione di queste attività si rimanda ai punti 2.2.2 e 2.2.4. Il discorso della
transizione tra generazioni differenti è stato soprattutto considerato dal punto di vista
software, che si ritiene sia più rilevante (cfr. sottosezione 6.2.
5
3.1 Le soluzioni attualmente utilizzate
3
3 RISULTANZE COMPLESSIVE
La compatibilità e le best practices: risultanze complessive
Gli aspetti presi in considerazione riguardano:
• per gli aspetti hardware: sistemi di calcolo, sistemi per la gestione della continuità
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 mobilità;
• dal punto di vista del software, l’analisi porta a osservare che i rischi di incompatibilità 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 eterogeneità di soluzioni bisogna
anche considerare il fatto che molti software proprietari utilizzano anche formati proprietari dei dati e ciò può limitare notevolmente l’interoperabilità 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 5.
3.1
Le soluzioni attualmente utilizzate (installato, strumenti
hardware-software, metodologie): aspetti che impattano sulla compatibilità
Nei questionari, per quanto riguarda le piattaforme elaborative si è 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 è 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
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 è concentrata
principalmente sulla struttura dei server per applicazioni WebGIS. Si è deciso di dare
particolare rilevanza a questa tematica, perché ricopre una delle principali attività 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 affidabilità e sicurezza, sono presenti in tutti i casi alcuni
elementi ridondanti come gli alimentatori e i dischi RAID.
Il protocollo FC (Fibre Channel ) è 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 società ed organizzazioni che hanno compilato il questionario. Questo buon livello di compatibilità, prendendo in considerazione server per
applicazioni WebGIS, è dovuto al fatto che in tutti i casi analizzati vengono impiegati
sistemi molto simili.
Anche sotto il profilo della continuità operativa, vengono analizzate e confrontate le differenti modalità di gestione della business continuity, da parte dei vari soggetti interessati
dal progetto PTA. Tutti i partner del progetto, per garantire la continuità di servizio a
seguito di eventi dannosi, prevedono una politica gestionale al fine di minimizzare i danni
e presentano degli accorgimenti tecnologici inerenti alla continuità operativa. Le soluzioni
più 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 continuità nella fornitura dell’alimentazione ai sistemi, oltre all’utilizzo di gruppi di continuità (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
più comunemente adottata consiste nell’utilizzo dei nastri magnetici LTO. Questa non è
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 continuità 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 capacità di comunicazione, intesa come larghezza
7
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, è 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 modalità di protezione delle trasmissioni mediante algoritmo di crittografia.
Questa protezione è 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
è molto variegata. Infatti, in base ai dati ricevuti, questa “capacità 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 realtà. A livello di architettura di rete,
tutti i partner sfruttano bilanciatori di carico, al fine di ottenere una migliore scalabilità e
affidabilità 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 mobilità” del progetto Interreg PTA, si è effettuato un confronto
tra le varie soluzioni e tecnologie applicabili per il controllo dei flussi di mobilità, 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 cioè:
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, 2400–2483,5 MHz, 868–868,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 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 identità
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 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
Allocazione delle Frequenze fa riferimento alla Raccomandazione ERC 70-03 Allegato 11, mentre la legislazione italiana in materia si basa sulla Decisione della
Commissione Europea 2010/368/CE (che prevede in particolare limiti più stringenti 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’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 è quella 5855–505 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 302 571.2: risulta quindi garantita la compatibilità.
Per quanto riguarda il software e i dati, a riguardo della piattaforma tecnologica da
realizzare per il progetto PTA, il problema della compatibilità software risulta essere sicuramente arginato da alcune scelte implementative effettuate. Una di queste prevede
che a ogni partner sia lasciata la responsabilità di gestire i propri dati geografici, fornendone l’accesso attraverso opportuni servizi standard, invece di creare un unico sistema
integrato; ciò elimina la necessità di uniformare ogni aspetto relativo al software per la
memorizzazione e il trattamento di tali dati, nonché al formato dei dati stessi. Si è 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, può 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
compatibilità. Nonostante ciò, 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. Ciò
è 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
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 compatibilità tra le varie versioni è pressoché completa e sono piuttosto rari
i casi in cui un software può essere eseguito correttamente su un sistema operativo più
vecchio mentre non funziona su uno più recente. Più probabile invece e da tener conto è
la compatibilità tra versione di sistema operativo e periferiche hardware, in quanto può
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 più 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 è cosı̀ scontata, ma
generalmente viene supportata da appositi strumenti forniti dalla software house. Fortunatamente, per il progetto PTA non si prevede la necessità di effettuare simili operazioni,
in quanto si è 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 compatibilità, 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 è stata scelta una piattaforma di virtualizzazione comune nominata nell’introduzione della presente sezione che dovrà essere utilizzata dai singoli partner per erogare
i servizi della piattaforma tecnologica.
Il software GIS, cioè quello che si occupa dell’elaborazione dei dati georeferenziati, è 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 compatibilità a questo livello: ognuno dei partner infatti è 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
(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 ciò che riguarda la sicurezza degli stessi. L’informazione più rilevante che emerge, in maniera piuttosto evidente,
dall’analisi delle risposte a questa parte del questionario è che tutti i partner, escluso il
canton Ticino che non si è 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 è 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 è 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 è un’altra pubblica amministrazione facente parte della stessa nazione, ma è 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 mobilità (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 tracciabilità anche al di fuori di un esplicito accordo.
Un’ultima nota riguarda WebGIS: innanzitutto è interessante notare una certa disomogeneità 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. Ciò 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 modalità 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 è 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 sarà ospitato sulla piattaforma
tecnologica virtualizzata.
11
3.2 Le buone pratiche adottate
3.2
Le buone pratiche adottate
Sotto il profilo delle buone pratiche già adottate, ci si è concentrati:
• per quanto riguarda lo hardware, sugli aspetti relativi al consumo energetico, alla
continuità 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 più 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
è vista una crescente sensibilità 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 elettricità 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 qualità 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
più 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
già 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) è 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 già indicato in precedenza, la continuità operativa costituisce un punto rilevante
per tutti i partner; le predisposizioni già oggi attuate costituiscono un punto di riferimento per lo sviluppo di successive soluzioni ancora più robuste e con compatibilità non
minore. Le soluzioni oggi adottate sono essenzialmente “locali”, con ridondanze e backup
risolti a livello del singolo partner; potrà 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 compatibilità è implicitamente garantita
dal ricorso, ad esempio, a tecniche quali GPS per la localizzazione, etc. In particolare per
12
quanto riguarda gli aspetti di mobilità, cresce a livello europeo la preoccupazione per
definire soluzioni standardizzate e con compatibilità 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 attività previste, alcune già 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 più 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’unità 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 può 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’apparecchiatura di bordo nonché 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
può 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 )
è un servizio di radiodiffusione che trasmette agli automobilisti informazioni sulle
13
condizioni del traffico. Le unità installate sui veicoli possono fornire tali informazioni
mediante messaggi vocali o visivi, con la possibilità 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 località a cui fa riferimento,
la direzione, l’entità dell’evento, la durata stimata ed eventuali consigli su percorsi
alternativi. Ad ogni evento è 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 è emerso
che i vari partner utilizzano sia software di tipo proprietario sia software libero, oppure
open-source. Il software proprietario è cosı̀ chiamato perchè 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 è quello
che viene pubblicato con una licenza che generalmente ne permette un libero utilizzo e
consente modifiche e personalizzazioni, nonché la sua ridistribuzione. Si noti che libero
e open source non significano esattamente la stessa cosa, nonostante la disponibilità del
codice sorgente sia alla base del software libero [SW12]; alle spalle del software libero c’è
la Free Software Foundation [SW13] mentre è la Open Source Initiative [SW14] a spingere
per il software open source.
Secondo Richard Stallman, fondatore della Free Software Foundation, il software può
essere definito libero se garantisce quattro libertà 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 comunità ne tragga beneficio.
Una delle licenze più utilizzate per la distribuzione del software libero, che garantisce le
quattro libertà sopraelencate, è la GNU General Public License [SW15]. Questa licenza è
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 più
significativi:
• il codice sorgente è sottoposto alla revisione di moltissime persone ed quindi più
diffcile che sfuggano errori e bug; inoltre, quando questi vengono trovati solitamente
vengono corretti molto rapidamente;
14
3.3 Prospettive future
• il software libero non utilizza standard proprietari (e segreti) per protocolli e dati
e quindi è più facile scrivere software compatibile e interoperabile;
• è possibile modificare il software libero e adattarlo alle proprie esigenze.
Probabilmente il principale difetto del software libero è che non è sempre disponibile:
in alcuni ambiti infatti, soprattutto se di nicchia, può 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 è 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 può essere difficile identificare quelle che con maggiore probabilità avranno successo. Nelle sezioni individuali per i
diversi filoni tecnologici, si approfondiscono le linee di sviluppo che oggi appaiono meglio
assestati, eventualmente già 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
4
4
HARDWARE
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
continuità 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 necessità 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 necessità 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 è stata seguita una particolare politica a riguardo della fornitura
di piattaforme elaborative?
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
Tabella 1: continua nella prossima pagina
16
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?
É stata fatta
una
progettazione architetturale
del
servizio.
In
funzione
dell’entità 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
(100%)
bit
x86
64
(100%)
bit
i386 (50%) e x86
64 bit (50%)
x86
64
(100%)
bit
N.D.
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.
5-6. 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.
Sı̀.
7. Quale o quali protocolli di comunicazione verso sistemi di storage sono disponibili nel
Centro di Elaborazione Dati?
FC, NFS e iSCSI.
FC,
NFS
FcoE.
e
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
4
HARDWARE
politica è definita mediante buone pratiche al fine di ottimizzare la progettazione architetturale 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 è concentrata principalmente sulla struttura dei server per applicazioni WebGIS. Si è deciso di dare particolare
rilevanza a questa tematica, perchè ricopre una delle principali attività 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.
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 affidabilità
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 ) è 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 società ed organizzazioni che hanno compilato il questionario. Questo buon livello di compatibilità, prendendo in considerazione server per
applicazioni WebGIS, è dovuto al fatto che in tutti i casi analizzati vengono impiegati
sistemi molto simili. I server considerati presentano processori con architettura x86 compatibile, 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, perchè 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 è assistito ad una crescente sensibilità e preoccupazione 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 elettricità 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 qualità ecologica dell’Unione europea (Ecolabel UE) ai computer portatili. Per computer portatili vengono intesi
18
4
HARDWARE
tutti quei sistemi che eseguono operazioni logiche ed elaborazione dati, sono concepiti
specificamente per essere portatili e per essere impiegati per un lungo periodo, con o
senza alimentazione di rete; dispongono di uno schermo integrato. Se un computer portatile presenta un alimentatore esterno, tale dispositivo si considera parte integrante del
sistema. I criteri vengono stabiliti in base ai seguenti aspetti considerati:
• Risparmio energetico
Le prestazioni dei computer portatili in termini di efficienza energetica devono essere
superiori alle prescrizioni per categoria fissate da ENERGY STAR v5.0. Per la
categoria A l’efficienza energetica deve essere superiore del 25%, per la categoria
B del 25% e invece per la categoria C del 15%. Nella categoria A rientrano tutti
i notebook che non appartengono alle altre categorie. Per essere classificati nella
categoria B, i notebook devono essere dotati di una GPU discreta. Mentre i notebook
rientrano nella categoria C se possiedono: almeno due core fisici, almeno due GB
di memoria RAM e una GPU discreta con un frame buffer di larghezza superiore a
128-bit.
• Gestione del consumo
I computer portatili devono possedere un sistema per la gestione del consumo che
consenta di oscurare lo schermo dopo 10 minuti di inattività e la possibilità di
passaggio alla modalità di sospensione (livello di sistema S3, sospeso in RAM) dopo
30 minuti. I computer portatili che presentano una scheda per il collegamento di
rete Ethernet devono permettere di inserire o disinserire la funzione Wake on LAN
(WOL). Inoltre, sempre nel caso in cui sia presente una scheda Ethernet, questa
categoria di computer devono essere in grado di abbandonare la modalità di veglia
sia in remoto (via rete), sia mediante impostazione (per esempio con un dispositivo
Real Time Clock ).
• Prolungamento della durata di vita
I computer portatili devono essere dotati di elementi che consentano di sostituire e
aggiornare la memoria ed espandere il sistema, devono essere presenti almeno tre
porte USB ed una porta per collegare uno schermo esterno. Il computer deve essere
concepito in modo che i principali componenti, compresi i dischi di memoria, i processori e le schede, possano essere sostituiti e/o aggiornati agevolmente, per esempio
impiegando alloggiamenti a incastro, a cassetto o a cartuccia per i componenti.
4.1.2.2
Personal computer
Come per i notebook, la Commissione europea il 9 giugno 2011 ha emesso la Decisione
2011/337/UE [HW4] che stabilisce i criteri ecologici per l’assegnazione del marchio di
qualità ecologica dell’Unione europea (Ecolabel UE) ai personal computer. Secondo questa decisione per personal computer viene inteso un apparecchio che esegue operazioni
logiche ed elabora dati, avvalendosi di dispositivi per l’immissione dei dati e di schermo e comprende un’unità di elaborazione centrale (CPU) per eseguire tali operazioni.
19
4
HARDWARE
Se un computer è commercializzato con un monitor, una tastiera o qualsivoglia altro dispositivo di immissione, anche tali dispositivi devono soddisfare i requisiti. I criteri per
l’assegnazione del marchio di qualità ecologica variano a seconda dei seguenti aspetti
considerati:
• Risparmio energetico
Le prestazioni dei personal computer in termini di efficienza energetica devono essere superiori alle prescrizioni di efficienza energetica fissate da ENERGY STAR
v5.0. Per la categoria A l’efficienza energetica deve essere superiore del 40%, per le
categorie B e C del 25% e per la categoria D del 30%. Nella categoria A rientrano
tutti i computer desktop che non appartengono alle altre categorie. Un personal
computer per essere classificato nella categoria B deve possedere: l’equivalente di
due core fisici, almeno 2 GB di memoria RAM. Nella categoria C, rientrano tutti i
personal computer che possiedono: più di due core fisici, almeno 2 GB di memoria
RAM e/o una GPU discreta. I sistemi desktop per essere classificati nella categoria
D devono essere dotati di: almeno quattro core fisici, almeno quattro GB di memoria RAM e/o una GPU discreta con un frame buffer di dimensioni superiori a 128
bit.
A riguardo del risparmio energetico associato ai monitor le prestazioni dello schermo del computer in termini di efficienza energetica in modalità attiva devono essere
superiori di almeno il 30% alle prescrizioni in ENERGY STAR v.5.0. Uno schermo
per computer in modalità standby deve presentare un consumo energetico non superiore a 1 W, in modalità attiva il consumo di energia deve essere uguale o inferiore
a 100 W misurati con la luminosità massima e in modalità spenta deve avere un
consumo non superiore a 0,5 W.
• Gestione consumo
I computer appartenenti a questa categoria devono possedere un sistema per la
gestione del consumo che consenta di oscurare lo schermo dopo 10 minuti di inattività e la possibilità di passaggio alla modalità di sospensione (livello di sistema S3,
sospeso in RAM) dopo 30 minuti. I personal computer che presentano una scheda
per il collegamento di rete Ethernet devono permettere di inserire o disinserire la
funzione Wake on LAN (WOL). Inoltre, sempre nel caso in cui sia presente una
scheda Ethernet, questa categoria di computer devono essere in grado di abbandonare la modalità di veglia sia in remoto (via rete), sia mediante impostazione (per
esempio con un dispositivo Real Time Clock ).
• Alimentatori interni
Gli alimentatori interni devono soddisfare almeno le prescrizioni di efficienza energetica per gli alimentatori interni fissate da ENERGY STAR v5.0. L’efficienza minima
deve essere pari al 85% al 50% della potenza nominale e pari al 82% al 20% e al
100% della potenza nominale con un fattore di potenza ≥0,9 al 100% della potenza
nominale.
20
4
HARDWARE
• Prolungamento della durata di vita
I personal computer devono essere dotati di elementi che consentano di sostituire
e aggiornare la memoria e le schede grafiche e che presentino almeno quattro porte
USB per espandere il sistema. Inoltre il PC deve essere concepito in modo che
i principali componenti (dischi di memoria, processori e schede) possano essere
sostituiti e/o aggiornati agevolmente.
4.1.2.3
Sistemi server e workstation
In merito ai consumi energetici associati a piattaforme di tipo server e workstation non
sono state ancora deliberate norme di legge europee o nazionali al fine di definire criteri
per l’assegnazione del marchio di qualità ecologica Ecolabel UE. Comunque il 16 giugno 2009 la Commissione delle Comunità europee ha emanato la Decisione 2009/489/CE
[HW5] che caratterizza queste tipologie di sistemi e ne definisce alcuni vincoli in merito
ai consumi energetici. In particolare questa decisione consiste in una attuazione a livello
europeo della etichettatura energetica statunitense Energy Star.
I sistemi server presi in considerazione nella Decisione 2009/489/CE sono sistemi di piccole dimensioni, per applicazioni domestiche o da ufficio, fondamentalmente progettato
per servire da host per altri computer. Un sistema per essere considerato un server di
piccole dimensioni deve avere le seguenti caratteristiche:
• essere progettato come impianto a piedistallo, a torre o di altro tipo simile a quello
di un desktop in modo tale che tutte le attività di elaborazione dati, archiviazione
e interfaccia di rete siano contenute in un unico case;
• essere progettato per essere operativo 24 ore al giorno, 7 giorni alla settimana, e
con un tempo di inattività non programmato estremamente ridotto (dell’ordine di
un determinato numero di ore all’anno);
• essere in grado di operare in situazioni di uso simultaneo da parte di più utenti
mediante piattaforme client collegate in rete;
• essere progettato per un sistema operativo accettato per applicazioni destinate a
uso domestico o di bassa gamma (ad esempio Windows Home Server, server Mac
OS X e Linux).
Anche i sistemi server di piccole dimensioni vengono suddivisi in due classi (A e B).
Nella classe A rientrano tutti i server di piccole dimensioni non appartenenti alla classe
B. Invece per essere classificati nella categoria B, i server di piccole dimensioni devono
essere dotati di: processore/i con più di un core fisico o più di un processore discreto e
una memoria RAM di almeno 1 gigabyte. Un sistema server in modalità “spento” deve
consumare meno di 2W, nel caso sia presente il sistema Wake On LAN attivo la potenza
massima deve essere inferiore a 2,7 W. Se il sistema si trova in modalità “inattivo”, un
server appartenente alla categoria A deve consumare una potenza inferiore od uguale a
50 W, mentre server rientranti nella categoria B devono prevedere un consumo di potenza
non superiore a 65 W.
21
4
HARDWARE
Secondo questa decisione con workstation si considerano sistemi ad elevate prestazioni
generalmente utilizzati per applicazioni che richiedono numerosi calcoli, quali la grafica, la progettazione assistita (CAD), lo sviluppo di software o applicazioni finanziarie e
scientifiche. Per essere considerato una workstation, un computer deve avere le seguenti
caratteristiche:
• avere un tempo medio fra i guasti (MTBF) di almeno 15 000 ore in base a Bellcore
TR-NWT-000332, numero 6, 12/97;
• supportare il codice correzione errore (EEC) e/o una memoria buffer;
• disporre di un’alimentazione supplementare per grafica di elevata qualità (ossia un
sistema di alimentazione supplementare PCI-E 6-pin 12V);
• non deve supportare la grafica UMA (Uniform Memory Access);
• deve includere cinque o più slot PCI, PCIe o PCI-X;
• deve essere in grado di fornire un supporto multiprocessore per due o più processori
(deve supportare fisicamente packages/sockets di processori separati, ossia non avere
un supporto per un processore singolo multicore).
Per le workstation i requisiti si basano su un valore del consumo energetico tipico (Typical
Electricity Consumption, TEC) calcolato in modo operativo, a potenza massima e su un
periodo considerato come ciclo di lavoro secondo la seguente espressione dove tutte le
potenze riportate sono espresse in watt.
PT EC = 0, 35 · Pspento + 0, 10 · Pstandby + 0, 55 · Pinattivo
La seguente espressione indica i requisiti associati a questo consumo di potenza per le
workstation riportati nella versione 5.0 delle specifiche Energy Star.
PT EC ≤ 0, 28 · [Pmax + (#HDD · 5)]
Nella decisione considerata non vengono analizzati sistemi server per ambienti data center.
Specifiche associate ai consumi energetici per questo tipo di piattaforme non vengono presi
in considerazione nei criteri ecologici riferiti all’Ecolabel UE. Comunque nel corso degli
ultimi anni sono stati avviati vari progetti di ricerca, da parte di grandi multinazionali in
campo ICT, per definire criteri e best practices per ridurre i consumi energetici nei data
center.
4.1.3
Supporto hardware a processi di virtualizzazione
Le soluzioni per la virtualizzazione hanno una lunga storia nel campo dell’informatica.
Al giorno d’oggi il processo di virtualizzazione è una metodologia attraverso la quale le
risorse di una piattaforma elaborativa vengono suddivise in più ambienti di esecuzione,
applicando una o più soluzioni come: partizionamento hardware e software, time-sharing,
22
4
HARDWARE
simulazione parziale o completa del sistema ed emulazione.
Vi sono molteplici vantaggi nell’utilizzo di sistemi virtualizzati. Una macchina virtuale
può essere usata per supportare più sistemi operativi contemporaneamente. Queste macchine possono essere anche utilizzate per consolidare il carico di lavoro di differenti server
sotto-utilizzati cosı̀ che poche piattaforme vengano utilizzate, di conseguenza si ottiene
un risparmio sulle risorse hardware ed una riduzione dei costi relativi all’infrastruttura.
Programmi software non recenti possono essere eseguiti su macchine virtuali, mentre non
funzionerebbero su un sistema operativo ed hardware recente. Possono anche fornire sicuri ed isolati ambienti di test per provare applicazioni non sicure, la virtualizzazione è una
buona soluzione per realizzare piattaforme di calcolo sicure. Dal punto di vista dell’utente, una macchina virtuale può fornire l’illusione di avere una particolare configurazione
hardware (come dispositivi SCSI, sistemi a multi-processore ecc.) e può essere usata per
simulare reti di calcolatori indipendenti.
Visto il crescente interesse da parte della comunità per i sistemi virtualizzati, alcune
aziende produttrici di CPU (Intel ed AMD) hanno iniziato a realizzare processori con architetture che facilitassero il processo di virtualizzazione. Questi progetti miravano anche
a ridurre il divario a livello di prestazioni tra un sistema normale ed uno virtualizzato.
Visto che gran parte dei sistemi computazionali in commercio presentano microprocessori
con architettura x86, questa analisi prende in considerazione aspetti e metodologie inerenti il supporto hardware a processi di virtualizzazione solo per questa categoria di CPU.
Vengono esclusi, da questo studio, processori con architetture PowerPC (IBM) e SPARC
(SUN-Oracle). La soluzione presentata è a carattere del tutto generale, non si riferisce ad
un particolare processore prodotto da una delle aziende citate. Questo perchè i processori
fabbricati da Intel ed AMD presentano la medesima architettura x86 compatibile.
Questa differenza nelle prestazioni tra un sistema virtualizzato ed uno “classico” è da
ricercarsi nella modalità con cui vengono assegnati i livelli di priorità alle varie istruzioni
che vengono eseguite. Infatti un microprocessore (per esempio Intel con architettura IA32 o Itanium) fornisce un sistema di protezione basato sul concetto di livello di privilegio
a due bit delle funzioni da eseguire, livello 0 per le istruzioni a maggior privilegio e livello
3 per quelle a privilegio più basso. Tale livello di privilegio determina se le istruzioni
privilegiate possono essere sicuramente eseguite. Inoltre, mediante questa soluzione viene
controllato l’accesso allo spazio di indirizzamento basato sulla configurazione delle page
table del processore. Gran parte dei software che vengono eseguiti su queste architetture
utilizzano livelli di priorità 0 e 3. Alcuni componenti di un sistema operativo che controlla
una CPU devono essere eseguiti con livello di privilegio 0. Dato che un Virtual Machine
Monitor (VMM) non consente questo controllo ad un sistema operativo ospite, tale OS
ospite non può eseguire ad un livello di privilegio 0. Un VMM funzionante su processori con questa architettura deve utilizzare una soluzione ring deprivileging, una tecnica
secondo la quale tutti i software ospiti vengono eseguiti ad un livello superiore allo 0.
Un sistema operativo guest potrebbe essere deprivilegiato in due modi diversi: potrebbe
essere eseguito sempre ad un livello di privilegio 1 (modello 0/1/3) oppure ad un livello
di privilegio 3 (modello 0/3/3). Sebbene il modello 0/1/3 supporta semplici VMM, non
può essere utilizzato per sistemi ospiti su architetture, per esempio IA-32, a 64 bit.
23
4
HARDWARE
Per gestire le problematiche che vengono riscontrate in sistemi virtualizzati che sfruttano
queste tipologie di architetture, i progettisti dei Virtual Machine Monitor hanno sviluppato alcune tecniche per modificare il programma guest, a livello sorgente o binario. Una
di queste tecniche, che modifica il programma a livello sorgente, viene chiamata paravirtualizzazione. Il codice sorgente del sistema operativo ospite viene modificato per creare
un’interfaccia che risulti semplice da virtualizzare. La paravirtualizzazione consente di
ottenere alte prestazioni e richiede modifiche alle applicazioni guest. Uno svantaggio di
questa tecnica è che viene limitato la gamma di sistemi operativi sopportati, un VMM
basato su questa soluzione non può utilizzare sistemi operativi il cui codice sorgente non
sia stato ancora modificato. Un Virtual Machine Monitor può fruttare OS non modificati
trasformando il codice binario on-the-fly del sistema operativo guest per gestire operazioni di virtualizzazione sensibili. Questa soluzione viene utilizzata per esempio da VMware,
Virtual PC e Virtual Server.
L’obiettivo principale nello sviluppo di nuove architetture di CPU, da parte dei principali produttori di microprocessori, è quello di eliminare la necessità di utilizzare soluzioni
come la paravirtualizzazione e la 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.
Queste nuove architetture aggiungono all’architettura di partenza due nuove modalità
di gestione delle operazioni: VMX root operation e VMX non-root operation. VMX root
operation è un ambiente dedicato per essere utilizzato dal VMM, il suo comportamento è
del tutto simile a quello della precedente architettura. Invece il VMX non-root operation
fornisce un ambiente alternativo controllato dal Virtual Machine Monitor e progettato
per supportare una macchina virtuale. Entrambe le nuove modalità presentano quattro
livelli di privilegio per le istruzioni, consentendo ai programmi ospiti di eseguire le operazioni al livello di privilegio richiesto e fornendo un VMM flessibile all’utilizzo di più
livelli. Questa architettura fornisce due nuove tipologie di transizione: una transizione
da VMX root operation a VMX non-root operation chiamata VMX entry, e una seconda
transizione da VMX non-root operation a VMX root operation definita VMX exit. Queste
due nuove operazioni vengono gestite mediante una nuova struttura di dati chiamata Virtual Machine Control Structure (VMCS). Questa nuova struttura include una guest state
area e una host state area, ognuna delle quali contiene campi corrispondenti a differenti
componenti dello stato del processore. La VMX entry carica lo stato del processore dalla
guest state area. Invece la VMX exit salva lo stato del processore nella guest state area e
quindi carica lo stato del processore dalla host state area. Lo svolgimento delle operazioni
del processore viene sostanzialmente modificato con l’introduzione della VMX non-root
operation. Il cambiamento più importante è da ricercarsi nel fatto che la maggior parte
degli eventi e delle istruzioni determinano la VM exit. Alcune istruzioni causano in modo incondizionato la VM exit e cosı̀ non potrà mai essere eseguita una VMX non-root
operation. Altre istruzioni e tutti gli eventi possono essere configurati per eseguire questa
operazione in modo condizionato utilizzando il VM execution control fields nel VMCS.
24
4.2 Continuità operativa
4.2
4
HARDWARE
Continuità operativa
Come per l’ambito “Piattaforme Elaborative”, anche per la tematica continuità operativa vengono analizzate e confrontate le differenti modalità di gestione della business
continuity, da parte dei vari soggetti interessati dal progetto PTA. Inoltre sono presentate e comparate le differenti soluzioni attuabili, a seconda delle esigenze, delle necessità
e dei criteri di progettazione, per gestire la continuità di erogazione di un servizio in
corrispondenza di un evento dannoso.
4.2.1
Nella sezione “Continuità Operativa” del questionario, presentato alle varie istituzioni e
società coinvolte nel progetto, sono state presentate alcune domande per comprendere
come venga gestita una situazione di emergenza, in modo da poter garantire una continuità dei servizi offerti o comunque una rapida ripresa in modo da minimizzare i danni.
Nella tabella 2 riportata di seguito vengono mostrate nel dettaglio le domande poste alle
varie istituzioni e le relative risposte.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1. Nella vostra organizzazione è stata adottata una politica al fine di garantire la continuità
operativa?
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
2. Se sı̀, a grandi linee, in cosa consiste la politica adottata?
Esiste un centro di Disaster
Recovery
I servizi essenziali sono su
server
ridondanti. Tutti i
server
hanno
una
doppia
linea di alimentazione. Il CED
è
alimentato
con
corrente
proveniente da
due
fornitori
diversi. Il CED
è sotto gruppo
di
continuità
ridondato.
Alimentazione e
politiche di backup.
Alimentatori ridondanti e sale macchine sicure.
N.D.
3. È previsto l’utilizzo di gruppi di continuità (UPS) per i vari sistemi?
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
25
4
HARDWARE
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
4. È previsto l’utilizzo di un qualche sistema per il backup dei dati?
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
5-6. Quale o quali soluzioni di backup vengono utilizzate?
Nastri magnetici LTO, nastri
virtuali e copia
locale.
Nastri magnetici LTO, replica
in linea sincrona
ed asincrona.
Nastri magnetici LTO e backup
remoto.
Backup remoto.
Nastri magnetici LTO e replica in linea sincrona.
7-8. Quale o quali tipologie di connessione tra sistema e dispositivi di memorizzazione sono
previste?
Storage
Area
Network e Network Attached
Storage.
Storage
Area
Network e Network Attached
Storage.
Storage
Network.
Area
Storage
Network.
Area
Storage
Network.
Area
9. La sua organizzazione ha a disposizione un sito secondario per le emergenze?
Sı̀
Sı̀
No
No
N.D.
10-11. Quale o quali sistemi per la gestione delle emergenze vengono utilizzati?
Cluster remoto
e sistemi virtuali.
Cluster remoto
e sistemi virtuali.
Nessuno.
Nessuno.
N.D.
12-13. La sua organizzazione ha seguito una qualche politica per far fronte alla migrazioni
di tali sistemi? In cosa consiste questa politica?
No
No
N.D.
N.D.
N.D.
Tabella 2: Risposte al questionario, sezione continuità
operativa
Tutti i partner del progetto, per garantire la continuità di servizio a seguito di eventi
dannosi, prevedono una politica gestionale al fine di minimizzare i danni e presentano
degli accorgimenti tecnologici inerenti alla continuità operativa. Le soluzioni più 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 continuità nella fornitura dell’alimentazione ai sistemi, oltre all’utilizzo di
gruppi di continuità (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 più comunemente adottata consiste nell’utilizzo dei nastri magnetici LTO. Questa non è l’unica soluzione prevista, in gran parte
dei casi viene affiancata da altre tecnologie come: la replica in linea sincrona ed asincro26
4
HARDWARE
na (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, tutti gli altri partner possiedono un sito secondario per gestire emergenze di
continuità di servizio. All’interno di questo sito vengono adottati cluster remoti e sistemi
virtuali, come soluzioni per la gestione di eventuali emergenze.
4.2.2
Soluzioni attuabili in base agli obiettivi
Nel percorso di sviluppo del piano di Business Continuity & Availability (Continuità
Operativa), ovvero di determinazione dell’affidabilità, è necessario considerare e valutare
il peso che assume ogni applicazione, dispositivo e data center nello svolgimento delle
operazioni. Ad esempio potrebbero esserci applicazioni che possono rimanere ferme anche
per 24 ore senza avere ripercussioni sensibili sulle attività, mentre per altre anche solo
pochi minuti di inattività potrebbero avere ripercussioni molto elevate. Occorre quindi
tenere in considerazione due valori fondamentali:
• il Recovery Time Objective (RTO), ovvero entro quanto tempo devono essere resi
disponibili i dati e per quanto tempo è possibile tollerare l’inattività e di conseguenza
quando l’applicazione potrà tornare operativa;
• il Recovery Point Objective (RPO), parametro che indica quale è la quantità di
dati che possono essere persi, dovendo ripristinare una situazione passata, senza
gravi ripercussioni sulle attività. Ad esempio, se viene fatto il backup una volta alla
settimana (per esempio la domenica) ed il problema della perdita dati si presenta
il venerdı̀, facendo il ripristino verranno persi tutti i dati dal lunedı̀ al venerdı̀.
È importante definire quante informazioni ripristinare e quanto tornare indietro,
temporalmente, per riottenere il sistema di partenza.
Sono presenti sul mercato varie soluzioni tecnologiche e progettuali in grado di proteggere
il sistema e di assecondare le esigenze definite mediante RTO e RPO.
4.2.2.1
Backup su nastro
Il backup e ripristino da nastro è spesso la base di partenza o comunque il complemento
di tutte le successive soluzioni, per questo può essere definita una soluzione “essenziale”.
Solo per le applicazioni con dati che non devono essere mantenuti nel tempo è possibile
non applicare il backup su nastro. Tutte le altre informazioni dovrebbero essere protette
con questa modalità, che consente di salvare il risultato del backup in un luogo differente
Ripristino
Perdita dati
Tempo di inattività
Meno di 24 ore
Meno di 24 ore
Meno di 5,5 ore al mese
27
4
HARDWARE
da dove sono presenti i dati originali ed il loro mantenimento per un lungo periodo.
Per automatizzare i processi di backup e ripristino ed abbattere i costi di gestione sono
disponibili tape library in grado di svolgere il lavoro in parallelo, in base al numero di
drive presenti, e di mantenere un numero considerevole di nastri negli alloggi di cui sono
dotate. Questo permette, grazie ai software di backup, di automatizzare la ricerca del
nastro con l’informazione da recuperare. Processo analogo può essere effettuato anche
nella fase di backup dei dati, in modo automatico anche su più nastri.
Un altro aspetto da considerare è la “sicurezza” delle informazioni. Un nastro di backup
potrebbe essere facilmente sottratto o perso, dovrà essere valutata la possibilità di scrivere
i dati in modo criptato in modo da permettere la rilettura solo a soggetti autorizzati. In
merito a questa problematica, sono disponibili programmi da integrare al software di
backup, oppure esistono nastri in grado di compiere questa operazione.
4.2.2.2
Backup su disco
Quando sono richieste maggiori prestazioni nella fase di recupero dei dati, occorre implementare soluzioni di tipo “critico”. Queste soluzioni prevedono l’utilizzo di tecnologie a
disco ad accesso rapido su cui memorizzare i dati nel caso in cui sia necessario recuperare
tali informazioni. Questa soluzione è economicamente fattibile, grazie alla presenza sul
mercato di dischi ad alta capacità e basso costo. In alcun casi potrebbe risultare più economica del backup su nastro, ad esempio, quando si devono effettuare frequenti backup;
i supporti magnetici dei nastri subiscono un’usura, che richiede un riciclo dei supporti,
da cui i sistemi disco sono immuni.
Esistono differenti soluzioni per la gestione della scrittura dei dati su disco:
1. usare un disk array indipendente su cui eseguire il backup;
2. usare una virtual library, ovvero una soluzione che si presenta come se fosse una
tape library;
3. usare le tecniche di replica locale interna degli array (snapshot, clone).
L’uso di un disk array indipendente consente di svolgere più backup in parallelo, consentendo di eseguire in contemporanea anche azioni di ripristino. Occorrerà prevedere
successivamente la copia verso nastri. Questa modalità viene definita in “due fasi”, la
prima su disco (area di staging), la seconda su nastro. In caso di ripristino, se il dato
risiede ancora su disco l’operazione sarà rapida. Nel caso in cui il dato cercato non sia più
presente nell’area di staging, occorrerà prelevarlo dal nastro. In merito a questa seconda
situazione, esistono programmi di backup in grado di gestire autonomamente questa fase
e di trasferire solo i dati necessari al ripristino. L’utilizzo di disk array indipendenti, su
cui effettuare il backup in due fasi, richiede la ridefinizione delle procedure di backup.
Ripristino
Perdita dati
Meno di 8 ore
Meno di 4 ore
Meno di 3,5 ore al mese
28
4
HARDWARE
In ambienti più complessi può risultare conveniente l’utilizzo di virtual library. Questa
soluzione consiste in un sistema di storage su disco, con il vantaggio di presentarsi ai programmi di backup come una tape library. La virtualizzazione dei dischi, trattati e gestiti
come nastri, permette l’integrazione di questo sistema con i programmi di backup già
esistenti, senza modificare processi e politiche di salvataggio e recupero dei dati. Anche
in questo caso, è necessario considerare il trasferimento delle informazioni su nastri per
l’archiviazione esterna.
Soluzioni come backup su nastro, su disco in due fasi e mediante virtual library prevedono
il blocco delle applicazioni, con conseguente impatto sulle attività. I programmi per la
gestione del backup presentano moduli che consentono di svolgere il backup “on line”,
ovvero senza fermare il servizio. Nel caso in cui la finestra temporale disponibile per il
backup non permetta il blocco del servizio, in alternativa ai programmi di backup “on
line”, è possibile sfruttare la replica locale interna. Questa metodologia consiste nell’effettuare, al momento stabilito, una copia interna dei dati verso un’altra area del disco.
Questo processo permette di bloccare l’erogazione del servizio solo per un breve periodo.
Per svolgere questo processo esistono differenti tecniche, le principali soluzioni sono:
• snapshot senza spostamento dei dati: solo le modifiche vengono registrate nell’istante in cui avvengono, viene richiesto uno spazio riservato preallocato;
• virtual snapshot: tecnica simile a quella snapshot ma senza alcuna richiesta di
preallocazione dello spazio in memoria;
• clone: tutti i dati vengono copiati antecedentemente;
• snapclone: tutti i dati vengono copiati successivamente.
4.2.2.3
Replica in remoto
La configurazione critica può crescere ulteriormente se le necessità di operatività lo richiedono, arrivando a soluzioni di tipo “continuo”. I sistemi e i dati considerati importanti
vengono ridondati in un sito secondario per far sı̀ che, in caso di disastro tale da rendere
inutilizzabili i sistemi informativi del sito primario, sia possibile attivare le attività sul
sito secondario al più presto e con la minima perdita di dati possibile. Questa soluzione
di replica dei dati in remoto è applicabile se, oltre al sito primario, è a disposizione un
secondo sito dislocato in un’altra area geografica. I dati presenti nello storage presso il
primo sito sono replicati nel secondo sito. Da qui i dati sono disponibili per il backup su
un dispositivo appropriato, quale una virtual library o tape library. I dati persi possono
essere ripristinati in poco tempo dalla copia di replica, con un ridotto impatto sulle operazioni in termini di costi.
Esistono differenti tecniche e politiche di gestione per eseguire questa tipologia di replica
Ripristino
Perdita dati
Meno di 1 ora
Fino a 30 minuti
Meno di 45 minuti al mese
29
4
HARDWARE
dei dati: replica sincrona, replica asincrona. La replica sincrona garantisce la specularità
dei dati presenti sui due siti, poiché viene considera terminata la transazione solo se i dati
sono stati scritti sia sulla postazione locale sia su quella remota. Le prestazioni di questa
soluzione sono fortemente influenzate dalla distanza tra i due siti. Questo è dovuto dall’incapacità di gestire l’impatto del ritardo di propagazione sulle prestazioni. L’efficacia
della replica sincrona diminuisce per distanze superiori ai 35 km. La replica asincrona
permette di far fronte ai limiti di distanza imposti dalla replica sincrona. In questo caso
il sito che si occuperà della replica può trovarsi anche a distanze notevoli (superiori ai
100 km).
Se vi sono applicazioni e servizi con esigenze di protezione e disponibilità continua è conveniente sfruttare sistemi cluster. In questo modo se si verifica un problema al sistema
primario, viene automaticamente effettuato il failover su di una piattaforma funzionante per continuare lo svolgimento delle operazioni. Il failover è un sistema di salvataggio
secondo cui le funzioni svolte da un componente vengono trasferite ad un secondo componente quando si verifica un problema sul primo. Se si dispone di una configurazione di
questo tipo, è importante che l’applicazione di backup associata sia in grado di operare
su differenti sistemi fisici per garantire che venga sempre effettuata la replica di tutti i
dati. Inoltre, il sistema di storage deve essere in grado di effettuare il failover assieme al
servizio/applicazione.
4.2.3
Infrastrutture di rete per i sistemi di storage
Al fine di garantire una buona protezione e disponibilità dei dati e servizi, non è sufficiente
prendere in esame soltanto i sistemi di memorizzazione, ma è anche necessario volgere
l’attenzione verso le differenti tipologie di collegamento tra piattaforme server e ambienti
di storage. Di seguito vengono presentate le principali soluzioni, che a seconda della
tipologia di realtà considerata, risultano più idonee da implementare.
4.2.3.1
Direct Attached Storage
Con Direct Attached Storage (DAS) ci si riferisce ad un sistema digitale di memorizzazione direttamente connesso ad apparati di elaborazione, come server o workstation,
senza l’utilizzo di una infrastruttura di rete per la comunicazione. La connessione diretta tra questi sistemi di storage e i vari apparati di elaborazione si basa principalmente
mediante protocolli ATA, SATA, eSATA, SCSI, SAS e Fibre Channel, mentre l’interfacciamento avviene tramite Host Bus Adapter (HBA). Un tipico sistema DAS è costituito,
al fine di garantire una buona tolleranza ai guasti, da dischi RAID (Redundant Array of
Independent Disks) e da controller per il raffreddamento e l’alimentazione ridondanti.
4.2.3.2
Storage Area Network
Storage Area Network (SAN) consiste in una infrastruttura di comunicazione ad alta velocità, definita dalla Storage Network Industry Association (SNIA), il cui scopo principale è
quello di gestire il trasferimento sicuro e robusto di dati tra le piattaforme elaborative e i
sistemi di archiviazione. Una SAN permette una connessione tipo “any-to-any” attraver30
4
HARDWARE
so la rete sfruttando vari dispositivi come router, hub, switch, gateway e director. Questa
tipologia di rete permette di eliminare le connessioni dirette tra i sistemi di storage e gli
elementi di elaborazione. Inoltre, elimina ogni restrizione associata al numero massimo di
dati a cui un singolo server può accedere ed allo stesso tempo limita il numero di dispositivi di memorizzazione connessi ad un singolo server. Una SAN può essere vista come
un’estensione del concetto bus di storage, permettendo ai dispositivi di memorizzazione
e ai sistemi di calcolo di essere connessi utilizzando i medesimi elementi alla base delle
reti LAN e WAN, consentendo collegamenti anche a grandi distanze geografiche.
Una rete SAN consente di superare i vincoli e i “colli di bottiglia” delle reti tradizionali,
facilitando le comunicazioni ad alta velocità nelle seguenti tre modalità:
• server-storage: i dispositivi di memorizzazione possono essere indirizzati dai server
in serie o simultaneamente.
• server-server: questa tipologia di rete può essere usata per comunicazioni ad alta
velocità ed alta capacità tra sistemi server.
• storage-storage: permette il trasferimento di dati tra dispositivi di memorizzazione senza l’intervento di sistemi server, consentendo a tali sistemi di svolgere altre
operazioni.
In questa tipologia di rete i principali protocolli utilizzati per gestire le comunicazioni a livello fisico, datalink e di rete sono: interfaccia Ethernet, Small Computer System
Interface (SCSI) e Fibre Channel (FC). L’interfaccia Ethernet è la soluzione più comunemente utilizzata per realizzare connessioni tra sistemi server e workstation. Mediante
questa tipologia di connessione può essere raggiunta una velocità massima di comunicazione pari a 10 Gbps. Small Computer System Interface consiste in un bus parallelo, di
lunghezza massima pari a 25 metri, con terminazione a cui possono essere collegati fino a
16 dispositivi. La velocità massima di trasferimento risulta pari a 640 MBps, secondo la
soluzione Ultra-640 SCSI. Il sistema Fibre Channel è un’interfaccia seriale implementata
sia con cavi a fibra ottica sia mediante cavi di rame UTP. Questa è la principale soluzione
adottata nelle maggiori reti SAN. Una delle ragioni per cui questa interfaccia è diventata
popolare è perchè consente di superare la limitazione della lunghezza del cavo a 25 metri
nel sistema SCSI.
Considerando i livelli di trasporto e sessione i protocolli maggiormente sfruttati sono:
Fibre Channel Protocol (FCP), iSCSI (Internet SCSI), FCIP (Fibre Channel over IP ),
iFPC (Internet Fibre Channel Protocol ) e FICON. Il Fibre Channel Protocol è il protocollo di interfaccia del SCSI su Fibre Channel. Venne inizialmente pensato per gestire i
collegamenti nei super computer, per poi diventare la tipologia standard di connessione
nelle reti SAN. Il iSCSI è un protocollo che permette di inviare comandi SCSI su di una
rete TCP/IP. È un protocollo utilizzato in ambiente SAN perchè consente l’archiviazione
dei dati su dispositivi virtuali, collegati attraverso la rete, dando l’illusione di disporre
localmente di un disco fisico che invece si trova in realtà su un dispositivo di storage
remoto. Fibre Channel over IP, conosciuto anche come Fibre Channel tunneling o storage tunneling, è un metodo che consente di inviare pacchetti (tunneled ) su di una rete
31
4
HARDWARE
TCP/IP. Questo sistema consente l’incapsulamento e la trasmissione dei blocchi di dati
Fibre Channel su socket TCP/IP, rendendo cosı̀ possibile l’utilizzo dell’infrastruttura di
rete esistente e consentendo di inviare tali informazioni anche a distanze maggiori. iFCP è
un meccanismo per trasmettere informazioni provenienti e dirette a dispositivi di memorizzazione Fibre Channel in una rete SAN o in una rete Internet sfruttando il protocollo
TCP/IP. Il Internet Fibre Channel Protocol non consiste in un semplice incapsulamento
dei blocchi di dati FC, ma è un protocollo gateway-to-gateway. I gateway vengono inseriti,
come livello intermedio, all’interno della rete tra dispositivi initiator e dispositivi target
di una rete FC. Come i gateway posso sia sostituire sia essere utilizzati in serie ad una
struttura FC, il protocollo iFCP potrebbe essere utilizzato come supporto per migrare da
una rete SAN basata su Fibre Channel a una su IP, oppure per ottenere una combinazione delle due soluzioni. FISCON è un protocollo basato su Fibre Channel come supporto
fisico. I canali FISCON consentono di gestire comunicazioni ad una velocità massima di
200 MBps in modalità full duplex ed ad una distanza massima di 100 km.
4.2.3.3
Network Attached Storage
Con Network Attached Storage (NAS) ci si riferisce generalmente a sistemi di archiviazione
connessi ad una rete che forniscono, a vari sistemi di elaborazione, un servizio di accesso
a file. Un elemento di storage di tipo NAS è costituito da un sistema che implementa un
file service, utilizzando protocolli di accesso come NFS (Network File System) o CIFS
(Common Internet File System), ed uno o più dispositivi sui quali vengono memorizzati
i dati. Questi sistemi possono essere collegati a qualsiasi tipologia di rete.
Un Network File System è un protocollo, più correttamente un file system, inizialmente
sviluppato dalla Sun Microsystems per consentire agli utenti di un computer client di
poter accedere a dispositivi di archiviazione remoti attraverso la rete come se fossero
dischi locali. Mediante questo sistema i calcolatori che compongono un sistema distribuito
possono condividere file, cartelle o interi file system utilizzando un protocollo client-server.
Mentre il CIFS è un protocollo di rete che consente di condividere file, stampanti e porte
seriali tra vari elementi all’interno della rete. Il Common Internet File System include
anche un meccanismo di comunicazione autenticata tra processi.
Un dispositivo NAS consente di aggiungere spazio di memoria ad una rete che già presenta
sistemi server senza che sia necessario bloccare il loro funzionamento per processi di
aggiornamento o manutenzione. Mediante l’utilizzo di NAS, la memorizzazione non è
parte integrante dei server. In un sistema storage-centric, i server gestiscono ancora tutti
i processi sui dati, mentre i dispositivi NAS forniscono i dati all’utente. Un sistema
NAS non ha bisogno di essere collocato all’interno di un server, può essere posizionato
in un qualsiasi punto della rete, per esempio rete LAN, e può essere costituito da più
elementi collegati. Queste unità comunicano con un host generalmente mediante protocolli
file-based od Ethernet.
32
4.3 Sistemi Embedded
4.3
4
HARDWARE
Sistemi Embedded
Un sistema embedded consiste in un apparato di elaborazione progettato per svolgere
determinate e/o specifiche funzioni, contrariamente a sistemi generici (general purpose),
come per esempio i computer commerciali, molto versatili e flessibili che quindi vanno
incontro alle necessità dell’utente finale. Questo permette di ottenere apparecchiature dalle dimensioni ridotte e dai costi contenuti, aspetti che comunque dipendono fortemente
anche dall’evoluzione delle tecnologie in campo ICT. I compiti, generalmente definiti in
fase di progettazione e sviluppo, che dovrà svolgere un dato sistema embedded sono il più
delle volte elaborazioni in tempo reale real time delle informazioni ricevute dal mondo
esterno.
Questa tipologia si apparati, al giorno d’oggi, risulta estremamente diffusa sotto le più
svariate forme e in molti campi di applicazione. I sistemi embedded risultano principalmente utilizzati per realizzare: apparati per le telecomunicazioni come telefoni, router,
ricevitori GPS e sistemi di identificazione a radio frequenza; dispositivi elettronici commerciali come riproduttori MP3, fotocamere e videocamere; sistemi per l’automazione
come controllo di motore, Anti-lock Braking System (ABS), Electronic Stability Control
(ESC/ESP) e Traction Control (TCS); apparecchiature biomedicali come termometri e
stetoscopi digitali, ecografi e scanner per risonanza magnetica.
A seconda della specifica applicazione, un sistema di tipo embedded è generalmente
costituito da:
• un elemento di calcolo ed elaborazione, generalmente basato su micro-controllore o
DSP. La tipologia di unità elaborativa varia a seconda del campo di applicazione
e dalla complessità delle operazioni che deve svolgere il sistema. Infatti in casi
particolari possono essere utilizzati sistemi a multi processore o circuiti creati ad
hoc mediante ASIC o FPGA;
• elementi di archiviazione. I dispositivi che vengono principalmente utilizzati per
memorizzare dati sono memorie FLASH PROM fisse o removibili (SD Card). Mentre
vengono raramente implementati hard disk ;
• periferiche di comunicazione. Anche in questo caso, la tipologia di sistema per la
comunicazione delle informazioni dipende dal campo di applicazione e dallo standard utilizzato. Per le comunicazioni wired vengono principalmente utilizzate interfaccie seriali (RS 232, I2C e USB), interfacce di rete (Ethernet - IEEE 802.3)
e principalmente per applicazioni automotive il CAN-Bus. Nel caso si considerino
comunicazioni wireless vengono utilizzati transceiver operanti principalmente nelle
bande di frequenze nell’intorno di 2,4 GHz, 915 MHz, 868 MHz e 433 MHz. Queste sono le frequenze utilizzate dai principali e maggiormente diffusi standard di
comunicazione wireless;
• periferiche di acquisizione. In questa categoria rientrano tutte le tipologie di sistemi, di vario genere, che permettano di acquisire informazioni provenienti dal mondo
esterno. In questo ampio insieme si estende dai componenti più semplici come semplici tasti o bottoni, ai più moderni MEMS quali accelerometri e giroscopi, passando
33
4
HARDWARE
per i classici sensori di temperatura, pressione e luminosità. Spesso vengono inseriti, tra queste periferiche e l’unità di elaborazione, dei convertitori analogico-digitali
(ADC) per convertire i dati da un dominio continuo ad un dominio discreto;
• periferiche per il controllo di attuatori. Questa tipologia di elementi sono principalmente presenti in sistemi operanti nel campo dell’automazione, come le schede
elettroniche atte a pilotare e controllare motori. In questa categoria di periferiche
rientrano per esempio i modulatori PWM (Pulse Width Modulation) e i convertitori
digitali-analogici (DAC);
• periferiche di visualizzazione. In molti sistemi embedded, principalmente quelli più
semplici ed economici, sono presenti alcuni diodi LED per visualizzare lo stato del
sistema. Mentre in sistemi più evoluti si possono trovare anche display.
Proprio per l’elevato numero di ambiti in cui è possibile trovare implementato un sistema embedded, si è preferito orientare questa analisi verso sistemi per il controllo di flussi
di mobilità, campo che tocca in modo diretto alcuni aspetti di questo progetto. Questo
studio ha lo scopo di mostrare quali sono, in questo campo di applicazione, i principali
apparati attualmente in uso e mostrare verso quale direzione si muove l’evoluzione tecnologica.
Il primo dispositivo che viene in mente quando si parla di sistemi per il controllo della
mobilità è quello comunemente chiamato navigatore satellitare. Questa tipologia di sistemi, mediante l’interazione ed integrazione di un segnale ricevuto da opportuni satelliti e
stazioni terra con una banca dati stradale memorizzata al suo interno, assiste generalmente il conducente di un veicolo indicando, in modo interattivo, il percorso da seguire
per raggiungere la destinazione impostata dall’utente. Di questa categoria di dispositivi
ne esistono differenti tipologie. Una modalità di classificazione si basa sulla costellazione
satellitare di riferimento. Infatti attualmente esistono tre differenti sistemi satellitari per
la determinazione della posizione: GPS (Global Positioning System), GLONASS (GLObal NAvigation Satellite System) e Galileo. Il GPS e il GLONASS sono rispettivamente il
sistema di posizionamento statunitense e russo ed entrambi nati per scopi militari e solo
successivamente estesi anche al mondo civile ma con notevoli restrizioni in risoluzione.
Mentre il sistema Galileo, ancora in fase di completamento e principalmente rivolto ai
settori civili e commerciali, è un progetto nato dalla collaborazione tra l’Unione Europea
e l’Agenzia Spaziale Europea (ESA) a cui, solo di recente, si sono aggiunti stati quali Cina
ed Israele. Inoltre, a seconda della tipologia di soluzione, questi sistemi possono essere
suddivisi in:
• integrati
rientrano in questa categoria i dispositivi dedicati, generalmente integrati all’interno
di veicoli oppure esterni, che presentano un ricevitore satellitare per ricevere le
informazioni temporali dai satelliti, un ricevitore radio per la ricezione dei dati dalle
stazioni terrestri, un display LCD con tecnologia touch screen per la visualizzazione
del percorso e consentire all’utente di interagire con il sistema, un processore per
l’elaborazione delle informazioni, una memoria integrata od esterna al fine di salvare
34
4
HARDWARE
le informazioni cartografiche ed un altoparlante per trasmettere informazioni verbali
sul percorso effettuato;
• ibridi
generalmente dispositivi portatili ad uso generico (palmari e telefoni cellulari) che
vengono trasformati in navigatori satellitari mediante l’utilizzo di periferiche esterne
oppure integrate al loro interno ed opportuni programmi di gestione.
Questi apparecchi offrono molte funzioni utili e semplificano la vita agli utenti della strada. Tuttavia, secondo la legislazione svizzera, alcune delle funzioni supplementari posso
risultare problematiche. Alcune tipologie di navigatori satellitari consento di segnalare
all’autista la presenza di postazioni fisse o mobili per la misurazione della velocità, semafori dotati di fotocamere e qualsiasi altra postazione di controllo delle forze dell’ordine.
Quindi secondo l’Art. 57b della Legge federale sulla circolazione stradale [HW6] è proibito l’utilizzo di Warn-Points of interest/Warn-POI relativi a postazioni di controllo della
circolazione. Diversamente, questo divieto non è previsto dalla legislazione italiana.
Altra tipologia di sistemi embedded molto diffusi all’interno dei veicoli sono quelli dedicati
al pagamento automatico del pedaggio autostradale. Questa categoria di apparecchiature
è generalmente composta da un sottosistema di terra (Road Side Equipment) e da un
apparato di bordo (On Board Unit). In Italia questa soluzione, prevista per tutte le categorie di autoveicoli circolanti su strada, è chiamata Telepass. L’unita di bordo è costituita
da un transponder semi-passivo appartenente alla categoria dei Dedicated Short Range
Communication (DSRC) ed operante nella banda di frequenze dei 5,8 GHz secondo la
standard europeo ETSI ES 200 674-1 [HW7]. Questo dispositivo, una volta interpellato
dal trasmettitore di terra, trasmette un codice univoco generalmente associato al codice
IBAN di un conto corrente bancario. La stazione di terra oltre ad essere equipaggiata di
un transceiver, per comunicare con l’apparato all’interno dei veicolo, presenta un impianto ottico (CTV), per identificare la presenza e la tipologia di veicolo, ed una fotocamera,
con lo scopo di memorizzare la targa del mezzo nel caso in cui non vi sia stata una comunicazione tra le due parti del sistema. In Svizzera esiste un sistema, a grandi linee simile
alla soluzione italiana, per la determinazione dell’ammontare della tassa di pedaggio sulle
autostrade valido solo per i veicoli destinati al trasporto merci di peso compreso tra 3.5 e
40 tonnellate. Questa tassa è commisurata al peso del veicolo, alla classe EURO di appartenenza e ai chilometri percorsi. Per determinare questa ultima variabile, su tutti i mezzi
interessati è presente l’apparato di rilevazione Emotach. Questo dispositivo è collegato
al tachigrafo del veicolo per registrare automaticamente i chilometri percorsi sul territorio svizzero. Inoltre viene completato con un sistema di posizionamento satellitare ed
un sensore di movimento. Queste due periferiche aggiuntive vengono inserite per evitare
problemi di manomissione del tachigrafo od interruzione del collegamento con il sistema
di rilevamento. All’interno del Emotach è presente anche un transponder, operante nella
banda di frequenze dei 5.8 GHz, per comunicare con le stazioni di terra in modo da poter
abilitare o disabilitare l’apparato di rilevazione in corrispondenza dell’attraversamento
del confine svizzero.
Dal 2001, con la pubblicazione del Libro Bianco della Commissione sulla politica europea
35
4
HARDWARE
dei trasporti, hanno avuto inizio alcune iniziative in merito alla sicurezza stradale e alla
realizzazione di veicoli intelligenti. Tra le varie attività previste, alcune già 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 più 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’unità 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 può 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/TS12813 [HW2], che consente
di controllare numerosi attributi presenti e passati dell’apparecchiatura di bordo
nonché 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 può 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 ) è un servizio
36
4
HARDWARE
di radiodiffusione che trasmette agli automobilisti informazioni sulle condizioni del
traffico. Le unità installate sui veicoli possono fornire tali informazioni mediante
messaggi vocali o visivi, con la possibilità 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 località a cui fa riferimento, la
direzione, l’entità dell’evento, la durata stimata ed eventuali consigli su percorsi
alternativi. Ad ogni evento è 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.
37
5
5
TELECOMUNICAZIONI
Telecomunicazioni
In questa sezione del report, basandosi sulle risposte delle regioni alle domande del questionario, vengono discussi differenti aspetti inerenti i sistemi per le telecumunicazioni.
Inoltre sono presentate e confrontate alcune soluzioni per la gestione dei flussi di mobilità. Questo confronto viene effettuato sulla base di quanto indicato dalla legislazione
italiana e svizzera in merito ad alcuni parametri per i sistemi di telecomunicazioni, come
per esempio: bande assegnate e limiti in potenza.
5.1
Per quanto riguarda aspetti inerenti i sistemi per le telecomunicazioni, l’analisi fatta
mediante il questionario aveva come obiettivo lo studio della capacità di comunicazione,
intesa come larghezza 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.
Nella tabella 3, riportata in seguito, vengono presentate le varie domande poste per
svolgere questa indagine e le risposte di ogni partner interpellato.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1-2. Nella vostra organizzazione è prevista una qualche forma di gestione ed identificazione
per l’accesso alla rete? In caso di risposta affermativa, indicare la tipologia di gestione degli
accessi.
Sı̀,
mediante
identificazione
al dominio.
Sı̀, il controllo
è in essere solo
per le connessioni
WiFi,
come da normativa vigente.
L’identificazione
avviene
mediante login
e
password,
eventualmente
temporanei per
le utenze guest.
Sı̀, mediante inserimento nome
utente e password.
No
Sı̀
38
5.1 Analisi risultati questionari
5
TELECOMUNICAZIONI
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
3-4. É prevista una qualche forma di crittografia per la protezione delle trasmissioni dati?
In caso di risposta affermativa, che tipo di cifratura viene utilizzata?
No
Sı̀, le connessioni WiFi che
potenzialmente
trasportano
dati non pubblici (a partire
dalle password )
sono
cifrate
WPA2,TKIP e
PEAP.
No
No
Sı̀
5-6. La vostra organizzazione è in possesso di un qualche apparato che, se utilizzato in
uno stato confinante, potrebbe violare le norme di legge? In caso di risposta affermativa,
in quale/i parametri viola le norme di legge o potrebbe avere problemi di funzionamento
generici?
No
Non so.
Non so.
No
N.D.
7. Quant’è la capacità della banda della vostra organizzazione verso internet?
20 Gbps
1 Gbps
80 Mbps
N.D.
N.D.
8. Quali sono le capacità di banda dei collegamenti nel vostro Centro di Elaborazione Dati?
10 Gbps
100 Mbps
Varia in funzione delle specifiche esigenze.
N.D.
N.D.
9. Quali tipologie di collegamenti sono previsti tra i server e gli switch?
Fibra ottica e
UTP.
UTP
UTP
N.D.
N.D.
10. Sono utilizzati bilanciatori di carico? In caso sia previsto l’utilizzo di bilanciatori di
carico, indicarne la marca e il modello.
Sı̀, prodotti dalla Cisco.
Sı̀,
RadWare
WSD.
Sı̀, Cisco ACE.
N.D.
N.D.
Tabella 3: Risposte al questionario, sezione telecomunicazioni
In quasi tutti i casi analizzati, tranne per la provincia autonoma di Bolzano, è 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
39
5.2 Soluzioni per il controllo dei flussi di mobilità
5
TELECOMUNICAZIONI
modalità di protezione delle trasmissioni mediante algoritmo di crittografia. Questa protezione è 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 è molto variegata. Infatti, in base ai
dati ricevuti, questa “capacità 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 realtà.
A livello di architettura di rete, tutti i partner sfruttano bilanciatori di carico, al fine di
ottenere una migliore scalabilità e affidabilità nella fornitura di un servizio, e collegamenti
UTP (Unshielded Twisted Pair ) come principale supporto per i collegamenti tra i server
e gli switch.
5.2
Soluzioni per il controllo dei flussi di mobilità
Su richiesta dei soggetti coinvolti nell’Azione 6 “Sistema di precisione open source per
il rilevamento di flussi di mobilità” del progetto Interreg PTA, è stato effettuato un
confronto tra le varie soluzioni e tecnologie applicabili per il controllo dei flussi di mobilità.
Questo confronto ha lo scopo di evidenziare eventuali punti in comune ed identificare
discrepanze tra quanto prevede la legislazione dei due paesi a riguardo di tali tecnologie. In
questa analisi è stata data particolare rilevanza ad aspetti inerenti le telecomunicazioni; in
particolare, per ogni soluzione considerata, sono stati presi in esame parametri come, per
esempio, la potenza di trasmissione, la modulazione e le regole di accesso ed occupazione
dello spettro radio.
5.2.1
Dispositivi a Corto Raggio per applicazioni non specifiche
Con il termine generico Dispositivi a Corto Raggio (SRD) si identifica un’ampia gamma di
apparecchiature come, per esempio, strumenti di telemetria, telecomandi, allarmi e sistemi
di comunicazione locale. Vengono inoltre considerati i trasmettitori radio che forniscono
comunicazioni mono-direzionali o bi-direzionali, essi posso possedere sia antenne integrate
dedicate, sia antenne esterne e sfruttare tutte le modulazioni di segnale indicate negli
standard di riferimento.
5.2.1.1
Banda 2400 - 2483,5 MHz
In questo intervallo di frequenze non si trovano differenze significative tra quanto riportato
nella legislazione italiana e in quella svizzera. Questo è dovuto al fatto che le norme dei
due paesi si basano su quanto indicato nell’Allegato 1 della Raccomandazione ERC 70-03
“Relating to the use of Short Range Device (SRD)”. In particolare viene imposto solo
40
5
TELECOMUNICAZIONI
un vincolo a riguardo della potenza massima di trasmissione, tale parametro non deve
essere superiore a 10 mW e.i.r.p. (Equivalent Isotropic Radiated Power ). Mentre non
viene indicato alcun tipo di restrizione per l’accesso allo spettro, requisiti di mitigazione
e spaziatura dei canali.
5.2.1.2
Banda 868 - 868,6 MHz
La legislazione italiana e svizzera, per definire i parametri caratteristici dei sistemi di
comunicazioni in questa banda, prende spunto dal ERC/REC 70-03 “Relating to the use
of Short Range Device (SRD)” Allegato 1. Di conseguenza non si riscontrano differenze
sostanziali. Per questo particolare intervallo di frequenze, in riferimento ai dispositivi a
corto raggio, viene indicato che:
• la potenza di trasmissione massima deve essere inferiore a 25 mW e.r.p. (Effective
Radiated Power );
• per l’accesso allo spettro radio devono essere utilizzate le tecniche LBT (Listen
Before Talk ) e AFA (Adaptive Frequency Agility), oppure deve essere impostato un
duty cycle di funzionamento non superiore al 1%;
• a riguardo della spaziatura dei canali non vi sono restrizioni, tutta la banda disponibile può essere utilizzata come un’unico canale.
5.2.1.3
Banda 433,05 - 434,79 MHz
Anche in questo terzo caso non si evidenziano particolari differenze tra quanto viene indicato dalle legislazione italiana e quella svizzera. Le norme in vigore di entrambi i paesi
fanno riferimento al medesimo documento ERC/REC 70-03 Allegato 1. Per questa particolare sotto-banda, nel documento di riferimento, si trovano due differenti indicazioni.
Nel primo caso viene richiesto che la potenza massima di trasmissione non debba eccedere
10 mW e.r.p. e che il duty cycle di funzionamento sia limitato al 10%. Nel secondo caso,
la potenza massima deve essere inferiore a 1 mW e.r.p. e la densità spettrale di potenza
non può superare i -13 dBm/10 kHz. La densità spettrale di potenza viene limitata nel
caso di modulazioni a larga banda con larghezza di banda superiore a 250 kHz. Oltre a
queste due specifiche sono definiti dei vincoli anche per un particolare intervallo di questa
banda. Nell’intervallo di frequenze compreso tra 434,0 MHz e 434,79 MHz, si impone che
la potenza massima di trasmissione risulti non superiore a 10 mW e.r.p. e una spaziatura
dei canali fino a 25 kHz.
5.2.2
5.2.2.1
Sistemi di identificazione a radio frequenza (RFID)
Banda 2446 - 2454 MHz
In questo intervallo di frequenza si evidenziano differenze sostanziali nei parametri fondamentali, per questa tipologia di sistemi di comunicazione, riportati nella legislazione
in vigore nei due paesi. Queste differenze sono da ricercarsi nel fatto che la normativa
41
5
TELECOMUNICAZIONI
svizzera e quella italiana fanno riferimento a due documenti differenti. Il Piano di Allocazione Nazionale delle Frequenze Svizzero, in questo caso specifico, fa riferimento alla
Raccomandazione ERC 70-03 Allegato 11. In questo documento viene indicato che la
potenza massima per le trasmissioni non deve superare i 500 mW e.i.r.p. Nel caso si considerino applicazioni indoor la potenza di trasmissione deve essere compresa tra 500 mW
e 4 W e.i.r.p. Per potenze superiori ai 500 mW deve essere utilizzata una modulazione a
spettro espanso a salto di frequenza (FHSS) con un duty cycle massimo del 15%. Invece la legislazione italiana in materia si basa sulla Decisione della Commissione Europea
2010/368/CE. All’interno di questa decisione viene indicato che la potenza massima di
trasmissione non essere superiore a 100 mW e.i.r.p.
5.2.2.2
Banda 865 - 868 MHz
In questo intervallo di frequenze 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. Questa raccomandazione suddivide questo intervallo in tre sotto bande:
• 865 - 865,6 MHz
In questo primo intervallo la potenza massima per le comunicazioni non deve
eccedere i 100 mW e.r.p. Inoltre sono presenti tre canali numerati da 1 a 3;
• 865,6 - 867,6 MHz
La potenza massima di trasmissione deve essere impostata pari a 2 W e.r.p. In
questa seconda sotto banda sono disponibili dieci canali (dal numero 4 al numero
13);
• 867,6 - 868 MHz
All’interno di questo terzo insieme di frequenze vi sono due canali (canale 14 e
canale 15) e la potenza massima deve essere inferiore a 500 mW e.r.p.
Ogni canale appartenente ad una delle tre sotto bande è ampio 200 kHz. Per queste sotto bande la frequenza centrale di ogni canale risulta: 864, 9M Hz + (0, 2M Hz ×
numerodelcanale). Inoltre non devono essere utilizzate modulazioni a spettro espanso o
altre tecniche a salto di frequenza.
5.2.3
Sistemi di trasporto intelligenti (STI)
Nella categoria di Sistemi di Trasporto Intelligenti (STI) vengo incluse 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. Risultano fondamentali in un approccio integrato alla sicurezza stradale. Questa
categoria comprende 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.
42
5.2.3.1
5
TELECOMUNICAZIONI
Banda 5855 - 5905 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 302 571. Secondo questo standard la potenza massima di trasmissione e la
densità spettrale di potenza non devono superare rispettivamente 33 dBm e.i.r.p. e 23
dBm/MHz e.i.r.p. Questo secondo vincolo è da applicare solo per canali con una larghezza
di banda superiore a 10 MHz. Inoltre viene indicato che per l’accesso ai canali ed allo
spettro devono essere sfruttate le tecniche LBT (Listen Before Talk ) e TPC (Transmit
Power Control ).
Questa banda viene suddivisa in tre intervalli:
• 5855 - 5875 MHz
All’interno di questa sotto-banda vengono identificati due canali: il canale 1 e 3 con
larghezza di banda di 10 MHz e rispettivamente frequenza portante 5860 MHz e
5870 MHz. Questi due canali possono essere visti come un’unico canale (canale 2)
con larghezza di banda di 20 MHz e frequenza portante 5865 MHz.
• 5875 - 5905 MHz
In questo secondo intervallo di frequenze sono presenti tre canali: il canale 4 con
larghezza di banda di 10 MHz e frequenza portante 5880 MHz, il canale 5 con
larghezza di banda di 10 MHz e frequenza portante 5890 MHz ed infine il canale 6
con larghezza di banda di 10 MHz e frequenza portante 5900 MHz. I canali 4, 5 e
6 possono essere utilizzati come solo canale (canale 10) avente larghezza di banda
di 30 MHz e frequenza portante 5890 MHz.
• 5905 - 5925 MHz
La terza sotto-banda presenta due canali: il canale 7 avente larghezza di banda di
10 MHz e frequenza portante 5910 MHz e il canale 9 con una larghezza di banda di
10 MHz e frequenza portante 5920 MHz. Anche in questo caso, i due canali possono
essere utilizzati come un’unico canale (canale 8) che possiede una larghezza di banda
di 20 MHz e frequenza centrale 5915 MHz.
43
6
6
SOFTWARE E DATI
Software e dati
Il software e i dati che devono essere acquisiti, manipolati e memorizzati per poi fornire
le informazioni e i servizi desiderati sono indubbiamente una parte fondamentale di un
sistema informativo. I rischi di incompatibilità 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 eterogeneità di
soluzioni bisogna anche considerare il fatto che molti software proprietari utilizzano anche
formati proprietari dei dati e ciò può limitare notevolmente l’interoperabilità e rendere
particolarmente onerosa la migrazione a una diversa soluzione software. La politica da
perseguire dovrebbe quindi essere quella di affidarsi a software che utilizza formati di dati
aperti, possibilmente standard e quindi più possibile interoperabili.
Si noti che, per quanto riguarda la piattaforma tecnologica da realizzare per il progetto
PTA, il problema della compatibilità software risulta essere sicuramente arginato da alcune scelte implementative effettuate. Una di queste prevede che a ogni partner sia lasciata
la responsabilità di gestire i propri dati geografici, fornendone l’accesso attraverso opportuni servizi standard, invece di creare un unico sistema integrato; ciò elimina la necessità
di uniformare ogni aspetto relativo al software per la memorizzazione e il trattamento di
tali dati, nonché al formato dei dati stessi. Si è inoltre scelto di realizzare i servizi richiesti
facendo uso di una piattaforma virtualizzata comune, basata sull’architettura hardware
x86 a 64 bit e sull’ambiene di virtualizzazione Proxmox [SW17].
In questa sezione del documento, dopo aver presentato e analizzato i risultati della
parte di questionario utilizzata per raccogliere informazioni sulle scelte in campo software compiute dai partner del progetto, vengono confrontati il software proprietario e
quello libero e si discute di software e dati GIS, argomento particolarmente rilevante per
il progetto PTA. L’ultima sottosezione contiene una panoramica e alcune considerazioni riguardanti i sistemi operativi real-time, in particolare per l’ambito wireless sensor
network/sistemi embedded che è interessante per l’azione 6 del progetto.
6.1
Le risposte dei partner alla parte di questionario relativa al software sono riportate in
tabella 4. La parte relativa ai dati invece, concentrandosi soprattutto su questioni di
accesso, condivisione e sicurezza, è presentata nella sezione 7, che riguarda la sicurezza
nel campo ICT.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1. Nella vostra organizzazione è presente una strategia per l’acquisizione del software?
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
44
6
SOFTWARE E DATI
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
2. Se sı̀, in cosa consiste, a grandi linee, questa strategia? Fa riferimento a qualche normativa
o regolamento interno?
Progettazione
ed effettuazione
di gare in caso
di
fornitori
multipli.
Acquisto diretto o gara secondo la normativa vigente.
Non si fa distizione tra soluzioni proprietarie ed open
source.
Standard de facto con obiettivo
di ottimizzazione delle risorse
utilizzate.
Standards adottati all’interno
dell’organizzazione.
N.D.
3-4. Per quanto riguarda i sistemi operativi (in generale) quali soluzioni utilizzate
maggiormente?
Desktop: Windows Vista e 7.
Server:
Linux
REDHAT.
Desktop:
Win2000.
Server: Windows 2003 Server,
RHEL4/5,
Solaris 8/9/10.
Principalmente
Microsoft.
Desktop: Windows XP SP3.
Server: Windows 2003 R2 /
Windows 2008
R2.
Sia proprietarie
sia open source.
5-6. Per quanto riguarda i sistemi operativi (per sistemi WebGIS) quali soluzioni utilizzate
maggiormente?
Windows Server
2003 e Linux
REDHAT.
RHEL5.
dows
Server.
Win2003
Windows Server
2003.
Desktop: Windows XP SP3.
Server: Windows 2003 R2 /
Windows 2008
R2.
N.D.
7-8. Per quanto riguarda il software di produttività individuale quali soluzioni utilizzate
maggiormente?
Microsoft Office
2007.
70% proprietario 30% open
source.
Microsoft Office
e Lotus Notes.
Microsoft Office
XP e OpenOffice 2.x
Proprietarie.
45
6
SOFTWARE E DATI
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
9-10. Per quanto riguarda il software di gestione dei dati (es. basi di dati) quali soluzioni
utilizzate maggiormente?
Oracle 10 e prodotti ESRI per i
dati territoriali.
La risposta al
quesito 4.9 varia in funzione
del parametro
utilizzato
per
la valutazione
(importanza
dei dati gestiti,
numero di database, numero
di server, ...),
ma
propende
comunque verso
Oracle, versioni
da 7.3 a 12.
OO.SS. MySQL
5 e postGIS.
Oracle 60% SQL server 30%
- MySQL 10%.
Oracle
9i/10g/11g.
N.D.
11-12. Per quanto riguarda il software di elaborazione e gestione dei dati geografici quali
soluzioni utilizzate maggiormente?
Prodotti ESRI
PostGIS
ESRI ArcGIS
ESRI ArcGIS
e OpenSource
GIS
N.D.
13-14. Per quanto riguarda il middleware, quali soluzioni utilizzate maggiormente?
IIS, ESRI ArcGIS, Tomcat,
Apache
BEA, JBoss
ESRI ArcGIS
ESRI SDE, Java
EE
N.D.
VMWare
VMWare,
HyperV
15. Quali piattaforme di virtualizzazione utilizzate?
VMWare
VMWare, Xen
VMWare
46
6
SOFTWARE E DATI
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
16-17. Esistono servizi GIS/WebGIS già ospitati su piattaforme di virtualizzazione?
Componenti relative alla piattaforma ArcGis
Server 9.3.1
WMS
SITAD (Sistema
Informativo
Territoriale
Ambientale
Diffuso)
Tutti i servizi
erogati
dal
Sistema
delle
Conoscenze
Territoriali
(SCT)
che
raccoglie,
organizza
e
rappresenta,
in
un’unica
struttura logica e fisica, le
informazioni
di
carattere
territoriale, ambientale e socioeconomico.
No
N.D.
Tabella 4: Risposte al questionario, sezione software
Sulla base delle risposte fornite dai partner è possibile effettuare una serie di interessanti considerazioni riguardanti le dotazioni software, sottolineando le similarità o gli
eventuali punti in cui è presente un distacco, più o meno netto, tra le soluzioni attualmente
adottate.
In primo luogo è rilevante osservare che le pubbliche amministrazioni prese in esame
in questo documento acquisiscono il software seguendo una strategia che, pur seguendo i
dettami della normativa vigente, può essere basata su obiettivi quali l’ottimizzazione delle
risorse utilizzate e su standard interni alle singole amministrazioni. Ciò rende possibili
scelte di acquisizione anche notevolmente differenti, per esempio influenzate da una scelta
iniziale nell’acquisizione dell’hardware oppure di una determinata famiglia di prodotti
software, con cui si vuole mantenere la compatibilità. Nonostante ciò, 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. Ciò
è 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
47
6
SOFTWARE E DATI
open source — in particolare Red Hat Enterprise Linux [SW1] — sopratutto in ambito
server. Può essere interessante far notare che regione Piemonte è l’unica a utilizzare
anche piattaforme elaborative basate su architettura SPARC e il sistema operativo Solaris
[SW18]. 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 compatibilità tra le varie versioni è pressoché completa e sono piuttosto rari
i casi in cui un software può essere eseguito correttamente su un sistema operativo più
vecchio mentre non funziona su uno più recente. Più probabile invece e da tener conto è
la compatibilità tra versione di sistema operativo e periferiche hardware, in quanto può
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 più recenti.
Similmente si è rilevato che la suite di programmi di produttività individuale più
utilizzata è Microsoft Office e, più in generale, sono predominanti le soluzioni proprietarie.
La regione Piemonte e la provincia di Bolzano fanno anche uso di soluzioni open source,
per esempio OpenOffice. Si ritiene che in questo ambito le problematiche di compatibilità
siano piuttosto ridotte, in quanto è sempre possibile scambiare i documenti in formati
standard di fatto, come il PDF che è standard ISO 32000 [SW19]. Al giorno d’oggi è anche
possibile creare e condividere documenti attraverso piattaforme online quali Google Docs
[SW20], risolvendo di fatto ogni problema di compatibilità e potendo comunque salvare i
documenti in locale in un formato a scelta tra quelli più comuni.
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 è cosı̀ scontata, ma generalmente viene supportata da appositi strumenti forniti dalla software house.
Fortunatamente, per il progetto PTA non si prevede la necessità di effettuare simili operazioni, in quanto si è 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 compatibilità, in quanto ogni partner dovrebbe essere responsabile
della gestione e della fornitura dei dati geografici di competenza.
La situazione delle soluzioni middleware di cui si servono i vari partner è piuttosto
variegata, perché oltre ai prodotti ESRI, sempre utilizzati dalle regioni Lombardia e Valle
d’Aosta e dalla provincia di Bolzano se ne aggiungono anche altre, come per esempio Java
Enterprise Edition [SW21], Microsoft IIS (Internet Information Services) [SW22], Apache
Tomcat [SW23], JBoss [SW24] e BEA (ora parte di Oracle) [SW25]. A parte la regione
48
6.2 Software proprietario vs. libero
6
SOFTWARE E DATI
Valle d’Aosta, che impiega un’unica soluzione proprietaria, gli altri partner utilizzano
prodotti sia proprietari sia open source, dove questi ultimi sono generalmente basati su
tecnologia Java. Anche in questo caso il fatto che i partner adottino soluzioni differenti
non dovrebbe destare grosse preoccupazioni, dato che nell’ambito della piattaforma PTA
i servizi GIS vengono forniti con uno standard concordato.
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 è stata scelta una piattaforma di virtualizzazione comune — nominata nell’introduzione della presente sezione — che dovrà essere utilizzata dai singoli partner per
erogare i servizi della piattaforma tecnologica. La migrazione dei dati geografici e dei
servizi GIS già esistenti, che risiedono già (almeno in parte) su piattaforme virtualizzate
per alcuni dei partner, sulla nuova piattaforma virtualizzata non è strettamente necessaria, in quanto i servizi forniti dalla piattaforma PTA possono appoggiarsi e interrogare
l’infrastruttura tecnologia già in essere nei sistemi informativi dei singoli partner.
6.2
Software proprietario vs. libero
Dall’analisi della parte di questionario inerente il software è emerso che i vari partner
utilizzano sia software di tipo proprietario sia software “libero”, oppure open-source. Il
software proprietario è cosı̀ chiamato perché 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 è quello che viene
pubblicato con una licenza che generalmente ne permette un libero utilizzo e consente
modifiche e personalizzazioni, nonché la sua ridistribuzione. Si noti che “libero” e “open
source” non significano esattamente la stessa cosa, nonostante la disponibilità del codice
sorgente sia alla base del software libero [SW12]; alle spalle del software libero c’è la Free
Software Foundation [SW13] mentre è la Open Source Initiative [SW14] a spingere per il
software open source.
Secondo Richard Stallman, fondatore della Free Software Foundation, il software può
essere definito libero se garantisce quattro libertà 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 comunità ne tragga beneficio.
Una delle licenze più utilizzate per la distribuzione del software libero, che garantisce
le quattro libertà sopraelencate, è la GNU General Public License [SW15]. Questa licenza
49
6.3 Software e dati GIS
6
SOFTWARE E DATI
è 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 più significativi:
• il codice sorgente è sottoposto alla revisione di moltissime persone ed è quindi più
difficile che sfuggano errori e bug; inoltre, quando questi vengono trovati solitamente
vengono corretti molto rapidamente;
• il software libero non utilizza standard proprietari (e segreti) per protocolli e dati
e quindi è più facile scrivere software compatibile e interoperabile;
• è possibile modificare il sofware libero e adattarlo alle proprie esigenze.
Probabilmente il principale difetto del software libero è che non è sempre disponibile:
in alcuni ambiti infatti, soprattutto se di nicchia, può essere piuttosto difficile trovare
un’alternativa valida a un software proprietario.
6.3
Software e dati GIS
Il software GIS, cioè quello che si occupa dell’elaborazione dei dati georeferenziati, è 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 compatibilità a questo livello: ognuno dei partner infatti è 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
(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.
Il software GIS maggiormente utilizzato dai partner del progetto è la suite dei prodotti
ESRI ArcGIS. Questo software è proprietario, ma supporta i principali standard ai vari
livelli in cui opera:
• web: SOAP, XML, REST, JavaScript;
• GIS: standard OGC quali GML, WFS, WMS, WCS;
• enterprise: EJB, SQL;
• applicativo: CAD, PDF;
50
6.3 Software e dati GIS
6
SOFTWARE E DATI
Informazioni più approfondite sull’argomento possono essere reperite sul sito internet
di ESRI Italia [SW26]. ArcGIS sembra dunque essere una buona soluzione integrata, pur
non essendo un software libero.
Un corposo elenco di software GIS è disponibile presso il sito dell’OGC [SW27] e in tale
elenco sono anche presenti gli standard OGC utilizzati dai singoli software, la tipologia
e se sono stati valutati “Certified OGC Compliant”. Un altro punto di riferimento per
il software GIS, in questo caso esclusivamente di tipo open source, è la Open Source
Geospatial Foundation [SW28], che è stata creata per produrre e supportare il miglior
software open source per la geomatica. Tra i progetti supportati da questa fondazione
c’è MapServer, un ambiente di sviluppo per realizzare applicazioni e servizi web GIS,
GRASS (Geographic Resources Analysis Support System), un software per l’analisi di
dati vettoriali e raster, e PostGIS, che permette di utilizzare il server PostgreSQL per
dati GIS.
I dati, in un sistema GIS, sono una componente fondamentale e sono suddivisi in
“livelli” tematici, in modo da affrontare più agevolmente e razionalmente la complessità
del mondo reale. Le due principali tipologie di dati sono le seguenti:
• dati spaziali, che descrivono la posizione delle entità geografiche;
• attributi, che descrivono caratteristiche associate alle entità geografiche.
I dati spaziali, la cui rappresentazione è tipicamente una mappa, possono essere
memorizzati utilizzando tre diversi formati:
• vettoriali;
• raster;
• immagini.
Il formato vettoriale prevede che le entità geografiche siano rappresentate utilizzando
una serie di punti (coordinate x,y) ed eventualmente degli archi che li collegano. Cosı̀
facendo è possibile definire entità geografiche rappresentate da singoli punti (alberi, pozzi...), linee (strade, fiumi...) e poligoni (confini amministrativi, laghi...). Più entità possono
condividere punti e archi ove queste entità sono a contatto tra di loro. I due modelli di
dato vettoriale comunemente utilizzati per i dati GIS sono quello topologico, in cui l’adiacenza tra entità geografiche è esplicitata, e il Computer-Aided Drafting (CAD), in
cui i poligoni sono entità indipendenti. Si noti che il CAD è un modello che non è stato
specificatamente pensato per la rappresentazione di dati geografici. Per questo motivo il
modello topologico è da preferire, soprattutto se si vuole operare analisi sui dati spaziali
in cui l’adiacenza di entità geografiche è un importante parametro. I vantaggi principali dei dati vettoriali sono la possibilità di rappresentare i dati alla risoluzione originale
senza ricorrere a generalizzazioni, l’assenza di conversioni visto che molti dati sono già
disponibili in formato vettoriale e l’accuratezza della posizione delle entità geografiche.
Gli svantaggi riguardano soprattutto la complessità delle operazioni da effettuare sia per
la creazione e l’aggiornamento della struttura topologica a partire dai dati vettoriali sia
51
6.4 Sistemi operativi real-time e per le WSN
6
SOFTWARE E DATI
per le operazioni di manipolazione e analisi dei dati e la necessità di salvare le coordinate
geografiche di ogni punto.
Il formato raster si basa sulla suddivisione dell’area geografica in una griglia composta
da celle, la cui dimensione dipende dall’accuratezza desiderata. Le coordinate all’interno
della griglia sono facilmente calcolabili, a patto di conoscere il punto d’origine, e l’adiacenza delle celle è implicitamente definita dalla struttura dati stessa. La soluzione più
comune è quella in cui le celle sono quadrate e hanno tutte la stessa dimensione. In questo caso non è necessario salvare la posizione geografica di ogni cella e la struttura dati
permette analisi molto rapide e più semplici da programmare. Uno dei principali difetti
è la difficoltà nello scegliere opportunamente la dimensione delle celle per ogni livello di
dati, cosı̀ da limitare le generalizzazioni e fornire una risoluzione sufficiente per gli scopi
ma al contempo non generare un numero troppo elevato di celle, che ha come conseguenza l’aumento della memoria necessaria e l’incremento dei tempi di calcolo per le analisi.
La dimensione delle celle deve anche essere scelta quando dati vettoriali devono essere
convertiti in dati raster e questa è un’operazione piuttosto comune.
I formati immagine vengono utilizzati per memorizzare fotografie satellitari, ortofotografie o scansioni di mappe. Affinché questi dati possano essere analizzati dal software
GIS è necessario che siano convertiti in formato raster.
I dati spaziali, come già detto in precedenza, possono essere arricchiti da attributi.
Gli attributi sono separati dai dati spaziali e possono essere mantenuti sia direttamente
dal software GIS sia in un database esterno. Attualmente quest’ultima soluzione è quella
più utilizzata e gli attributi sono tipicamente memorizzati all’interno di tabelle di un
database relazionale e collegati ai dati spaziali mediante un identificatore, che nel caso
dei dati raster è implicitamente definito dal numero di riga e colonna della cella mentre
per i dati vettoriali deve essere esplicitamente assegnato a ogni entità geografica.
Come nota conclusiva di questa sezione si ricorda che l’Unione Europea ha lanciato
un’iniziativa, chiamata INSPIRE, con lo scopo di fornire un’infrastruttura per i dati
geografici che consenta la realizzazione di banche dati geografici interoperabili. Sul sito
internet di INSPIRE [SW29] sono disponibili, oltre a direttive e regolamenti europei,
numerosi documenti tecnici e linee guida relativi alle specifiche dei dati.
6.4
Sistemi operativi real-time e per le WSN
Un sistema operativo real-time è un sistema specializzato per sistemi in cui è necessario
completare un elaborazione o ottenere una risposta entro un lasso di tempo predeterminato. Ciò non significa che real-time sia sinonimo di velocissimo, in quanto non è detto
che il tempo di risposta massimo sia piccolo. L’importante è che un sistema operativo
real-time sia prevedibile: i tempi massimi necessari per eseguire le chiamate di sistema devono essere noti e il sistema deve poter stabilire la fattibilità dell’esecuzione di una o più
elaborazioni, di cui deve conoscere i tempi di calcolo necessari e i relativi tempi massimi
da non superare. Queste caratteristiche sono spesso fondamentali in ambito industriale,
dove un ritardo nel prendere una decisione può causare malfunzionamenti nell’impianto e
possibili problemi per la sicurezza, e anche in altre situazioni, dove per esempio si effettua
52
6
SOFTWARE E DATI
qualche genere di monitoraggio e devono scattare allarmi o contromisure in caso vengano
rilevate una serie di condizioni particolari.
Esistono differenti tipologie di elaborazioni real-time. Un primo fattore discriminante è
la gravità di un eventuale superamento del tempo massimo e quindi abbiamo elaborazioni:
• hard real-time, la cui mancata esecuzione entro il tempo massimo stabilito causa
danni irreparabili e potenzialmente pericolosi;
• soft real-time, che provocano danni non irreparabili e che tipicamente sono dipendenti dal tempo passato dalla deadline all’effettivo completamento dell’operazione.
Le elaborazioni possono anche essere differenziate sulla base dell’eventuale periodicità
con cui devono essere eseguite:
• periodiche, ossia quando l’elaborazione deve essere effettuata con cadenza regolare
(è il caso, per esempio, della lettura di sensori tramite polling);
• aperiodiche, cioè se l’esecuzione non viene effettuata a intervalli regolari prestabiliti,
ma se ne conosce la frequenza massima;
• sporadiche, ovvero quando l’attivazione dell’elaborazione non è predicibile perché
dipende da eventi esterni.
Un’altra capacità che un sistema operativo real-time deve avere è quella di interrompere l’esecuzione di un elaborazione qualora sia necessario iniziarne immediatamente
un’altra più critica che altrimenti non potrebbe completare entro la soglia limite.
Dopo questa breve introduzione ai sistemi operativi real-time prendiamo in considerazione quel gruppo di sistemi operativi appositamente creati per piccoli dispositivi,
tipicamente dotati di limitata potenza di calcolo; in particolare ci interessiamo all’ambito delle reti di sensori wireless. Nella progettazione di un sistema operativo per WSN
assumono una particolare importanza alcuni aspetti come l’architettura, il modello di
programmazione, lo scheduling, la gestione della memoria, il supporto alla comunicazione
e la condivisione delle risorse. Un altro importante aspetto da considerare è l’eventuale predisposizione del sistema operativo per poter garantire le proprietà di un sistema
real-time.
Per quanto riguarda l’architettura del sistema operativo, ovvero com’è strutturato e
organizzato, esistono diverse soluzioni, tra cui troviamo quelle caratterizzate da un kernel
monolitico oppure da un micro-kernel. Nel primo caso tutti i servizi offerti dal sistema
operativo sono realizzati da svariati moduli che sono strettamente integrati e operano
nello stesso spazio, rendendo l’esecuzione efficiente; in un kernel monolitico però un singolo bug può bloccare l’intero sistema e la manutenzione del kernel risulta essere più
complicata. L’architettura a micro-kernel prevede invece che il kernel sia molto ridotto e
fornisca funzionalità minime, mentre tutte le altre funzionalità del sistema sono offerte
da moduli separati che operano a livello utente. Ciò evita che l’intero sistema si blocchi se
uno dei moduli ha un problema, semplifica le operazioni di manutezione ed estensione del
sistema operativo, ma riduce le prestazioni. Nell’ambito dei sistemi embedded e delle reti
53
6
SOFTWARE E DATI
di sensori wireless l’approccio micro-kernel dovrebbe essere il più indicato, per la ridotta
dimensione del kernel e per la possibilità di aggiungere solamente i moduli necessari. I
modelli di programmazione più significativi sono quello “multithreading” e quello “guidato dagli eventi”. Il più adatto tra i due a sistemi embedded e reti di sensori è il secondo,
ma il primo è quello più conosciuto dai programmatori e quindi ciò che si cerca di fare
è fornire un modello di programmazione multithreading più leggero, adatto ai dispositivi embedded. Lo scheduling, ovvero l’ordine in cui vengono eseguiti i singoli compiti, è
particolarmente importante e visto che sistemi embedded e reti di sensori wireless possono potenzialmente operare in scenari critici è opportuno che siano supportati algoritmi
di scheduling in grado di garantire, se necessario, anche le caratteristiche di un sistema
real-time. Visti i limiti di questi dispositivi, in termini di potenza di calcolo, memoria
e autonomia operativa, gli algoritmi di scheduling devono essere efficienti in tutti questi
ambiti. La gestione della memoria può essere statica oppure dinamica, a seconda se si
propende per un approccio semplice ma poco flessibile oppure per uno più complesso ma
che garantisce una maggiore flessibilità. La protezione della memoria — e, più in generale, la condivisione delle risorse — non è un problema se esiste un’unica applicazione in
esecuzione, come a volte capita sui nodi di una rete di sensori, ma diventa una questione
da considerare con l’introduzione del multithreading. Nelle reti di sensori è particolarmente importante il supporto alla comunicazione, in quanto ogni nodo tipicamente deve
comunicare con altri nodi, eventualmente di tipo differente; un sistema operativo per tali
dispositivi deve quindi fornire il necessario supporto alla comunicazione.
Questi argomenti sono trattati in maniera più estesa in una panoramica sui sistemi
operativi per wireless sensor networks pubblicata recentemente [SW30]. Nello stesso articolo sono anche presentati e confrontati cinque popolari sistemi operativi per wireless
sensor networks, ossia TinyOS, Contiki, MANTIS, Nano-RK e LiteOS. L’unico tra questi
a supportare applicazioni real-time è Nano-RK.
54
7
7
SICUREZZA ICT
Sicurezza ICT
La sicurezza nel settore informatico e delle comunicazioni è un argomento assolutamente
di primo piano: basti pensare che, al giorno d’oggi, moltissime informazioni che riguardano
le singole persone, le aziende, le pubbliche amministrazioni, i governi e cosı̀ via sono
memorizzate digitalmente e possono essere scambiate attraverso le intranet aziendali ma
anche la rete internet. Al fine di assicurare la confidenza e l’integrità delle informazioni che
devono transitare sulla rete internet, verificare in maniera affidabile l’identità dell’altra
parte in un qualche genere di transazione, evitare che dati sensibili diventino pubblici e
che malintenzionati possano accedere o distruggere importanti informazioni è necessario
sfruttare i più recenti strumenti messi a disposizione per proteggere i sistemi informativi
e i dati ivi contenuti.
Di seguito sono prima presentati i risultati dei questionari relativi all’accesso ai dati
e alla sicurezza e poi sono introdotte una serie di tecniche per la sicurezza in ambito
informatico, dalla crittografia ai firewall. Infine è introdotto il discorso della sicurezza
nelle reti di sensori wireless.
7.1
In questa sezione è stato deciso di inserire le risposte ai questionari sia per la parte relativa
l’accesso e la condivisione dei dati sia per ciò che riguarda la sicurezza degli stessi. In
tabella 5 sono presentate le risposte dei partner sul primo argomento summenzionato.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1. Quali sono i dati che prevedete di condividere/riutilizzare nell’ambito del progetto PTA?
Dati relativi alle
componenti infrastrutturali
Limiti
amministrativi,
viabilità, ferrovie, idrografia,
edificati
Limiti amministrativi, reticolo
idrografico,
toponomastica
(geographical names di
INSPIRE circoscritto
ai
nomi dei centri
abitati), centri
abitati, rete dei
trasporti
I dati già condivisi ora
N.D.
55
7
SICUREZZA ICT
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
2. Per quanto riguarda i dati che prevedete di condividere/riutilizzare nell’ambito del progetto PTA, quali sono le politiche di accesso, condivisione e riuso dei dati detenuti e gestiti
presso la vostra organizzazione nei confronti di altre pubbliche amministrazioni nazionali?
Seguono qualche normativa locale o regolamento interno?
Da definire e comunque i dati
sono pubblici
Regione
Piemonte ha DGR
che approva le
Linee Guida per
il riutilizzo e
l’interscambio
del patrimonio
informativo
regionale e definisce le relative
licenze
d’uso
dei dati (DGR
36,1109
del
30/11/10). In
tale contesto si
stanno definendo le specifiche
licenze
d’uso
anche per i dati
PTA.
Studio in corso
Nessuna restrizione nella condivisione dei dati
N.D.
presso la vostra organizzazione nei confronti di altre pubbliche amministrazioni estere?
Seguono qualche normativa locale o regolamento interno?
Come risposta
alla domanda 2
Come risposta
alla domanda 2
Come risposta
alla domanda 2
Come risposta
alla domanda 2
N.D.
presso la vostra organizzazione nei confronti di generici utenti? Seguono qualche normativa
locale o regolamento interno?
Come risposta
alla domanda 2
Come risposta
alla domanda 2
Come risposta
alla domanda 2
Come risposta
alla domanda 2
N.D.
56
7
SICUREZZA ICT
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
5. Quali sono gli strumenti che prevedete di utilizzare per la condivisione dei dati tra
pubbliche amministrazioni e altri partner nell’ambito del progetto PTA?
Da definire
Verranno realizzati
servizi
WMS
Geoportale
PTA
Servizi web /
downloads
N.D.
6. Quali sono gli strumenti di identificazione/autenticazione che prevedete di utilizzare
per la condivisione dei dati tra pubbliche amministrazioni e altri partner nell’ambito del
progetto PTA?
Non presenti
Non sono previsti strumenti di
autenticazione
Dati
pubblici
senza
necessità
di
autenticazione
Nessuna identificazione
/
autenticazione
prevista per il
momento
N.D.
7. Quali sono i dati che prevedete di rendere accessibili agli utenti generici nell’ambito del
progetto PTA?
I dati sono pubblici
Come risposta
alla domanda 1
Come risposta
alla domanda 1
Tutti i dati pubblicati già adesso
N.D.
8-9. Ritenete sia necessario che l’accesso ai servizi e ai dati della piattaforma PTA avvenga
tramite un’opportuna autenticazione per gli utenti generici?
No
No
No
No
N.D.
10. Quali sono gli strumenti di identificazione/autenticazione utilizzati dalla vostra
organizzazione per l’accesso a servizi e dati (in generale) da parte di generici utenti?
Carta regionale dei servizi,
username e password
Carta d’identità
elettronica,
carta nazionale
/ regionale dei
servizi, username e password,
OTP per la PA,
certificati su file
Username e password
Carta nazionale
dei servizi
N.D.
57
7
SICUREZZA ICT
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
11. Esistono politiche di accesso, condivisione e riuso differenti per altri tipi di dati detenuti e gestiti presso la vostra organizzazione nei confronti di altre pubbliche amministrazioni nazionali o estere e utenti generici? Seguono qualche normativa locale o regolamento
interno?
No
Come risposta
alla domanda 2
anche per dati
generici
No
Per dati nonGIS vengono rispettate normative legislative
N.D.
Tabella 5: Risposte al questionario, sezione accesso ai dati
L’informazione più rilevante che emerge, in maniera piuttosto evidente, dall’analisi delle
risposte a questa parte del questionario è che tutti i partner, escluso il canton Ticino che non
si è 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 è 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 è 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 è un’altra pubblica amministrazione facente
parte della stessa nazione, ma è 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 mobilità (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 tracciabilità anche al di fuori di un esplicito
accordo.
L’argomento è già stato trattato in maniera più approfondita nella sezione 3.3 del documento intitolato “Studio della compatibilità normativa nel settore ICT e TLC” e già prodotto
all’interno dell’azione 3 del progetto PTA, ma si ritiene rilevante far notare che solamente la
58
7
SICUREZZA ICT
regione Piemonte ha normato in maniera chiara la condivisione e il riutilizzo del patrimonio informativo regionale, stabilendo le licenze d’uso dei dati [SW31]. Si reputa auspicabile che anche
le altre regioni italiane — che sembrano essere già indirizzate in quella direzione — prevedano
l’adozione di una simile normativa, cosı̀ da rendere maggiormente trasparente e semplificato
l’interscambio e il riutilizzo di informazioni.
Per quanto riguarda gli strumenti di identificazione e autenticazione attualmente utilizzati dai partner italiani si può affermare che le soluzioni maggiormente adottate sono la carta
regionale o nazionale dei servizi e il comune paradigma nome utente/password.
Tabella 6 fornisce invece le risposte dei soggetti che partecipano al progetto PTA riguardo
la sicurezza dei dati.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1. Quali sono le politiche adottate per la sicurezza dei dati detenuti e gestiti presso la vostra
organizzazione? Fanno riferimento a qualche normativa locale o regolamento interno?
Normativa relativa al DPS e
leggi relative alla privacy
D.Lgs 196/2003
Documento
Programmatico
sulla Sicurezza
in ottemperanza
alla normativa
sulla tutela dei
dati personali
(privacy)
Regolamento
interno
N.D.
Sı̀,
comunicazioni
interne
all’Amministrazione regionale.
Non se ne ravvisa la rilevanza
nel
progetto
PTA Standard
utilizzato X509
(InfoCert)
Sı̀, dati nonGIS, dati non
rilevanti
nel
progetto PTA
N.D.
No
N.D.
N.D.
N.D.
rilevanti
nel
progetto PTA
N.D.
2-3. Utilizzate la firma elettronica?
Sı̀, non per dati rilevanti al
progetto PTA
No
4-5. Utilizzate la firma elettronica avanzata?
Sı̀, Servizi Sanitari e non per
dati GIS
No
6-7. Utilizzate la firma digitale?
Sı̀, Servizi Sanitari e non per
dati GIS
Sı̀, non per PTA
59
7
SICUREZZA ICT
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
Sı̀.
Per
comunicazioni
di
carattere
ufficiale:
per
ciascuna Area
Organizzativa
Omogenea
AOO - l’Amministrazione
dispone di una
casella
PEC.
Non
rilevante
nel
progetto
PTA
rilevanti
nel
progetto PTA
N.D.
Sı̀. Per trasmissione dati sanitari e/o sensibili. Non rilevante nel progetto
PTA
Sı̀. Dati nonGIS, dati non rilevanti nel progetto GIS (email, VPN)
N.D.
8-9. Utilizzate la posta elettronica certificata?
Sı̀, Servizi Sanitari ma non per
i servizi GIS
Sı̀. Nessuna rilevanza per PTA.
Altri
utilizzi:
bandi di gara;
flussi documentali con Enti
consorziati;
comunicazioni
obbligatorie per
legge.
10-11. Utilizzate connessioni cifrate?
Sı̀, non per GIS.
Sı̀. Le connessioni che trasportano dati non
pubblici (a partire dalle password) sono cifrate SSL. La
versione è funzione del sistema remoto.
12. In caso utilizziate altri strumenti per la sicurezza nel trasferimento dei dati, quali sono
e per quale genere di dati vengono utilizzati? Alcune di questi dati possono riguardare il
progetto PTA?
Non per PTA
N.D.
N.D.
N.D.
N.D.
Tabella 6: Risposte al questionario, sezione sicurezza dei dati
Le pubbliche amministrazioni locali italiane stabiliscono le politiche da adottare per la sicurezza dei dati sensibili da loro detenuti sulla base del “Codice in materia di protezione dei dati
personali” e più in particolare seguendo il Documento Programmatico sulla Sicurezza (DPS),
che deve essere annualmente redatto dal titolare di dati sensibili e ha lo scopo di delineare il
quadro delle misure di sicurezza, organizzative, fisiche e logiche, adottate per il trattamento dei
dati personali.
Tutti i partner fanno uso di sistemi per garantire, quando necessario, proprietà quali l’inte-
60
7.2 Tecniche per la sicurezza ICT
7
SICUREZZA ICT
grità e la confidenzialità dei dati, ma anche l’autenticazione dell’autore di un documento o del
mittente all’interno di una comunicazione e la prova — con valore legale — dell’avvenuta spedizione e ricezione di una comunicazione. Le soluzioni maggiormente utilizzate risultano essere
la firma elettronica, la firma digitale, la posta elettronica certificata e connessioni cifrate, ma
tutti i partner sono concordi che tali soluzioni non sono necessarie nell’ambito della piattaforma
PTA, quantomeno per ciò che riguarda i dati geografici.
7.2
Tecniche per la sicurezza ICT
Nonostante la maggior parte dei dati che saranno scambiati all’interno della piattaforma PTA e
poi forniti agli utenti sono pubblici e quindi non richiedono particolari accorgimenti, è rilevante
affrontare la problematica della sicurezza in ambito ICT poiché è importante proteggere anche
i sistemi che ospitano i dati o forniscono i servizi da intrusioni indesiderate e potenzialmente
pericolose, che potrebbero per esempio essere mirare alla manomissione di dati o causare un’interruzione del servizio. Tenendo poi conto del fatto che per una parte dei dati (quelli relativi
al rilevamento dei flussi di mobilità) è necessario applicare le misure minime di sicurezza in
quanto dati sensibili si ritiene anche possa essere utile introdurre, dal punto di vista tecnico,
strumenti quali la firma digitale e le tecniche di cifratura più utilizzate. Introduciamo per prima
cosa proprio questi strumenti, prima di affrontare il discorso della sicurezza architetturale.
7.2.1
Confidenzialità, integrità e autenticazione
In molti casi, in particolare se l’informazione scambiata contiene dati sensibili, privati o più
semplicemente importanti, è fondamentale fare in modo che siano perseguite le due seguenti
proprietà:
• confidenzialità: solamente gli utenti autorizzati possono accedere alle informazioni;
• integrità: solamente gli utenti autorizzati possono modificare le informazioni.
Per gestire le autorizzazioni degli utenti è necessario prevedere un sistema che permetta di
identificare e autenticare gli utenti. Prendiamo in esame tutte queste problematiche nei seguenti
paragrafi.
7.2.1.1
Sistemi crittografici
La confidenzialità delle informazioni si ottiene attraverso l’utilizzo di un sistema crittografico,
cioè un sistema che permette di cifrare e decifrare un messaggio utilizzando un opportuno
algoritmo e una o più chiavi. Esistono due categorie di sistemi crittografici:
• sistemi simmetrici;
• sistemi asimmetrici.
I sistemi simmetrici utilizzano una sola chiave per cifrare e decifrare il messaggio. Questi
sistemi sono tipicamente molto veloci ed efficienti, ma presentano il problema del trasferimento
sicuro della chiave tra chi codifica il messaggio e chi lo deve decodificare. Ciò significa che è
necessaria la presenza di un canale di comunicazione sicuro su cui passare la chiave segreta.
Alcuni esempi di sistemi simmetrici sono il Data Encryption Standard (DES), scelto come
61
7
SICUREZZA ICT
standard per il governo degli Stati Uniti d’America nel 1977 dal National Institute of Standards
and Technology (NIST) [SICT2] e pubblicato come Federal Information Processing Standard
(FIPS) [SICT3] con sigla FIPS FUB 46, e la sua evoluzione Triple DES (3DES), introdotta nel
1999 nel FIPS-46-3 [SICT4]. Al giorno d’oggi il DES è stato rimpiazzato dal più sicuro Advanced
Encryption Standard (AES), scelto come standard sempre dal NIST nel 2001 e pubblicato come
FIPS FUB 197 [SICT5]. AES è un algoritmo particolarmente efficiente liberamente distribuibile
e utilizzabile.
I sistemi asimmetrici si basano su una coppia di chiavi, una delle quali è privata e deve essere
nota solamente al suo proprietario mentre l’altra è pubblica. Le due chiavi sono corrispondenti,
ovvero ciò che viene cifrato con una può essere decifrato con l’altra e viceversa. Al contrario di
ciò che succede con i sistemi simmetrici, in questo caso non è necessario scambiarsi la chiave
segreta in quanto la chiave pubblica può essere nota a tutti. Nel caso si voglia garantire la
confidenzialità dell’informazione non bisogna cifrare il messaggio con la propria chiave privata,
in quanto tutti sarebbero in grado di decifrarlo utilizzando la chiave pubblica, ma utilizzare
la chiave pubblica del destinatario del messaggio, cosı̀ la decifrazione può essere effettuata
solamente attraverso la chiave privata corrispondente. Da questa considerazione emerge il fatto
che, con la crittografia asimmetrica non solo è possibile garantire la confidenzialità, ma si può,
in alternativa, anche certificare il mittente del messaggio, poiché se un messaggio può essere
decifrato con la chiave pubblica di un utente allora — supponendo che la sua chiave privata sia
veramente tale — tale messaggio cifrato deve essere stato inviato dall’utente in questione. Tra
gli algoritmi asimmetrici più conosciuti ci sono Diffie-Hellman [SICT6], che serve esclusivamente
per concordare una chiave segreta tra due entità su un canale di comunicazione insicuro, RSA
(sulla cui base sono nati numerosi prodotti per la sicurezza [SICT7]) e il Digital Signature
Standard (DSS), scelto come standard dal NIST per la firma digitale nel 1991 e rivisto nel 2000
nel FIPS FUB 186-2 [SICT8].
Si noti che, nella pratica, la crittografia asimmetrica si usa principalmente per concordare
tra le due parti, in sicurezza, una chiave segreta condivisa da utilizzare per il resto del trasferimento o della transazione. Questo succede poiché gli algoritmi crittografici asimmetrici sono
computazionalmente più onerosi rispetto a quelli simmetrici. Un’altra considerazione rilevante
è che la potenza degli elaboratori cresce sempre di più e la sicurezza dei sistemi crittografici,
sia simmetrici sia asimmetrici, dipende dalla lunghezza delle chiavi utilizzate. Per la crittografia
simmetrica la lunghezza delle chiavi usate da AES (128,192,256 bit) è ritenuta sufficiente dalla
National Security Agency (NSA) [SICT9] per i documenti “secret” e “top secret” [SICT10]. Nella crittografia asimmetrica è necessario utilizzare chiavi decisamente più lunghe e, per esempio,
per RSA è consigliato l’utilizzo di chiavi da almeno 1024 bit, ma sarebbe preferibile utilizzare
chiavi da 2048 bit per assicurare la sicurezza anche nei prossimi anni [SICT11].
Vari linguaggi di programmazione includono librerie per la crittografia, sia simmetrica sia
asimmetrica: per esempio in Java gli strumenti sono contenuti nel package javax.crypto e in
java.security e nella piattaforma .NET si trovano in System.Security.Cryptography. Algoritmi
di cifratura simmetrici e asimmetrici sono anche disponibili attraverso il progetto open source
OpenSSL [SICT12].
7.2.1.2
Funzioni di hash
L’integrità delle informazioni — per esempio di un generico file — si può verificare tramite
ciò che viene chiamato “message digest”, ovvero il prodotto di una funzione, detta di hashing,
62
7
SICUREZZA ICT
che genera deterministicamente un risultato di dimensione fissa, tipicamente una stringa di
caratteri esadecimali, a partire da un generico file. Una funzione F di hash deve avere tre
proprietà fondamentali, cioè deve essere computazionalmente intrattabile:
• trovare un input x tale che F(x) produca un risultato h uguale a un hash desiderato;
• trovare un input y tale che, dato un altro input x, F(y)=F(y);
• trovare coppie di input x,y tali che F(y)=F(y).
Gli algoritmi di hash più noti sono il Message Digest Algorithm, a oggi giunto alla versione
5 (MD5) e standardizzato con la RFC 1321 [SICT13] e il Secure Hash Algorithm (SHA), la cui
standardizzazione più recente è presentata nel FIPS FUB 180-3 [SICT14], in cui ben 5 versioni
di SHA sono definite “algoritmi di hash sicuri”. La versione più diffusa di SHA, cioè SHA-1, ha
sostituito l’algoritmo MD5, che ormai è ritenuto non sufficientemente sicuro.
Il risultato della funzione di hash, che tipicamente è molto piccolo (SHA-1 produce digest di
160 bit), deve essere generato al momento dell’invio di un messaggio e può essere utilizzato dal
destinatario per verificarne l’integrità. In questo modo è possibile cifrare con la chiave privata
soltanto il piccolo digest invece che un intero documento. Il destinatario dunque può decifrare
il messaggio di digest utilizzando la chiave pubblica del mittente, verificandone la provenienza,
utilizzare a sua volta la funzione di hash sul documento e confrontare il digest ricevuto con
quello appena generato, accertando che il documento non sia stato modificato da utenti non
autorizzati. Il digest di un documento, crittografato con la chiave privata del suo autore, viene
chiamato firma digitale del documento.
Java e il Framework .NET mettono a disposizione una serie di strumenti per la creazione di
digest, rispettivamente nei package java.security e System.Security.Cryptography.
7.2.1.3
Identificazione e autenticazione
L’identificazione e l’autenticazione sono necessarie per stabilire l’identità di un generico utente
— ma potrebbe essere anche un’entità differente, come un provider di servizi — e verificare, in
maniera affidabile, la correttezza dell’identità fornita. Esistono tre paradigmi di autenticazione:
• one-way: il client si autentica presso il server, che invece si suppone abbia un’identità
valida; questo paradigma è il più diffuso;
• two-way: client e server si autenticano vicendevolmente;
• thrusted third party: un’entità esterna, ritenuta affidabile sia dal client sia dal server,
autentica entrambe le parti.
Esistono inoltre svariati metodi e tecnologie per l’autenticazione, che possono essere raccolti
in tre categorie:
• ciò che si sa: password, pin;
• ciò che si ha: smart card, token, certificato digitale;
• ciò che si è: dati biometrici come le impronte digitali, l’iride, la retina, la voce...
La discussione sugli strumenti per identificazione e autenticazione è rimandata al documento
integrativo sull’identità digitale — in cui verranno presi in considerazione anche firme e certificati
digitali — che ha come obiettivo trattare questo problema sia dal punto di vista normativo sia
tecnologico.
63
7.2.2
7
SICUREZZA ICT
Sicurezza architetturale
È buona norma separare la rete privata, a cui sono collegate le risorse informatiche della pubblica amministrazione o dell’azienda, dalle reti esterne — un esempio è la rete internet —, che
sono tipicamente insicure. Di seguito prendiamo in considerazione alcuni strumenti e soluzioni
pensati per rendere sicura la rete privata permettendo comunque l’accesso, debitamente controllato, ai servizi che si vuole fornire al mondo esterno e contemporaneamente rendendo possibile,
qualora sia necessario, che dalla rete privata si possa accedere a servizi e informazioni reperibili
all’esterno.
7.2.2.1
Firewall
Un firewall è un sistema di controllo degli accessi che verifica tutto il traffico che lo attraversa
e consente o nega il passaggio di tale traffico sulla base di una politica di sicurezza. Visto che
il firewall è in grado di controllare solamente in traffico che lo attraversa, per non minare la
sicurezza della propria rete interna è necessario evitare la creazione di altri punti di accesso,
come potrebbe essere un computer connesso contemporaneamente alla rete interna e a internet
attraverso un modem.
Esistono varie tipologie di firewall, che possono essere suddivisi in due macro categorie:
• firewall che operano a livello di rete.
In questa categoria rientrano i tipi più semplici di firewall, che sono in grado di filtrare
il traffico sulla base di informazioni ottenibili ai livelli 3 (network) e 4 (transport) del
modello ISO/OSI. I due principali esponenti di questa categoria sono:
– packet filter: è il firewall più semplice e le regole che formano la politica di sicurezza si
fondano semplicemente sulle informazioni ricavabili dall’header del singolo pacchetto
IP, cioé indirizzo sorgente e destinazione, porta sorgente e destinazione, tipo e opzioni
di protocollo. Con un sistema di questo tipo si può permettere o bloccare il traffico
proveniente da determinate sorgenti e diretto a determinate destinazioni e, grazie ai
numeri di porta, consentire o negare il traffico verso servizi noti, mentre non si può
tracciare la correlazione tra pacchetti all’interno di una comunicazione.
– stateful packet filter: questo firewall aggiunge alle capacità del precedente quella di
analizzare alcune relazioni tra i pacchetti che lo attraversano, tipicamente tenendo
traccia dello stato della connessione TCP; ciò porta numerosi benefici, tra cui la
possibilità di accettare connessioni dalla rete esterna solamente se queste fanno parte di una connessione iniziata dall’interno, ma introduce anche possibili problemi
di memoria e di performance, visto che diventa necessario tenere traccia di tutte le
connessioni che attraversano il firewall. I firewall di questo tipo più moderni possono
anche avere funzionalità più avanzate come l’analisi dei contenuti di sessioni e protocolli (es. possono far controllare gli allegati della posta elettronica a un antivirus)
ed è possibile configurarli inserendo una lista di attacchi noti che quindi il firewall
può riconoscere e bloccare.
• firewall che operano a livello applicativo.
Questi apparati operano a un livello superiore rispetto a quelli della categoria precedente,
ovvero intercettano e analizzano le connessioni a livello applicativo e sono in grado di
monitorare la comunicazione da e verso una o più applicazioni o servizi specifici, validando
64
7
SICUREZZA ICT
il protocollo di comunicazione utilizzato ed eventuali dati sensibili che transitano nella
comunicazione (per esempio le password). L’esempio più rilevante di questa categoria di
strumenti per la sicurezza è l’application proxy firewall. Le caratteristiche di un proxy
sono le seguenti:
– solitamente viene realizzato su un server con un generico sistema operativo invece
che su una macchina specifica, al contrario dei packet filter;
– è necessario implementare proxy differenti per servizi e applicazioni differenti;
– presenta un insieme opportunamente ridotto e messo in sicurezza dei servizi offerti,
che può sia difendere gli utenti interni che vogliono accedere a servizi esterni, sia i
servizi interni dall’accesso non autorizzato dall’esterno;
– può effettuare l’autenticazione degli utenti e applicare specifiche politiche di accesso;
– permette il filtraggio dei contenuti.
Tutte le connessioni da e verso un servizio applicativo quindi devono transitare attraverso
il proxy.
I principali vantaggi dei firewall packet filter è che sono molto veloci, possono supportare in
maniera trasparente praticamente tutti i protocolli di comunicazione e, se ben configurati, sono
molto sicuri, anche perché sono delle macchine costruite esattamente per quel compito. I packet
filter possono inoltre essere estesi per supportare l’ispezione a livello applicativo.
I firewall che lavorano a livello applicativo permettono un controllo più fino per i protocolli
applicativi supportati, su cui è possibile effettuare ispezioni specifiche, logging e caching; in più
permettono l’autenticazione degli utenti e l’applicazione di differenti politiche sulla base dei
singoli utenti o dei gruppi di utenti. Tutto ciò ha un costo in termini di prestazioni e scalabilità.
Oltre a ciò bisogna considerare che, pur essendo perfettamente configurati, potrebbero comunque presentare problemi di sicurezza in quanto il loro funzionamento è basato sulle librerie di
un generico sistema operativo, che potrebbero non essere esenti da bug. Per concludere, si noti
inoltre che i proxy generalmente non effettuano alcun filtraggio basato sulle informazioni reperibili a livello di rete. Per questi ultimi motivi può essere consigliabile utilizzare il proxy dietro
a un packet filter, per esempio configurando quest’ultimo in modo da far passare solamente il
traffico proveniente dal proxy, obbligando di fatto il suo utilizzo.
7.2.2.2
Architettura a due zone
In una situazione ottimale e semplificata si potrebbe stabilire che gli utenti sicuri sono tutti
all’interno della rete privata mentre quelli che potrebbero essere potenzialmente malevoli si
trovano tutti all’esterno. In questo documento trascuriamo il caso in cui utenti con fini ostili
abbiano si trovino all’interno della rete privata — non perché di scarsa importanza ma siccome
esula dall’ambito del discorso — e prendiamo in considerazione la necessità di fornire accesso,
sia limitato sia completo, alle risorse aziendali anche a persone esterne alla rete privata. I vari
tipi di accesso e traffico che riguardano le risorse e gli utenti all’interno della rete privata sono
i seguenti:
• traffico dall’interno verso l’interno:
– di utenti che accedono alle risorse situate all’interno della rete privata;
65
7
SICUREZZA ICT
– tra i vari server presenti all’interno della rete (per esempio tra un server web e un
database per l’ottenimento di dati).
• traffico dall’interno verso l’esterno, di utenti interni che si collegano a internet, usano la
posta elettronica o altri servizi esterni alla rete privata;
• traffico dall’esterno verso l’interno:
– di utenti esterni che però hanno necessità di accedere alle risorse come se fossero
nella rete privata;
– di utenti che vogliono accedere alle risorse messe loro a disposizione (es. navigare sul
sito internet dell’organizzazione, inviare posta elettronica verso l’interno, sfruttare
altri servizi);
La situazione che si configura è quindi quella in cui, all’interno della rete privata, esistono
contemporaneamente server e relativi servizi verso cui l’accesso deve essere limitato esclusivamente a utenti fidati e autenticati e server che offrono invece servizi a generici utenti anonimi.
Al fine di ottenere una protezione massima per i primi risulta necessario separarli dai secondi:
la soluzione è quindi creare una rete “intermedia” tra quella esterna e quella privata interna,
chiamata DeMilitarized Zone (DMZ), al cui interno locare i server che devono essere accessibili
dall’esterno e che non erogano servizi critici e confinare gli accessi provenienti dall’esterno. Per
suddividere la rete dell’organizzazione in queste due zone è possibile utilizzare:
• due firewall, uno che funge da punto di contatto tra la rete esterna e la DMZ e l’altro
posto tra quest’ultima e la rete privata;
• un singolo firewall a tre vie, a cui cioè sono collegate rete esterna, DMZ e privata.
Supponendo che si sia creata l’architettura a due zone utilizzando due firewall, un esempio
di posizionamento dei server e dei relativi servizi all’interno delle due reti può essere il seguente:
• DMZ: server web esterno, server FTP, server SMTP in ingresso; in questa porzione della
rete quindi potrebbe trovare posto il server che espone i servizi relativi ai dati geografici
della piattaforma PTA.
• rete privata: database server, server web interno, server SMTP in uscita, proxy HTTP
per la navigazione in internet dalla rete interna; in questa parte della rete dovrebbe essere
posizionato il database dei dati GIS.
Il firewall esterno, dunque, deve essere configurato in modo da consentire l’accesso dall’esterno esclusivamente ai servizi presenti nella DMZ, mentre quello interno può far passare del
traffico da proveniente da un server della DMZ (es. il web server) a un servizio della rete privata
(es. la base di dati) e deve consentire il traffico in uscita, eventualmente obbligando l’utilizzo
dei proxy.
Rimane da risolvere la problematica di fornire accesso sicuro ai servizi e ai dati presenti nella
rete privata a utenti che lo necessitano e si trovano però nella rete esterna. Viene affrontata nel
prossimo paragrafo.
66
7.3 Sicurezza nelle Wireless Sensor Networks (WSN)
7.2.2.3
7
SICUREZZA ICT
Virtual Private Network (VPN)
Qualora sia necessario permettere l’accesso alle risorse private della rete interna anche da una
rete esterna insicura, quale internet, è possibile utilizzare una VPN, ovvero una connessione
crittografata e sicura che garantisce la confidenzialità e l’integrità dei dati trasmessi. In una
architettura a due zone con due firewall distinti, come quella descritta nel paragrafo precedente,
il traffico della connessione VPN deve attraversare il firewall esterno per raggiungere il firewall
interno, che deve fungere anche da server VPN.
Si possono applicare due politiche differenti per gestire il traffico di un utente collegato
a una VPN. La prima prevede che tutto il traffico generato dall’utente, a prescindere dalla
destinazione, entri nella connessione VPN, raggiunga il server VPN e quindi venga smistato. In
questo modo c’è un singolo punto di controllo e ciò permette una maggiore sicurezza, ma tutto
il traffico (anche quello verso internet) deve passare per il firewall esterno dell’organizzazione
ed essere gestito dal server VPN, che eventualmente lo rendirizza nuovamente verso la rete
internet. La seconda politica, chiamata “split tunnelling”, prevede invece che il traffico per la rete
aziendale entri nel tunnel VPN mentre quello diretto a internet passi direttamente per il proprio
Internet Service Provider (ISP). Cosı̀ facendo il carico sugli apparati di rete dell’organizzazione
viene ridotto, ma la sicurezza diminuisce poiché la macchina dell’utente connesso in VPN può
diventare un punto di accesso per connessioni non autorizzate alla VPN.
Alcune tecnologie che possono essere utilizzate per la creazione di una VPN sono il Point
to Point Tunnelling Protocol (PPTP), un protocollo proprietario di Microsoft reso disponibile
come RFC 2637 [SICT15], Internet Protocol SECurity (IPSEC), un insieme di protocolli per
l’autenticazione e la cifratura dei pacchetti a livello di rete (IP) [SICT16], e VPN su Secure
Socket Layer (SSL), un protocollo di comunicazione progettato per transazioni sicure in internet
che sfrutta la crittografia simmetrica e asimmetrica per garantire la confidenzialità e l’integrita
dell’informazione, l’autenticazione del server e opzionalmente quella del client.
7.3
Sicurezza nelle Wireless Sensor Networks (WSN)
L’azione 6 del progetto PTA prevede il monitoraggio dei flussi di mobilità e quest’attività può
essere effettuata, per esempio nelle gallerie, utilizzando una rete di sensori wireless, attraverso
cui si può identificare il mezzo in transito (se è dotato anch’esso di un adeguato trasmettitore) e
la sua posizione. In tali reti di sensori i protocolli comunemente utilizzati per la comunicazione
sono lo standard IEEE 802.15.4 [TLC1] e ZigBee [TLC2], che si appoggia sui servizi offerti
proprio da 802.15.4 per fornire funzionalità di più alto livello. Un’interessante pagina su questi
due protocolli è disponibile nei riferimenti bibliografici [TLC3].
Uno dei servizi implementati dal layer Media Access Control (MAC) di 802.15.4 è proprio
relativo alla sicurezza. Lo standard IEEE 802.15.4 stabilisce l’algoritmo utilizzato per la cifratura delle comunicazioni, cioè AES con chiavi a 128 bit. Ciò è sicuramente importante in un
ambito come quello delle reti di sensori, in cui i nodi sono tipicamente semplici, hanno a disposizione una potenza di calcolo limitata e devono essere molto efficienti: non solo AES è un
algoritmo particolarmente efficiente, ma essendo anche l’unico scelto dallo standard può essere
implementato direttamente via hardware. La sicurezza delle informazioni contenute in ognuno
dei pacchetti scambiati è garantita dalla cifratura del payload contenuto nel frame di livello
MAC. AES è anche utilizzato per verificare l’integrita dei dati ricevuti: alcune parti del MAC
frame vengono cifrate e ciò permette, al nodo ricevente, di riconoscere se il messaggio è giunto
67
7.3 Sicurezza nelle Wireless Sensor Networks (WSN)
7
SICUREZZA ICT
da un nodo non autorizzato e quindi scartarlo direttamente. Nel MAC frame di 802.15.4 sono
tre i campi che vengono interessati dalla sicurezza:
• Frame Control, situato nel header del MAC frame; in questo campo è presente il Security
Enabled Bit, che è posto a 1 se è richiesto l’utilizzo degli strumenti per la sicurezza;
• Auxiliary Security Control, situato nel header del MAC frame; questo campo, che è valido
soltanto se il sopracitato bit sulla sicurezza è posto a 1, contiene svariate informazioni
necessarie a specificare la politica di sicurezza utilizzata e a realizzare le misure di sicurezza
previste.
• Data Payload, posto nel MAC payload; questo campo contiene i dati, eventualmente
cifrati, a seconda della configurazione dei due campi precedenti.
Ogni nodo 802.15.4 inoltre utilizza una Access Control List per poter verificare i nodi
autorizzati e la politica relativa di sicurezza da utilizzare.
ZigBee implementa due layer aggiuntivi di sicurezza su quello fornito da 802.15.4, uno a
livello di rete e l’altro a livello applicativo. ZigBee completa dunque i servizi per la sicurezza
forniti dall’altro protocollo, in particolare per ciò che riguarda la gestione delle chiavi. Esistono
tre tipi di chiave:
• master, che sono pre-installate in ogni nodo e servono a rendere sicuro lo scambio della
chiave che viene poi usata nella comunicazione;
• link, cioè le chiavi usate per la comunicazione tra due nodi e sono uniche per ogni coppia
di nodi;
• network, che è una chiave comune a tutti gli appartenenti a una rete e necessaria per
parteciparvi; questa chiave deve essere generata da un nodo che funge da coordinatore o
che, eventualmente, ha solo la funzione di generare/rigenerare queste chiavi, distribuirle
all’interno della rete e autenticare i nodi che vogliono aggiungersi alla rete.
Informazioni più dettagliate riguardanti la sicurezza nei protocolli 802.15.4 e ZigBee sono
disponibili in una pagina internet presente nei riferimenti [SICT17].
68
8
8
WEBGIS
WebGIS
Si è deciso di inserire quest’ultima sezione del documento per ragioni di completezza: l’ambito
WebGIS è soprattutto di competenza dell’azione 5 del progetto PTA, ma si ritiene comunque
utile presentare in questo documento le risposte dei partner sull’argomento, raccolte sempre
tramite i questionari, cosı̀ da fornire al lettore interessato tutte le informazioni raccolte tra i
partner attraverso l’utilizzo dei questionari.
8.1
In tabella 7 sono riportate le risposte alle varie domande poste con lo scopo di ottenere informazioni riguardanti l’ambito dei servizi WebGIS che verranno prodotti per il progetto PTA ed
erogati sfruttando la piattaforma tecnologica virtualizzata.
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
1-2. Il servizio prevede il bilanciamento del carico sul frontend?
No
Sı̀, HTTP
Sı̀
No
N.D.
3-4. Il servizio prevede il bilanciamento del carico sul backend?
Sı̀, viene utilizzato il Cluster di ArcGISServer
No
Sı̀
No
N.D.
5-6. Il servizio prevede SLA (Service Level Agreement)?
No
Sı̀. NB: WebGIS per PTA
non
prevede
SLA. (Web)GIS
“Regione Piemonte” prevede
SLA.
No
Sı̀, garanzia dei
servizi e gruppo
di continuità.
N.D.
7. Il servizio prevede l’autenticazione tra le componenti software?
Sı̀
No
No
No
N.D.
No
N.D.
N.D.
N.D.
8. Il servizio prevede l’autenticazione dell’utente finale?
No
No
No
9. Quali tipologie di servizi si prevede l’erogazione?
Mappe navigabili in modalità
WMS
N.D.
Servizi mappe
navigabili
69
8
WEBGIS
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
10. Quale RDBMS (Relational DataBase Management System) è previsto per i servizi GIS?
Oracle
PostGIS
Oracle
Oracle
DB2 distribuito
(prevista migrazione su Oracle)
11. Quale linguaggio si prevede di utilizzare per applicativi GIS?
J2EE
J2EE, PHP /
Perl / Python,
.NET
.NET,
JavaScript, API per
browser
J2EE
JavaScript (prevista migrazione su tecnologia
Flex)
12-13. Sono previsti vincoli tra software applicativo e sistema operativo?
No
No
No
Sı̀ (in fase di
valutazione)
N.D.
14-15. Sono previsti vincoli tra software applicativo e architettura hardware?
No
No
No
No
N.D.
16-17. Sono previsti vincoli tra dispositivi esterni collegati fisicamente ai sistemi di calcolo?
No
No
No
No
No (allo stato
attuale)
18-19. Sono previsti vincoli sulla latenza e sui tempi di risposta dell’applicativo ospitato
dalla PTV?
No
No
No
No
N.D.
20. È necessario prevedere una “live migration” di uno o più servizi nell’ambito della stessa
istanza di PTV?
No
No
No
No
N.D.
21-22. È possibile stimare il numero di connessioni contemporanee e della larghezza di
banda richiesta?
No
No
No
No
N.D.
23-24. I servizi erogati dalla PTA utilizzeranno webservices di altri partner?
Sı̀,
servizi
WMS esposti in
HTTP
Sı̀, WMS e CSW
Sı̀, Servizi mappa WMS (Web
Map Service),
WFS (Web Feature Service) e
di catalogo
No
Sı̀ (da definire)
70
8
WEBGIS
Lombardia
Piemonte
Valle d’Aosta
Bolzano
Ticino
25-26. I servizi erogati dalla PTA utilizzeranno webservices di soggetti esterni?
No
Sı̀, Google Maps
Sı̀, OpenStreetMap e altri in
corso di definizione
No
Sı̀ (da definire)
27. Quanto spazio di memoria risulterebbe necessario per applicazioni WebGIS all’interno
del progetto PTA?
200 MB
1 GB
In corso di definizione
25 GB
N.D.
Tabella 7: Risposte al questionario, sezione WebGIS
Visto che una parte delle risposte fornite sono già state discusse in sezioni precedenti di questo documento e altre forniscono informazioni su dettagli tecnici, di seguito saranno evidenziati
solamente i fatti ritenuti maggiormente interessanti.
Innanzitutto è interessante notare una certa disomogeneità 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. Ciò 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 modalità 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 è 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 sarà ospitato
sulla piattaforma tecnologica virtualizzata.
71
RIFERIMENTI
Riferimenti
Hardware
[HW1] Decisione 6 Ottobre 2009, n. 750, Decisione della commissione sulla definizione del servizio europeo di telepedaggio e dei relativi elementi tecnici. Commissione delle comunità
europee.
[HW2] Electronic fee collection - compliance check communication for autonomous systems.
[HW3] Decisione 6 Giugno 2011, n. 330, Decisione della commissione che stabilisce i criteri
ecologici per l’assegnazione del marchio di qualità ecologica dell’Unione europea (Ecolabel
UE) ai computer portatili. Commissione europea.
[HW4] Decisione 9 Giugno 2011, n. 337, Decisione della commissione che stabilisce i criteri
ecologici per l’assegnazione del marchio di qualità ecologica dell’Unione europea (Ecolabel
UE) ai personal computer. Commissione europea.
[HW5] Decisione 16 Giugno 2009, n. 489, Decisione della commissione che definisce la posizione
della Comunità riguardo a una decisione degli enti di gestione in applicazione dell’accordo tra il governo degli Stati Uniti d’America e la Comunità europea per il coordinamento
dei programmi di etichettatura in materia di efficienza energetica delle apparecchiature per ufficio, concernente la revisione delle specifiche applicabili ai computer di cui
all’allegato C, parte VIII, dell’accordo. Commissione europea.
[HW6] Legge federale 1 Gennaio 2011, n. 741.01, Legge federale sulla circolazione stradale.
Assemblea federale della Confederazione Svizzera.
[HW7] Electromagnetic compatibility and radio spectrum matters (erm); road transport and
traffic telematics (rttt); part 1: Technical characteristics and test methods for high data
rate (hdr) data transmission equipment operating in the 5,8 ghz industrial, scientific
and medical (ism) band.
[HW8] Road transport and traffic telematics - esafety - ecall minimum set of data (msd).
Telecomunicazioni
[TLC1] Standard IEEE 802.15.4:
http://standards.ieee.org/getieee802/download/802.15.4d-2009.pdf.
[TLC2] Sito internet ZigBee Alliance: http://www.zigbee.org/home.aspx.
[TLC3] 802.15.4 vs. ZigBee: http://www.sensor-networks.org/index.php?page=0823123150.
I
RIFERIMENTI
Software e dati
[SW1] Sito internet Red Hat Enterprise Linux:
http://www.it.redhat.com/products/rhel.
[SW2] Sito internet Oracle Database:
http://www.oracle.com/it/products/database/index.html.
[SW3] Sito internet ESRI ArcGIS:
http://www.esriitalia.it/index.php?option=com content
&view=article&id=101&itemid=122&lang=it.
[SW4] Sito internet PostGIS: http://postgis.refractions.net/.
[SW5] Sito internet PostgreSQL: http://www.postgresql.org/.
[SW6] Sito internet VMware: http://www.vmware.com/it/.
[SW7] Sito internet Xen: http://www.xen.org/.
[SW8] Sito internet HyperV:
http://www.microsoft.com/hyper-v-server/en/us/default.aspx.
[SW9] Web Map Service: http://www.opengeospatial.org/standards/wms.
[SW10] Web Coverage Service: http://www.opengeospatial.org/standards/wcs.
[SW11] Open Geospatial Consortium: http://www.opengeospatial.org.
[SW12] Perché “software libero” è meglio di “open source”:
http://www.gnu.org/philosophy/free-software-for-freedom.it.html.
[SW13] Sito internet Free Software Foundation: http://www.fsf.org/.
[SW14] Sito internet Open Source Initiative: http://www.opensource.org/.
[SW15] GNU General Public License: http://www.gnu.org/licenses/gpl.html.
[SW16] GNU lesser General Public License: http://www.gnu.org/licenses/lgpl.html.
[SW17] Sito internet Proxmox VE:
http://www.proxmox.com/products/proxmox-ve.
[SW18] Sito internet Solaris:
http://www.oracle.com/us/products/servers-storage/solaris/index.html.
[SW19] Sito internet ISO 32000:
http://www.iso.org/iso/catalogue detail.htm?csnumber=51502.
[SW20] Sito internet Google Apps for Business:
http://www.google.com/apps/intl/it/business/docs.html.
[SW21] Sito internet Java Enterprise Edition:
http://www.oracle.com/technetwork/java/javaee/overview/index.html.
II
RIFERIMENTI
[SW22] Sito internet Microsoft IIS: http://www.iis.net/.
[SW23] Sito internet Apache Tomcat: http://tomcat.apache.org/.
[SW24] Sito internet JBoss: http://www.jboss.org/.
[SW25] Sito internet BEA in Oracle:
http://www.oracle.com/us/corporate/acquisitions/bea/index.html.
[SW26] ArcGIS e interoperabilità:
http://www.esriitalia.it/index.php?option=com content
&view=article&id=151&itemid=117&lang=it.
[SW27] Lista software GIS: http://www.opengeospatial.org/resource/products.
[SW28] Sito internet Open Source Geospatial Foundation: http://www.osgeo.org/.
[SW29] Sito internet INSPIRE: http://inspire.jrc.ec.europa.eu/.
[SW30] M. O. Farooq and T. Kunz. Operating systems for wireless sensor networks: A survey.
Sensors, 11(6):5900–5930, 2011.
[SW31] DGR 30 Novembre 2010, n. 36-1109, Approvazione “Linee Guida relative al riutilizzo e
all’interscambio del Patrimonio Informativo Regionale”. Revoca della D.G.R. 29 giugno
2009, n. 31-11679. Giunta regionale, regione Piemonte.
Sicurezza ICT
[SICT1] D.Lgs. 30 Giugno 2003, n. 196, Codice in materia di protezione dei dati personali.
Presidente della Repubblica, Stato italiano.
[SICT2] Sito internet NIST: http://www.nist.gov/index.html.
[SICT3] Sito internet pubblicazioni FIPS: http://www.itl.nist.gov/fipspubs.
[SICT4] Data Encryption Standard (DES):
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf.
[SICT5] Advanced Encryption Standard (AES):
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
[SICT6] Brevetto Diffie-Hellman: http://www.google.com/patents?vid=4200770.
[SICT7] Sito internet RSA: http://www.rsa.com/.
[SICT8] Digital signature standard DSS:
http://csrc.nist.gov/publications/fips/fips186-3/fips 186-3.pdf.
[SICT9] Sito internet NSA: http://www.nsa.gov/.
[SICT10] NSA Suite B Cryptography:
http://www.nsa.gov/ia/programs/suiteb cryptography/index.shtml.
III
RIFERIMENTI
[SICT11] RSA Key Size:
http://www.rsa.com/rsalabs/node.asp?id=2004.
[SICT12] Sito internet OpenSSL: http://www.openssl.org/.
[SICT13] MD5: http://tools.ietf.org/html/rfc1321.
[SICT14] Secure Hash Standard:
http://csrc.nist.gov/publications/fips/fips180-3/fips180-3 final.pdf.
[SICT15] PPTP: http://tools.ietf.org/html/rfc2637.
[SICT16] IPSEC: http://datatracker.ietf.org/wg/ipsec/.
[SICT17] Security in 802.15.4 and ZigBee networks:
http://www.sensor-networks.org/index.php?page=0903503549.
IV

- Piattaforma Tecnologica Alpina

Transcript

Documenti analoghi

Predittori indipendenti di fallimento sino a 7.5 anni dopo 35 386

BOOSTER D`ANTENNA Dati Tecnici – AB 3

Radio Manà Manà anche sugli 89,100 MHz

Aaron Iemma – Curriculum Vitae - MUSE

Generatore di funzioni 2 MHz

Prepagati Automatici Alitalia Guida Rapida

Corso “Quantum GIS” - livello avanzato

è consistente e diversific:uo: pulizi:i dell:i sede, ri<..

R-Drive Image

lo spazio virtuale