Implementazione di IEC 60870-5-104 in gateway X-Monitor - SIAGAS

Pagina creata da Matteo Fontana
 
CONTINUA A LEGGERE
Implementazione di IEC 60870-5-104 in gateway X-Monitor - SIAGAS
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
Implementazione di IEC 60870-5-104 in gateway X-Monitor - SIAGAS
Stefano Fogarollo: Implementazione di IEC 60870-5-104 in gateway X-Monitor, Tesi
di laurea, © 18 Luglio 2019.
Implementazione di IEC 60870-5-104 in gateway X-Monitor - SIAGAS
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

                                        iv
Abstract

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.

                                          v
Norme 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;

                                        vi
Indice

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

                                                  vii
viii                                                                                                                             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                                                                                                              41
INDICE      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

                                          x
ELENCO 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

                                           1
2                                                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;

                                           3
4                                               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

                                           7
8                                  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 LATEX
3.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’alto
3.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 stage
3.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

                                         15
16                           CAPITOLO 4. IEC 60870-5-104

     Figura 4.1: Overview del sistema
4.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 elemento
18                                                   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 dati
4.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.

                                           23
24                                                           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.

                                         27
28                                                                  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-XM
30                                                                   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 opzioni
6.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, non
32                                                                  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.

                                            35
36                                                    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 passaggio
7.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.

                                           39
Appendice 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.

                                            41
Puoi anche leggere