Università degli studi di Cagliari Facoltà di Ingegneria e Architettura
Corso di laurea in Ingegneria Elettrica ed Elettronica
Relazione finale di tirocinio presso Vitrociset S.p.A.
Relatore:
Prof. G. Armano
Presentata da:
Marco Frau Matr. 70/87/65096
A.A. 2017 / 2018
2
Indice
1. Svolgimento del tirocinio pag. 3
2. Storia dell’azienda Vitrociset pag. 4
3. Introduzione al framework Qt pag. 5
a. Il framework Qt
b. Cenni di programmazione a eventi
4. Introduzione all’ Electronic Warfare pag. 8
a. Generalità
b. Requisiti di un sistema EW
5. Simulazione di scenari di minaccia pag. 11
6. Comando remoto di strumentazione per misurazione tramite SCPI pag. 14 7. Monitoraggio di dispositivi tramite protocollo SNMP pag. 18
8. Conclusioni pag. 22
9. Bibliografia pag. 23
3
1. Svolgimento del tirocinio
Il tirocinio si è svolto presso l’azienda Vitrociset S.p.A, presso lo stabilimento di Capo San Lorenzo (CA), dal 08 Gennaio 2018 al 26 Marzo 2018, per un totale di 328 ore.
Durante il primo mese, sono stato introdotto al Framework Qt per lo sviluppo di applicazioni in linguaggio di programmazione C++, nel secondo mese sono stato assegnato ad un progetto nell’ambito dell’Electronic Warfare (EW) per la simulazione di scenari di minaccia elettronica.
In questo secondo ambito, ho provveduto allo sviluppo delle librerie C++ per la comunicazione con la strumentazione di misura, in particolare un analizzatore di spettro Keysight, e con strumentazione per generazione di segnali. Per la comunicazione è stata sviluppata una libreria per l’interfacciamento mediante comandi SCPI. Inoltre, è stata implementata una libreria che utilizza il protocollo di comunicazione Simple Network Manager Protocol (SMNP) per il monitoraggio di un dispositivo di pressurizzazione.
Il progetto ha richiesto l’analisi dei requisiti a partire da una specifica software e da una specifica architetturale, e la stima delle ore necessarie per soddisfare ogni requisito.
Successivamente, è stata studiata l’implementazione di socket TCP e UDP per la comunicazione dei dati verso gli strumenti, e l’utilizzo di metodi di serializzazione via XML.
4
2. Storia dell’azienda Vitrociset
L’azienda Vitrociset nasce nel 1992 dall’incorporazione delle società CISET e di Vitroselenia: CISET, Compagnia Italiana Servizi Tecnici, nata nel 1970 e specializzata nella manutenzione di sistemi tecnici per il controllo del traffico aereo in ambito sia civile che militare; Vitroselenia, che dagli anni ’60 operava nella logistica per la Difesa.
Nel 2009, l’azienda acquisisce Enterprise Digital Architects S.p.A., nata nel 2000 da uno spin-off di Ericsson e attiva nell’ICT in ambito di Polizie e Pubblica Amministrazione.
Vitrociset è attiva anche nel settore difesa e spazio, ed ha curato la realizzazione del segmento di terra del primo test per il lanciatore Vega, tra cui torre di lancio, centro missione e bunker.
Nel 2011 l’azienda inaugura il proprio centro di Ricerca e Sviluppo internazionale (R&D), distribuito tra le sedi di Roma, Napoli, Capo San Lorenzo, e Transinne in Belgio.
Nell’ultimo periodo, Vitrociset con il suo centro di Ricerca e Sviluppo si è aggiudicata tre progetti nell’ambito Smart Cities e Communities.
5
3. Introduzione al framework QT 3.a Il framework Qt
Qt è un framework sviluppato in C++ dall’azienda Trolltech nel 1990 per lo sviluppo di applicazioni desktop, embedded e mobile. Utilizza un pre-processore chiamato MOC “Meta Object Compiler” che permette di estendere il linguaggio C++ con funzionalità aggiuntive come il meccanismo di gestione eventi “signals and slots”. Prima della compilazione i sorgenti C++ estesi sono letti dal MOC e viene generato un codice C++ standard. Le applicazioni o le librarie sviluppate con Qt possono essere poi compilate con compilatori standard come MinGW o GCC. Attualmente è supportato dall’azienda The Qt Company.
Qt offre pieno supporto per i sistemi Windows, Linux e macOS. Inoltre è possibile sviluppare anche applicazioni per Android e iOS. Con opportuni plugin si può utilizzare il framework per lo sviluppo in linguaggi Java, Python, C, Perl e PHP.
Dispone di una grande varietà di librerie per la gestione multi piattaforma dei file, l’accesso ai database SQL e il parsing di file XML.
Il framework, inoltre, dispone di supporto per grafica 3D per applicazioni di Virtual Reality (VR) / Augmented Reality (AR), nonché grafica 2D specifica per dispositivi embedded e focalizzata sul risparmio della batteria dei dispositivi mobili.
Possono essere realizzate interessanti applicazioni in ambito automotive, automation, Internet of Things, e medicale.
L’azienda The Qt Company supporta inoltre l’ambiente di sviluppo QtCreator che rappresenta un ottimo tool per il design visuale di interfacce grafiche.
In Qt vengono specificati gli QWidget, oggetti software che rappresentano la classe di partenza per tutti gli elementi dell’interfaccia grafica. Un QWidget può rilevare eventi da
6 mouse, tastiera o l’interazione con altri oggetti dell’interfaccia. Specializzazioni di questa classe consentono di realizzare diversi widget che implementano la funzione desiderata (es.
pulsanti, caselle di testo, menù).
Attraverso l’ambiente QtCreator è possibile posizionare gli Widget nell’ambiente grafico direttamente tramite un semplice drag and drop.
3.b Cenni di programmazione a eventi
La programmazione a eventi è un paradigma di programmazione con il quale vengono realizzate applicazione reattive. A differenza dei programmi tradizionali in cui il flusso del programma segue un percorso fisso e le ramificazioni avvengono esclusivamente in punti stabiliti dal programmatore, nella programmazione a eventi le reazioni sono determinate dal verificarsi di eventi esterni che condizionano il flusso del programma.
La reazione dell’applicazione può comportare il cambio dello stato interno (es. valore delle variabili), il cambiamento dell’interfaccia grafica (es. apertura o chiusura di una finestra), attivazione di una routine di calcolo, generazione di ulteriori eventi per altre applicazioni.
Per la valutazione degli eventi il sistema si trova in un ciclo di istruzioni al cui interno vengono continuamente verificate le condizioni da valutare (e.s. la pressione di un pulsante), in reazione alle quali vengono eseguite le istruzioni atte alla gestione di quel determinato evento.
La verifica degli eventi viene generalmente gestita mediante due metodiche: il polling e gli interrupt.
Nel polling viene eseguita una verifica ciclica dei bit associati ad ogni periferica (es. mouse, tastiera), ed ha il vantaggio di poter gestire pienamente il sistema, ma presenta lo svantaggio di utilizzare il tempo di calcolo per lunghi periodi di busy-waiting.
7 Con la gestione degli interrupt si aspetta un segnale asincrono da parte di una periferica hardware (es. segnale di inceppamento carta di una stampante) o da software (es. segnale di applicazione terminata).
Una procedura da eseguire al verificarsi dell’evento si chiama “callback”, viene definita e registrata in fase di inizializzazione, cioè collegata al widget ed all’evento in questione.
Se in fase di polling o di interrupt il sistema individua un evento, viene chiamata la procedura callback corrispondente.
In qt, questo meccanismo è facilitato dal sistema
“signals and slots”. Si tratta di un meccanismo in cui il verificarsi di un evento è rappresentato da un segnale emesso da un’applicazione o da un oggetto software, mentre uno slot è una procedura che viene eseguita a verificarsi dell’evento.
All’interno di un software sviluppato con qt viene associato un segnale ad uno o più slot desiderati.
8
4. Introduzione all’Electronic Warfare
4.a Generalità
Il concetto di Electronic Warfare (EW) si basa sull’analisi delle emissioni elettromagnetiche originate da un target in modo tale da ottenere informazioni sulla fonte. In particolare è necessario comprendere se il target sia amichevole oppure ostile, e nel secondo caso conoscere le sue intenzioni, quali obiettivi sta minacciando e adottare le contromisure adeguate. Tali contromisure possono prevedere l’inibizione sia delle comunicazioni nemiche che l’uso dei sistemi d’arma.
Una definizione precisa di EW è fornita dal Comitato Militare Nato: “Azione militare per lo sfruttamento dello spettro elettromagnetico (EM), che comprende l’intercettazione e l’identificazione di emissioni EM, l’impiego di energia EM per ridurre o impedire l’uso ostile dello spettro EM e azioni per garantire il suo utilizzo efficace da parte delle forze alleate.”
I tre componenti dell’EW sono:
• Le misure a supporto dell’EW (ESM)
• Contromisure elettroniche (ECM)
• Misure elettroniche protettive (EPM)
I sistemi ESM raccolgono dati e producono informazioni che possono essere utilizzate come fonte di informazione per il sistema di intelligence, sorveglianza, acquisizione tattica e ricognizione (sistema ISTAR).
9 Il prodotto dei sistemi ESM può essere:
• Electronic Intelligence (ELINT), cioè “materiale tecnico o informazione di intelligence derivante da trasmissioni elettromagnetiche come radar, e raccolte parte di soggetti non destinatari di tali informazioni”;
• Communications Intelligence (COMINT), cioè “materiale tecnico o informazione di intelligence derivante da comunicazioni EM e dai sistemi di comunicazione (es.
trasmissione Morse, voce)”
• Signals Intelligence (SIGINT), che rappresenta l’ambito comprendente sia ELINT che COMINT.
Le organizzazioni coinvolte nell’Electronic Warfare hanno il compito di:
• fornire immediatamente un’allerta in caso di pericolo;
• fornire una fonte di SIGINT in forma di report tattici;
• acquisire informazioni da emettitori EM avversari;
• attivare i meccanismi di contromisura ECM e di protezione elettronica EPM.
4.a Requisiti di un sistema di Electronic Warfare
I requisiti di un sistema EW sono molteplici:
Contesto e ambiente
Il sistema deve essere in grado di operare continuamente con qualsiasi condizione meteo, condurre operazioni ECM, processare le informazioni classificate e le informazioni speciali in un ambiente che rispetti standard ben definiti, comunicare in sicurezza con le altre organizzazioni EW e con il centro di comando.
10 Inoltre, deve essere in grado di operare in contesti particolari, come ambienti nucleari, chimici o biologici. Deve poter essere dispiegato su piattaforme mobili, mezzi blindati, e come strumentazione equipaggiabile dalla fanteria. Il sistema deve essere, inoltre, il più possibile modulare per garantire veloci riparazioni.
Capacità di ricerca e intercettazione
Il sistema deve essere in grado di condurre una ricerca ad ampio spettro, rilevare e monitorare le emittenti EM, registrare i dati raccolti efficientemente senza ridondanza, e interagire con altri componenti di analisi. L’operatore deve essere in grado di selezionare quali dati raccogliere, garantendo un’interfaccia semplice per la configurazione del sistema.
I dati raccolti devono essere il più possibile precisi in modo da supportare anche altri sensori o sistemi UAV (Unmanned Air Vehicle).
Capacità di analisi dei dati raccolti
Il sistema deve essere in grado di integrare i dati raccolti con le informazioni provenienti da banche dati esterne di altre organizzazioni EW, dati da sensori esterni e database di SIGINT nazionali. È necessario poter processare i dati velocemente, disponendo di efficaci sistemi di data mining che consentano di estrarre le informazioni di interesse. Completano il quadro le attività di correlazione coi dati storici, applicazioni di intelligenza artificiale per l’individuazione di particolari pattern nei dati.
11
5. Simulazione di scenari di minaccia
Per la simulazione degli scenari di minaccia sono disponibili diversi software commerciali, durante il tirocinio è stato utilizzato “Multi Emitter Scenario Generator” (MESG) di proprietà Keysight.
Figura 1 Simulazione di uno scenario, dettaglio dei velivoli coinvolti
12
Figura 2 sequenza temporale del segnale generato
Attraverso questo software è possibile generare segnali che rappresentano accuratamente l’ambiente di Electronic Warfare. La simulazione di ambienti ad emissione multipla è indispensabile per creare un contesto realistico e rappresentativo. La verifica dei sistemi EW è fortemente influenzata dalla capacità di poter eseguire dei test in ambienti realistici.
Tali test devono essere facilmente ripetibili per poter identificare e risolvere le problematiche. Un fattore importante è il costo dei test, poiché devono essere eseguiti in diversi ambienti come laboratori, camere di test o direttamente in volo.
Riprodurre realisticamente un ambiente significa operare in un contesto in cui coesistono molteplici emittenti che trasmettono contemporaneamente. Mantenere questa contemporaneità richiede che siano dispiegate molteplici sorgenti, aumentando fortemente i costi dei test, lo spazio da dedicare e la complessità del sistema.
13 Una soluzione è la capacità di poter simulare molteplici emittenti a molteplici frequenze con una singola sorgente, e la capacità di selezionare velocemente ampiezza, frequenza e modulazione.
Diversi parametri di un impulso vengono rilevati dai sistemi EW, tra cui l’ampiezza (Amp), l’ampiezza d’impulso (Pw), l’angolo di arrivo (AOA), il tempo di arrivo (TOA), e la modulazione d’impulso.
I segnali utilizzati per il test dei sistemi EW devono essere a banda larga, solitamente in un range da 500MHz a 18 GHz. Con le moderne strumentazioni si è arrivati a raggiungere anche le frequenze a 40GHz, che permettono di simulare anche radar per rilevamento di missili.
I parametri di un impulso simulato vengono inseriti un Pulse Descriptor Word (PDW) che generalmente contiene il tempo di arrivo, l’ampiezza di impulso, la potenza e la frequenza.
Una volta realizzato l’impulso desiderato, è possibile utilizzare un generatore di segnale dove caricare il PDW e riprodurlo.
Figura 4 Generatore di segnale Keysight UXG N5193A Figura 3 Descrizione di un PDW
14 6. Comando remoto di strumentazione per misurazione tramite SCPI
Lo standard SCPI si basa sugli standard IEEE 488.1 e IEEE 488.2.
Nello standard IEEE 488.1, anche chiamato GPIB, viene definito un livello di trasporto con dei messaggi di controllo come Service Request (interrupt di un dispositivo verso il controller), polling da connessione seriale, e indicazione di fine messaggio.
Nello standard IEEE 488.2, viene definita una sintassi standard che comprende comandi, parametri e risposte. Viene definita sulla base del precedente 488.1, in cui specifica l’uso messaggi di controllo, ed a cui aggiunge il Message Exchange Protocol (MEP).
SCPI è basato sulla sintassi IEEE 488.2, e sul modello di stato dello strumento. Definisce un dizionario di comandi per lo strumento, ed è orientato alle interfacce remote. Il vantaggio principale è di avere una sintassi in ASCII che facilita la leggibilità e permette la comprensione intuitiva dei comandi. Si tratta anche di un protocollo aperto che permette l’aggiunta di ulteriori comandi. Viene supportato da molti produttori tra cui Keysight, Agilent, Tektronix e Fluke. I comandi SCPI possono essere inviati tramite diverse interfacce tra cui GPIB, LAN, RS-232 e USB.
Possiamo distinguere i comandi in tre aree: comandi di controllo, comandi di configurazione e comandi di interrogazione.
I comandi di controllo sono solitamente comuni a tutti i dispositivi e permettono ad esempio il clear dei registri di stato (*CLS), il reset del dispositivo (*RST), l’identificazione del modello del dispositivo(*IDN?).
15 I comandi di configurazione e di interrogazione hanno una struttura gerarchica e sono separati dal carattere ‘:’ .
I comandi di configurazione sono write-only, cioè impostano un parametro e non aspettano una risposta.
Per esempio SENSE:FREQUENCY:START 2000 imposta il valore iniziale a 2 KHz per lo sweep range.
I comandi di interrogazione si riconoscono per la presenza del carattere ‘?’ alla fine del comando:
Per esempio SENSE:FREQUENCY:START? Restituisce il valore iniziale dello sweep- range appena inserito.
La configurazione del dispositivo inizia sempre con il comando di reset (*RST) che riporta il dispositivo allo stato iniziale. Successivamente è possibile impostare i parametri richiesti. Per configurare il dispositivo in modalità RUN è possibile utilizzare il comando
“INIT: CONT 1”, mentre per entrare in modalità HOLD “INIT: CONT 0 “.
Come applicazione pratica iniziale è stato utilizzato il dispositivo analizzatore di spettro Fieldfox prodotto da Keysight, ed è stato scelto linux Opensuse come distribuzione di sviluppo.
Figura 5 N9918A FieldFox Handheld Microwave Analyzer, 26.5 GHz
16 Importante è comprendere i meccanismi di temporizzazione all’interno del dispositivo:
infatti è necessario attendere il completamento dell’operazione precedente prima di poter inviare un ulteriore comando. Nello specifico, si può leggere dalla documentazione dello strumento in esame che dopo l’istruzione di reset è necessario attendere alcuni minuti. Una strategia può essere quella di inserire all’interno del programma un loop di attesa con la procedura sleep (), ma introduce un tempo di ritardo fisso che degrada le prestazioni del nostro software.
Una soluzione possibile è interrogare continuamente il dispositivo col comando *OPC?
il quale restituisce 1 quando le precedenti operazioni sono completate. Una volta rilevato il valore corretto, si può continuare l’esecuzione del programma. Questa metodica ha il vantaggio di evitare l’introduzione di ritardi fissi, e basare le temporizzazioni solo sul polling del dispositivo. Un esempio di comunicazione è il seguente, basandosi su un oggetto di classe instrument che implementa i metodi necessari all’invio dei comandi e la lettura delle risposte del dispositivo. Un’ulteriore miglioria potrebbe prevedere l’utilizzo di un meccanismo di timeout.
Instrument instr; //istanziamo un oggetto instrument instr.write("*RST"); //scriviamo il comando di reset do{
instr.write("*OPC?"); //scriviamo il comando OPC
int reply=instr.read(); //il metodo legge la risposta in formato intero
} while(!reply==1) //rimaniamo nel loop fintanto che la risposta non è uguale a 1 //ulteriore esecuzione di comandi
17 La comunicazione con il dispositivo avviene attraverso socket TCP. I metodi implementati sono l’apertura e la chiusura della connessione, l’invio dei dati e la ricezione delle risposte. Per la realizzazione del socket è stata una utilizzata la classe del framework Qt chiama QTcpSocket.
18 7. Monitoraggio di dispositivi tramite protocollo SNMP
Il protocollo SNMP (Simple Network Management Protocol) rappresenta uno standard per la gestione delle reti, ed è implementato da molti produttori di hardware.
Attraverso il protocollo SNMP, i dispositivi mettono a disposizione e forniscono accesso a informazioni che è possibile interrogare o modificare. Tali informazioni rappresentano lo stato del dispositivo, i suoi parametri interni, e altre impostazioni che ne specificano il funzionamento.
Il protocollo gestisce oggetti specifici, a cui viene assegnato un Object Identifier (OID) che consiste in un insieme di numeri separati da punti.
Figura 6 Architettura Agent Manager (Oracle, s.d.)
19 SNMP definisce alcune entità:
• Network Element: il dispositivo hardware connesso alla rete;
• Agent: il modulo software che risiede sul network element, ed ha il compito di memorizzare le informazioni;
• Managed Object: consiste in una caratteristica o una proprietà da gestire;
• Management Information Base (MIB): che consiste in un insieme di Managed Object;
• Sintassi: linguaggio utilizzato per la descrizione dei Managed Object all’interno del MIB. Viene utilizzato un sottoinsieme dello standard ISO ASN.1 (Abstract Syntax Notation)
• Structure of Management Information: definisce le regole per descrivere le informazioni di gestione.
• Network Management Station (Manager): il terminale da cui si sta si sta gestendo il Network Element.
La Structure of Management Information impone che tutti i managed object dispongano di un nome, una sintassi e una codifica. Il nome corrisponde ad un Object Identifier (OID), la sintassi definisce il tipo di dato dell’oggetto (es. intero), la codifica descrive come le informazioni associate al managed object sono formattate per la loro trasmissione.
Un MIB ha una struttura ad albero con diversi livelli dalla radice alle foglie. Ogni OID ha un indirizzo che segue i livelli dell’albero. È possibile specificare sia il percorso testuale, che quello numerico.
20 Ecco un esempio per lo stesso OID:
Iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).bea(140).tuxedo(300) 1.3.6.1.4.1.140.300
Figura 7 Architettura ad albero per un MIB Oracle (Oracle, s.d.)
Per il progetto è stata utilizzata la prima versione del protocollo SNMP: essa prevede che i moduli Agent siano in ascolto sulla porta UDP 161, e che le risposte siano inviate al Manager utilizzando un numero di porta casuale. La scelta di UDP comporta l’utilizzo di un protocollo connection-less che non garantisce l’affidabilità dei pacchetti inviati.
21 Le principali operazioni del protocollo SNMPv1 sono le seguenti:
• GET: utilizzata dal Manager per reperire un valore dal MIB dell’Agent
• GET-NEXT: Utilizzata dal Manager per accedere ricorsivamente al MIB
• SET: utilizzata dal Manager per impostare un valore sul MIB
• TRAP: utilizzata dall’Agent per inviare messaggi di errore al Manager
Il formato del pacchetto SNMPv1 comprende un numero di versione, una Community String che viene utilizzata come password, un Protocol Data Unit (PDU) di tipo SNMP.
Figura 8 Composizione di un messaggio SNMP (H3C)
Nella nostra applicazione era richiesto di poter scambiare informazioni con un dispositivo pressurizzatore, in modo da poter rilevare la presenza di errori e gestire le sue informazioni.
22
8. Conclusioni
Il tirocinio è stata un’esperienza interessante ed educativa, e mi ha permesso di conoscere la realtà aziendale. Si tratta di un’opportunità per mettersi in gioco e provare le proprie capacità e le conoscenze in un contesto reale. Ho potuto sperimentare la soddisfazione di vedere operativo un progetto al quale ho partecipato, grazie anche alle utili nozioni apprese durante gli anni di Università. Ho potuto apprezzare anche il lavoro di squadra, in cui ogni membro del progetto ha un proprio ruolo ma è sempre pronto a supportare gli altri colleghi.
Desidero ringraziare il mio Tutor aziendale Dr. Giovanni Battista Laratta per la grande disponibilità ed il supporto nei miei confronti in questo periodo di tirocinio. Ringrazio anche la Dr.ssa Erika De Bernardis per avermi concesso l’opportunità di partecipare a questo tirocinio aziendale. Un ringraziamento anche al Prof. Giuliano Armano per il prezioso supporto durante il tirocinio.
23
Bibliografia
Agilent Technologies. (s.d.). Developing a SCPI command set.
Calarco. (A.A 2002/2003). Corso di Amministrazione di reti.
Canada National Defence, Land Force Information Operations. (s.d.). Electronic Warfare.
H3C. (s.d.). SNMP Technology White Paper.
Keysight. (2014). Electronic Warfare Signal Generation: Technologies and Methods.
MC 101 NATO Signals Intelligence Policy. (s.d.).
NATO Military Committee. (s.d.). Nato Glossary of Terms and Definitions.
Oracle. (s.d.). Oracle SNMP Reference. Tratto da
https://docs.oracle.com/cd/E13203_01/tuxedo/tux91/snmpmref/1tmib.htm.
Palumbo, I. F. (A.A. 2008/2009). Architetture di sistemi embedded.
Prof. Dr. W. A. Mahmoud, D. A. (2011, Febbraio). Radar parameter generation to identify the target. Journal of Engineering.
Robins. (2009, Febbraio 24). Introduction to Radar Warning Receivers. Georgia Tech.
Schleher D.C. (1986). Introduction to Electronic Warfare. Artech House.
Storia Vitrociset. (s.d.). Tratto da Sito Web Vitrociset: http://www.vitrociset.it/azienda/id/2/storia Ulaby, L. (2014). Microwave Radar and Radiometric Remote Sensing. The University of Michigan Press.
What is QT. (s.d.). Tratto da Sito Web QT: https://www.qt.io/what-is-qt/
