Implementazione di IEC 60870-5-104 in gateway X-Monitor - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Implementazione di IEC 60870-5-104
in gateway X-Monitor
Tesi di laurea
Relatore
Dott. Armir Bujari
Laureando
Stefano Fogarollo
Matricola 1098023
Anno Accademico 2018-2019
Stefano Fogarollo: Implementazione di IEC 60870-5-104 in gateway X-Monitor, Tesi di laurea, © 18 Luglio 2019.
iii Dedicato a Vera
“Quidquid latine dictum sit, altum sonatur.”
— Sconosciuto
Ringraziamenti
Ringrazio di cuore la mia famiglia, specialmente Norma, Sara, Paola, Tarcisio,
Eugenia e Piero, per avermi seguito in ogni momento; Stefano e Monica per avermi
sfamato nei momenti di più bisogno.
Vorrei esprimere la mia gratitudine al Dott. Armir Bujari per l’aiuto e il sostegno
fornitomi durante lo svolgimento del lavoro.
Ringrazio sentitamente Vittorio e Bob per avermi permesso di lavorare insieme
a loro. Pietro, Riccardo e Olivia per avermi guidato, sin dall’inizio, in Atroos e
ThisOne!. Ringrazio molto Beatrice, co-relatrice di questa tesi.
Infine un speciale ringraziamento va a Eliisa, Gianluca, Klest, Mario, Sara, Teresa
e Valeria: senza di loro non ci sarebbe tutto questo.
Padova, 18 Luglio 2019 Stefano Fogarollo
ivAbstract
Il presente documento raccoglie il lavoro svolto dallo stagista, Stefano Fogarollo,
durante il periodo di stage, della durata di 316 ore, presso ThisOne!.
Lo scopo principale dello stage consisteva nell’implementazione del protocollo IEC
60870-5-104 volta alla trasmissione di dati relativi a potenze elettriche verso la
piattaforma Monet. Lo studente ha dovuto acquisire competenze Qt nel contesto
embedded GNU/Linux, ambiente richiesto per l’implementazione dell’applicativo.
L’esperienza acquisita e stata poi sfruttata per interfacciarsi in rete con il gateway
X-Monitor GZE-300.
vNorme tipografiche
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
• gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio-
nati vengono definiti nel glossario, situato alla fine del presente documento;
• per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: parola g ;
• i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati
con il carattere corsivo;
viIndice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Panoramica stage . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Panoramica documento . . . . . . . . . . . . . . . . . . . . . 2
2 Progetto di stage 3
2.1 L’offerta di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Panoramica dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Obiettivi formativi . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.3 Rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Strumenti e tecnologie 7
3.1 Gestione di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Versionamento . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Altri strumenti per la gestione di progetto . . . . . . . . . . . 8
3.1.4 Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Sistemi operativi . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Fase 1: Formazione generale . . . . . . . . . . . . . . . . . . . 11
3.3.2 Fase 2: Progettazione architettura . . . . . . . . . . . . . . . 12
3.3.3 Fase 3: Codifica architettura . . . . . . . . . . . . . . . . . . 12
3.3.4 Fase 4: Progettazione e codifica test . . . . . . . . . . . . . . 12
3.4 Riepilogo delle ore previste . . . . . . . . . . . . . . . . . . . . . . . 13
4 IEC 60870-5-104 15
4.1 Il contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Lo standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Indirizzamento . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . 18
viiviii INDICE
4.2.3 ASDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4 IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 C99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Qt binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Problemi rilevati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Supporto del protocollo . . . . . . . . . . . . . . . . . . . . . 20
5 X-Monitor 23
5.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.5 Flusso del programma . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.6 Problemi rilevati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.6.1 Qt Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 UI 27
6.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Analisi funzionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Definizione degli attori . . . . . . . . . . . . . . . . . . . . . . 28
6.2.2 Visione generale . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.2.1 UC-O1 - Gestione opzioni protocollo . . . . . . . . . 28
6.2.2.2 UC-O2 - Gestione feeds reali . . . . . . . . . . . . . 29
6.2.2.3 UC-O3 - Gestione feeds virtuali . . . . . . . . . . . 29
6.2.2.4 UC-O4 - Gestione devices . . . . . . . . . . . . . . . 30
6.3 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3.1 LuCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3.2 Feeds virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4 Problemi rilevati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.1 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.2 Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.3 Personalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 32
7 Conclusioni 35
7.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 35
7.2 Consuntivo ore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4 Valutazione retrospettiva . . . . . . . . . . . . . . . . . . . . . . . . 36
7.5 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.5.1 Scalabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.5.2 Gestione profili devices . . . . . . . . . . . . . . . . . . . . . . 37
A Convenzioni 39
B Convenzione sui requisiti 41INDICE ix Glossario 43
Elenco delle figure
1.1 Logo ThisOne! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.1 Logo Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Logo Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Logo Openproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Logo Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Logo Google Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 Logo Google Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7 Logo Doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Logo LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.9 Logo Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.10 Logo GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.11 Logo OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.12 Logo FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.13 Logo JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.14 Logo GDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15 Logo Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.16 Gantt di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Overview del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Topologia di rete di un sistema di monitoraggio SCADAg , © [2] . . . 18
4.3 APDU, © [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 ASDU, © [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Logo piattaforma Monet . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Diagramma ad alto livello 1 - Gestione opzioni protocollo . . . . . . 28
6.2 Diagramma ad alto livello 2 - Gestione feeds reali . . . . . . . . . . . 29
6.3 Diagramma ad alto livello 3 - Gestione feeds virtuali . . . . . . . . . 30
6.4 Diagramma ad alto livello 4 - Gestione devices . . . . . . . . . . . . 31
xELENCO DELLE TABELLE xi Elenco delle tabelle 2.1 Obiettivi prefissati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Rischi individuati per progetto formativo . . . . . . . . . . . . . . . 5 5.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1 Resoconto obiettivi raggiunti. . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Rapporto orario tra ore previste ed impiegate. . . . . . . . . . . . . . 36
Capitolo 1
Introduzione
1.1 L’azienda
ThisOne! è una società operante nell’ambito dell’Information and Communications
Technologyg con sede a Noventana (PD). I focus dell’azienda sono lo sviluppo,
l’integrazione e l’erogazione di servizi informatici per clienti privati. ThisOne! è
stata fondata da Vittorio De Zuane nel 2013 e ora gode di circa una decina di
collaboratori esterni.
Figura 1.1: Logo ThisOne!
1.1.1 Storia
Dopo varie esperienze nell’ambito delle tecnologie di rete come VoIPg , Vittorio De
Zuane è entrato nel mondo IoT nei primi anni 2000 e ha fondato ThisOne! nel 2013,
una delle prime startup nella zona nell’ambito IoT.
I principali obiettivi di ThisOne! sono la fornitura di hardware embedded, l’integra-
zione di sensoristica volta alla fruizione di dati provenienti da macchine industriali e
la comunicazione di dati tra devices attraverso protocolli di rete.
Di recente ThisOne! si sta spingendo verso il mondo dell’automazione industriale e
collabora a progetti di innovazione dell’industria con lo scopo di introdurre nuove
tecnologie e sistemi all’interno delle aziende. Questo si traduce nella creazione di
12 CAPITOLO 1. INTRODUZIONE
piattaforme per la gestione e analisi di dati, progettazione di sistemi autonomi di
trasporto e più in generale progetti di ricerca e sviluppo nell’ambito industriale.
1.1.2 Panoramica stage
Lo studente è entrato in contatto con ThisOne! nel Settembre 2018, e dopo vari
incontri e colloqui con il fondatore e proprietario di ThisOne!, ha cominciato il
periodo di stage ad Aprile 2019.
ThisOne! è stata un ottimo spunto per affacciarsi al mondo lavorativo e un’opportu-
nità senza pari per cominciare ad esplorare il campo non strettamente accademico.
ThisOne! ha saputo offrire un ottimo servizio di formazione e preparazione, adeguato
allo sviluppo del prodotto richiesto.
Lo scopo del lavoro di stage è lo studio e implementazione di IEC 60870-5-104 ai
fini della trasmissione di dati relativi a potenze elettriche.
1.1.3 Panoramica documento
Questo documento è organizzato come segue:
1. Capitolo 1 che descrive sommariamente l’azienda e il progetto di stage;
2. Capitolo 2 una panoramica dello stage;
3. Capitolo 3 dove vengono elencati gli strumenti e le tecnologie adoperate dallo
stagista in sede di stage;
4. Capitolo 4 che da un’anteprima di IEC 60870-5-104;
5. Capitolo 5 che descrive l’architettura (backend) progettata e implementata
in X-Monitor;
6. Capitolo 6 che descrive l’architettura (frontend);
7. Capitolo 7 dove vengono espresse alcune conclusioni e osservazioni post-stage;
8. Appendice A compendio sugli UCg ;
9. Appendice B compendio sui requisiti.Capitolo 2
Progetto di stage
2.1 L’offerta di stage
Lo scopo di questo progetto di stage è stato implementare il protocollo IEC 60870-5-
104 all’interno di un applicativo GNU/Linux per il prodotto Gatewayg X-Monitor.
Lo scopo dell’applicativo è la raccolta dati via radio (IEEE 802.15.4), modbus (RS485)
o TCP/IPg relativi a potenze elettriche consumo/produzione e la comunicazione
degli stessi verso la piattaforma Monet con protocollo IEC 60870-5-104. Lo studente
ha avuto il compito di realizzare la comunicazione con un gateway concentratore, il
quale poi comunica i dati raccolti alla piattaforma cloud di visualizzazione.
In seguito lo studente ha proseguito alla progettazione e codifica dell’interfaccia di
gestione di tale applicativo.
2.2 Panoramica dello stage
2.2.1 Obiettivi aziendali
Lo scopo del prodotto è offrire ai clienti di ThisOne! un nuovo servizio di monitoraggio
remoto. Il prodotto si pone l’obiettivo di facilitare il monitoraggio, l’acquisizione e
la visualizzazione di dati relativi a potenze elettriche.
2.2.2 Obiettivi formativi
Gli obiettivi che dovevano essere raggiunti durante lo stage sono riportati in tabella
2.1, caratterizzati da un identificativo, priorità e breve descrizione. L’identificativo
(riportato in breve con "ID"), è composto da un numero e da una lettera, la quale
può assumere i seguenti valori:
• O: per i requisiti obbligatori, vincolanti in quanto obiettivo primario richiesto
dal committente;
• D: per i requisiti desiderabili, non vincolanti o strettamente necessari, ma dal
riconoscibile valore aggiunto;
34 CAPITOLO 2. PROGETTO DI STAGE
ID Priorità Descrizione
O01 Obbligatorio Conoscenza metodologie e strumenti
linguistici per le interviste al cliente
O02 Obbligatorio Conoscenza del dominio embedded GNU/-
Linux
D01 Desiderabile Capacità di debug applicazioni scritte in
C/C++
D02 Desiderabile Capacità di usare tool di analisi di rete
(e.g Wireshark)
Tabella 2.1: Obiettivi prefissati
2.2.3 Rischi
Al fine di prevenire e contenere situazioni potenzialmente pericolose, durante il
periodo di stage, è stata redatta, in collaborazione con ThisOne!, un’analisi degli
ipotetici rischi che avrebbero potuto rallentare o danneggiare il lavoro di stage.
I maggiori rischi, la probabilità d’occorrenza, le conseguenze e le azioni di mitigazione
attuabili sono riportate nella tabella 2.2, dove 0 è il valore di rischio pressoché nullo
e 3 è il valore di massima criticità [1].
Id Nome P I Descrizione Rimedi
R1 Inesperienza 1 2 É altamente improbabi- Una possibile soluzione
del dominio le che lo studente non ottimale potrebbe esse-
abbia esperienza nel do- re un periodo di forma-
minio embedded GNU/- zione sul dominio assi-
Linux. Questa evenien- stito da un individuo
za però, potrebbe rallen- che sia in grado di chia-
tare la produzione della rire eventuali dubbi e
documentazione e degli difficoltà.
allegati tecnici.
R2 Valutazione 2 2 É possibile che nella pia- Per poter contenere que-
scadenze nificazione vengano sot- sto rischio è necessario
tovalutati aspetti tempo- considerare scadenze più
rali che possono portare stringenti nell’eventua-
a ritardi. lità che lo studente si
trovi in difficoltà.2.2. PANORAMICA DELLO STAGE 5
R3 Rapporti in- 3 1 É improbabile che lo stu- In caso di problematiche
terpersonali dente, nonostante venga tra colleghi è necessa-
nell’am- inserito in un ambiente rio rivolgersi al referen-
biente di nuovo e non familiare, te aziendale o all’ufficio
lavoro non riesca a collaborare risorse umane.
e interagire in maniera
efficiente.
R4 Confronto 3 3 É molto probabile che in- É stato consigliato l’uti-
con gli sorgano delle incompren- lizzo di strumenti profes-
stakeholder sioni tra lo studente e gli sionali.
stakeholder coinvolti nel
progetto.
Tabella 2.2: Rischi individuati per progetto formativo
Escludendo qualche incompresione tra lo studente e gli stakeholder (R4), non si
sono verificate altre situazioni di rischio, data un’ottima pianificazione a monte del
progetto.
Nel capitolo successivo si andranno ad elencare le varie tecnologie e i metodi che
sono stati adottati durante il periodo di stage.Capitolo 3
Strumenti e tecnologie
Gli strumenti e le tecnologie utilizzate nell’ambiente di lavoro durante lo stage sono
le seguenti:
3.1 Gestione di progetto
3.1.1 Versionamento
Per quanto riguarda il versionamento, l’azienda ha un Repositoryg Gitg privato nel
proprio server, il cui accesso in scrittura è stato dato allo stagista. Poichè git è
ampiamente usato dai membri dell’azienda non è stata cominciata nemmeno la
ricerca di altri metodi di versionamento. Il ramo master di tale repository comprende
il codice delle applicazioni correntemente installate e testate nel gateway. Per lo
studente è stato creato un branch di sviluppo di cui è stato fatto il merge a collaudo
completato. Come GUIg per Git è stato utilizzato Gitkg , un software minimale ma
efficace, sviluppato in GTK+g che ha permesso allo stagista di chiarire dubbi sui
commit nel corso dello sviluppo. Esso infatti, offre una visualizzazione grafica dei
branchg , commitg e tagg s che ne permette una comprensione immediata e, nonostante
la semplicità dell’interfaccia, espone tutti i comandi base di Git in maniera intuitiva.
Figura 3.1: Logo Git
3.1.2 Ticketing
Attualmente esistono molteplici tool per il ticketing in progetti collaborativi. A
fronte di un intenso e prolungato periodo decisionale tra i più popolari software, la
scelta sì è ridotta a due: Redmineg e Openprojectg .
• Lo sviluppo di Redmine è cominciato 13 anni fa da parte di Jean-Philippe
Lang. Si basa su tecnologie ormai datate (tra cui Perl) che però forniscono un
78 CAPITOLO 3. STRUMENTI E TECNOLOGIE
Figura 3.3: Logo Openpro-
Figura 3.2: Logo Redmine
ject
servizio di tutto rispetto. La sua robustezza e la possibilità di personalizzazione
hanno fatto si che fosse scelto come tool di ticketing e gestione di progetto;
• Openproject è molto simile a Redmine ma gode di una GUI nettamente più
intuitiva e facile da usare. É più recente e usato da più persone (grazie
all’offerta di membership e prezzi convenienti), ma ha una curva di learning
più ripida rispetto a quella di Redmine. Inoltre alcune core features possono
risultare difficili da utilizzare per i principianti.
3.1.3 Altri strumenti per la gestione di progetto
• Google Drive per la condivisione veloce e informale di file come guide, docu-
mentazioni, riferimenti utili e documenti informali;
• Google Calendar per la gestione degli eventi ed impegni;
• Google Mail per le email.
Figura 3.4: Logo Figura 3.5: Logo
Figura 3.6: Logo
Google Google
Google
Drive Calen-
Mail
dar
3.1.4 Documentazione
Gestendo decine di migliaia di righe di codice diventa difficile basarsi solo su commenti
e documentazione delle funzioni scritta direttamente nel codice sorgente; per questo
motivo si è scelto di documentare il codice sorgente con tool che supportavano vari
linguaggi e che permettevano la generazione automatica di documentazione finale su
vari formati (es. pdf, html).
Figura 3.7: Logo Doxygen
Figura 3.8: Logo LATEX3.2. AMBIENTE DI SVILUPPO 9
• Doxygen si è rivelato un’ottima scelta, dato che supporta il parsing di docu-
mentazione scritta in codice C++, Python e Lua (i più frequenti linguaggi
utilizzati durante lo sviluppo del prodotto). La stesura della documentazione
secondo il formato supportato da Doxygen non ha rappresentato un problema
dato che è un formato abbastanza libero e supportato da varie IDEg ;
• Usando doxygen, si è potuto generare la documentazione relativa in formato
pdf e latex.
3.2 Ambiente di sviluppo
3.2.1 Framework
Diversi framework sono stati analizzati per eseguire la codifica nel gateway data la
vasta e ampia disponibilità di scelta nel mondo embedded GNU/Linux. Tuttavia
lo studente e l’azienda si sono ridotti a scegliere tra Qt e GTK+. La principale
differenza tra i due framework è il linguaggio: Qt usa C++, GTK+ usa C. Alla fine
del periodo di scelta, l’azienda e lo studente hanno concordato per l’uso di Qt 4.8.6.
Figura 3.9: Logo Qt
Figura 3.10: Logo GTK+
• Qt è uno dei più famosi framework di sviluppo GUI cross-platform. La prima
release è datata 20 Maggio 1995: esso gode di una notevole quantità di tutorial,
documentazione e supporto tecnico. É stato scelto Qt 4.8.6 in quanto il gateway
non soddisfa i requisiti minimi per la versione 5. Inoltre Qt 4.8.6 ha un impatto
molto minore sul sistema rispetto a Qt 5;
• GTK+ è nato nel 1998 e anch’esso gode di un apprezzabile sostegno tecnico e
documentazione. Tuttavia, rispetto a Qt, offre solo componenti per GUI: non
offre librerie di networking, caching e bus di sistema, necessarie per lo sviluppo
dell’applicativo da installare nel gateway.
3.2.2 IDE
• Avendo scelto Qt come framework di sviluppo, l’IDE è quasi una scelta obbli-
gata, dato che Qt Creator (la IDE ufficiale sviluppata da e per Qt) rappresenta
un ottimo tool di sviluppo nel contesto Qt.10 CAPITOLO 3. STRUMENTI E TECNOLOGIE
3.2.3 Sistemi operativi
Nonostante il mondo embedded sia pieno di soluzioni e OSs per facilitare lo sviluppo
di gateways, le alternative adatte allo sviluppo del gateway X-Monitor erano solo
due.
Figura 3.11: Logo OpenWrt
Figura 3.12: Logo FreeBSD
• OpenWrt è un OS basato su Linux che è usato principalmente in gateway
domestici per routing del traffico di rete. Tutti i componenti sono stati
ottimizzati per pesare il meno possibile e essere installati occupando un limitato
spazio e memoria. ThisOne! e lo studente hanno concordato sulla scelta di
questa tecnologia;
• FreeBSD è una fork di BSDg , molto popolare nei primi anni 2000. Sebbene
sia leggero e stabile quanto OpenWrt esso non permette un’elevata persona-
lizzazione del prodotto: a differenza di Linux (che consiste principalmente in
un kernel scritto in C), FreeBSD comprende kernel, librerie e programmi per
l’utente infatti kernel. In più, per quanto riguarda il supporto agli sviluppatori,
FreeBSD offre relativamente poco supporto rispetto a Linux.
3.2.4 Configurazione
La gesione della configurazione è divisa in due moduli.
Figura 3.13: Logo JSON
• All’interno di OpenWrt la configurazione delle interfacce e servizi è gestita
da UCIg . La configurazione è particolarmente efficace ed efficiente dato l’alto3.3. PIANIFICAZIONE DEL LAVORO 11
grado di affidabilità e la semplicità di utilizzo che offre. Il tutto viene gestito
tramite un particolare set di files all’interno di specifiche cartelle.
• In aggiunta a UCI lo studente ha usato alcuni file in formato JSONg : essi sono
stati necessari per collegare varie parti di configurazione.
3.2.5 Debugging
• Nonostante l’IDE Qt Creator abbia aiutato notevolmente lo studente durante
la codifica del software, l’uso di un debugger per controllare crash e bug nel
software è stato necessario. Perciò si sono valutate molte opzioni di debug del
codice (anche Qt creator offre questa possibilità) ma lo studente, su consiglio
di ThisOne!, ha optato per l’uso di GDBg . É stato richiesto l’uso di 1/2 ore di
formazione relativa, ma dopo aver imparato i comandi di base lo studente ha
saputo arginare efficacemente gran parte dei bug scoperti a run-time.
• Per monitorare lo stato dei pacchetti spediti in rete lo studente ha usato
Wireshark. É uno degli strumenti più usati nel campo e ha permesso (grazie
all’aiuto di filtri) di captare e analizzare ogni singolo pacchetto messo in rete
da parte del gateway.
Figura 3.14: Logo GDB
Figura 3.15: Logo
Wireshark
3.3 Pianificazione del lavoro
Il lavoro assegnato è stato pianificato e diviso in quattro fasi. Le fasi sono state così
ripartite:
• Fase 1: formazione generale su IEC 60870-5-104 e embedded GNU/Linux
• Fase 2: progettazione architettura per lettura e output dati
• Fase 3: codifica architettura per lettura e output dati
• Fase 4: progettazione e codifica test su lettura e output dati
3.3.1 Fase 1: Formazione generale
ThisOne! ha fornito allo stagista una formazione pienamente soddisfacente per
quanto riguarda il mondo embedded GNU/Linux e in particolare l’implementazione
di protocolli di rete all’interno di embedded Linux devices.12 CAPITOLO 3. STRUMENTI E TECNOLOGIE
3.3.2 Fase 2: Progettazione architettura
Lo studente insieme a ThisOne! e lo stakeholder ha analizzato il dominio dell’ap-
plicazione e ideato una possibile soluzione. In particolare in queste due settimane
lo studente è stato continuamente in contatto con lo stakeholder per chiarire ogni
dubbio su come l’applicazione doveva agire.
Infine ThisOne! ha contribuito a preparare un test plant per lo studente al fine di
valutare e capire al meglio la situazione da codificare.
3.3.3 Fase 3: Codifica architettura
Dunque lo studente si è impegnato per due settimane per codificare le varie parti
dell’applicazione. Si fa notare che i numerosi schemi redatti nelle settimane precedenti
sono valsi utili alla scrittura del codice.
3.3.4 Fase 4: Progettazione e codifica test
Nella parte finale dello stage lo studente ha proceduto alla stesura di alcuni test
per verificare il funzionamento del prodotto sviluppato. In particolare, oltre a test
di unità, lo studente ha implementato test di integrazione di tutto il sistema, per
verificare il processo complessivo.
Figura 3.16: Gantt di stage3.4. RIEPILOGO DELLE ORE PREVISTE 13
3.4 Riepilogo delle ore previste
Durata in ore Descrizione dell’attività
38 Formazione sulle tecnologie
40 Progettazione architettura per lettura dati
12 Analisi del problema e del dominio applicativo
24 Progettazione architettura e APIs
4 Stesura documentazione relativa ad analisi e progettazione
40 Progettazione architettura per output dati
12 Analisi del problema e del dominio applicativo
24 Progettazione architettura e APIs
4 Stesura documentazione relativa ad analisi e progettazione
40 Codifica architettura per lettura dati
12 Analisi del problema e del dominio applicativo
24 Codifica APIs
4 Stesura documentazione relativa ad analisi e progettazione
40 Codifica architettura per output dati
12 Analisi del problema e del dominio applicativo
24 Codifica APIs
4 Stesura documentazione relativa ad analisi e progettazione
40 Progettazione e codifica test su lettura dati
12 Progettazione tests
24 Codifica tests
4 Stesura documentazione relativa a progettazione
40 Progettazione e codifica test su output dati
12 Progettazione tests
24 Codifica tests
4 Stesura documentazione relativa a progettazione
38 Collaudo Finale
30 Collaudo
5 Stesura documentazione finale
1 Incontro di presentazione della piattaforma
2 Live demo di tutto il lavoro di stage
Totale ore 316
Nel capitolo successivo lo studente andrà a definire nello specifico lo standard e il
protocollo IEC 60870-5-104 implementato.Capitolo 4
IEC 60870-5-104
Questo capitolo descrive il protocollo IEC-60870-5-104 e la relativa implementazione
in X-Monitor.
4.1 Il contesto
Gli elementi principali del sistema dove lo studente ha implementato IEC 60870-5-104
sono cinque:
• una lista di sensori (possibilmente che trasmettono dati con protocolli diversi);
• i sensori sono collegati in rete radio (IEEE 802.15.4) a un router X-Monitor;
• un router X-Monitor, dove lo studente ha implementato IEC 60870-5-104,
usando il framework Qt come base per l’applicazione;
• il router è collegato in rete e manda attraverso TCP/IP i messaggi, secondo
IEC 60870-5-104;
• la piattaforma Monet configura il router, riceve e visualizza i pacchetti dati.
Lo stagista si è occupato del collegamento router-Monet e dell’implementazione
di IEC 60870-5-104 nel router. Il Capitolo 5 si occuperà di dettagliare l’architettura
dell’applicazione sviluppata in Qt; nel Capitolo 6 lo studente andrà a descrivere
l’interfaccia web di gestione della configurazione.
Di seguito dunque una panoramica dello standard seguito.
4.2 Lo standard
Il protocollo IEC 60870-5-104 fa parte dello standard IEC 60870-5 che fornisce un
profilo di comunicazione per mandare messaggi di telecontrollog tra due sistemi
nell’ambito dell’automazione industriale di sistemi elettrici.
IEC 60870-5-104 fornisce l’accesso alla rete a IEC 60870-5-101 usando profili stan-
dard di trasporto. Nella pratica consegna messaggi IEC 60870-5-101 nello strato
applicativo (layer 7) di una rete usando TCP (2404 è la porta di default). IEC
60870-5-104 assicura la comunicazione tra la stazione di controllo e la sotto-stazione
1516 CAPITOLO 4. IEC 60870-5-104
Figura 4.1: Overview del sistema4.2. LO STANDARD 17
nella rete TCP/IPg . La comunicazione è basata sul modello client-serverg .
IECg ha definito lo standard 60870 per l’automazione di macchinari e sistemi
nel campo di potenze elettriche. La parte 5 dello standard fornisce un profilo di
comunicazione per lo scambio di tali messaggi. In particolare la parte 5 consta delle
seguenti parti:
• IEC 60870-5-1 Formati di trasmissione frame
• IEC 60870-5-2 Procedure di trasmissione
• IEC 60870-5-3 Struttura generale dei dati
• IEC 60870-5-4 Definizione e codifica dei dati applicazione
• IEC 60870-5-5 Funzioni di base dei delle applicazioni
• IEC 60870-5-6 Linee guida per i test
IEC ha anche generato standard per attività di telecontrollo, trasmissione di quantità,
scambio dati e accesso alla rete:
• IEC 60870-5-7 Estensione di sicurezza a IEC 60870-5-101 e IEC 60870-5-104
• IEC 60870-5-101 Attività di telecontrollo di base
• IEC 60870-5-102 Trasmissione di quantità
• IEC 60870-5-103 Interfaccia informativa delle attrezzature di protezione
• IEC 60870-5-104 Accesso alla rete per IEC 60870-5-101
• IEC 60870-5-601 Test di controllo per IEC 60870-5-101
• IEC 60870-5-604 Test di controllo per IEC 60870-5-104
4.2.1 Indirizzamento
IEC 101 definisce l’indirizzamento sia nel livello di accesso alla rete che al livello
dell’applicazione. L’indirizzo di un dispositivo (o OAg ) e l’indirizzo ASDUg (o CAg )
sono forniti per l’identificazione della stazione finale.
1. L’indirizzo del dispositivo è il numero di identificazione del dispositivo
2. Ogni dispositivo sulla rete di comunicazione ha un indirizzo comune di ASDU.
Combinando CA e OA riusciamo ad ottenere un indirizzo univoco per ogni
dato elemento18 CAPITOLO 4. IEC 60870-5-104
Figura 4.2: Topologia di rete di un sistema di monitoraggio SCADAg , © [2]
4.2.2 Comunicazione
Un concetto importante nell’indirizzamento secondo IEC 60870-5 è la differenza tra
controllare e monitorare la stazione. Viene assunto per ipotesi che il sistema abbia
una struttura gerarchica a controllo centralizzato: ogni stazione è o una stazione di
controllo o una stazione controllata (vedi [3]).
• La stazione controllata viene monitorata o comandata da una stazione master
(RTU). Viene anche chiamata outstation, remote station, RTU, 101-Slave o
104-Server
• La stazione di controllo è una stazione in cui viene eseguito un controllo delle
stazioni esterne (SCADA). In genere, è un PC con sistema SCADA; può anche
essere un RTU32
IEC 101/104 definisce diverse direzioni della comunicazione:
• Monitor, dalla stazione controllata (RTU) alla stazione di controllo (PC)
• Control, dalla stazione di controllo, tipica di un sistema SCADA, verso la
stazione controllata, tipicamente una RTU
• Reversed, quando la stazione monitorata invia comandi e la stazione di controllo
sta inviando dati4.3. IMPLEMENTAZIONE 19
4.2.3 ASDU
L’ASDU contiene 2 settori principali:
1. Data unit identifier che definisce il tipo specifico di dati e include informazioni
riguardo a COTg
2. i dati stessi, cioè una lista di IOg (fino ad un massimo di 127)
4.2.4 IO
Ogni IO in un ASDU ha un univoco IOAg . L’indirizzo è usato come destinazione
nella direzione di controllo, e come origine nella direzione di monitor. Tutti gli
IO all’interno di uno stesso ASDU devono avere lo stesso tipo: se più IO con tipo
diverso devono essere trasmessi allora sono necessari più ASDU.
I tipi di IO sono molteplici e spaziano ogni possibile tipo di dato proveniente da un
sistema che fornisce dati relativi a potenze elettriche. In particolare, nel lavoro di
stage, è stato quasi sempre richiesto di mandare IO con tipi:
• 9 (0x09), valori misurati, normalizzati (tra 0 e 1)
• 13 (0x0D), valori misurati a 16 bit (short)
Figura 4.3: APDU, © [2]
Figura 4.4: ASDU, © [2]
4.3 Implementazione
IEC 60870-5-104 è stato prima implementato in una libreria C; in seguito definendo
dei Qt binding a livello dell’applicazione.20 CAPITOLO 4. IEC 60870-5-104
4.3.1 C99
Per l’implementazione lo studente, su consiglio dell’azienda, si è basato sulla libreria
fornita da MZ Automation GmbH, leader tedesco nello sviluppo e consulenza di
protocolli di comunicazione industriale come IEC 61850, IEC 60870-5, TASE.2/ICCP
e DNP3.
La libreria è scritta in C (versione 1999) in modo da poter essere supportata da più
devices possibili. Essa è open-source e scaricabile tramite il sito ufficiale dell’azienda
o da [4].
4.3.2 Qt binding
A livello Qt, lo studente ha implementato un QTimer per eseguire il tick dello slave
IEC e quindi mantenere il socket di connessione aperto.
Inoltre il componente Qt implementa il design patterng proxy in quanto modera e
controlla l’accesso (semplificandolo) verso lo slave IEC: in questo modo l’applicazione
chiama soltanto un subset delle funzioni di IEC, togliendo ogni complessità dal
codice.
4.4 Problemi rilevati
Come succede quasi sempre in ambito embedded i problemi riscontrati sono stati
molteplici ma tutti risolvibili in meno di poche ore. L’integrazione con Monet ha
decisamente caratterizzato l’ultima parte della fase di test e collaudo del prodotto.
Monet è la piattaforma IoT che supporta IEC 60870-5-104 con cui il router deve
interfacciarsi. Essa è particolarmente adatta alla visualizzazione e gestione di dati
relativi a smart gridg e più in generale a smart cityg [5].
Figura 4.5: Logo piattaforma Monet
4.4.1 Supporto del protocollo
Uno dei problemi riscontrati è la difficoltà di Monet (o della versione di Monet
fornita al cliente) di supportare i tipi di IO. In particolare lo studente ha notato che,
seppur trasmettendo ASDU secondo il protocollo, Monet rilevava solo parte degli IO
in determinati ASDU e solamente IO di tipo 9 (0x09), 11 (0x0B), 13 (0x0D) e
15 (0x0F).
Nonostante ciò, il cliente è stato soddisfatto della trasmissione di IO in quanto i tipi
richiesti erano solamente 9 (0x09) e 11 (0x0B).4.4. PROBLEMI RILEVATI 21 Nel capitolo successivo verrà descritta l’architettura (backend) dell’applicazione installata nel gateway.
Capitolo 5
X-Monitor
Questo capitolo descrive l’architettura dell’applicazione prodotta e installata in
gateway X-Monitor.
5.1 Requisiti
5.1.1 Requisiti funzionali
La tabella 6.1 contiene, per ciascun requisito funzionale, un codice identificativo
affiancato da una breve descrizione.
ID Descrizione
R-FO1 L’applicazione deve poter essere eseguita in background come
servizio Linux da command-line.
R-FO2 L’applicazione, una volta configurato il master, deve mandare
i dati esattamente ogni 4 secondi
R-FF2.1 L’applicazione deve poter essere in grado di cambiare l’inter-
vallo di tempo in cui mandare i dati senza dover essere fatta
ripartire
R-FO3 L’applicazione deve implementare IEC 60870-5-104 per la
trasmissione dei dati
R-FO4 L’applicazione deve poter essere configurata via web
Tabella 5.1: Requisiti funzionali
Non ci sono stati particolari requisiti di prestazioni, né sicurezza poiché il gateway
fornito ha prestazioni molto superiori rispetto alla media di mercato (vedi [6]) e
essendo l’applicazione inserita in un contesto dove la maggior parte del tempo CPU
era impiegato nella gestione di I/O.
2324 CAPITOLO 5. X-MONITOR
5.2 Architettura
L’architettura dell’applicazione consta di 3 livelli:
1. il livello alto che costituisce l’interfaccia dell’applicazione con i controlli a livello
OS (per mettere in background il processo è richiesta la gestione di un PID) e
le chiamate verso il middlewareg
2. il worker (che rappresenta il middleware) che agisce direttamente sullo slave
IEC
3. il livello basso (rappresentato dallo slave IEC) che implementa IEC 60870-5-104
5.3 Cache
Per ottimizzare la lettura dei dati, l’applicazione si appoggia a un modulo sviluppato
direttamente dall’azienda che permette il caching dei dati in memoria.
La gestione della cache viene eseguita da questo modulo e consta di una parte di
lettura dati (attraverso i protocolli implementati) e di caching degli stessi in memoria:
poi questa memoria potrà essere letta tramite comandi D-Busg . In particolare il
processo applicativo fa chiamate D-Bus verso il processo di caching che risponde con
i dati richiesti.
Questo sistema inoltre, permette di modulare le parti dell’applicazione in modo
efficace: l’applicazione può essere testata separatamente dal componente di caching
e viceversa.
5.4 Configurazione
Rispecchiando la gestione dei messaggi in IEC 60870-5-104, la gestione della configu-
razione dell’applicazione è divisa in due moduli:
• configurazione UCI (a livello OSg ) per la gestione delle opzioni di protocollo
(i.e OA, CA, porta di comunicazione ...), d’ora in poi CU
• files JSON per la gestione dei profili dei devices, dei registri e delle feeds, d’ora
in poi CJ
CU è necessario per configurare il protocollo via LuCI: per di più è anche di facile
utilizzo e parsing. Tuttavia non permette una gestione facile e precisa da Qt delle
molteplici opzioni. Dunque l’azienda ha proposto di utilizzare il formato JSON per
racchiudere i dati più complessi e difficili da organizzare. CJ si è pertanto resa
necessaria.
CJ è nella pratica implementata con una struttura ad albero di files JSON: a partire
da una cartella root, ogni device ha un univoco file JSON che ne descrive il profilo
(cioè numero, formato e struttura dei registri nel device).5.5. FLUSSO DEL PROGRAMMA 25
5.5 Flusso del programma
Come indica R-FO2 l’applicazione è costruita attorno a un loop che esegue la stessa
azione ogni 4 secondi (tempo modificabile da configurazione). Dopo una fase iniziale
di setup (interfacce, cache e lettura configurazione), ad ogni timeout avviene:
1. lettura cache devices e lettura configurazione
2. per ogni device nella configurazione:
(a) lettura cache (registri)
(b) packing dei valori dei registri secondo quanto specificato dal feed (virtuale
o meno)
(c) output di (molteplici) IO in ASDU secondo IEC 60870-5-104
3. sleep del tempo specificato (default è 4 secondi)
5.6 Problemi rilevati
Sebbene l’implementazione del protocollo sia risultata correttamente eseguita, come
ha dimostrato il collaudo e l’esecuzione dei test a fine codifica, il cliente ha riscontrato
vari problemi nel prodotto. Tutti sono stati risolti nel più breve tempo possibile
(preventivato nelle ore di sviluppo del prodotto); tuttavia un problema riguardante
il collegamento dello slave IEC allo strato applicativo (e la sua interfaccia Qt) è
risultato richiedere una soluzione particolare.
5.6.1 Qt Timer
Il problema riguarda il timer che dovrebbe far scattare il timeout e il conseguente
invio di dati alla piattaforma Monet. Il problema si riduce al fatto che viene usato
un QTimer al posto di un timer preciso (a livello OS).
Infatti il QTimer non è abbastanza preciso (se il timer viene fissato a 4 secondi, esso
scatta in un intervallo tra i 3.95 e i 4.05 secondi): perciò l’azienda ha proposto di
utilizzare un thread sottostante che manda un segnale all’applicazione che indica
che c’è stato un timeout.
In futuro questa soluzione non sarà scalabile in quanto a seconda del numero di
feeds (e quindi di devices di cui si dovrà eseguire il parsing) il tempo richiesto al
parsing della configurazione è variabile.
Nel capitolo successivo lo studente darà una panoramica sulla parte frontend del
prodotto software sviluppato.Capitolo 6
UI
Questo capitolo descrive la gestione dell’interfaccia dell’applicazione installata in
gateway X-Monitor.
6.1 Requisiti
6.1.1 Requisiti funzionali
La tabella 6.1 contiene, per ciascun requisito funzionale, un codice identificativo
affiancato da una breve descrizione.
ID Descrizione
R-FO1 L’interfaccia deve generare file di configurazione interpretabili
anche da command-line (e.g JSON)
R-FO2 L’interfaccia deve poter gestire opzioni sia di IEC 60870-5-104
sia dell’applicazione installata in gateway X-Monitor
R-FO4 L’interfaccia deve poter creare nuove feedg combinando
aritmeticamente feed già esistenti
R-FF4 L’interfaccia web dell’applicazione deve poter gestire
dinamicamente i devices in rete
Tabella 6.1: Requisiti funzionali
6.2 Analisi funzionale
Lo scopo del lato frontend del progetto è la gestione della configurazione delle feeds
e delle opzioni di IEC 60870-5-104.
2728 CAPITOLO 6. UI
6.2.1 Definizione degli attori
Gli attori principali coinvolti nel progetto si distinguono in utenti fisici e in sistemi
esterni che interagiscono con il gateway.
Gli attori identificati come utenti fisici, che utilizzano l’interfaccia utente sono i
seguenti:
• Operatore: è un dipendente del cliente a cui è stato affidato il compito della
gestione della configurazione del gateway
• Amministratore: gode degli stessi permessi dell’operatore, ma può anche creare,
modificare, rimuovere nuovi operatori. Esso gestisce l’accesso al gateway.
Gli attori identificati come sistemi esterni, che interagiscono con specifiche
funzionalità dell’interfaccia, sono i seguenti:
• OS installato in X-Monitor, cioè OpenWrt
• backend installato in X-Monitor, d’ora in poi B-XM
6.2.2 Visione generale
6.2.2.1 UC-O1 - Gestione opzioni protocollo
Figura 6.1: Diagramma ad alto livello 1 - Gestione opzioni protocollo
• Attori: Operatore, Amministratore, OpenWrt
• Descrizione: Le funzionalità di gestione delle opzioni di IEC 60870-5-104
vengono esposte agli attori fisici.6.2. ANALISI FUNZIONALE 29
• Pre-condizioni: Gli attori fisici devono necessariamente eseguito l’accesso
alla piattaforma. Non ci devono essere errori sintattici nella configurazione
attuale (che viene parsed da UCI)
• Post-condizioni: Un nuovo file di configurazione viene scritto applicando il
modello UCI: l’applicazione Qt si riavvierà in automatico con le nuove opzioni
6.2.2.2 UC-O2 - Gestione feeds reali
Figura 6.2: Diagramma ad alto livello 2 - Gestione feeds reali
• Attori: Operatore, Amministratore, B-XM
• Descrizione: Le funzionalità di gestione delle feeds reali vengono esposte agli
attori fisici
• Pre-condizioni: Gli attori fisici devono avere necessariamente eseguito l’acces-
so alla piattaforma. Non ci devono essere errori sintattici nella configurazione
attuale
• Post-condizioni: Un nuovo file di configurazione JSON viene scritto: l’appli-
cazione Qt si riavvierà in automatico con le nuove opzioni
6.2.2.3 UC-O3 - Gestione feeds virtuali
• Attori: Operatore, Amministratore, B-XM30 CAPITOLO 6. UI
Figura 6.3: Diagramma ad alto livello 3 - Gestione feeds virtuali
• Descrizione: Le funzionalità di gestione delle feeds virtuali vengono esposte
agli attori fisici
• Pre-condizioni: Gli attori fisici devono avere necessariamente eseguito l’acces-
so alla piattaforma. Non ci devono essere errori sintattici nella configurazione
attuale
• Post-condizioni: Un nuovo file di configurazione JSON viene scritto: l’appli-
cazione Qt si riavvierà in automatico con le nuove opzioni
6.2.2.4 UC-O4 - Gestione devices
• Attori: Operatore, Amministratore, OpenWrt
• Descrizione: Le funzionalità di gestione dei devices vengono esposte agli
attori fisici
• Pre-condizioni: Gli attori fisici devono avere necessariamente eseguito l’acces-
so alla piattaforma. Non ci devono essere errori sintattici nella configurazione
attuale (di cui viene fatto il parsing da UCI)
• Post-condizioni: Un nuovo file di configurazione viene scritto applicando il
modello UCI: l’applicazione Qt si riavvierà in automatico con le nuove opzioni6.3. ARCHITETTURA 31
Figura 6.4: Diagramma ad alto livello 4 - Gestione devices
6.3 Architettura
Per quanto riguarda l’architettura del front-end, lo studente si è basato sul framework
MVCg di LuCI, il default in OpenWrt.
LuCI usa i file di configurazione UCI come modello. Adotta CBIg , un linguaggio di
configurazione, per trasformare un file UCI in HTML che andrà renderizzato nelle
pagine web. Il controllore è rappresentato da una serie di script Lua.
6.3.1 LuCI
LuCI ha un semplice processore di template basato su espressioni regolari, che esegue
il parsingg dei file HTML trasformandoli in funzioni scritte in Lua. La più semplice
forma di un template è un file HTML. Verrà renderizzato senza parsing.
In LuCI ogni template è un oggetto con un proprio scope. Quindi potrà essere
istanziato e ogni oggetto avere un proprio scope. LuCI sopporta svariati markup
speciali racchiusi tra i tag .
6.3.2 Feeds virtuali
Per permettere la creazione e modifica di feed virtuali (cioè combinazioni aritmetiche
di più feeds reali) lo studente ha adottato i seguenti accorgimenti:
• i nomi delle feeds (reali e virtuali) devono rispettare un’espressione regolare ben
definita, in modo che quando avverrà il parsing dell’espressione virtuale, non32 CAPITOLO 6. UI
ci sarà possibilità d’errore nell’individuare quali sono le operazioni aritmetiche
e quali sono i nomi delle feeds
• le operazioni aritmetiche disponibili sono solo un subset delle operazioni mate-
matiche usate in ambito ingegneristico (cioè +, -, ·, ÷, ˆ). Per la combinazione
di feeds per mezzo di operazioni più complesse è possibile adoperare i tipi
più adatti secondo quanto specificato da IEC 60870-5-104 (es. IO di tipo 15
(0x0F)), 16 (0x10) ...)
6.4 Problemi rilevati
6.4.1 Debug
Essendo l’architettura del sistema modulare, lo studente ha solamente costruito i
moduli che necessitavano alla creazione e gestione delle APIs: questo ha fatto sì che
fosse difficile e complicato il debugging della singola route.
Inoltre il server deve essere fatto ripartire ogni volta che una route viene modificata
o aggiunta.
6.4.2 Documentazione
Sebbene OpenWrt sia molto supportato e popolare (soprattutto negli ultimi anni) è
pur sempre un OSSg sviluppato da volontari, dunque la qualità della documentazione
può risultare scadente rispetto a software professionali (o supportati direttamente
da compagnie private).
Un esempio di documentazione scadente che ha creato non pochi problemi è dato
dallo sviluppo dell’interfaccia usata per la gestione delle feed virtuali. Lo studente,
su consiglio dell’azienda, ha cominciato a creare l’interfaccia basandosi sul modello
Table. Dopo diverse ore di sviluppo e conseguente debug, lo studente si è risoluto ad
estendere invece il modello Map, ufficialmente non ottimizzato per supportare i tipi
di dato di quell’interfaccia, ma unica soluzione adatta a superare lo scoglio.
Lo studente, con l’aiuto dell’azienda, è riuscito a capire il motivo del bug solo dopo
ore passate ad analizzare il codice sorgente, essendo la documentazione poco chiara
riguardo al problema.
6.4.3 Personalizzazione
Per quanto riguarda la personalizzazione dell’interfaccia, OpenWrt offre poche possi-
bilità di integrazione con framework front-end. Le uniche personalizzazioni, senza
riscrivere in gran parte il framework, sono relative all’uso di Javascript e CSS.
Questo potrebbe creare problemi in quanto il cliente potrebbe richiedere funziona-
lità avanzate, disponibili solo in framework front-end più recenti. D’altra parte il
front-end di OpenWrt è uno dei più solidi e robusti che ci siano sul mercato.
A seconda del progetto, va valutato il trade-off tra robustezza e personalizzazione; in
questo caso, nel progetto di stage, il framework di front-end disponibile in OpenWrt
è stato sfruttato al massimo in modo da ottenere le funzionalità richieste dal cliente.6.4. PROBLEMI RILEVATI 33 Nel capitolo successivo lo studente trarrà le dovute conclusioni e osservazioni di fine stage.
Capitolo 7
Conclusioni
In questo capitolo vengono elencati gli obiettivi prefissati, le conoscenze e tecniche
apprese durante il periodo il periodo di stage, il consuntivo delle ore e la valutazione
retrospettiva dell’esperienza di stage.
7.1 Raggiungimento degli obiettivi
Gli obiettivi obbligatori, posti all’inizio del periodo di stage, sono stati tutti raggiunti.
Come visibile in tabella 7.1 lo studente non è riuscito a raggiungere il secondo
obiettivo facoltativo per mancanza di tempo.
ID Priorità Descrizione Completamento
O01 Obbligatorio comunicazione di dati verso la Soddisfatto
piattaforma Monet
O02 Obbligatorio utilizzare IEC 60870-5-104 per Soddisfatto
trasmissione dati
D01 Desiderabile configurabilità via interfaccia web Soddisfatto
del prodotto
D02 Desiderabile aggiungere registri virtuali che sa- Soddisfatto
ranno differenze, moltiplicazione per
una costante di uno o più registri
fisici
F01 Facoltativo gestione dinamica devices Soddisfatto
F02 Facoltativo gestione upgrade del software Non soddisfatto
Tabella 7.1: Resoconto obiettivi raggiunti.
3536 CAPITOLO 7. CONCLUSIONI
7.2 Consuntivo ore
Il progetto di stage ha impiegato 316 ore, in linea con quanto previsto. La ripartizione
prevista delle ore è stata rispettata, come mostra la tabella 7.2.
Attività Preventivo Consuntivo
Formazione sulle tecnologie 38 40
Progettazione architettura per lettura dati 40 35
Progettazione architettura per output dati 40 45
Codifica architettura per lettura dati 40 33
Codifica architettura per output dati 40 35
Progettazione e codifica test su lettura dati 40 45
Progettazione e codifica test su output dati 40 42
Collaudo Finale 38 41
Tabella 7.2: Rapporto orario tra ore previste ed impiegate.
7.3 Conoscenze acquisite
Durante l’esperienza di stage lo studente ha avuto la possibilità di acquisire cono-
scenze su embedded GNU/Linux e delle entità che ne prendono parte, in particolare
OpenWrt e UCI. Lo studente ha avuto la possibilità di apprendere standard indu-
striali come IEC 60870-5-104.
Una volta apprese queste nozioni lo studente si è potuto cimentare nella progettazio-
ne e codifica dell’implementazione di IEC 60870-5-104 usando tecnologie come Qt.
Infine lo studente ha potuto testare e validare il tutto secondo pratiche e standard
industriali.
7.4 Valutazione retrospettiva
• L’esperienza di stage ha permesso allo studente di ampliare le proprie cono-
scenze in ambito embedded GNU/Linux, ma non solo: ha contribuito alla sua
formazione in campo progettuale e ha rappresentato un’ottima sfida e punto
di partenza verso sviluppi futuri nel settore
• Dal punto di vista personale, le relazioni instaurate con le persone che circon-
davano lo studente durante il periodo di stage rappresentano un forte legame
che accompagnerà lo studente nel futuro. Lo studente crede di essere stato
fortunato ad aver trovato un’azienda dove non solo importavano le conoscenze
tecniche ma anche la persona stessa. Interessante notare come le persone che
circondavano lo studente durante le ore passate in azienda abbiano potuto in-
fluire positivamente nel lavoro dello stagista anche quando non c’era passaggio7.5. SVILUPPI FUTURI 37
di conoscenze tecniche: l’ambiente di lavoro è molto importante per un’ottima
riuscita di progetto.
• A seguito del collaudo finale da parte del proponente, lo studente e l’azienda
sono rimasti piacevolmente sorpresi che il proponente non ha trovato problemi
nel prodotto, ma anzi ha accennato ad una possibile nuova collaborazione
nel prossimo futuro. Anche dal punto di vista interno il prodotto è di buona
fattura.
• Infine, in merito alle tecnologie usate, lo studente conferma che sono estrema-
mente valide e utili nel ambito. Lo studente non crede che avrebbe trovato
migliori tecnologie per eseguire il prodotto.
7.5 Sviluppi futuri
7.5.1 Scalabilità
La soluzione adottata prevede di scansionare file di configurazione e cache alla ricerca
dei devices di cui mandare i dati. Questa è, per ragioni architetturali, una ricerca
con complessità O(n) dove n è il numero di devices.
Ciò fa si che in ambiente di produzione (cioè migliaia di devices) il processo di lettura
cache e ricerca potrebbe occupare più del tempo di intervallo entro cui mandare i dati.
Perciò è necessario cambiare dinamicamente l’istante di tempo in cui cominciare ad
eseguire il loop al cuore dell’algoritmo in modo da compensare il numero elevato di
devices da cercare.
Ciò, ad avviso dello studente, è solo possibile grazie a tanti tentativi e prove empiriche.
7.5.2 Gestione profili devices
Al momento, la soluzione proposta non ammette modifica, inserimento o rimozione
di profili dei devices. Il cliente quindi, deve andare manualmente a scrivere sul disco
del gateway il nuovo profilo.
Una feature che potrebbe aiutare la gestione del sistema è un’interfaccia web dedicata
appositamente alla gestione dei profili di ogni devices.Appendice A
Convenzioni
I casi d’uso definiti sono classificati secondo la seguente convenzione:
UC- + [Priorità] + [Codice]
La Priorità stabilisce il livello di importanza e urgenza di un certo scenario all’interno
del sistema. Essa può assumere i seguenti valori:
• Obbligatorio
• Desiderabile
• Facoltativo
Il Codice è un attributo numerico che identifica univocamente il caso d’uso. L’attri-
buto è costruito gerarchicamente. Tale attributo è strutturato come segue:
UC-Ox.y
• Codice genitore: (indicato dalla lettera x nell’esempio) rappresenta il codice
di livello più alto all’interno del caso d’uso e viene identificato come un caso
d’uso meno specifico rispetto a quello preso in esame;
• Codice identificativo: (indicato dalla lettera y nell’esempio), rappresenta il
codice di livello più basso all’interno del caso d’uso. Viene identificato con un
valore numerico.
39Appendice B
Convenzione sui requisiti
I requisiti sono classificati secondo la seguente convenzione:
R- + [Tipologia] + [Priorità] + [Codice]
La Tipologia definisce a quale tipologia appartenga un certo requisito. L’attributo è
utile per distinguere e separare i requisiti nel tracciamento dei requisiti. L’attributo
può assumere solo i seguenti valori:
• Funzionale (codice F) per denotare i requisiti che definiscono unna funzione
del sistema e il suo comportamento
• Prestazionale (codice P) per i requisiti che si riferiscono alle prestazioni del
sistema
• Qualità (codice Q) per i requisiti che definiscono la qualità del prodotto
Priorità stabilisce il livello di importanza di un certo requisito all’interno del sistema,
essa può assumere solo i seguenti valori:
• Obbligatorio
• Desiderabile
• Facoltativo
Codice è un attributo numerico che identifica univocamente il requisito.
41Puoi anche leggere
