Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Sistemi Scada
Sistemi Scada
Autori:
Stefano Bimbo, Enrico Colaiacovo
APOGEO srl
Socio Unico Giangiacomo Feltrinelli Editore srl
Via Natale Battaglia 12 – 20127 Milano (Italy)
Telefono: 02-289981 – Telefax: 02-26116334
Email ebook@apogeonline.com
U.R.L. http://www.apogeonline.com/libri/88-503-1042-0/scheda
ISBN 88-503-1042-0
Stefano Bimbo
Enrico Colaiacovo
Roma, novembre 2005
Premessa
i
ii
Indice
I Generalità 3
1 Cos’è un sistema SCADA 5
1.1 Gestione di un depuratore di liquami e acque reflue . . . . . . 6
1.2 Gestione del traffico ferroviario . . . . . . . . . . . . . . . . . 10
1.3 Telerilevamento ambientale terrestre . . . . . . . . . . . . . . 14
2 SCADA: definizioni 17
2.1 Acquisizione dati . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Supervisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Controllo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 SCADA vs DCS . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Il processo controllato 21
3.1 Realtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Alta affidabilità . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Alta disponibilità . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Grado d’interazione uomo-macchina . . . . . . . . . . . . . . . 24
3.5 Sistemi di dimensioni geografiche . . . . . . . . . . . . . . . . 25
II Architettura 27
4 Introduzione 29
iii
5.4 Evoluzione degli apparati di acquisizione dati . . . . . . . . . 44
7 Sistema di elaborazione 55
7.1 Gestione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Processi di elaborazione . . . . . . . . . . . . . . . . . . . . . 58
7.3 Condivisione dell’informazione . . . . . . . . . . . . . . . . . . 59
8 Elaborazione dati 63
8.1 Trattamento dati . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.1 Tipi di dati . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.2 Database runtime . . . . . . . . . . . . . . . . . . . . . 65
8.1.3 Configurazione dei dati trattati . . . . . . . . . . . . . 67
8.2 Elaborazione comandi . . . . . . . . . . . . . . . . . . . . . . 72
8.2.1 Un buon motivo per realizzare azioni automatiche . . . 73
8.2.2 Motivi che impongono l’uso di azioni automatiche . . . 75
8.2.3 Caratteristiche delle azioni automatiche . . . . . . . . . 76
8.2.4 Algoritmi e procedure . . . . . . . . . . . . . . . . . . 80
8.3 Calcoli in linea . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.3.1 Informazioni di tipo aggregato . . . . . . . . . . . . . . 82
8.3.2 Informazioni logiche . . . . . . . . . . . . . . . . . . . 83
8.3.3 Informazioni statistiche . . . . . . . . . . . . . . . . . . 83
9 Interfaccia uomo-macchina 85
9.1 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.2 Funzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.2.1 Presentazione dei dati . . . . . . . . . . . . . . . . . . 87
9.2.2 Gestione dei comandi operatore . . . . . . . . . . . . . 92
9.3 Evoluzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
iv
10 Eventi e allarmi 97
10.1 Differenza tra eventi e allarmi . . . . . . . . . . . . . . . . . . 97
10.2 Trattamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.2.1 Categorie . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.2.2 Priorità . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.2.3 Disabilitazione dinamica . . . . . . . . . . . . . . . . . 101
10.2.4 Permessi operatore . . . . . . . . . . . . . . . . . . . . 102
10.3 Evoluzione dei sistemi di avviso . . . . . . . . . . . . . . . . . 103
11 Archiviazione 105
11.1 Perché archiviare i dati . . . . . . . . . . . . . . . . . . . . . . 105
11.1.1 Studio del processo . . . . . . . . . . . . . . . . . . . . 105
11.1.2 Documentazione storica . . . . . . . . . . . . . . . . . 106
11.1.3 Interesse statistico o contabile . . . . . . . . . . . . . . 107
11.2 Metodi e tecnologie . . . . . . . . . . . . . . . . . . . . . . . . 108
11.2.1 Organizzazione e modalità di archiviazione . . . . . . . 108
11.2.2 Strumenti . . . . . . . . . . . . . . . . . . . . . . . . . 110
IV Conclusioni 125
14 Strumenti e competenze 127
14.1 Definizione dei requisiti . . . . . . . . . . . . . . . . . . . . . . 128
14.1.1 Definizione dei punti da sottoporre a controllo . . . . . 129
14.1.2 Definizione funzionale . . . . . . . . . . . . . . . . . . 130
14.1.3 Definizione delle modalità di trasmissione dati . . . . . 130
14.1.4 Definizione delle informazioni da archiviare . . . . . . . 131
14.1.5 Definizione delle criticità . . . . . . . . . . . . . . . . . 132
14.1.6 Definizione dell’interoperabilità con sistemi esterni . . . 132
14.2 Fase di definizione dell’architettura . . . . . . . . . . . . . . . 133
14.3 Fase di verifica . . . . . . . . . . . . . . . . . . . . . . . . . . 136
v
14.4 Fase di installazione . . . . . . . . . . . . . . . . . . . . . . . . 139
14.5 Fase di messa in servizio . . . . . . . . . . . . . . . . . . . . . 141
14.6 Fase di esercizio e manutenzione . . . . . . . . . . . . . . . . . 143
Glossario 154
Bibliografia 156
V Appendici 157
A GNU Free Documentation License 159
1. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . 160
2. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . 161
3. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . 162
4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . 162
5. COMBINING DOCUMENTS . . . . . . . . . . . . . . . . . . . 165
6. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . 165
7. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . 165
8. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
10. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . 166
ADDENDUM: How to use this License for your documents . . . . . 167
1
2
Parte I
Generalità
3
Capitolo 1
5
CAPITOLO 1. COS’È UN SISTEMA SCADA
6
CAPITOLO 1. COS’È UN SISTEMA SCADA
7
CAPITOLO 1. COS’È UN SISTEMA SCADA
8
CAPITOLO 1. COS’È UN SISTEMA SCADA
per la parte relativa agli impianti periferici gli apparati utilizzati all’interno
del depuratore possono essere dotati di logiche di automazione che governa-
no la gestione dei singoli organi. Diversamente dagli apparati di acquisizione
già visti, gli apparati presenti nel depuratore solitamente comunicano con
continuità con il centro di controllo. Questo è dovuto principalmente a:
9
CAPITOLO 1. COS’È UN SISTEMA SCADA
10
CAPITOLO 1. COS’È UN SISTEMA SCADA
11
CAPITOLO 1. COS’È UN SISTEMA SCADA
Quadro sinottico
Banco di controllo
12
CAPITOLO 1. COS’È UN SISTEMA SCADA
Gli stadi di sviluppo dei reali sistemi di gestione del traffico ferroviario
sono stati caratterizzati dall’introduzione di meccanismi automatici per la
gestione delle barriere dei passaggi a livello adiacenti agli scali, la segnala-
zione agli scali adiacenti della posizione dei convogli e dell’entità di eventuali
ritardi, la configurazione automatica della topologia attiva in funzione del-
l’orario di esercizio. La complessità degli attuali sistemi dipende dall’insieme
di funzioni che essi possono svolgere mentre la struttura che li caratterizza è
in gran parte simile a quella dei primi prototipi realizzati.
13
CAPITOLO 1. COS’È UN SISTEMA SCADA
14
CAPITOLO 1. COS’È UN SISTEMA SCADA
Centro di elaborazione
15
CAPITOLO 1. COS’È UN SISTEMA SCADA
16
Capitolo 2
SCADA: definizioni
17
CAPITOLO 2. SCADA: DEFINIZIONI
18
CAPITOLO 2. SCADA: DEFINIZIONI
2.2 Supervisione
La supervisione è la funzione per mezzo della quale un sistema SCADA rende
possibile l’osservazione dello stato e dell’evoluzione degli stati di un processo
controllato. A questa funzione appartengono tutte le funzionalità di visualiz-
zazione delle informazioni relative allo stato attuale del processo, di gestione
delle informazioni storiche, di gestione degli stati che costituiscono eccezioni
rispetto alla normale evoluzione del processo controllato. La funzione di su-
pervisione costituisce un fine per qualsiasi sistema SCADA. Questa funzione
è determinante nella caratterizzazione di un sistema nel senso che un sistema
che non permetta di accedere alle informazioni di stato corrente e/o storiche
del processo osservato e/o controllato non può essere definito come sistema
SCADA.
2.3 Controllo
La funzione di controllo rappresenta la capacità di un sistema di prendere de-
cisioni relative all’evoluzione dello stato del processo controllato in funzione
dell’evoluzione del processo medesimo. La modalità con la quale le proce-
dure di controllo vengono realizzate nell’ambito dell’intera architettura del
sistema dipende fortemente dal tipo di processo, essendo questo in grado im-
porre scelte architetturali sia hardware che software. In questo senso i sistemi
SCADA sono comunemente intesi come sistemi che hanno nella funzione di
acquisizione dati l’intera catena di acquisizione che dai sensori al sistema
di elaborazione e archiviazione veicola informazioni che sono i dati grezzi
prelevati come valori di parametri di stato del processo. Le funzionalità di
controllo sono quindi concentrate nel sistema di elaborazione il quale, una
volta eseguite opportune procedure di elaborazione, sfrutta il sistema di ac-
quisizione dati in senso inverso per cambiare il valore di opportuni parametri
di stato del processo controllato.
19
CAPITOLO 2. SCADA: DEFINIZIONI
20
Capitolo 3
Il processo controllato
21
CAPITOLO 3. IL PROCESSO CONTROLLATO
3.1 Realtime
Il termine realtime si riferisce alla capacità del sistema di reagire alle solleci-
tazioni del processo con ritardi trascurabili rispetto alla dinamica evolutiva
del processo medesimo. Allo stesso tempo la reazione del sistema deve essere
caratterizzata da tempi di elaborazione compatibili con quelli imposti dagli
obiettivi del controllo. Le funzioni svolte da un sistema di controllo sono tali
da rendere questa capacità di reazione un requisito solitamente irrinunciabile
mentre altri elementi di complessità del sistema e del processo controllato
sono in contrasto con questo requisito.
Le soluzioni possono contemplare il contenimento dei tempi di reazione
per insiemi ridotti di eventi generati dal processo, il sacrificio di funzioni
complesse a favore di soluzioni semplici, l’adozione, quando possibile, di so-
luzioni tecnologiche dedicate (realizzazioni ad hoc) e altri accorgimenti che,
come questi, acquisiscono un significato soltanto all’interno del contesto di
sviluppo del singolo sistema.
Un primo elemento in contrasto con la caratteristica di un sistema di ope-
rare in tempo reale risiede nei limiti imposti dalla tecnologia. L’evoluzione
dei sistemi di calcolo è tale da rendere realistico il desiderio di realizzare un
sistema realtime ma l’idea che questa sia sufficiente a esaudire un desiderio
di questo tipo è quantomeno ardita. Molti processi hanno una dinamica che
non potrà mai essere superata da quella di un sistema di controllo a meno
di una rivoluzione tecnologica (oltre la quale tutte le considerazioni fatte in
questo testo sarebbero, o saranno, obsolete) e continueranno a essere “go-
vernati” più che “controllati”. Limiti tecnologici risiedono, oltre che nella
capacità dei sistemi di calcolo, nelle caratteristiche dei sistemi di comuni-
cazione a disposizione dei sistemi di controllo. Questi intervengono quando
le dimensioni del processo sono tali da rendere necessario l’allestimento di
sistemi di comunicazione complessi e di grandi dimensioni (reti geografiche).
L’uso delle migliori tecnologie, del presente e del futuro, non sarà mai in
grado di rendere nulli i tempi di trasferimento dell’informazione, tempi che
hanno effetti sui ritardi di reazione dell’intero sistema.
Ai limiti imposti dalla tecnologia si aggiungono elementi di complessità
introdotti dalle sovrastrutture necessarie a un corretto esercizio del sistema.
Tra i molti sono significativi i casi dell’affidabilità e della disponibilità per
l’importanza che questi rivestono nel giudizio di qualità di un sistema di
controllo. La capacità di operare correttamente con continuità può essere
assicurata per mezzo di processi di elaborazione che in molti casi si sovrap-
pongono a quelli di acquisizione e controllo inficiandone le caratteristiche
22
CAPITOLO 3. IL PROCESSO CONTROLLATO
dinamiche.
23
CAPITOLO 3. IL PROCESSO CONTROLLATO
24
CAPITOLO 3. IL PROCESSO CONTROLLATO
25
CAPITOLO 3. IL PROCESSO CONTROLLATO
26
Parte II
Architettura
27
Capitolo 4
Introduzione
29
CAPITOLO 4. INTRODUZIONE
Sistema di elaborazione
Strutture di acquisizione
30
Capitolo 5
5.1 Funzionamento
L’apparato di acquisizione dati costituisce il mezzo attraverso il quale il si-
stema SCADA è in grado di comunicare con il mondo circostante. Esso ha
il compito di tradurre le informazioni prese dalla vita reale in informazioni
gestibili da un sistema SCADA e viceversa.
Quando nasce la necessità di scambiare informazioni tra due attori è
necessario stabilire un comune linguaggio di comunicazione che permetta lo
scambio. In riferimento all’uomo il primo pensiero cade sulla comunicazione
orale o, meglio, sulla lingua parlata, anche se questo non è l’unico strumento
di comunicazione. Si pensi infatti alle difficoltà che ognuno di noi incontra
nel comunicare le cose più semplici a una persona che non parli la nostra
stessa lingua: in questi casi ci vengono in soccorso linguaggi non orali molto
efficaci quali, ad esempio, la mimica.
Qualunque sia il metodo utilizzato esso si basa su precise regole per le
quali un dato suono, gesto, movimento indica una stessa cosa per entrambe
le parti. Alla base della comunicazione c’è sempre la definizione della moda-
lità di scambio delle informazioni e la codifica delle stesse in modo da poter
comprendere il significato delle informazioni scambiate. Alcune volte è pos-
sibile che gli attori della comunicazione non siano in grado di utilizzare un
linguaggio comune. In questi casi è necessario ricorrere all’utilizzo di un tra-
duttore (cosı̀ come avviene tra persone che parlano lingue diverse). Il ruolo
del traduttore è estremamente delicato in quanto deve essere svolto in modo
31
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
32
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
33
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
34
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
35
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
36
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
37
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
38
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
In alcuni casi l’interazione del sistema SCADA con il mondo esterno non av-
viene per mezzo di semplici informazioni quali quelle descritte in precedenza.
Può accadere che il sistema SCADA si debba interfacciare con dispositivi
complessi per ottenere informazioni. Esistono contatori di energia elettrica
che mettono a disposizione una serie molto ampia di informazioni (tensioni,
correnti, potenze, cosfi istantanei, valori medi degli stessi nell’ultimo quarto
d’ora e nelle ultime ventiquattro ore, valori massimi, ecc.). Gestire que-
sta serie di informazioni con un equivalente numero di uscite analogiche dal
contatore è tecnicamente sconveniente e, quindi, i costruttori hanno previ-
sto un’interfaccia al contatore che sia in grado di stabilire un colloquio con
un dispositivo esterno attraverso un protocollo di comunicazione (spesso per
questi dispositivi si trovano disponibili protocolli di tipo ModBus, LonWorks,
CANbus, ecc.). In questi casi, benché le informazioni acquisite siano rappre-
sentabili come informazioni semplici di tipo digitale o analogico, la modalità
di acquisizione non è riconducibile a una tra quelle descritte. In questo caso
l’apparato di acquisizione ha a disposizione una porta di comunicazione evo-
luta che lo mette in condizioni di stabilire una comunicazione autonoma con
il dispositivo di campo e acquisire le informazioni desiderate.
39
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
40
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
Spesso un’uscita viene utilizzata per comandare un relè che poi, attraverso un
suo contatto, sarà utilizzato nel circuito di comando vero e proprio. Questo
passaggio è utilizzato per disaccoppiare elettricamente il circuito dell’appa-
rato di acquisizione dati dal circuito di comando in modo che un problema
tecnico su un apparato non pregiudichi allo stesso tempo le due funzioni.
Per un corretto dimensionamento del circuito elettrico, sia nel caso di relè
41
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
misure in tensione
(±10mV, ±250mV, ±500mV, ±1V, ±2,5V, ±5V, 1...5V, ±10V)
misure in corrente
(±10mA, ±3,2mA, ±20mA, 0...20mA, 4...20mA)
misure di resistenze
(150Ω, 300Ω, 600Ω)
misure da termocoppie
(tipo B, E, N, J, K, L, N, R, S, T, U)
misure da termoresistenze
(Pt100, Pt200, Pt500, Pt1000, Ni100, Ni120, Ni200, Ni500, Ni1000,
Cu10)
42
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
43
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
44
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
45
CAPITOLO 5. APPARATI DI ACQUISIZIONE DATI
46
Capitolo 6
Protocolli e tecnologie di
comunicazione
47
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
possibile dare una descrizione e suggerire elementi di analisi utili nel momento
in cui deve essere presa una decisione definitiva.
Le sezioni che seguono hanno l’obiettivo di suggerire elementi di analisi
per la scelta di infrastrutture di comunicazione adeguate alle caratteristiche
del sistema in sviluppo. L’approfondimento di temi legati alle comunicazioni
può essere affrontato consultando testi specifici (rif. [12], [11])
6.1 Velocità
La velocità di scambio dati è un elemento che può essere oggetto di ana-
lisi per ragioni di necessità o di opportunità. Analizzando lo scambio dati
tra apparecchiature di acquisizione e sottosistemi di controllo è necessario
tenere in considerazione le caratteristiche dinamiche del processo controlla-
to in modo da provvedere alla realizzazione di un canale di comunicazione
sufficientemente veloce da permettere che l’intero processo di acquisizione,
trasmissione, elaborazione, trasmissione, attuazione avvenga in tempi tali
da rendere efficaci le azioni di controllo. In questi casi i vincoli imposti
dal processo controllato possono essere stringenti al punto da impedire che
l’azione di controllo si realizzi in funzione delle elaborazioni realizzate dal
sistema “centrale”, costringendo alla realizzazione di sistemi a intelligenza
distribuita. Sistemi di gestione della distribuzione dell’energia o di gestione
di strutture di trasporto di gas sono esempi di sistemi che necessitano di ca-
nali di comunicazione ad alta velocità e che spesso richiedono la realizzazione
di strutture periferiche in grado di attuare politiche di controllo autonome
ripetto al centro di controllo. Sono evidentemente casi nei quali la tecnologia
non supporta servizi di comunicazione adeguati alle velocità necessarie alla
realizzazione del controllo.
Sistemi di notevoli dimensioni geografiche risentono maggiormente dei
limiti di velocità imposti dalle tecnologie disponibili anche perché non per-
mettono, in genere, di realizzare un’infrastruttura dedicata obbligando allo
sfruttamento di strutture commerciali rese disponibili dai gestori telefonici i
quali, per ovvie ragioni commerciali, offrono servizi di tipo general purpose
non sempre adeguati. Anche nei casi in cui i gestori di sistemi di trasporto
dell’informazione erogano servizi adeguati alle esigenze questi possono rive-
larsi proibitivi in termini di costi di gestione costringendo all’adozione di
architetture a intelligenza distribuita. Processi di dimensioni tali da consen-
tire la realizzazione di infrastrutture di comunicazione dedicate conducono, di
solito, a una maggiore libertà di scelta consentendo lo sviluppo di un’analisi
non vincolata alla velocità dei canali di comunicazione.
48
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
6.2 Sicurezza
La sicurezza è una caratteristica dei sistemi di comunicazione che diventa
rilevante quando questi possono trovarsi a essere esposti a intrusioni indesi-
derate e potenzialmente pericolose, anche nel caso in cui queste non dovessero
essere effetto di comportamenti deprecabili (cfr. sezione 13). La sicurezza
del sistema di comunicazione deve rispondere, cioè, a esigenze che non di-
pendono solo dalla “cattiva fede” ma anche dalla probabilità di errore che
caratterizza qualsiasi comportamento umano. Anche se il sistema sicuro è
soltanto il sistema “chiuso” è possibile prendere provvedimenti per limitare il
rischio di malfunzionamenti delle comunicazioni causati da imperizia o dolo.
La gestione della sicurezza deve essere considerata adeguatamente sia dal
punto di vista delle comunicazioni tra sistema e apparati periferici, le quali
veicolano le informazioni di stato del processo controllato e, con esse, le azioni
di comando impartite dal sistema, che dal punto di vista dell’interazione tra
49
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
50
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
6.4 Affidabilità
La trasmissione dei dati è un processo caratterizzato da fenomeni che pos-
sono pregiudicare l’integrità dell’informazione trasportata comportando un
reale rischio di valutazione errata dello stato di esercizio del processo control-
lato. In un sistema di controllo destinato a gestire processi caratterizzati da
tempi di evoluzione molto bassi è impensabile procedere a una validazione
dei dati ricevuti (sia dal centro di elaborazione in fase di supervisione che
dalle apparecchiature periferiche in sede di attuazione del controllo). Algo-
ritmi di validazione efficaci possono essere approntati per la valutazione della
qualità dell’insieme di dati raccolti nel caso di sistemi di supervisione privi
di meccanismi di controllo, sistemi per i quali i tempi di elaborazione sono
legati, di solito, all’intervento diretto degli addetti alla supervisione. Nella
maggioranza dei casi, quindi, l’integrità dei dati deve essere considerata un
elemento caratteristico dei meccanismi di trasmissione.
Architetture tecnologiche e protocollari diverse sono dotate di algoritmi di
controllo per l’individuazione di errori causati dalle infrastrutture di traspor-
to tra loro molto diversi. Allo stesso modo molto diversi sono i provvedimenti
che i servizi di comunicazione sono in grado di prendere per colmare la la-
cuna introdotta nel flusso informativo da eventuali errori di trasmissione.
Tali differenze però influenzano attributi non meno importanti del sistema
di comunicazione tra i quali senza dubbio il più sensibile è la velocità di tra-
smissione. La certezza di ricevere un flusso di dati privo di errori comporta,
infatti, l’introduzione di meccanismi di controllo della presenza di errori, di
richiesta di ritrasmissione dell’informazione errata all’entità trasmittente, di
gestione dell’ordinamento delle unità informative all’interno del flusso.
I due estremi tra le molte soluzioni possibili al problema dell’integrità
del flusso informativo sono quelli che realizzano la trasmissione senza alcun
controllo, lasciando al fruitore del servizio la responsabilità di intercettare
gli errori e di scegliere i provvedimenti da adottare, e quelli che garantisco-
no l’integrità del flusso come elemento caratteristico della trasmissione dati.
Come spesso accade la grande libertà di scelta si traduce in una maggiore
efficacia del sistema se la soluzione adottata è frutto di una corretta anali-
51
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
6.5 Disponibilità
Nella realizzazione di un sistema di supervisione e controllo è sempre impor-
tante valutare correttamente gli effetti causati da disservizi nel trasferimento
dell’informazione, cioè da eventuali interruzioni del servizio di trasmissione
dati. In generale un sistema di supervisione è caratterizzato da un legame
diretto tra continuità del servizio di trasmissione tra sistema e apparati di
acquisizione dati e continuità dell’attività di controllo. Lo stesso legame non
52
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
53
CAPITOLO 6. PROTOCOLLI E TECNOLOGIE DI COMUNICAZIONE
6.6 Intelligibilità
L’itelligibilità dell’informazione è un elemento fondamentale per la realizza-
zione di un sistema dotato di potenziale evolutivo per le funzioni che realizza
e di efficienza nell’interazione con sistemi esterni. Le soluzioni che posso-
no essere adottate sono molte ma soltanto in numero limitato sono quelle
che permettono di utilizzare interfacce di comunicazione condivise. In que-
sto senso è fondamentale analizzare attentamente le soluzioni proposte dai
produttori di dispositivi e software utilizzati nello sviluppo del sistema di
controllo.
Nella definizione delle interfacce è sempre buona norma fare riferimento
agli “standard” disponibili privilegiando quelli che hanno dimostrato di essere
soluzioni efficaci al problema delle comunicazioni. Le virgolette utilizzate per
il termine “standard” vogliono sottolineare l’importanza dell’uso di tecnolo-
gie frutto del processo di produzione di modelli di comunicazione condivisi
(sia esso condotto da istituti dedicati allo scopo o da altre entità) e, al tempo
stesso, un suggerimento a interpretare correttamente il termine. Nel mondo
della tecnologia si può considerare standard tutto ciò che viene convenzio-
nalmente uniformato a un modello di riferimento comune. Il modello è un
sistema di regole alle quali deve far riferimento una implementazione che vo-
glia definirsi aderente allo standard. È un fatto, quindi, che un’architettura a
elevata diffusione non deve essere considerata standard se per essa non esiste
un’adeguata definizione del modello che realizza e la libertà per i produttori
di infrastrutture di comunicazione di affrontare una propria realizzazione del-
la stessa. L’uso di prodotti non standard è una scelta che risulta vincolante
da un punto di vista sia funzionale che tecnologico. Entrambi gli aspetti sono
legati al fatto che un sistema di comunicazione proprietario impone l’uso di
dispositivi per i quali la scelta è limitata, di solito, ai soli dispositivi (tra
quelli funzionalmente adeguati agli scopi del sistema) in grado di utilizzare
l’interfaccia di comunicazione adottata, cosı̀ come accade per la realizzazione
o l’adeguamento di sistemi esterni destinati a comunicare con il sistema di
controllo.
Un altro elemento di riflessione sull’uso di architetture standardizzate
consiste nel fatto che tutto ciò che appartiene alla comunità scientifica e
tecnologica non dipende dal mercato, dalla fortuna di un’azienda, dall’abilità
di un manager. La condivisione dei modelli è garanzia di continuità prima
che di qualità e rappresenta un bene irrinunciabile per chiunque si trovi a
realizzare sistemi che abbiano aspettative di vita superiori alla vita media di
un prodotto tecnologico commerciale.
54
Capitolo 7
Sistema di elaborazione
Dalla figura emerge una visione del sistema quale struttura caratteriz-
zata da tre elementi fondamentali: gestione dati, elaborazione, disponibilità
dell’informazione. Per gestione dati si intende il complesso di funzioni desti-
nate allo scambio dati con le apparecchiature periferiche, al trattamento dei
dati per la generazione di un insieme di dati intelligibile per le funzioni di
elaborazione e di rappresentazione, all’archiviazione dei dati grezzi e dell’in-
formazione aggregata frutto delle elaborazioni. Per elaborazione si intende
tutto quanto responsabile della corretta interpretazione dei dati visti come
insieme rappresentativo dello stato di evoluzione del processo controllato e
dell’attuazione delle azioni di controllo. Il terzo elemento è la produzione
dell’informazione finalizzata alla fruizione da parte di sistemi esterni e dalle
strutture di interazione tra operatori e sistema.
55
CAPITOLO 7. SISTEMA DI ELABORAZIONE
Interfaccia
uomo−macchina
Base dati
relazionale
Interfaccia di Interfaccia di
comunicazione accesso ai dati
Infrastruttura per
la comunicazione
con sistemi
concorrenti
Archiviazione dati
Elaborazione
comandi operatore
Elaborazione
dati
Base dati
Elaborazione runtime
allarmi−eventi
Elaborazione
controlli automatici
Trattamento dati
Interfaccia
di comunicazione
con le apparecchiature
di acquisizione dati
56
CAPITOLO 7. SISTEMA DI ELABORAZIONE
Una gestione dei dati cosı̀ fatta esaurisce le esigenze che caratterizzano un
sistema SCADA per le funzionalità fondamentali di supervisione e controllo
ma non permettono di accumulare conoscenza riguardo l’evoluzione del pro-
cesso controllato. Per l’archiviazione dei dati acquisiti dalle apparecchiature
periferiche e dell’informazione generata dal sistema nello svolgimento delle
sue funzioni è necessario provvedere con un sistema di gestione dati che abbia
le caratteristiche di una base dati relazionale. Le proprietà che rendono la
base dati relazionale strumento privilegiato per la gestione delle informazioni
storiche di un sistema di controllo sono l’intelligibilità dell’informazione, la
disponibilità di strumenti di accesso di livello applicativo, l’abilità di gestire
grandi quantità di dati. Queste caratteristiche si accompagnano a tempi di
di accesso ai dati che non sono confrontabili con quelli caratteristici dei data-
base runtime ma l’analisi a posteriori di informazioni storiche non ha finalità
di controllo e non necessita di prestazioni particolari. L’uso di basi dati re-
lazionali introduce, cosı̀, elementi di accessibilità ai dati che consentono di
supportare l’ampliamento delle finalità per le quali l’informazione raccolta
dal sistema viene archiviata. La razionalità dell’organizzazione dei dati, la
semplicità dei processi di interrogazione della base dati, la completezza del-
l’informazione e la possibilità di associare quest’ultima a quella proveniente
da sistemi concorrenti consente di utilizzare i dati per ragioni tra loro mol-
to diverse quali l’analisi dell’evoluzione del processo controllato finalizzata
alla previsione, la contabilizzazione di grandezze gestite dal sistema legate
57
CAPITOLO 7. SISTEMA DI ELABORAZIONE
58
CAPITOLO 7. SISTEMA DI ELABORAZIONE
59
CAPITOLO 7. SISTEMA DI ELABORAZIONE
60
Parte III
Sistema di elaborazione
61
Capitolo 8
Elaborazione dati
63
CAPITOLO 8. ELABORAZIONE DATI
controllo.
Alla categoria dei dati discreti fanno capo le informazioni che possono
assumere solamente stati logici distinti. Tipico esempio è un ingresso digitale
ad 1 bit che può assumere solamente lo stato logico ON o lo stato logico OFF.
In alcuni casi è possibile avere anche dati discreti che possono assumere più
di due stati logici e in questo caso si possono avere informazioni a due, tre,
quattro, n bit. Si pensi ad esempio allo stato di un interruttore elettrico che,
essendo rappresentato da due finecorsa, uno di chiusura e uno di apertura,
può assumere i seguenti valori:
01 : il contatto del fine corsa di apertura aperto e quello del fine corsa di
chiusura chiuso indicano che l’interruttore è in posizione di chiusura
10 : il contatto del fine corsa di apertura chiuso e quello del fine corsa di
chiusura aperto indicano che l’interruttore è in posizione di apertura
00 : il contatto del fine corsa di apertura aperto e quello del fine corsa di
chiusura aperto indicano che l’interruttore è in posizione intermedia
(probabilmente si sta compiendo la manovra)
11 : il contatto del fine corsa di apertura chiuso e quello del fine corsa di
chiusura chiuso indicano che l’interruttore è in posizione incongruen-
te (probabilmente c’è un malfunzionamento nell’organo o nei contatti
ausiliari)
64
CAPITOLO 8. ELABORAZIONE DATI
Alla categoria dei dati analogici fanno capo le informazioni che si rife-
riscono ad un valore analogico e che normalmente sono rappresentate per
mezzo di un valore intero o reale. Ad esempio il valore di temperatura letto
da una termocoppia potrebbe essere convertito in informazione analogica che
indica un intervallo di misurazione da 0 a 200 gradi centigradi.
Alla categoria dei dati stringa fanno capo tutte le informazioni che posso-
no essere rappresentate come insieme di caratteri e che spesso corrispondono
a un messaggio da interpretare direttamente nella lingua degli operatori. Si
pensi ad esempio al caso in cui si debba comandare un pannello per segnalare
un’informazione ad un operatore di campo riguardo una particolare opera-
zione da svolgere. In qualche caso piuttosto che dire “esegui operazione: 13”
dove 13 indica il codice di un’operazione da svolgere, è preferibile un mes-
saggio del tipo “esegui operazione: apertura valvola di bypass”. In altri casi
l’apparato periferico è chiamato a gestire dati di tipo complesso che però non
è in grado di interpretare dovendo cosı̀ trasferirli al sistema di elaborazione
nella forma in cui li riceve.
65
CAPITOLO 8. ELABORAZIONE DATI
• il valore corrente
• il codice di qualità
66
CAPITOLO 8. ELABORAZIONE DATI
• acquisizione
• rilevamento allarmi
67
CAPITOLO 8. ELABORAZIONE DATI
del sistema o, come accade nei sistemi più moderni, essere contenuti in un
database relazionale. In generale per la gestione di un dato è necessario defi-
nire informazioni per ogni fase del suo trattamento. Questo è il tema trattato
nelle sezioni che seguono.
Processo di acquisizione
• canale di acquisizione
68
CAPITOLO 8. ELABORAZIONE DATI
fatta nel caso dei dati di tipo analogico tra dati il cui valore è rappresentato
tramite un valore intero e quelli rappresentati in virgola mobile.
Abbiamo visto nella sezione dedicata agli apparati di acquisizione dati che
ogni informazione gestita dal sistema subisce una serie di conversioni di valo-
re durante il suo tragitto dal campo al sistema centrale. Queste conversioni
sono necessarie per permettere agli apparati periferici di gestire contestual-
mente informazioni che rappresentano grandezze fisiche diverse e scale di
valori diverse, cioè indipendentemente dalla tipologia di informazione fisica.
Una volta che l’informazione arriva al centro deve subire il processo inver-
so per poter descrivere esattamente le caratteristiche della grandezza fisica
originaria. La conversione assume caratteristiche diverse se si tratta di con-
versione di misure o di segnali. Quanto di seguito descritto si riferisce alle
informazioni che viaggiano in direzione del centro, ma è valido, con le oppor-
tune considerazioni, anche per le informazioni che viaggiano dal centro verso
il campo.
Si consideri la conversione nel caso di trattamento di segnali. In questo
caso è noto che un segnale rappresenta per mezzo di stati logici un insieme di
stati fisici dell’organo (ad esempio motore in marcia o fermo). La conversione
che avviene al centro in questo caso è molto semplice e consiste nell’associare
ad ogni valore logico che arriva dall’apparato di acquisizione il corrispondente
stato fisico.
Nel caso di conversione per le misure il problema è più complesso. Le
informazioni acquisite da un apparato periferico vengono scambiate con il
centro per mezzo di unità di misura convenzionali che si definiscono unità
grezze. Un’unità grezza in realtà non è un’unità di misura ma un valore adi-
mensionale. Il valore grezzo rappresenta il valore assunto dal dato acquisito
all’interno dell’intervallo di variazione definito dall’apparato che lo acquisi-
sce. Ad esempio una misura analogica può essere rappresentata con un valore
intero espresso con cifra a due byte con segno; l’intervallo di variazione della
misura va cosı̀ dal valore -32768 al valore +32767.
È impensabile di proporre ad un operatore un valore di questo genere
in quanto non dà informazioni né sul tipo di misura, né sul valore assun-
to dalla misura. Si deve procedere in questo caso alla conversione in va-
lore ingegneristico. Per poter procedere a questa conversione è necessario
conoscere:
• l’unità ingegneristica
69
CAPITOLO 8. ELABORAZIONE DATI
• la funzione di conversione
70
CAPITOLO 8. ELABORAZIONE DATI
• allarme di deviazione
L’allarme per superamento limite viene generato nel momento in cui il va-
lore di una misura supera un certo valore di riferimento definito come limite.
Solitamente si definiscono due valori di limite superiore e due valori di limite
inferiore. Si costruisce in questo modo una banda di normale funzionamento
attorno al dato, una banda stretta di attenzione ed una banda ampia di peri-
colo. I dati necessari a generare questi allarmi sono semplicemente i quattro
valori limite che definiscono le due bande di osservazione.
L’allarme di deviazione può essere utilizzato quando una misura rappre-
senta una grandezza fisica che il processo deve tenere sotto controllo per
assicurare il rispetto costante di un valore predefinito. Si pensi ad esempio
ad una regolazione che debba mantenere la temperatura di un recipiente sta-
bilmente a 35 gradi centigradi. La misura della temperatura fornisce il valore
corrente della temperatura ma può essere comodo associare alla temperatura
un allarme che il sistema genera se il valore si allontana da quello impostato
di una certa quota percentuale. Questo allarme verrà generato sia per va-
riazioni che tendono ad innalzare la temperatura oltre il set-point, sia per
variazioni che tendono ad abbassare la temperatura. Solitamente si possono
associare due soglie di variazione: la variazione minima e la variazione mas-
sima in modo da definire anche in questo caso un limite di attenzione ed un
limite di pericolo.
L’allarme di velocità di variazione, o ROC (Rate Of Change), è un allar-
me che viene generato quando il valore di un dato subisce una variazione nel
71
CAPITOLO 8. ELABORAZIONE DATI
72
CAPITOLO 8. ELABORAZIONE DATI
73
CAPITOLO 8. ELABORAZIONE DATI
74
CAPITOLO 8. ELABORAZIONE DATI
75
CAPITOLO 8. ELABORAZIONE DATI
Azione Proporzionale: P
Si consideri la realizzazione di un meccanismo di controllo della velocità di
un’automobile che sia in grado di lasciare all’automobilista il solo onere di
scegliere la velocità desiderata. Esso deve conoscere il valore fissato dall’au-
tomobilista e, in base a questo, determinare la quantità di carburante da
iniettare nel motore. L’automobile può essere vista cosı̀ come un processo
caratterizzato da un ingresso, la quantità di carburante iniettato nel motore,
e un’uscita, la velocità di marcia. Un sistema che abbia lo scopo di regolare
la velocità in base al valore fissato dall’automobilista non può far altro che:
76
CAPITOLO 8. ELABORAZIONE DATI
Vd E Algoritmo I V (velocità)
Processo
+ di Controllato
controllo
−
V
Sensore
V = velocità attuale
Sistema di controllo Vd = velocità desiderata
E = errore (Vd − V)
I = valore di iniezione
I =K ·E (8.1)
77
CAPITOLO 8. ELABORAZIONE DATI
50
45
40
35
30
25
20
15
10
5
0
0 10 20 30 40 50
Azione Proporzionale-Derivativa: PD
dE
I = Kp · E + Kd · (8.2)
dt
En − En−1
I = Kp · En + Kd · (8.3)
Tn − Tn−1
78
CAPITOLO 8. ELABORAZIONE DATI
140
130
120
110
100
90
80
70
60
50
40
0 10 20 30 40 50 60 70
79
CAPITOLO 8. ELABORAZIONE DATI
80
CAPITOLO 8. ELABORAZIONE DATI
Come detto molti di questi problemi non si affrontano con gli strumenti
dei “controlli automatici” ma, come se lo fossero, il gergo dei sistemi SCADA
li qualifica, non del tutto a torto, come risolvibili per mezzo di “logiche” o
“algoritmi” di controllo.
81
CAPITOLO 8. ELABORAZIONE DATI
82
CAPITOLO 8. ELABORAZIONE DATI
• elevazione a potenza
• estrazione di radice
• operatore logico OR
83
CAPITOLO 8. ELABORAZIONE DATI
nel tempo del valore del dato primario. Analogamente, valori che hanno
variazioni ripetute nel tempo possono fornire un’indicazione migliore se se
ne calcola la media in un certo intervallo. Per quanto riguarda dati di tipo
digitale può essere comodo conoscere il numero di transizioni di stato nel
tempo ed il tempo di permanenza medio in un dato stato.
I calcoli statistici sono sempre caratterizzati dall’applicazione di una fun-
zione nel dominio del tempo. Le funzioni più utilizzate per la generazione di
questo tipo di dati sono:
• calcolo dell’integrale
84
Capitolo 9
Interfaccia uomo-macchina
9.1 Caratteristiche
In un sistema SCADA la parte di interfaccia del sistema con l’operatore pren-
de il nome di interfaccia uomo-macchina. A questo componente è demandata
la gestione delle interazioni con l’uomo e quindi nella progettazione dello stes-
so si devono tenere in considerazione aspetti che riguardano la comunicazione
con un essere umano piuttosto che caratteristiche di ottimizzazione tipiche
delle macchine utilizzate. Se un calcolatore è insensibile, ad esempio, all’or-
dinamento di un insieme di informazioni un operatore umano trae grande
giovamento dall’uso di elenchi ordinati (magari in ordine alfabetico).
Tutto quello che viene progettato per la realizzazione dell’interfaccia uo-
mo macchina tiene conto del fatto che l’utente di questo componente è l’uomo
e al centro dell’attenzione ci devono essere le sue esigenze. Non solamente
gli aspetti più direttamente collegati alla restituzione delle informazioni all’u-
tente, quindi, ma anche ogni aspetto che possa facilitare il compito dell’uomo
nell’interazione con il sistema. Il sistema SCADA deve essere solo un mez-
zo per permettere all’uomo di gestire e controllare un processo e in questa
attività esso deve risultare il più possibile “trasparente” per gli attori veri
che sono l’operatore e il processo controllato. Responsabilità dell’interfaccia
uomo-macchina è quella di agevolare il compito dell’operatore umano: più
facile e intuitiva risulta l’interazione con il sistema SCADA, migliore sarà il
risultato.
Curare l’usabilità del sistema SCADA corrisponde a mettere a proprio
agio gli operatori anche con il secondo fine di ottenere un ampio utilizzo del
sistema che sarà visto dagli operatori come un aiuto nello svolgimento delle
attività di tutti i giorni. L’agevolazione di queste operazioni contribuisce a
creare un senso di fiducia negli operatori tale che anche in situazioni critiche
85
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
essi potranno fidarsi delle risposte che il sistema fornisce, limitando situazioni
di stress psicologico certamente non auspicabili in momenti critici. Anche la
cura della semplicità delle operazioni e dei dispositivi attraverso i quali si
attua l’interfaccia è motivo di studio per rendere efficace l’interazione con gli
operatori. La riduzione e la semplificazione delle operazioni, l’automazione
delle operazioni ripetitive, l’utilizzo di dispositivi ergonomici sono elementi
che possono determinare il successo dell’adozione di un sistema SCADA.
Non si dimentichi che il processo di automazione delle aziende che vede nel
sistema SCADA uno dei suoi strumenti fondamentali è spesso accompagnato
da una diminuzione di impegno per il personale che proprio dal sistema di
automazione si trova sostituito nello svolgere i compiti di controllo. Questo
non sempre si risolve in una riduzione del personale che può essere ricollocato
o riqualificato (disfarsi di personale qualificato ed esperto dovrebbe sempre
essere motivo di preoccupazione per l’azienda) ma l’adozione di un sistema
SCADA viene spesso vista con diffidenza da parte del personale. Questo
anche per il fatto che una scelta di questo genere comporta un cambiamento
di abitudini e una possibile perdita delle sicurezze accumulate nel corso della
vita lavorativa. La diffidenza nei confronti delle conseguenze che l’adozione
di un sistema di automazione comporta spesso si manifesta nella resistenza
a questo tipo di novità e nel tentativo, nei casi peggiori, di denigrare le
caratteristiche del sistema stesso al fine di giustificarne il mancato utilizzo.
Anche per questi motivi un sistema che agevoli le operazioni di interazione
con gli operatori si candida al successo più di altri in quanto in grado di far
apprezzare gli aspetti positivi legati al suo uso.
9.2 Funzioni
La funzione principale dell’interfaccia uomo-macchina, come detto, è la ge-
stione delle interazioni tra il sistema SCADA e gli operatori. Le informazioni
che possono essere scambiate tra questi due attori sono distinguibili in:
86
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
• rappresentazioni schematiche
• rappresentazioni tabellari
• diagrammi temporali
Rappresentazioni schematiche
L’interfaccia uomo-macchina deve permettere agli operatori residenti in una
sala destinata al controllo di avere una “vista” sullo stato del processo. Il
metodo usato per ottenere questa condizione è la realizzazione di una rap-
presentazione schematica degli impianti. Questa rappresentazione può es-
sere sviluppata utilizzando diverse tecniche e nel corso degli anni ha subito
un’evoluzione significativa, anche grazie al progresso tecnologico che ha mes-
so a disposizione dei progettisti di sistemi SCADA possibilità e potenze di
elaborazione via via crescenti.
Inizialmente la tendenza è stata quella di avere un “quadro mimico”
a parete che rappresentasse tutto il processo suddiviso nelle sue parti prin-
cipali. La necessità di rappresentare tutto il processo in un’unica vista ha
comportato la schematizzazione dello stesso e la condensazione delle informa-
zioni in pochi dati. Per ottenere completezza e chiarezza d’informazione da
schemi caratterizzati da un alto livello di sintesi sono state definite rappresen-
tazioni simboliche caratteristiche degli organi di campo e tipologie ristrette
di presentazione delle informazioni associate. Ad esempio accanto al simbo-
lo rappresentativo di un motore una lampadina stava a indicare lo stato di
esercizio (in marcia se accesa o in arresto se spenta).
In figura 9.1 è riportato un esempio di schema utilizzato per la realiz-
zazione dei quadri mimici. Osservando la figura è possibile notare che una
rappresentazione del processo di questo tipo pur essendo corretta corrisponde
ad un insieme incompleto di informazioni in quanto essa realizza una “vista”
astratta di alto livello. D’altra parte l’avere a disposizione troppe informa-
zioni contemporaneamente in un quadro mimico può comportare difficoltà
nell’interpretazione da parte degli operatori. Affinché un operatore operi
correttamente e tempestivamente è necessario che le informazioni che lo rag-
giungono siano poche ma significative e associate in modo univoco all’organo
87
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
88
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
89
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
Rappresentazioni tabellari
Diagrammi temporali
90
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
140
Productivity level
130
120
Productivity level
110
100
90
80
70
60
50
0 10 20 30 40 50 60
Time
91
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
92
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
Attivazione di un comando
93
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
All’azione deve seguire una risposta da parte del sistema SCADA che mostri
se il comando ha realmente prodotto gli effetti desiderati. Non è mai buo-
na regola lasciare chi esegue un comando nell’incertezza rispetto all’avenuta
esecuzione dello stesso. È bene ricordare che un comando impartito a bor-
do dell’organo manovrato restituisce immediatamente informazioni di esito
percepite dai sensi dell’operatore in termini di rumori e movimenti tipici o
atipici. Quando il comando viene inviato da una sala controllo non si può
avere percezione della reale esecuzione della manovra richiesta. In questo
caso è bene che il sistema SCADA mostri all’operatore almeno due stati: il
sistema ha ricevuto il comando e sta procedendo all’esecuzione, il risultato
dell’esecuzione del comando.
Ogni volta che l’operatore esegue un comando il sistema deve mostrare il
fatto che lo ha preso in carico con segnalazioni del tipo “comando in corso”
oppure con una modifica del simbolo grafico utilizzato. Quando il comando
è stato eseguito il sistema deve riportare lo stato di avvenuta esecuzione, sia
in caso di successo che in caso di fallimento. Per questo scopo potrebbero
essere utilizzati messaggi simili a quello precedente, “comando eseguito” o
“comando fallito”, oppure rappresentazioni grafiche convenzionali. Nella de-
finizione di come il sistema risponde alla richiesta di un comando da parte di
un operatore si deve ricordare che un’informazione sintetica giunge con mag-
94
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
9.3 Evoluzione
Quanto descritto finora in questo capitolo riguarda le interfacce di interazio-
ne tra uomo e macchina che solitamente si trovano in un sistema SCADA.
Al giorno d’oggi la maggior parte dei sistemi SCADA viene realizzato pre-
vedendo delle postazioni operatore dotate di schermo, tastiera e dispositivo
di puntamento (mouse o track-ball) che costituiscono l’insieme minimo suffi-
cente per permettere a un operatore di svolgere i normali compiti. A questa
architettura a volte si accompagna un quadro mimico riassuntivo dell’intero
processo in grado di rappresentare con un insieme ristretto di informazioni
quanto necessario per avere un’idea dello stato del processo. Il quadro mi-
mico può essere realizzato con tecniche quali quadri a mosaico oppure con
proiettori a parete che riportano le stesse pagine video che sono visibili sul
sistema.
Sebbene queste interfacce siano sufficenti per avere la possibilità di intera-
gire con il sistema SCADA, in alcuni casi esse non rispondono completamente
alle necessità di chi è demandato a controllare il processo. Non sempre infatti
è richiesta una presenza continua degli operatori in “sala controllo”, perchè
il processo controllato non è cosı̀ importante o pericoloso oppure perché c’è
la necessità di avere più punti di accesso alle informazioni collezionate dal
sistema.
Sulla base di queste considerazioni è possibile introdurre un elemento
giudicato come importante strumento di evoluzione dei sistemi SCADA tra-
dizionali. Sempre più spesso le consuete interfacce videografiche vengono
affiancate da interfacce che permettono di essere utilizzate da parte di ope-
ratori che non risiedono in una sala controllo. L’evoluzione delle tecnologie,
soprattutto nell’ambito delle telecomunicazioni radiomobili, permette di ave-
re sullo schermo di un terminale mobile, quale può essere un telefono cellulare,
una serie di informazioni che consentono di tenere sotto controllo il processo.
Operatori dotati di terminali mobili possono essere sollecitati a intervenire
95
CAPITOLO 9. INTERFACCIA UOMO-MACCHINA
96
Capitolo 10
Eventi e allarmi
Uno dei compiti di un sistema SCADA è quello di avvertire nel più breve
tempo possibile un operatore riguardo una condizione anomala che si sta
verificando nel processo. In questo modo l’operatore può intervenire tempe-
stivamente per prevenire situazioni potenzialmente pericolose per il processo,
per l’ambiente o per l’uomo. In alcuni casi situazioni particolarmente peri-
colose sono gestite in modo autonomo direttamente dal sistema SCADA,
proprio per garantire la correttezza delle operazioni e un intervento che sia
il più rapido possibile.
Le informazioni che il sistema SCADA gestisce debbono essere trattate in
maniera differente discriminandone la natura sulla base delle considerazioni
fatte in precedenza. Infatti alcune informazioni sono semplici dati che il
sistema presenta all’operatore, altre informazioni debbono essere elaborate
con particolare tempismo e cura. In questo secondo caso si parla di allarmi
e di eventi.
97
CAPITOLO 10. EVENTI E ALLARMI
Bande di attenzione
Zona di pericolo
Banda normale
Limite di attenzione basso
98
CAPITOLO 10. EVENTI E ALLARMI
10.2 Trattamento
La natura particolare delle informazioni eventi ed allarmi è tale che anche il
trattamento che essi subiscono prevede una gestione particolare. Ogni volta
che un allarme o un evento si genera l’operatore è chiamato ad effettuarne un
riconoscimento. Riconoscere un allarme o un evento significa prendere visio-
ne della sua segnalazione e quindi della potenziale situazione di pericolo per
il processo. Per facilitare il compito dell’operatore e metterlo in condizione
di avere informazioni immediate su eventi e allarmi correntemente attivi il
sistema utilizza una lista nella quale introduce una voce ogni volta che viene
generato un evento o un allarme. Nel momento in cui la condizione anomala
scompare e si ritorna al normale funzionamento il sistema segnala il ritorno
da una condizione di allarme o da un evento. Se l’operatore aveva già ef-
fettuato il riconoscimento, l’allarme o l’evento viene rimosso dalla lista degli
allarmi/eventi attivi, altrimenti vi rimane fino a che non sarà riconosciu-
to. Un sistema SCADA non dovrebbe consentire la cancellazione automatica
dalla lista se non è stato eseguito il riconoscimento. Questa pratica infatti
contrasterebbe con le motivazioni che hanno portato alla definizione di allar-
me o evento: condizione anomala che deve essere portata a conoscenza di chi
gestisce il processo.
Questa lista deve essere consultabile dall’operatore per avere informazioni
circa le situazioni critiche del sistema. Spesso la criticità delle situazioni che
conducono alla generazione di un allarme o di un evento è tale che in ogni pa-
gina che l’operatore ha a disposizione sono riportati gli ultimi allarmi/eventi
accaduti. In sistemi SCADA che permettono di avere a disposizione una
rappresentazione su più pagine video gli operatori solitamente hanno sempre
in visualizzazione la pagina degli allarmi. Spesso a chi realizza il sistema si
chiede di evidenziare la condizione di allarme con particolari rappresentazioni
(ad esempio il valore che lampeggia) oppure di portare automaticamente alla
vista dell’operatore la pagina che contiene la lista degli allarmi attivi. In fi-
gura 10.2 è riportato un esempio di come può apparire e di quali funzionaliltà
dispone una pagina di gestione di eventi e allarmi.
Un’altra operazione che il sistema compie sulle informazioni di allar-
me/evento è l’associazione dell’etichetta “tempo”. Ogni volta che un allar-
me/evento si genera, viene riconosciuto, viene cancellato, il sistema associa
99
CAPITOLO 10. EVENTI E ALLARMI
10.2.1 Categorie
La possibilità di associare una o più categorie a un allarme/evento corrispon-
de alla possibilità di catalogare queste informazioni in modo da raggrupparle
per tipo. Si possono in questo modo effettuare ricerche nella lista allar-
mi/eventi o nel loro archivio sulla base della categoria di appartenenza. Si
100
CAPITOLO 10. EVENTI E ALLARMI
10.2.2 Priorità
La priorità associata ad un allarme/evento permette di darne una classifi-
cazione in base al grado di importanza. Esistono condizioni di allarme che
richiedono un intervento immediato, altre che possono essere considerate tol-
lerabili per un breve periodo di tempo, altre ancora che richiedono interventi
per i quali non è necessario agire con urgenza.
Spesso a gradi diversi di priorità si fanno corrispondere anche modalità di
presentazione diverse. Ad esempio per allarmi a bassa piorità può essere suffi-
cente l’inserimento nell’archivio degli allarmi/eventi mentre allarmi a priorità
medie oltre che nell’archivio vengono inseriti nella lista degli allarmi/eventi
attivi che gli operatori hanno in vista; per priorità massime, oltre a quanto
fatto per gli altri livelli, si procede all’attivazione di segnalazioni acustiche o
visive (sirene, lampeggiatori) per sollecitare l’attenzione degli operatori.
101
CAPITOLO 10. EVENTI E ALLARMI
102
CAPITOLO 10. EVENTI E ALLARMI
103
CAPITOLO 10. EVENTI E ALLARMI
104
Capitolo 11
Archiviazione
105
CAPITOLO 11. ARCHIVIAZIONE
visione diretta dei dati grezzi ma pur sempre limitate allo stato attuale del
processo controllato, a istantanee raffiguranti un fotogramma all’interno di
un flusso continuo, non permette di comprendere alcuni aspetti fondamentali
legati all’evoluzione. Aspetti che riguardano le relazioni di causa-effetto tra
perturbazioni imposte al processo ed evoluzioni dello stato, la dinamica del
processo in termini di variabilità nel tempo di grandezze significative, la
correlazione tra grandezze del processo e, di conseguenza, le relazioni tra le
evoluzioni di tali grandezze.
Lo studio dell’evoluzione del processo è esso stesso, in molti casi, scopo
del sistema di supervisione. Un caso esemplare è quello dei sistemi di teleri-
levamento ambientale: l’analisi dei dati archiviati consente di giungere alla
conoscenza dell’evoluzione di particolari fenomeni fisici e di metterla in rela-
zione con l’evoluzione degli altri parametri registrabili, tutto ciò portando a
una conoscenza altrimenti non raggiungibile.
106
CAPITOLO 11. ARCHIVIAZIONE
107
CAPITOLO 11. ARCHIVIAZIONE
108
CAPITOLO 11. ARCHIVIAZIONE
109
CAPITOLO 11. ARCHIVIAZIONE
11.2.2 Strumenti
Nelle sezioni precedenti è specificato il fatto che la struttura dei dati si fon-
da in ogni caso sul modello relazionale. Questa precisazione non determina
la scelta degli strumenti di gestione dell’archivio anche se la strada privile-
giata conduce ai sistemi di gestione dei database detti RDBMS (Relational
DataBase Management System). Strada che non sempre è in discesa poiché
110
CAPITOLO 11. ARCHIVIAZIONE
111
CAPITOLO 11. ARCHIVIAZIONE
112
Capitolo 12
Il presente capitolo tratta un aspetto dei sistemi che nel corso degli anni ha
subito un’evoluzione tale da renderlo protagonista di una significativa spin-
ta verso l’integrazione tra sistemi di controllo concorrenti e, cosa ancor più
significativa, tra ambienti di controllo e strutture di supporto alla decisione.
L’analisi dei dati è stata l’evoluzione naturale di sistemi che nel tempo si sono
rivelati capaci di diventare depositari di dati essenziali per la comprensione
dei processi sottoposti a supervisione e controllo. Sistemi progettati a scopo
di supervisione, quali sono i sistemi di rilevamento per lo studio delle attività
sismiche, dell’inquinamento ambientale, delle variabili d’interesse meteorolo-
gico, hanno mostrato profonde analogie con sistemi di controllo per l’industria
destinati alla contabilizzazione di alcune grandezze fisiche caratteristiche del
processo controllato o all’analisi delle stesse finalizzata a produrre previsioni
e a valutare prestazioni. Le due categorie di sistemi sono chiamate a svolgere
un compito per il quale è indispensabile allestire strutture di archiviazione
e analisi dei dati. Le sezioni che seguono contengono un’introduzione agli
strumenti comunemente utilizzati in fase di analisi, quelli che solitamente
sono integrati nelle funzionalità del sistema di elaborazione e quelli che ben
presto lo saranno.
113
CAPITOLO 12. ANALISI DEI DATI
L’uso che può essere fatto dei trend storici dipende fortemente dal tipo di
processo controllato e, di conseguenza, di sistema. Se il processo controllato
è l’attività sismica di un’area territoriale il trend deve permettere la rappre-
sentazione dell’intensità rilevata in uno o più punti in funzione del tempo.
Quando le variabili osservate sono indicatori della presenza di fattori inqui-
nanti nell’aria deve essere possibile rappresentare il comportamento di tali
fattori su scala temporale. L’andamento delle temperature, comprese massi-
me e minime, dell’intensità delle precipitazioni, del grado di umidità e della
pressione sono solo alcuni esempi di casi nei quali una rappresentazione gra-
fica permette di rendere immediata la lettura delle variabili meteorologiche
fondamentali.
114
CAPITOLO 12. ANALISI DEI DATI
140
Grandezza target
Inseguitore
120
100
80
60
40
20
0
0 20 40 60 80 100
115
CAPITOLO 12. ANALISI DEI DATI
140
Grandezza target
Inseguitore
130
120
110
100
90
80
70
60
50
0 20 40 60 80 100
116
CAPITOLO 12. ANALISI DEI DATI
117
CAPITOLO 12. ANALISI DEI DATI
118
Capitolo 13
3. interfaccia uomo-macchina
119
CAPITOLO 13. SICUREZZA DEL SISTEMA
120
CAPITOLO 13. SICUREZZA DEL SISTEMA
121
CAPITOLO 13. SICUREZZA DEL SISTEMA
122
CAPITOLO 13. SICUREZZA DEL SISTEMA
13.3 Infrastrutture
123
CAPITOLO 13. SICUREZZA DEL SISTEMA
124
Parte IV
Conclusioni
125
Capitolo 14
Strumenti e competenze
127
CAPITOLO 14. STRUMENTI E COMPETENZE
128
CAPITOLO 14. STRUMENTI E COMPETENZE
coinvolgere anche il cliente in quanto solo cosı̀ si può riuscire a far convergere
le necessità e le possibilità realizzative.
Che si possa procedere alla definizione dei requisiti in una unica fase
iniziale oppure si debba procedere alla loro definizione in corso d’opera, il
metodo più comune è avere una serie di incontri tra cliente e fornitore in
modo da chiarire da una parte e dall’altra cosa si vuole ottenere e cosa si
otterrà. Spesso le richieste del cliente debbono essere tradotte in linguaggio
tecnico da parte del fornitore in modo da poter essere interpretate, cosı̀ come
le proposte del fornitore debbono essere tradotte in linguaggio comprensibile
al cliente. Questa necessità di utilizzare un linguaggio comune fa nascere nel
fornitore l’esigenza di coinvolgere per questa fase di definizione dei requisiti
(ciò che è interessante analizzare in questo frangente) personale che sia in
grado di mediare tra le richieste del cliente e quello che il fornitore è in
grado di offrire, con lo sguardo rivolto a questioni non soltanto tecniche (ad
esempio il contenimento dei costi entro limiti accettabili per il cliente). La
cosa più importante in questo caso è non considerare nulla come scontato,
sottinteso, non ben definito. La chiarezza deve essere la base di partenza per
poter procedere alla definizione dei requisiti in modo che nessuno possa essere
all’oscuro di quanto si richiede o si fornisce. Ciò è maggiormente importante
se si considera che il periodo di realizzazione del sistema spesso trascorre
senza contatti tra cliente e fornitore, contatti che si riattivano nel momento
in cui il sistema è completo e pronto per essere installato.
Nel seguito sono elencati alcuni degli aspetti principali da definire come
requisiti di base. È importante ricordare la natura del tutto generale dell’e-
lenco proposto e il fatto che esso deve essere integrato con quanto l’esperienza
del progettista può suggerire.
129
CAPITOLO 14. STRUMENTI E COMPETENZE
130
CAPITOLO 14. STRUMENTI E COMPETENZE
trasmissione dati in relazione alle distanze, alla quantità di dati, alla di-
sponibilità dei medesimi (intesa sia come periodo di acquisizione che come
estensione temporale). La definizione di queste caratteristiche è un’attività
che spesso può essere svolta con un certo grado di autonomia dal fornitore in
quanto il cliente non sempre ha la capacità per entrare nel merito di aspetti
estremamente tecnici. In alcuni casi invece le necessità esplicitate dal clien-
te sono indicative della soluzione da adottare (ad esempio può porre vincoli
sulla posa di cavi e imporre l’uso di vettori radio). In ogni caso il cliente
deve essere adeguatamente informato della scelta effettuata o, nel caso siano
plausibili più alternative, delle caratteristiche positive e negative delle solu-
zioni proposte. Tutto questo ha lo scopo di essere il più possibile trasparenti
in merito a quanto verrà realizzato.
Una volta che sono stati definiti i punti da acquisire e le funzioni del siste-
ma, dovrà essere determinato l’insieme delle informazioni che debbono essere
archiviate al fine di consentire la conservazione della storia del processo. La
scelta delle informazioni da archiviare deve essere curata perché da essa di-
pende la scelta del sistema di archiviazione e delle risorse da destinare allo
stesso. Si è visto in precedenza che l’adozione di un data base relazionale è
scelta obbligata per realizzare il motore di archiviazione. Si tenga presente
però che ogni motore DBMS ha le sue caratteristiche peculiari e un costo
a esse associato. È inutile dimensionare il sistema SCADA con l’intenzio-
ne di archiviare tutti i dati trattati con la frequenza tipica dell’acquisizione.
Procedere su questa strada farebbe arrivare facilmente ad avere un siste-
ma di archiviazione che da solo occuperebbe la maggior parte del sistema
SCADA sia economicamente sia in termini di risorse destinate. Per poter
dimensionare correttamente il sistema di archiviazione si dovrebbe prima di
tutto definire cosa fare con i dati archiviati: servono per avere un riepilogo
del funzionamento del sistema? servono per poter ricreare degli scenari fuori
linea per permettere lo studio a posteriori di eventi? servono per ragioni
legali? Ognuna di queste domande porta a soluzioni diverse da caso a ca-
so che solamente l’esperienza permette di definire. Dalla parte del cliente è
necessario che l’esigenza finale dell’archiviazione dei dati sia esplicitata. Per
fare questo le figure interessate potrebbero essere i gestori del sistema e il
settore gestionale dell’azienda (che potrebbe aver bisogno di questi dati per
svolgere il proprio lavoro).
131
CAPITOLO 14. STRUMENTI E COMPETENZE
• ridondanza
• disponibilità
• permessi operatore
132
CAPITOLO 14. STRUMENTI E COMPETENZE
133
CAPITOLO 14. STRUMENTI E COMPETENZE
134
CAPITOLO 14. STRUMENTI E COMPETENZE
135
CAPITOLO 14. STRUMENTI E COMPETENZE
136
CAPITOLO 14. STRUMENTI E COMPETENZE
137
CAPITOLO 14. STRUMENTI E COMPETENZE
presenza del cliente e del fornitore e producono evidenze formali dei risultati
dell’esecuzione di ogni procedura di test. Si concludono solamente quando
il cliente riterrà superato il test con risultati accettabili (rispetto a quanto
richiesto). Ogni volta che l’esecuzione di una procedura di test non dovesse
presentare risultati soddisfacenti a causa di malfunzionamenti del sistema,
questi debbono essere corretti al fine di realizzare quanto richiesto. In base
alla gravità del malfunzionamento presentato, il singolo test o l’intera fase
di test di accettazione dovrà essere sospesa in attesa della correzione. Dopo
ogni correzione si dovrà procedere alla riesecuzione della procedura di test
incriminata (o dell’intero set di procedure) fino a quando tutti i risultati
saranno considerati accettabili. Al termine della fase SAT, il sistema è pronto
per l’installazione e l’avvio della fase di utilizzo.
Quanto fin qui descritto aderisce a quello indicato come metodo waterfall
di produzione di un sistema informatico. Senza addentrarci nelle motivazioni
è necessario dire che questo metodo, nel corso degli anni, si è rivelato inef-
ficace. Principalmente si è osservato che il metodo non coincide con quanto
in realtà avviene nei rapporti usuali tra fornitore e cliente. Non è possibile
lavorare su fasi di progetto chiuse che non prevedono interazioni con le altre
e che debbono fornire risultati ottimi pena il buon esito delle fasi successi-
ve. La realtà ci parla di sistemi che sono spesso in divenire e lo sforzo per
rappresentare questi sistemi con il metodo descritto è tale da far ritenere lo
sforzo da compiere sproporzionato rispetto al risultato da raggiungere.
Si è detto che il cliente deve essere coinvolto direttamente, il più pos-
sibile, in tutte le fasi del progetto. Non è esente da questa considerazione
la fase di verifica del sistema. Già nella fase di progettazione si è parlato
della necessità di fornire in tempi brevi soluzioni, anche di tipo prototipale,
che siano in grado di allineare le richieste con quanto si andrà a fornire. La
verifica di queste soluzioni può essere vista come la realizzazione della fase di
accettazione del sistema da parte del cliente, non in un unico passo compiuto
al termine della realizzazione del sistema ma durante la fase di realizzazione
stessa, in modo da avere riscontri immediati sulla validità delle scelte compiu-
te. Cambia l’importanza dei test. Essi diventano funzionali all’assicurazione
di livelli misurabili di qualità della fornitura. Cambia anche l’approccio ai
test troppo spesso vissuti come se fossero esami essendo, al contrario, parte
integrante del processo di progettazione e realizzazione. Garantirsi la possi-
bilità di confrontare immediatamente quanto realizzato con quanto richiesto
è un modo efficace per prendere tempestivamente contromisure se attese e ri-
sultati non coincidono; in più permette di superare tutte le naturali difficoltà
che possono rivelarsi gravissime, o addirittura insormontabili, se affrontate
138
CAPITOLO 14. STRUMENTI E COMPETENZE
139
CAPITOLO 14. STRUMENTI E COMPETENZE
invece viene spesso osservata nei rapporti tra cliente e fornitore). Quando
l’approssimarsi della scadenza di consegna genera una eccessiva pressione nel
gruppo di progetto può accadere che piccoli problemi vengano ingigantiti e
nuovi problemi creati. Inoltre la fretta spesso viene usata a giustificazione di
una fase di analisi dei problemi che potrebbe risultare lacunosa tanto da pro-
durre soluzioni inefficaci (per cui un problema deve essere affrontato più volte
senza mai trovare la soluzione definitiva) o addirittura dannose (in quanto
altre parti del sistema risultano danneggiate dalla soluzione adottata). In
ogni caso la fretta nella risoluzione di un problema è un problema a propria
volta che accresce il rischio di ritardi nella consegna (cioè esattamente quello
che si voleva evitare). Tutto ciò senza considerare l’impatto psicologicamente
negativo che un sistema malfunzionante ha nei confronti sia del gruppo di
progetto che nel cliente.
Comunque, senza entrare nello specifico, è bene considerare che quanto
più il sistema viene verificato prima di essere installato, minore sarà il tem-
po di installazione. Considerando che l’installazione è un’attività per sua
natura costosa (si svolge presso il cliente e quindi si debbono considerare i
costi di trasferta del personale interessato), si comprende che dovrebbe essere
interesse di tutti condividere questa considerazione.
La capacità di valutare in situazione di contingenza quale parametro sa-
crificare in vista di un miglioramento complessivo, non è cosa che possa far
parte di trattazioni di questo tipo. Solamente l’esperienza può portare a va-
lutare caso per caso quale contromisura adottare nell’ottica di raggiungere
i risultati migliori. E proprio in questa considerazione nasce la definizione
delle competenze necessarie in fase di installazione. La complessità delle si-
tuazioni da affrontare, il fatto che si lavora spesso con tempi stretti, fuori
sede, senza la disponibilità degli strumenti migliori, la necessità di integrarsi
con altri fornitori e quindi di affrontare situazioni non previste, suggerisce di
utilizzare personale esperto. Il gruppo di installazione può essere composto
anche da personale inesperto se guidato da un coordinatore esperto.
Dal punto di vista degli interventi in campo è bene cercare di seguire una
filosofia che permetta di procedere per passi successivi in modo da suddividere
l’impegno di installazione in diverse aree. Ad esempio si potrebbe procedere
all’installazione degli apparati periferici e, per ognuno di essi, alla verifica
della corrispondenza dei dati acquisiti con quelli previsti. Questa attività
che prende il nome di battitura del campo consente di verificare che a livello
di informazioni acquisite ci sia corrispondenza tra quanto progettato e quanto
realizzato in campo. Avere la sicurezza che un dato sia esattamente quello
che ci aspettiamo è fondamentale per assicurare il funzionamento del sistema
140
CAPITOLO 14. STRUMENTI E COMPETENZE
141
CAPITOLO 14. STRUMENTI E COMPETENZE
Al primo tipo fanno capo tutti quei problemi che non consentono l’utilizzo
del sistema fino a che un provvedimento risolutivo non venga attuato. Si
tratta di problemi gravi che richiedono l’intervento immediato e la soluzione
in tempi brevissimi. Dal manifestarsi del problema fino alla sua risoluzione
il periodo di dimostrazione viene sospeso. Di solito si stabilisce un tempo
massimo di intervento trascorso il quale, se il problema persiste, la sospen-
sione dell’esercizio si trasforma in interruzione. Per riportare il sistema in
attività sarà necessario eliminare i malfunzionamenti, procedere alle oppor-
tune verifiche e riavviare l’esercizio in regime di verifica della disponibilità.
In questo caso il periodo di dimostrazione riparte dall’inizio. Se invece il
problema viene risolto nel tempo massimo fissato, si ricomincia a utilizzare il
sistema senza che il tempo speso per la soluzione del problema venga tenuto
in conto per il calcolo della disponibilità.
Nel caso di problemi non bloccanti, il manifestarsi di uno di questi non
comporta la sospensione del periodo di dimostrazione, ma semplicemente il
tracciamento del problema manifestato per una sua soluzione in tempi che
non sono preventivamente determinati (il sistema è in grado di funzionare
anche senza che il problema sia risolto). In qualche caso si fissa un numero
massimo di problemi non bloccanti aperti contemporaneamente. Superato
questo numero i problemi vengono considerati di tipo bloccante e si procede
secondo quanto già descritto.
Il periodo di dimostrazione è un periodo molto importante sia dal punto
di vista del cliente che da quello del fornitore. In questo periodo il cliente de-
ve avere assicurazione del corretto funzionamento del sistema in tutte le sue
funzioni. Per il fornitore è invece l’esame che porta al primo giudizio com-
plessivo sul valore del prodotto. Anche la capacità del fornitore di affrontare
con efficacia e rapidità i problemi che dovessero emergere è motivo di valuta-
zione della qualità della fornitura (intesa come sistema e servizi accessori), in
particolare rispetto ai requisiti di manutenibilità definiti in fase progettua-
le. Non si deve mai sottovalutare la facilità di intervento sul sistema fornito
né rispetto alla risoluzione dei problemi né rispetto all’implementazione di
nuove funzioni richieste dal cliente.
La particolare natura di questa fase suggerisce al fornitore di disporre di
un gruppo di lavoro che conosca il sistema nel dettaglio, pena l’inefficacia e la
lentezza degli interventi. È bene non disperdere le conoscenze del sistema una
volta iniziata la fase di installazione ma mantenere vivo il gruppo di progetto
(magari riducendolo alle sole figure chiave) anche per un primo periodo di
esercizio. L’esperienza porta a dire che la maggior parte degli interventi di
manutenzione, correzione, aggiornamento realizzati su un sistema si verifica
142
CAPITOLO 14. STRUMENTI E COMPETENZE
nella prima parte della sua vita operativa. Le competenze che il gruppo di
supporto all’installazione e alla messa in esercizio deve avere sono tali e tante
da coprire tutti gli ambiti nei quali il sistema si muove. Importantissime in
questa fase sono quelle figure professionali che hanno una visione d’insieme
del sistema, della sua architettura e delle sue funzioni. Spesso le ragioni di
successo di un sistema risiedono nella capacità del fornitore di offrire soluzioni
rapide alle richieste del cliente e figure che conoscano nel dettaglio il sistema
si possono rivelare indispensabili allo scopo.
143
CAPITOLO 14. STRUMENTI E COMPETENZE
La manutenzione non deve essere percepita né dal cliente né dal fornitore
come una fase in cui si attende la comparsa di un problema per procede-
re all’intervento risolutivo. In questa fase dovrebbero essere realizzate tutte
le modifiche necessarie al raggiungimento del livello ottimale di efficienza e
usabilità. Modifiche che possono trovare le loro richieste solo dopo che gli
operatori ne abbiano fatto conoscenza grazie all’uso quotidiano. In definitiva
un sistema in esercizio non deve essere visto come un’infrastruttura che biso-
gna solamente mantenere in vita. Il sistema deve essere visto come un’entità
della quale alimentare una crescita funzionale al potenziamento dell’efficacia
del processo controllato e dell’attività del personale coinvolto nel control-
lo. Perché questo possa avvenire è necessario che si stabilisca un rapporto
di fiducia tra il cliente e il fornitore, rapporto che deve manifestarsi in una
collaborazione mirata al miglioramento del sistema.
Il miglioramento delle funzioni del sistema, l’introduzione di nuove fun-
zioni, l’osservazione e il miglioramento delle prestazioni sono attività da ri-
condurre alla fase di manutenzione. Tra queste alcune possono essere svolte
soltanto osservando il comportamento del sistema in esercizio, altre possono
essere svolte soltanto in ambienti distinti da questo. Ciò che risulta oppor-
tuno è l’allestimento di un sistema in tutto simile a quello in servizio, tranne
che per l’interazione con il processo controllato. Si tratta di un ambiente
di test gemello del sistema in linea per il quale il processo da controllare è
sostituito da un sottosistema di simulazione. Una soluzione di questo genere
viene vissuta, naturalmente, come un inutile costo da sovrapporre a quello
affrontato per la realizzazione del sistema. Un modo per contenere il peso
del costo di un ambiente di test è collocare questo ambiente all’interno dei
provvedimenti da adottare per la definizione delle procedure di disaster re-
covery, infatti la dotazione di una copia fedele del sistema in esercizio può
essere un valido strumento per la definizione di tali procedure.
144
Capitolo 15
Nel corso della trattazione è stato fatto più volte cenno a possibili evoluzioni
dell’architettura e delle funzionalità dei sistemi SCADA. Queste hanno pre-
so forma nel corso degli anni, e continuano a emergere, grazie allo sviluppo
delle tecnologie e a un diverso modo di interpretare il significato dei sistemi
di controllo nell’ambito dei sistemi informativi aziendali. Il sistema SCADA
segue linee di trasformazione che lo stanno conducendo a una integrazione
sempre maggiore con sistemi affini, con i sistemi di gestione e di supporto alla
decisione. Allo stesso tempo l’uso di nuove tecnologie consente di definire ar-
chitetture con le quali è possibile realizzare nuove funzionalità o perfezionare
quelle esistenti, fino a giungere alla formulazione di una nuova definizione dei
sistemi SCADA che consideri l’acronimo realmente rappresentativo di fun-
zionalità e non di un tipo di sistema, funzionalità rese disponibili nella forma
di servizi personalizzati erogati da un “provider”.
La trattazione che segue ha lo scopo di introdurre elementi di riflessione
sul significato dei sistemi SCADA nel panorama tecnologico attuale secondo
i caratteri appena delineati. È bene sottolineare che alcuni apetti dell’evolu-
zione trattati nel seguito del capitolo si riferiscono a fenomeni d’integrazione
tra sistemi che pur essendo in atto da molti anni non hanno ancora condotto
alla definizione di modelli evoluti di progettazione. La causa di questo ritardo
non risiede nel limite imposto dalle tecnologie ma da un’analisi superficiale
delle esigenze che emergono dai settori aziendali che non realizzano i pro-
cessi produttivi intesi in senso fisico. In sintesi si può dire che i produttori
di sistemi e piattaforme di sviluppo SCADA non hanno ancora compreso in
modo compiuto il ruolo dei sistemi informativi e l’importanza che rivestono
all’interno di questi i sistemi di controllo. L’inerzia con la quale il mondo dei
sistemi SCADA affronta questi temi è in parte giustificata dal fatto che al
già elevato livello di complessità che caratterizza la realizzazione di sistemi
di controllo si vanno aggiungendo nuovi elementi di complessità. Per questi
145
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
146
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
Internet
BUSINESS
OFFICE
Rete
Terminali
mobili
SCADA
Rete
PROCESSO
147
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
148
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
mondo esterno per mezzo delle tecnologie offerte dalla rete internet. L’e-
rogazione di servizi per mezzo delle tecnologie web (vendita, ordinazioni,
assistenza, ...) può essere affrontata soltanto quando lo consente il livello
raggiunto nell’integrazione tra i sistemi di controllo delle attività produtti-
ve e quelli destinati alla gestione aziendale. A titolo di esempio può essere
considerato il servizio di vendita “online” nel quale un aggiornamento co-
stante della disponibilità dei prodotti offerti permette al sistema di vendita
di soddisfare in modo adeguato le esigenze dei clienti. Allo stesso modo un
corretto uso dei dati relativi alle ordinazioni e di quelli riguardanti l’attività
produttiva consentono ai settori gestionali di compiere le scelte migliori in
fase di pianificazione delle attività.
Per quel che riguarda gli effetti causati dall’evoluzione tecnologica sullo
sviluppo dei sistemi SCADA si può dire che il contributo più significativo
è stato dato dalle tecnologie di telecomunicazione. La diffusione e il per-
fezionamento di reti basate sullo standard IEEE 802, detto “ethernet”, ha
consentito di disporre di infrastrutture di comunicazione affidabili, flessibili,
modulari e gestibili per le quali sono stati definiti protocolli di comunicazione
specifici dei diversi ambiti del controllo di processo. L’introduzione di questo
tipo di reti è stato un fattore determinante soprattutto nello sviluppo dei
sistemi di dimensioni geografiche, per i quali è possibile sfruttare la tecno-
logia TCP/IP per mezzo delle infrastrutture rese disponibili dai fornitori di
servizi di telecomunicazioni. Un significato altrettanto importante sembra
che lo avranno i servizi di radiocomunicazione. I sistemi radiocellulari per
le comunicazioni tra entità remote di un sistema di dimensioni geografiche
e le reti wireless per le comunicazioni locali si stanno imponendo, anche se
ancora soltanto sulla carta, come soluzioni efficienti a problemi di connetti-
vità che a dire il vero sono già affrontati con successo. Quello che la telefonia
cellulare ha consentito di realizzare è un nuovo insieme di funzioni che in
qualche modo cambia l’organizzazione del lavoro. Oggi è possibile associare
a stati del sistema di controllo per i quali è necessario l’intervento di un ope-
ratore l’invio di messaggi sms di richiesta d’intervento. Questo consente di
realizzare sistemi non presidiati capaci di richiamare l’attenzione di operatori
impegnati in altre attività su stati di esercizio che non possono essere gestiti
con procedure automatiche.
Tornando al modello di sistema integrato riportato in figura 15.1 è oppor-
tuno ripetere che un sistema integrato dovrebbe essere progettato tenendo in
considerazione tutte le componenti che lo costituiscono, per evitare di com-
mettere tutti gli errori che vengono compiuti quando si sceglie di rimandare
l’analisi dei requisiti dell’integrazione al momento in cui la realizzazione delle
149
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
150
CAPITOLO 15. EVOLUZIONE DEI SISTEMI SCADA
Sistema di HMI
elaborazione
WAN
Apparecchiature
periferiche
Processo
controllato
151
tecnologie di scambio dati tra entità remote. Prestazioni, sicurezza e affi-
dabilità sono aspetti che debbono essere analizzati con particolare attenzio-
ne. Il secondo riguarda la gestione dei dati acquisiti e prodotti dal sistema.
L’adozione di un servizio SCADA da parte di un committente comporta la
condivisione con il fornitore dell’accesso ai dati. Il fornitore risulta essere
addirittura il depositario, in senso fisico, di un partimonio di conoscenza che
in molti casi può essere considerato come elemento strategico nell’attività
che ha portato alla realizzazione del sistema. Un altro elemento da tene-
re in considerazione riguarda la perdita di competenze interne all’azienda o
all’ente che commissiona un servizio di questo tipo. Ciò che inevitabilmen-
te accade è l’allontanamento degli addetti a supervisione e controllo dalla
realtà del processo e dei sistemi e la conseguente incapacità di giudicare con
adeguato senso critico il livello di qualità del controllo attuato dal sistema
e dei servizi che lo realizzano. Un’ultima importante considerazione attiene
l’interesse che committenti e fornitori hanno nei confronti dei servizi SCA-
DA. I primi hanno la necessità di realizzare un sistema che sia in grado di
soddisfare le esigenze di controllo del processo del quale sono responsabili. I
secondi hanno l’interesse di ottenere la massima soddisfazione del cliente sia
in termini di servizio erogato che di costi esposti. Gli interessi delle due parti
trovano un punto d’incontro soddisfacente fin quando il fornitore risulta in
grado di realizzare un servizio adeguato alle esigenze del committente all’in-
terno di economie di scala realizzate per mezzo della definizione di servizi
standard. Quando il processo presenta caratteristiche poco comuni o non ge-
stibili con i servizi erogati, accade che l’incontro tra domanda e offerta porta
alla personalizzazione del servizio soltanto se questa viene considerata come
un’evoluzione che può essere integrata nell’offerta di servizi complessiva (la
quale ha inevitabilemnte carattere generalista).
152
Glossario
banco di controllo banco dotato di tasti, leve e bottoni per mezzo dei quali
gli operatori possono impartire comandi per il controllo del processo
pagine video rappresentazioni dello stato del processo realizzate per mezzo
di strumenti software; queste hanno sostituito la tecnologia del quadro
mimico
153
porta punto di accesso di un sistema di elaborazione o di un dispositivo per
mezzo del quale è possibile attivare uno scambio dati per la fruizione
di un servizio
154
Bibliografia
[4] Eric Rescorla. SSL and TLS: Designing and Building Secure Systems,
volume 1. Addison-Wesley Professional, 2000.
[7] N.S. Nise. Control Systems Engineering, volume 1. Wiley and Sons Inc,
3 edition, 2000.
[8] Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo Torlone. Basi
di dati - Modelli e linguaggi di interrogazione, volume 1. McGraw-Hill,
2002.
[10] R.C. Dorf, R.H. Bishop. Modern Control Systems, volume 1. Addison-
Wesley, 2001.
155
[12] Andrew S. Tanenbaum. Reti di Computer, volume 1. Prentice Hall
International, 3 edition, 1997.
[13] VISUAL Project. VISUAL web-enabled open source SCADA and HMI
software for LINUX. sourceforge.net/projects/visual.
156
Parte V
Appendici
157
Appendice A
Preamble
159
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be distributed
under the terms of this License. Such a notice grants a world-wide, royalty-
free license, unlimited in duration, to use that work under the conditions
stated herein. The Document, below, refers to any such manual or work.
Any member of the public is a licensee, and is addressed as you. You accept
the license if you copy, modify or distribute the work in a way requiring
permission under copyright law.
A Modified Version of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
A Secondary Section is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the publishers
or authors of the Document to the Document’s overall subject (or to rela-
ted matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a Se-
condary Section may not explain any mathematics.) The relationship could
be a matter of historical connection with the subject or with related matters,
or of legal, commercial, philosophical, ethical or political position regarding
them.
The Invariant Sections are certain Secondary Sections whose titles are
designated, as being those of Invariant Sections, in the notice that says that
the Document is released under this License. If a section does not fit the
above definition of Secondary then it is not allowed to be designated as Inva-
riant. The Document may contain zero Invariant Sections. If the Document
does not identify any Invariant Sections then there are none.
The Cover Texts are certain short passages of text that are listed, as
Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License. A Front-Cover Text may be at
most 5 words, and a Back-Cover Text may be at most 25 words.
A Transparent copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general public,
that is suitable for revising the document straightforwardly with generic text
editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input
to text formatters or for automatic translation to a variety of formats suitable
for input to text formatters. A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart or
160
discourage subsequent modification by readers is not Transparent. An image
format is not Transparent if used for any substantial amount of text. A copy
that is not Transparent is called Opaque.
Examples of suitable formats for Transparent copies include plain ASCII
without markup, Texinfo input format, LaTeX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML,
PostScript or PDF designed for human modification. Examples of transpa-
rent image formats include PNG, XCF and JPG. Opaque formats include
proprietary formats that can be read and edited only by proprietary word
processors, SGML or XML for which the DTD and/or processing tools are
not generally available, and the machine-generated HTML, PostScript or
PDF produced by some word processors for output purposes only.
The Title Page means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this License
requires to appear in the title page. For works in formats which do not have
any title page as such, Title Page means the text near the most prominent
appearance of the work’s title, preceding the beginning of the body of the
text.
A section Entitled XYZ means a named subunit of the Document whose
title either is precisely XYZ or contains XYZ in parentheses following text
that translates XYZ in another language. (Here XYZ stands for a specific
section name mentioned below, such as Acknowledgements, Dedications,
Endorsements, or History.) To Preserve the Title of such a section
when you modify the Document means that it remains a section Entitled
XYZ according to this definition.
The Document may include Warranty Disclaimers next to the notice whi-
ch states that this License applies to the Document. These Warranty Disclai-
mers are considered to be included by reference in this License, but only as
regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either com-
mercially or noncommercially, provided that this License, the copyright no-
tices, and the license notice saying this License applies to the Document are
reproduced in all copies, and that you add no other conditions whatsoever
to those of this License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or distribute.
161
However, you may accept compensation in exchange for copies. If you distri-
bute a large enough number of copies you must also follow the conditions in
section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the Do-
cument’s license notice requires Cover Texts, you must enclose the copies
in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover
Texts on the front cover, and Back-Cover Texts on the back cover. Both
covers must also clearly and legibly identify you as the publisher of these
copies. The front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the covers in
addition. Copying with changes limited to the covers, as long as they pre-
serve the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the actual
cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent co-
py along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using public
has access to download using public-standard network protocols a complete
Transparent copy of the Document, free of added material. If you use the
latter option, you must take reasonably prudent steps, when you begin di-
stribution of Opaque copies in quantity, to ensure that this Transparent copy
will remain thus accessible at the stated location until at least one year after
the last time you distribute an Opaque copy (directly or through your agents
or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give them
a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release the Mo-
dified Version under precisely this License, with the Modified Version filling
162
the role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must
do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that
of the Document, and from those of previous versions (which should, if
there were any, be listed in the History section of the Document). You
may use the same title as a previous version if the original publisher of
that version gives permission.
C. State on the Title page the name of the publisher of the Modified
Version, as the publisher.
G. Preserve in that license notice the full lists of Invariant Sections and
required Cover Texts given in the Document’s license notice.
I. Preserve the section Entitled History, Preserve its Title, and add to it
an item stating at least the title, year, new authors, and publisher of
the Modified Version as given on the Title Page. If there is no section
Entitled History in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page, then
add an item describing the Modified Version as stated in the previous
sentence.
J. Preserve the network location, if any, given in the Document for public
access to a Transparent copy of the Document, and likewise the network
163
locations given in the Document for previous versions it was based on.
These may be placed in the History section. You may omit a network
location for a work that was published at least four years before the
Document itself, or if the original publisher of the version it refers to
gives permission.
164
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under
this License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections
of all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve
all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and mul-
tiple identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if
known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled History in
the various original documents, forming one section Entitled History; likewise
combine any sections Entitled Acknowledgements, and any sections Entitled
Dedications. You must delete all sections Entitled Endorsements.
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other docu-
ments released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in the
collection, provided that you follow the rules of this License for verbatim
copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this License
into the extracted document, and follow this License in all other respects
regarding verbatim copying of that document.
7. AGGREGATION WITH
INDEPENDENT WORKS
165
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, is called an aggregate if the copyright resulting from
the compilation is not used to limit the legal rights of the compilation’s users
beyond what the individual works permit. When the Document is included in
an aggregate, this License does not apply to the other works in the aggregate
which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one half of the entire
aggregate, the Document’s Cover Texts may be placed on covers that bracket
the Document within the aggregate, or the electronic equivalent of covers if
the Document is in electronic form. Otherwise they must appear on printed
covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribu-
te translations of the Document under the terms of section 4. Replacing
Invariant Sections with translations requires special permission from their
copyright holders, but you may include translations of some or all Invariant
Sections in addition to the original versions of these Invariant Sections. You
may include a translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions of those
notices and disclaimers. In case of a disagreement between the translation
and the original version of this License or a notice or disclaimer, the original
version will prevail.
If a section in the Document is Entitled Acknowledgements, Dedications,
or History, the requirement (section 4) to Preserve its Title (section 1) will
typically require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will automatically
terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
c
Copyright
YEAR YOUR NAME. Permission is granted to co-
py, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.2 or any later
version published by the Free Software Foundation; with no Inva-
riant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled GNU Free
Documentation License.
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts
being LIST.
If you have Invariant Sections without Cover Texts, or some other com-
bination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we re-
commend releasing these examples in parallel under your choice of free soft-
ware license, such as the GNU General Public License, to permit their use
in free software.
167