PALUZZANO TESI

UNIVERSITÀ DEGLI STUDI DI TRIESTE Dipartimento di Ingegneria e Architettura

Corso di Studi in Ingegneria Informatica

REALIZZAZIONE DI UN SOFTWARE DI COMUNICAZIONE MULTIPROTOCOLLO PER IL CONTROLLO DI PROCESSO IN

AMBITO INDUSTRIALE

Tesi di Laurea Triennale

Laureando: Enrico PALUZZANO

Relatore: prof. Alberto BARTOLI

_____________________________________

ANNO ACCADEMICO 2012-2013

Ai miei genitori,alla mia famigliaed ai miei amici.

Si ringrazia il team di livello 2 e tutto il personale della SMS Concast.

I N D I C E

1 introduzione 1

1.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 reti di comunicazione industriali 3

2.1 Organizzazione aziendale . . . . . . . . . . . . . . . . . 3

2.2 Struttura delle reti industriali . . . . . . . . . . . . . . . 5

2.3 Protocolli utilizzati da SoftNet-S7 . . . . . . . . . . . . . 6

2.4 Enunciazione dei principi delle comunicazioni . . . . . 6

2.5 Problematiche legate alla comunicazione . . . . . . . . 8

2.6 Entitá coinvolte nella comunicazione . . . . . . . . . . . 9

3 analisi e progettazione del software di comuni-cazione 11

3.1 Analisi delle caratteristiche del software precedente . . 11

3.2 Analisi del comportamento delle entitá . . . . . . . . . 11

3.3 Studio del software esistente . . . . . . . . . . . . . . . 13

3.3.1 Studio del Gate e delle strutture condivise . . . 14

3.3.2 Studio dei driver di comunicazione . . . . . . . 15

3.4 Schema UML delle classi . . . . . . . . . . . . . . . . . . 18

4 implementazione del gate 21

4.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . 21

4.2 Utilizzo delle eccezioni . . . . . . . . . . . . . . . . . . . 21

4.3 Implementazione della classe PipeObject . . . . . . . . 22

4.4 Implementazione della classe PlcDriver . . . . . . . . . 23

4.5 Riprogettazione del comportamento ancestrale del driver 23

4.6 Implementazione del sistema remoto . . . . . . . . . . 26

4.7 Implementazione degli Score . . . . . . . . . . . . . . . 27

4.8 Implementazione dell’applicazione di test Board . . . . 28

5 implementazione delle interfacce 29

5.1 Implementazione dell’interfaccia Gate tramite WPF . . 29

5.2 Implementazione dell’interfaccia Board tramite WPF . 30

6 utilizzo e test del sistema di comunicazione gate 33

6.1 Casi d’uso del Gate . . . . . . . . . . . . . . . . . . . . . 33

6.2 Test del Gate tramite l’applicazione Board . . . . . . . . 33

7 conclusioni 35

bibliografia 37

v

1I N T R O D U Z I O N E

1.1 premessa

Il lavoro che mi accingo a presentare é stato svolto nell’ambito deltirocinio all’interno dell’azienda SMS Concast con sede a Tarcento(UD).SMS Concast sviluppa e produce apparecchiature per l’intero proces-so di produzione di acciaio ed in particolare si occupa di fornire soft-ware per l’automazione, il controllo e l’ottimizzazione dei processisiderurgici.In questa tesi viene presentata la realizzazione di un software di co-municazione per la raccolta dati da periferiche PLC, allo scopo dialimentare i software di controllo del processo produttivo.Le applicazioni sviluppate dall’azienda svolgono svariati compiti, dal-la visualizzazione dello stato degli impianti al calcolo dei piani ditaglio dell’acciaio.Per svolgere tutte le loro funzioni, i suddetti applicativi devono potercomunicare con le macchine di produzione, le quali sono automatiz-zate e controllate da dei dispositivi che ne gestiscono lo stato e lecomandano.Questi dispositivi vengono chiamati PLC (Programmable Logic Con-troller), cioé controllori a logica programmabile.All’interno di un impianto siderurgico é possibile che vengano instal-lati vari PLC, anche di case produttrici differenti. Per poter gestireogni tipo di PLC ogni casa produttrice fornisce un proprio driver, cheutilizza librerie e protocolli proprietari specifici.Le comunicazioni tra applicazioni e PLC all’interno dell’acciaieria av-vengono tramite una rete locale (LAN) alla quale i dispositivi so-no connessi; esse hanno un ruolo fondamentale in quanto la lorointerruzione non permetterebbe piú alle applicazioni di controllarecorrettamente il processo produttivo.I motivi che hanno spinto l’azienda a produrre un software di comu-nicazione che facesse da intermediario tra applicazioni e PLC sono:

1. la difficoltá che comporta il dover comunicare con dispositiviprodotti da aziende differenti;

2. la necessitá di affidabilitá e robustezza delle comunicazioni inambito industriale.

La produzione di questo tipo di software offre notevoli vantaggi po-ichè l’utilizzo di uno strumento che centralizza le comunicazioni per-mette ai tecnici di monitorare le richieste delle singole applicazioni,di cronometrarle e di simularle al fine di testare e diagnosticare fun-zionalitá e problemi della rete e delle comunicazioni stesse.

1

2 introduzione

Attualmente é giá stato implementato, ed é tutt’ora funzionante inmolti impianti, un software di comunicazione di questo tipo svilup-pato in linguaggio Pascal.Una nuova commessa ha peró imposto il cambiamento del linguaggiodi sviluppo, richiedendo che tutte le applicazioni fossero scritte inC# ed avessero le interfacce prodotte in WPF (Windows PresentationFoundation).Il tirocinio ha avuto come obiettivo quello di analizzare la soluzioneprecedente, di migliorarla ove possibile e di riprogettarla utilizzandoil linguaggio C#, sfruttando le librerie dotNet.I passi intrapresi nello sviluppo della soluzione sono i seguenti:

• introduzione e studio del problema da risolvere con particolareattenzione alle specifiche di affidabilitá legate all’applicazioneindustriale;

• analisi critica della precedente soluzione software, giá sviluppa-ta dall’azienda, al fine di evidenziarne le carenze ed i punti diforza;

• progettazione e sviluppo di una nuova soluzione software.

2R E T I D I C O M U N I C A Z I O N E I N D U S T R I A L I

In questo capitolo verranno esposti i principali problemi legati alla co-municazione industriale e verranno illustrati i protocolli di piú bassolivello utilizzati. Piú in generale si definiranno i principi, le funziona-litá e l’ambiente in cui il software di comunicazione é stato prodottoe quello in cui dovrá operare.

2.1 organizzazione aziendale

Per la gestione del processo produttivo l’organizzazione della SMSConcast é strutturata su piú livelli, ognuno preposto allo sviluppo diun singolo aspetto del processo.Il livello gerarchicamente piú basso, denominato “Livello 1”, si occu-pa dell’automazione e dell’equipaggiamento meccanico delle macchi-ne.In questo livello viene curata la preparazione per la corretta esecuzio-ne delle istruzioni per la produzione.I PLC sono dispositivi che hanno il compito di elaborare i segna-li provenienti dai rilevatori ed inviare i comandi agli attuatori checontrollano diversi tipi di sistemi (meccanici, fisici, ottici, ecc.).Al loro interno i PLC incorporano uno o piú processori (CPU) cheleggono e scrivono dati sulla memoria, tipicamente interna, e coman-dano gli attuatori.Le applicazioni che necessitano di comunicare con un PLC hannola possibilitá di agire sulla memoria, cambiando cosí il suo statointerno.

MEMORIA CPU

PLC

SCHEDA DI RETE

ATTUATTORI RILEVATORI

Figura 1: Organizzazione aziendale.

Il livello superiore, denominato “Livello 2”, si occupa del controllodel processo produttivoIl software progettato e descritto in questa tesi é il sistema di comuni-cazione tra il livello 2 ed i PLC.

3

4 reti di comunicazione industriali

Le applicazioni di livello 2 vengono utilizzate per l’ottimizzazionedella produzione e per il confronto dei dati di produzione con model-li matematici studiati ad hoc, visualizzando graficamente l’andamen-to dei parametri e calcolando le azioni necessarie.Alcuni degli utilizzi possibili, in campo siderurgico, sono il controlloe l’analisi dei parametri chimici durante la fusione, al fine di produrrela “ricetta chimica” di additivi ottimale per la produzione della legavoluta.E’ sostanzialmente il livello che supervisiona e controlla “cosa pro-durre” e “come produrre”.Il livello gerarchicamente piú alto, denominato “Livello 3”, si occupadella gestione delle commesse e di schedulare il lavoro da eseguireunitamente alla gestione contabile del processo: in poche parole sioccupa del “quando produrre”, “in che ordine temporale” e “per chi”.

APP APP

APP APP APP

LIVELLO 2

LIVELLO 3

LIVELLO 1

GATE

PLC S7

APP

PLC SR

APP APP

HW HW HW

BOARD

Software presentato nella tesi

Software scviluppato dai team

di livello

Dispositivi programmabili PLC

AB = Allen Bradley

S7 = Siemens

SR = Driver Sand Receive

Macchine meccaniche

PROCESSO

PRODUTTIVO

Scheduling

Controllo di

processo

Automazione

PLC AB

APP

Figura 2: Organizzazione aziendale.

2.2 struttura delle reti industriali 5

2.2 struttura delle reti industriali

I sistemi informatici in un impianto industriale vengono utilizzati perautomatizzare il processo produttivo ed offrire supporto agli opera-tori.All’interno di un impianto siderurgico i PLC sono gli unici dispositiviche conoscono lo stato fisico delle macchine che essi stessi controlla-no.Le applicazioni che hanno la necessitá di conoscere e comandare lostato della produzione, hanno la possibilitá di organizzare tali opera-zioni esclusivamente comunicando con i PLC.Applicazioni diverse devono elaborare dati provenienti da diversicomponenti dell’impianto siderurgico e devono fornire istruzioni allemacchine per poter controllare la produzione.Ció comporta che gli applicativi debbano poter comunicare con di-versi PLC anche simultaneamente. Conseguenza di questo fatto éche PLC ed applicazioni devono essere collegati tramite una rete dicomunicazione.Per questo motivo all’interno delle acciaierie deve essere installatauna rete locale capace di offrire i servizi per la comunicazione neces-sari all’impianto.La rete industriale su cui verrá installato il software prodotto avráun’architettura descritta attraverso il seguente modello ISO/OSI:

APPLICAZIONEDai processi di rete all’applicazione

PRESENTAZIONE

Presentazione dei dati e criptazione

SESSIONEControllo comunicazioni tra applicazioni

TRASPORTOConnessione end-to-end e affidabilità

RETEDeterminazione e traduzione degli indirizzi

COLLEGAMENTO

Indirizzamento fisico

FISICO

Media, segnale e trasmissione binaria

PLC GATEWAY

PROTOCOLLI SOFTNET

PROTOCOLLI DRIVER ALLEN BRADLEY

PROTOCOLLI SEND RECEIVE

TCP / IP

INTERFACCIA ETHERNET

MAC ADDRESS

1

2

4

6

7

5

3

Figura 3: Descrizione dei protocolli di rete secondo il modello ISO/OSI.

I protocolli delle reti considerate in questa tesi utilizzano lo standardEthernet a livello fisico e data-Link, mentre sfruttano TCP/IP a livellodi trasporto.Ai livelli sessione ed applicazione, vengono utilizzati i protocolli svi-luppati dalle case produttrici dei PLC.Le problematiche che i protocolli di rete affrontano non sono sololegate alle prestazioni, ma anche all’affidabilitá ed alla capacitá di ri-


levare e correggere guasti ed errori, che non sono rari in un impiantosiderurgico.

2.3 protocolli utilizzati da softnet-s7

Di seguito viene illustrato il funzionamento delle librerie proprietariee dei protocolli di un PLC SIEMENS S7.Un PLC di questo tipo é stato messo a disposizione dall’azienda du-rante lo svolgimento del tirocinio per le fasi di progettazione e testdelle funzionalitá del sistema di comunicazione.Il PLC in questione é stato utilizzato facendo particolare attenzione alcorretto utilizzo delle librerie di comunicazione native del PLC stesso.La SIEMENS sviluppa pacchetti software e dispositivi hardware perla comunicazione tra le macchine e gli altri componenti di un impian-to di produzione.Quest’azienda mette a disposizione una collezione di programmi efunzionalitá chiamata SIMATIC NET di cui fa parte il pacchetto SOFT-NET.SOFTNET fornisce API e tools per la configurazione, all’interno delsistema operativo, della connessione dei PLC collegati tramite la retelocale.L’installazione e la configurazione della SOFTNET sono dei processicomplessi che vengono svolti da tecnici specializzati del livello 2 eche consentono il corretto funzionamento delle librerie native; taliprocessi non verranno trattati in questo documento.Il software di comunicazione da sviluppare dovrá incorporare ed uti-lizzare le corrette procedure proprietarie, a seconda del tipo di PLCcon cui l’applicazione richiedente necessita di comunicare.La stessa SOFTNET mette a disposizione, per la comunicazione coni dspositivi S7, un’API che risulta accessibile attraverso la libreriaS732.dll.Questa libreria é stata scritta in linguaggio C e contiene delle funzio-nalitá per la comunicazione con i PLC SIEMENS.

2.4 enunciazione dei principi delle comunicazioni

Attraverso la configurazione del software SOFTNET e tramite la libre-ria S732.dll é possibile comunicare con un PLC SIEMENS.La comunicazione tramite questa libreria rende trasparenti alle ap-plicazioni tutte le problematiche relative ai protocolli di piú bassolivello.Per esempio, un’applicazione non deve conoscere l’indirizzo di reteIP o il MAC di un PLC per comunicare con esso, ma é sufficienteche conosca l’ID del PLC cosí come é stato configurato tramite laSOFTNET.Come giá enunciato, i principi di funzionamento della SOFTNETnon verranno trattati; tuttavia, per completezza, vengono descrittibrevemente i protocolli per la comunicazione ai livelli sessione edapplicazione, implementati dalla SOFTNET stessa.

2.4 enunciazione dei principi delle comunicazioni 7

All’interno dei livelli sessione ed applicazione, vengono gestite dueunitá logiche:

1. VFD (Virtual Field Device);

2. Connection.

Tramite la configurazione di SOFTNET vengono generati uno o piúdispositivi virtuali con i quali le applicazioni comunicano direttamen-te (VFD).Vengono inoltre create una o piú connessioni (Connection) tra questidispositivi virtuali e i PLC reali.Questa tecnica permette un’astrazione del PLC fisico e del canale dicomunicazione, mascherando di fatto i protocolli di piú basso livelloalle applicazioni richiedenti.Un’applicazione puó comunicare con piú VFD ed ha accesso esclusi-vo ad ognuno.A sua volta un VFD puó essere mappata per comunicare con un so-lo PLC reale e su di esso possono essere aperte varie Connectionutilizzate per lo scambio dei dati.

APPLICAZIONE 1 APPLICAZIONE 2

VFD 1 VFD 2

PLC 2PLC 1

VFD 3

connessioni

Figura 4: Relazione tra Applicazioni, VFD e PLC.

In sintesi, quando un’applicazione vorrá comunicare con un determi-nato PLC, comunicherá in realtá con un VFD utilizzando una deter-minata Connection.La logica appena descritta vale, in particolare, per i dispositivi PLCSIEMENS S7 ed é utile per comprendere le funzioni della libreriaassociata.Di seguito viene illustrata (Fig. 5, 7) una tipica sequenza di chiama-te alle funzioni della libreria S732.dll per inizializzare e chiudere lacomunicazione con un PLC S7.E’ importante notare che le funzioni chiamate non sono bloccanti inquanto ogni funzione restituisce un valore che garantisce l’esecuzio-ne della funzione stessa ma non l’esito effettivo, il quale puó esserericevuto con l’esecuzione del polling, tramite la funzione s7receive.


USER PROGRAM S732.dll

s7_init(string DeviceName, string VFD_Name)

int cp_desc, S7_OK

s7_get_cref(int cp_descr, string ConnecrionName)

int cref, S7_OK

s7_initiate_req(int cref, string ConnectionName)

S7_OK

s7_receive(int cp_desc)

result

s7_get_initate_cnf()

S7_OK

alt

result = S7_INITIATE_CNF

Figura 5: Apertura comunicazioni S7.

2.5 problematiche legate alla comunicazione

Lo sviluppo di un sistema di comunicazione capace di soddisfare lenecessitá delle applicazioni industriali deve affrontare delle proble-matiche legate soprattutto all’affidabilitá.In un impianto industriale é necessario che le comunicazioni sianoaffidabili ed i sistemi che le gestiscono siano robusti, in quanto infor-mazioni trasmesse male, o in ritardo, oppure non trasmesse affatto,possono provocare dei danni.Per questo motivo é importante che il software in questione generimeno errori possibili e reagisca bene ad eventuali malfunzionamenti.Il sistema di comunicazione non deve mai bloccare le applicazionichiamanti e deve sempre rispondere alle richieste anche in manieranegativa, oppure deve far scadere le stesse per timeout.Tra i requisiti del software da produrre non compare la necessitá diavere una gestione delle prioritá rispetto alle applicazioni che richie-dono la comunicazione.Dal punto di vista delle prioritá rispetto al tipo di richieste che il siste-ma deve soddisfare, invece, le Transazioni in scrittura devono averela precedenza su quelle in lettura: questo é conseguenza del fatto chele operazioni di lettura avvengono frequentemente per monitorarelo stato dell’impianto e il ritardo di una di queste comunicazioni éaccettabile.

2.6 entitá coinvolte nella comunicazione 9


s7_read_request(int cp_desc, int cref,

int order_id, string read_params)

S7_OK

s7_receive(int cp_desc)

result

s7_get_read_cnf(int length, char* buffer)

S7_OK

alt

result = S7_READ_CNF

Figura 6: Lettura dati da un PLC S7.


s7_abort(int cp_desc, int cref)

s7_shut(int cp_descr)

Figura 7: Chiusura della connessione S7.

Per contro, se un’applicazione elabora un qualsiasi piano utile per laproduzione, é importante che lo comunichi il piú velocemente pos-sibile ai PLC, altrimenti si puó verificare un ritardo nel processo diproduzione.

2.6 entitá coinvolte nella comunicazione

Per progettare un software capace di eseguire sistematicamente lesequenze descritte nel paragrafo 2.4 e che sia concorrenziale per leapplicazioni, é stato necessario definire delle entitá intermedie tra gliinterlocutori (applicazioni e PLC).Esse rappresentano, attraverso le loro strutture, il canale di comuni-cazione, le operazioni di lettura o scrittura ed il driver di comunica-zione.Le entitá , ognuna con un ruolo all’interno della comunicazione, sono:

• Link: rappresenta il canale di comunicazione;

• Transazione: rappresenta il processo di lettura o scrittura;


• PlcDriver: si prende carico delle richieste pervenute dalle appli-cazioni e di comunicare con i PLC secondo le corrette librerienative.

Per la gestione delle entitá é stato largamente utilizzato un modello astati finiti con l’intenzione di rendere semplice ed adatta la successivaimplementazione delle classi.Un’applicazione, per comunicare con un PLC, chiede al Gate l’aper-tura di un Link verso tale PLC e poi accoda, riferendosi al predettoLink, delle Transazioni di lettura o scrittura.Il PlcDriver esegue tutte le procedure per aprire il Link e successi-vamente si prende carido delle richieste accodate, interagendo con iPLC tramite i driver proprietari.Questa iterazione con i PLC viene mascherata alle applicazioni libe-randole dall’effettivo compito di svolgere le comunicazioni.Essendo uno dei requisiti il fatto di impegnare per il minor tempopossibile le applicazioni nella comunicazione, l’accodare richieste e ilprelevarne l’esito sono procedure distinte ed utilizzabili in manieraasincrona dalle applicazioni.Un’importante conseguenza di questo fatto é che un’applicazione nonviene impegnata per attendere l’esito delle richieste ai PLC.Questo procedimento soddisfa un altro requisito, quello di consentirealle applicazioni la comunicazione con piú PLC contemporaneamen-te.Ad esempio, se per monitorare un impianto un’applicazione deveeseguire delle letture su 10 PLC, prima accoderá tutte e 10 le richiestedi lettura e successivamente inizierá a prelevarne il risultato.

3A N A L I S I E P R O G E T TA Z I O N E D E L S O F T WA R E D IC O M U N I C A Z I O N E

In questo capitolo verrá offerta una panoramica sullo stato dell’arte.Verranno illustrate le caratteristiche del software utilizzato dall’azien-da e si cercherá di evidenziare i punti di forza e le funzionalitá cheandranno mantenuti e quelli possibilmente migliorabili.

3.1 analisi delle caratteristiche del software prece-dente

La prima considerazione sul software precedentemente sviluppatodall’azienda é che quest’ultimo soddisfa le caratteristiche di affidabi-litá e robustezza analizzate.Questo software é stato progettato in Pascal e sfrutta le potenzialitádella programmazione orientata agli oggetti.Le entitá descritte nel capitolo precedente vengono rappresentate daoggetti che ne emulano i comportamenti ed incorporano le strutturenecessarie.L’utilizzo della programmazione parallela é un punto di forza di que-sto sistema, che permette ad ogni tipologia di driver proprietario dipoter essere eseguito indipendentemente dagli altri driver e di poteroperare in maniera parallela.Il sistema é stato predisposto per l’utilizzo da remoto e lo scambio diinformazioni con le applicazioni avviene tramite una serializzazionedei parametri delle funzioni utilizzate, sottoforma di stringhe.Il software precedente utilizza un registro degli eventi (LOG), capa-ce di registrarli e dividerli per categoria (ad esempio: Error, Debug,Warning).Per quanto riguarda la diagnosi del sistema, questa viene svolta trami-te gli Score, che sono strutture che registrano i dati temporali (l’inizio,la fine, l’esito, ecc.) delle funzioni eseguite dal Gate.Gli Score sono utilizzati in un’altra applicazione detta Board.Tramite il Board si puó monitorare il Gate e rilevare errori e ritardi,cosí da rendere possibile l’ottimizzazione del sistema stesso.

3.2 analisi del comportamento delle entitá

Il sistema di comunicazione deve gestire il comportamento delle enti-tá logiche Link e Transazione.Come precedentemente enunciato la descrizione di questi comporta-menti avviene tramite un modello a stati finiti.Nella progettazione del nuovo sistema di comunicazione, questi sche-mi sono stati lievemente modificati ed ottimizzati.

11

12 analisi e progettazione del software di comunicazione

La modifica piú rilevante é stata fatta applicando anche a PlcDriverquesto modello, a differenza del precedente comportamento, che ve-niva rappresentato tramite un diagramma di flusso.Questa miglioria é importante in quanto PlcDriver rappresenta ilcuore del software di comunicazione.Questo aspetto verrá approfondito nei capitoli successivi (Cap. 4).

Closed

Opening

Reading

Error

Writing

Apertura link

rifiutata o fallita

Timeout Timeout

Timeout

Opened

Chiusura link

richiesta

Unused

Figura 8: Diagramma di stato dei Link.

Lo stato dei Link viene gestito dal driver con le seguenti definizioni:

Closed: é lo stato iniziale al momento della creazione di un Link; siraggiunge questo stato anche quando si termina un Link.Opening: é lo stato impostato dal driver nel momento in cui cerca diaprire il Link e inizializzare la comunicazione con un PLC.Opened: é lo stato impostato dal driver nel momento in cui riesce adaprire la connessione con il PLC; a questo punto é possibile accodareTransazioni per questo Link.Reading: é lo stato impostato dal driver nel momento in cui prendein carico una Transazione di lettura per il Link.Writing: é lo stato impostato dal driver nel momento in cui prende incarico una trnasazone di scrittura per il Link.Error: é lo stato impostato dal driver nel momento in cui non riescea comunicare con il PLC oppure quando un Link rimane in Opening,Writing o Reading per un tempo troppo lungo.Unused: é lo stato impostato dal driver nel momento in cui un Linkrimane nello stato Opened o Closed chiuso per troppo tempo; il Linkviene terminato e poi gli viene impostato questo stato per essere eli-minato.

3.3 studio del software esistente 13

Unused Queued Unqueued

Ongoing Success Error

Timeout

Figura 9: Diagramma di stato delle Trasazioni.

Lo stato delle Transazioni é gestito dal PipeObject con le seguenti de-finizioni:

Unused: viene impostato questo stato quando la Transazione non éancora stata utilizzata.Queued: viene impostato questo stato quando é richiesta una nuovaTransazione verso un Link.Ongoing: viene impostato questo stato quando il driver si prende ca-rico di eseguire la Transazione.Success: viene impostato questo stato quando il driver termina di ese-guire la TransazioneUnqueued: viene impostato questo stato quando l’applicazione haletto il risultato della Transazione.Timeout: viene impostato questo stato quando una Transazione é ri-masta inutilizzata per un determinato periodo.Error: viene impostato questo stato quando il driver ha riscontrato unerrore nell’esecuzione della Transazione.

3.3 studio del software esistente

Il software esistente, creato sulla base delle entitá sopra descritte,concretizza tali entitá in classi distinte. Le classi principali del Gatesono:

• PipeObject;

• PlcDirver;

• Link;

• Transazioni;

• GateDefinitions.

La classe PipeObject, che é la classe principale, contiene tutte le istan-ze delle strutture necessarie al funzionamento del sistema ed é iltramite tra le richieste delle applicazioni ed il PlcDriver.


Il compito principale di PipeObject é quello di gestire l’interazionecon tali strutture.PlcDriver é la classe ancestrale che descrive il comportamento gene-rale che i driver specifici devono ereditare.Il suo compito é quello di eseguire le richieste delle applicazioniaccodate tramite PipeObject.GateDefinitions é la classe contenente tutte le definizioni delle strut-ture condivise e viene utilizzata dalle applicazioni per comunicarecon il Gate.

3.3.1 Studio del Gate e delle strutture condivise

Le applicazioni utilizzano il Gate tramite la classe PipeObject attra-verso le funzioni messe a disposizione da quest’ultima.La descrizione delle funzioni principali di PipeObject utilizzate dalleapplicazioni sono:

• void DefineLink(PlcLinkConfig LinkConfig): definisce un Linkad un PLC tramite la classe (PlcLinkConfig) che descrvive i pa-rametri di configurazione;

• void RemoveLink(string PlcId): rimuove un Link ad un determi-nato PLC tramite il suo PlcId;

• int SetReadReq(string PlcId, ushort DB, ushort DW, ushort DL):inoltra una richiesta di lettura ad un determinato PLC chieden-do di leggere nel blocco DB, nella word DW, una lunghezzadi DL words; restituisce il numero della Transazione necessarioper ricevere i dati della lettura e per capire se é effettivamenteandata a buon fine;

• int SetWriteReq(string PlcId, ushort DB, ushort DW, ushort DL,ushort[] Data): inoltra una richiesta di scrittura ad un determi-nato PLC chiedendo di scrivere nel blocco DB, nella word DW,una lunghezza di DL words i dati contenuti nell’array Data; re-stituisce un numero identificativo della Transazione utilizzatoper visualizzarne successivamente lo stato;

• bool GetReadRes(int TransNo, out int State, out ushort[] Da-ta): richiede il risultato della lettura della Transazione TransNoprecedentemente accodata; riceve, come risposta, lo stato dellaTransazione ed un array con i dati della lettura;

• bool GetWriteRes(int TransNo, out int State): richiede il risulta-to della scrittura della Transazione TransNo precedentementeaccodata; riceve, come risposta, lo stato della Transazione;

• void ResetDrivers(): questa funzione permette di resettare i dri-ver ed é scarsamente utilizzata dalle applicazioni; viene utiliz-zata in automatico in presenza di Link che persistono in unostato di errore;


• void RemoveUnusedLinks(): questa funzione elimina i Link nonutilizzati se scaduti per timeout;

• void SetSimulationOn(): setta lo stato di simulazione delle Tran-sazioni;

• void SetSimulationOff(): permette di uscire dallo stato di simu-lazione delle Transazioni.

Le definizioni delle funzioni appena descritte sono state tratte dalsoftware sviluppato in questa tesi e non dal precedente, in quantonon hanno subito sostanziali modifiche.Di seguito vengono rappresentate le sequenze di chiamate alle fun-zioni del PipeObject da parte delle applicazioni per aprire un Link edaccodare una richiesta di lettura oppure di scrittura.

APPLICAZIONE PipeObject

SetWriteRequest(string PlcId, ushort DB, ushort DW,

ushort DL, ushort[] data)

DefineLink(PlcLinkConfig LinkConfig)

int TransactionNumber

GetWriteResult(int TransactionNumber)

bool result

loop

return = false

Figura 10: Sequenza di chiamate alle funzioni del GATE per la scrittura suPLC.

3.3.2 Studio dei driver di comunicazione

Il driver di comunicazione é rappresentato dalla classe PlcDriver chematerializza il comportamento ancestrale di ogni driver.PlcDriver viene ereditato in tre classi figlie, le quali ridefiniscono imetodi specifici per utilizzare le diverse librerie proprietarie (AllenBradley, Softnet o Send Receive).Queste tipologie di driver, per natura, utilizzano parametri di con-nessione differenti e per questo motivo anche la struttura Link vie-ne ereditata e riadattata per poter essere utilizzata con i parametrispecializzati di ogni driver.La classe PlcDriver, per fornire la condizione di esecuzione paralleladei driver, ha un suo ciclo di esecuzione continuo: in poche parole,essa percorre ciclicamente una funzione di esecuzione fino a che nonviene terminato il driver oppure non si verifica un errore imprevisto.


APPLICAZIONE PipeObject

SetReadRequest(string PlcId, ushort DB, ushort DW, ushort DL)

DefineLink(PlcLinkConfig LinkConfig)

int TransactionNumber

GetReadResult(int TransactionNumber)

bool result, TransState State, ushort[] Data

loop

return = false

Figura 11: Sequenza di chiamate alle funzioni del GATE per la lettura daPLC.

In questo ciclo il driver controlla se sono presenti Link da servire e incaso affermativo carica le librerie native e le inizializza.Successivamente, se l’inizializzazione é andata a buon fine, il drivercontrolla se su tali Link sono pervenute Transazioni da eseguire ed incaso affermativo le esegue.Dopo un certo tempo, se non sopraggiungono nuove Transazioni, ildriver elimina dalla propria lista i Link inattivi, rilascia le librerie e simette in attesa di nuovi Link da servire.La gestione dei Link all’interno del Gate assume, quindi, una notevoleimportanza soprattutto per quanto riguarda l’interazione PipeObject- PlcDriver.Quando una richiesta di apertura di un Link arriva da un’applica-zione al PipeObject, questa memorizza tale Link in una lista propria,ne crea una copia e, in base al tipo di Link, la inserisce in una listaall’interno del driver a cui appartiene.PipeObject a questo punto mantiene la definizione del Link nelleproprie strutture in maniera indipendente da quelle di PlcDriver.In entrambe le strutture avviene una pulizia dei Link non utilizzati(con stato “Unused”) attraverso un watch dog (letteralmente “cane daguardia”): esso altro non é che un thread che scorre la lista dei Linked elimina quelli inutilizzati, a intervalli regolari.Le Transazioni, invece, vengono memorizzate in due array all’internodi PipeObject: uno preposto alla scrittura ed uno alla lettura, i qualiinizialmente vengono dimensionati a 30 elementi ciascuno.A differenza dei Link, le Transazioni vengono memorizzate in un ar-ray per poter riutilizzare le istanze esistenti senza ricrearne di nuo-ve; ció consente di visualizzare ed accedere alle Transazioni anche sequeste sono giá state eseguite e scodate.La grandezza degli array, in realtá, non é fissa e a fronte di carichiparticolarmente gravosi puó aumentare per servire il grosso carico dirichieste.


Nelle fasi successive non si contrae agli iniziali 30 elementi bensícontinua ad operare alla massima grandezza raggiunta.Per poter accedere e servire le richieste, ogni driver percorre la pro-pria lista dei Link e per ognuno di esso, attraverso una funzione delPipeObject, preleva, se presente, una Transazione accodata e la esegueprima di passare al Link successivo.L’array delle Transazioni in scrittura viene controllato per primo inquanto servire tali Transazioni é prioritario rispetto a servire quellein lettura.L’utilizzo delle strutture dei Link e delle Transazioni da parte di piúinterlocutori in maniera asincrona e concorrente impone l’utilizzo disemafori a mutua esclusione per garantire il corretto accesso ad esse.

GATE

APPLICAZIONI

PIPEOBJECT

LINKPLC

TRANSAZIONI

PLC

PLC

PLCDRIVER

SOFTNET

SENDRECEIVE

ALLNBRADLEYALLEN-BRADLEY

LINK

SOFTNET LINK

SENDRECEIVE LINK

Figura 12: Descrizione delle relazioni tra le principali entitá del sistema dicomunicazione.


3.4 schema uml delle classi

<<Enumeration>>

PlcLinkState

PipeObject

public void

DefineLink(Pipe.PlcLinkConfig

Config)

public int SetReadReq(string PlcId,

ushort DB, ushort DW, ushort

DL)

public int SetWriteReq(string PlcId,

ushort DB, ushort DW, ushort

DL, ushort[] Data)

public bool GetReadRes(int TransNo,

out int State, out ushort[] Data)

public bool GetWriteRes(int TransNo,

out int State)

public bool NextReadRequest(PlcLink

Link)

public bool NextWriteRequest(PlcLink

Link)

public void RemoveLink(string PlcId)

public void RemoveUnusedLinks()

public void ResetDrivers()

public void SetSimulationOff()

public void SetSimulationOn()

PlcTrans

PlcLinkData

Thread

public Start()

public Thread(ThreadStart start)

PlcLink

PlcLinkList

PlcTransData

<<Enumeration>>

PlcTransState

Unused

Queued

Unqueued

Ongoing

Success

Error

Timeout

Closed

Opening

Opened

Reading

Writing

Unused

Error

Watch dog

Read Trans

Write Trans

Figura 13: Diagramma delle classi PipeObject.

3.4 schema uml delle classi 19

PlcDriver

public bool AddLink(PlcLink Link)

public bool RemoveLink(PlcLink Link)

public PlcDriverData GetDriverDtata()

public void ResetDriver()

public void ResetDriverPreservingLinks()

public void terminateDriver()

protected void Execute()

protected SetDriverState(PlcDriverState dState)

protected void OpenLink(PlcLink Link)

protected void ReadLink(PlcLink Link)

protected void WriteLink(PlcLink Link)

protected void CloseLink(PlcLink Link)

protected void TerminateLink(PlcLink Link)

Thread

public Start()

public Thread(ThreadStart start)

<<Enumeration>>

PlcDriverState

Unused

Active

Error

Simulation

Restarting

Stopped

Closed

1:1 1 : M

1:1

PlcLink

PlcDriverSoftnet

PlcDriverAllenBradley

PlcDriverSendReceive

protected abstract bool InitializeDriver()

protected abstract void FinalizeDriver()

protected abstract Result SetOpenRequest(PlcLink Link)

protected abstract Result GetOpenResult(PlcLink Link)

protected abstract void ResetOpenRequest(PlcLink Link)

protected abstract Result SetReadRequest(PlcLink Link)

protected abstract Result GetReadResult(PlcLink Link)

protected abstract void ResetReadRequest(PlcLink Link)

protected abstract Result SetWriteRequest(PlcLink Link)

protected abstract Result GetWriteResult(PlcLink Link, )

protected abstract void ResetWriteRequest(PlcLink Link)

protected abstract void ServeCloseRequest(PlcLink Link)

PlcLinkList

Figura 14: Diagramma delle classi PlcDriver

4I M P L E M E N TA Z I O N E D E L G AT E

In questo capitolo verranno trattati gli aspetti cruciali dell’implemen-tazione. Verrá presentata la soluzione adottata, approfondendone ipassi piú rilevanti, sottolineando le principali funzionalitá introdotteed evidenziando le modifiche piú consistenti apportate, spiegando,dove necessario, i motivi e le difficoltá incontrate.

4.1 ambiente di sviluppo

L’implementazione di una soluzione software cosí complessa, comequella prodotta dal livello 2 per l’automazione del processo produtti-vo, richiede l’utilizzo di strumenti di sviluppo avanzati: essi cercanodi risolvere alcune problematiche legate principalmente alla necessitádi operare in team e all’organizzazione del codice.Questi aspetti sono rilevanti soprattutto perchè un’implementazionedel software ordinata e ben organizzata permette di produrre menoerrori e consente un’efficiente ed efficace manutenzione del software.Quest’ultimo aspetto, in particolare, é molto importante in quanto leapplicazioni all’interno di un’acciaieria necessitano di uno sviluppocontinuo.Per far fronte a tutte queste necessitá, all’interno del livello 2 si uti-lizza l’ambiente di sviluppo integrato (IDE) Visual Studio 2010 edil sistema software di controllo di versione distribuito GIT (con larelativa estensione per Visual Studio).Con GIT é possibile controllare e gestire lo sviluppo del softwareattraverso un repository.Le principali caratteristiche del GIT sono:

• favorire lo sviluppo non lineare: supporta diramazioni e fusioni(branching e merging);

• permettere lo sviluppo distribuito: ogni sviluppatore possiedeuna copia locale interna della cronologia di sviluppo;

• gestire efficientemente grandi progetti: GIT é molto veloce escalabile.

GIT possiede una licenza GNU GPL (General Public License) e la suadistribuzione é libera.

4.2 utilizzo delle eccezioni

Una delle potenzialitá offerta da C#, che é stata largamente utilizzatanello sviluppo del software, é la gestione delle eccezioni: é stato fattolargo uso di questa tecnica nell’implementazione di tutte le parti del

21

22 implementazione del gate

software e questo ha portato evidenti benefici rispetto alla precedentesoluzione.Nel software oggetto della tesi, ogni qual volta si verifica un erroreviene lanciata un’eccezione che deve essere gestita in maniera oppor-tuna.L’utilizzo delle eccezioni é stata una parte molto delicata dello svilup-po, in quanto se non gestite correttamente fanno terminare l’applica-zione in maniera errata.

4.3 implementazione della classe pipeobject

L’implementazione del nuovo sistema di comunicazione Gate é ini-ziata dalla classe principale PipeObject, la quale rappresenta la partedel software di comunicazione a cui le applicazioni fanno riferimentoper comunicare con i PLC.E’ importante che questa classe possieda un’unica istanza; ció é statorealizzato utilizzando un “Singleton”.Il “Singleton” é un pattern, cioé una soluzione progettuale, che per-mette ad una classe di possedere una sola istanza e di fornire un pun-to di accesso globale ad essa; per accedervi si utilizza una funzionestatica della classe PipeObject chiamata CurrGate().Non volendo entrare nella descrizione dettagliata del pattern, di que-sta funzione si puó dire che semplicemente restituisce l’istanza delPipeObject in esecuzione creandola se non ne esiste una.Questo pattern é stato utilizzato in svariate altre situazioni come adesempio per il gestore degli Score e dei Log.Una caratteristica rilevante del PipeObject é quella di simulare la co-municazione con i PLC; esso é la classe che incorpora tutte le funzioniper riprodurre, introducendo dei ritardi fittizi, le Transazioni verso unPLC.Questo é molto utile sia per testare il Gate, sia per testare le applica-zioni del livello su impianti giá funzionanti.Nella gestione dello stato di simulazione sono state apportate dellemodifiche rilevanti rispetto al precedente sistema di comunicazione:lo stato di simulazione veniva impostato tramite un pulsante sull’in-terfaccia del Gate e veniva affidata ad un tecnico la responsabilitádell’impostazione di tale stato, senza alcun controllo da parte delsoftware.Questo comportamento é stato giudicato scomodo in quanto se unimpianto é in funzione ed un tecnico inserisce lo stato di simulazio-ne, i PLC non controllano piú il processo produttivo; similmente se lostato di simulazione viene interrotto passando in modalitá reale é pos-sibile che le applicazioni che in quel momento stanno testando dellefunzionalitá, vadano ad agire direttamente sul sistema di produzionealterandolo dannosamente.A fronte di queste considerazioni, nella nuova soluzione prodotta, lostato di simulazione puó essere impostato solo se al momento nonsono presenti Link aperti.

4.4 implementazione della classe plcdriver 23

Il PipeObject, per passare in modalitá simulazione, setta una variabile,crea dei blocchi simulati e fa in modo che le richieste di apertura delLink non vengano piú passate ai driver.Il driver all’inizio del ciclo Execute si accorgerá, tramite la varia-bile impostata da PipeObject, che quest’ultimo é in simulazione eimposterá il proprio stato in Simulation.Le Transazioni accodate in seguito verranno effettuate utilizzando isuddetti blocchi simulati.

4.4 implementazione della classe plcdriver

La classe PlcDriver é la classe ancestrale del driver che definisce lefunzioni per interagire con PipeObject.PlcDriver contiene al suo interno un thread che ciclicamente percorrela funzione Execute.Rispetto alla versione precedente, questa funzione ha subito una no-tevole trasformazione facendo in modo che PlcDriver assumesse unmodello diverso, ovverosia a stati finiti.Con tale modifica é stato possibile ordinare il comportamento del dri-ver e rendere il codice molto piú chiaro; questo modello ha permes-so di riscontrare piccoli errori e ridondanze all’interno del progettoprecedente.

4.5 riprogettazione del comportamento ancestrale del

driver

La riprogettazione del comportamento ancestrale del driver é la modi-fica piú rilevante del nuovo software di comunicazione; tale modificacomportamentale é locata interamente nella funzione di esecuzione(Execute).Questa funzione é stata totalmente riscritta aggiungendone all’iniziouno switch capace di differenziare le operazioni da eseguire in baseallo stato del driver.Il comportamento del driver é gestito dai seguenti stati:

Unused: in questo stato il driver non ha inizializzato le librerie e at-tende che PipeObject gli assegni un Link da servire.Active: in questo stato, cioé quando un Link necessita di essere servi-to, il driver carica le librerie native e cerca se in PipeObject sono stateaccodate nuove Transazioni per i Link aperti.Error: se l’inizializzazione della libreria é fallita, il driver entra in que-sto stato e, a seguito di un tempo di attesa, cerca di re-inizializzarla.Restarting: in questo stato il driver rilascia le librerie, se caricate, eli-mina tutti i Link e si riavvia. Questa modalitá é stata inserita a seguitodi alcuni problemi con una serie di reti, riscontrate in alcuni impianti:a volte accadeva che all’interno di reti particolari un Link persistessenello stato di Error ed il driver non riuscisse piú a servire alcun Link;in tal caso si rendeva necessario un riavvio per poter nuovamente in-teragire con i PLC.


INIZIO

UNUSED

Entry / Link da servire = 0

Do / Attende e inizial. driver

Exit / Link da servire > 0

ACTIVE

Entry / Link da servire > 0

Do / Apre link, attende transazioni ed esegue

transazioni

Exit / Links da servire = 0 oppure un link è in stato

di errore per più di MaxOveralltime oppure è

stata richiesta la chiusura del driver

STOPPED

Do / Finalizza il driver e

rimuove i link.FINE

RESTARTING

Do / Finalizza driver e terimina link

SIMULATION

Entry / Mod. sim. richiesta

Do / Finalizza il driver e attende

Exit / Mod. live richiesta

ERROR

Entry / Inizial. driver fallita

Do / Aspetta timeout

Figura 15: Diagramma degli stati di PlcDriver

Simulation: se il PipeObject é in modalitá simulazione il driver rila-scia le librerie, se caricate, e attende che PipeObject esca dalla moda-litá simulazione ed entri in modalitá reale.Stopped: il driver entra in questo stato se é richiesta la chiusura deldriver; in questo stato vengono rilasciate le librerie, terminati tutti ithread di esecuzione e viene chiuso il sistema.

Questa gestione del driver risulta molto pulita dal punto di vista delcodice e permette una certa sincronia nelle operazioni; essendo l’ese-cuzione della funzione Execute ciclica, il driver ad ogni ciclo controllae gestisce il suo stato che puó eventualmente venirgli imposto daalcune condizioni esterne.Una caratteristica rilevante di PlcDriver é che eventi di natura asin-crona vengono rilevati dal driver solo al ciclo successivo e quindi inmaniera sincrona dal suo punto di vista.

Di seguito viene riportato una porzione del codice della funzione Exe-cute che rappresenta le operazioni che il driver esegue quando é nellostato ATTIVO.

Listing 1: “Porzione della funzione Execute. Viene eseguita dal driverquando si trova nello stato ACTIVE”

1 case PlcDriverState.Active:

#region ACTIVE

ScoreState = PipeObject.DriverScores().GetScore(_ThreadDriver.

Name + " Active");ScoreState.IncStarted();

4.5 riprogettazione del comportamento ancestrale del driver 25

6 if (_Links.Count == 0)

{

if (_Initialized)

{

FinalizeDriver();

11 }

SetDriverState(PlcDriverState.Unused, ‘‘There are no links to

serve’’

, String.Format(‘‘Driver {0} DLL released, because there are

no links to serve.’’

, PlcDriverDesc.GetInfo(_Type).Name));

}

16 else

{

// Detection of reset cycles requirement

if (_Links.OverallErrorTime > GateConstants.

MaxDriverLinksErrorTime)

{

21 SetDriverState(PlcDriverState.Restarting, "Driver automatic−reset . . . ");

break;

}

for (int i = 0; i < _Links.Count; i++)

{

26 if (_Links[i].IsLinkInactive())

{

PlcLink Link = _Links[i];

RemoveLink(Link);

}

31 else

{

// Try to Open Closed Links

switch (_Links[i].State)

{

36 case PlcLinkState.Error:

case PlcLinkState.Closed:

case PlcLinkState.Opening:

if (_Links[i].CanStartNewOperation())

{

41 // Check if link has finished opening or else

submit a open request

OpenLink(_Links[i]);

}

break;

case PlcLinkState.Opened:

46 // Serve a new transaction to an open link. Writes

have priority

if (_Links[i].CanStartNewOperation())

{

if (PipeObject.CurrGate().NextWriteRequest(_Links

[i]))

{

51 WriteLink(_Links[i]);

}

else


{

if (PipeObject.CurrGate().NextReadRequest(_Links[i]))

56 {

ReadLink(_Links[i]);

}

}

}

61 break;

case PlcLinkState.Writing:

// Check if reading finished

WriteLink(_Links[i]);

break;

66 case PlcLinkState.Reading:

// Check if reading finished

ReadLink(_Links[i]);

break;

}

71 }

}

Thread.Sleep(20);

}

ScoreState.IncSucceded();

76 break;

#endregion

}

L’implementazione dei driver specifici tramite l’ereditarietá della clas-se PlcDriver é stata completata per il driver Softnet, per il quale sidisponeva di un PLC.Per quanto riguarda il driver AllenBradley é stato implementato soloil codice e del driver non si é potuto testare alcuna funzionalitá, nondisponendo di un PLC di quel tipo.Nessun aspetto di SendReceive r stato considerato e sviluppato.Nella realizzazione del driver Softnet, il quale utilizza le funzionidella libreria SIEMENS scritta in C (S732.dll), sono state riscontrategrandi difficoltá in quanto l’ambiente C# rientra nella famiglia deicodici managed i quali gestiscono automaticamente l’allocazione dellestrutture in memoria.L’uso dei puntatori in questo tipo di codici é deprecabile e quindi éstato necessario un grosso sforzo per riuscire ad utilizzare le libreriecitate con i tipi di variabili offerti da C#.Le principali tecniche utilizzate per consentire al software di include-re le funzioni della libreria S732.dll, sono: i tipi delegate delle funzioni,i descrittori dei tipi di variabile e l’uso di alcune parti del codicedette unsafe, che sono porzioni di codice gestite in maniera diversadal compilatore, ovverosia come se fossero state scritte con un codicedi tipo unmanaged.

4.6 implementazione del sistema remoto

Nella fase di sviluppo della soluzione software, é maturato l’interesseda parte del team del livello 2 di verificare le potenzialitá offerte da

4.7 implementazione degli score 27

WCF (Windows Comunication Foundation) ed il Gate é stato unabuona piattaforma su cui testare tale tecnologia.Questo é servito per avere una panoramica sul futuro sviluppo delleapplicazioni del livello stesso, non solo per quanto riguarda quellodel Gate.Dal punto di vista del sistema di comunicazione prodotto, l’utilizzodi queste funzionalitá é stato implementato ed é funzionante.Non é stato possibile approfondire tale parte del progetto in quantonon avrebbe avuto senso nel quadro generale dello sviluppo softwaredel livello, principalmente perchè al momento non era ancora statastudiata alcuna strategia in merito.Il sistema remoto del Gate non fa altro che rendere pubbliche alleapplicazioni i metodi del PipeObject.Attraverso un indirizzo é possibile collegarsi all’oggetto PipeObject eriuscire a comunicare con esso; in questa parte vengono omesse tuttele strategie adottate nel dettaglio.Il problema piú rilevante é stato riscontrato nel lancio delle eccezio-ni in remoto; si é reso indispensabile incapsulare le normali eccezio-ni sollevate dal Gate in altre modellate appositamente per viaggiaresulla rete, in modo che evitino di bloccarlo.Sebbene lo sviluppo é stato solo marginale, sono stati tratti ottimispunti per le successive implementazioni da parte di tutte le applica-zioni, anche se permangono alcune riserve per quanto riguarda i datitrasmessi in rete e le modalitá con cui vengono serializzati.L’ultima modifica al progetto é stata fatta inserendo la classe GateDe-finitions in una libreria chiamata Pipe che dovrá essere inclusa in ogniapplicazione che vuole comunicare con il Gate, in quanto contiene ledefinizioni delle variabili necessarie per la comunicazione.

4.7 implementazione degli score

Un’importante fase dello sviluppo del software é stata quella di test;essa ha consentito di ottimizzare e controllare il software prodotto,permettendo di correggere errori ed apportare migliorie.Per questo motivo il Gate implementa la classe Score, che é capace diregistrare la durata e l’esito di gran parte delle funzioni esaminate.Attraverso questa classe é possibile visualizzare dettagli sull’efficien-za e l’affidabilitá del software di comunicazione prodotto.Partendo dal concetto che ogni qualvolta si genera un’eccezione c’équalcosa che non funziona nel sistema, avere uno strumento che regi-stra l’esito delle funzioni permette di localizzare l’errore molto sem-plicemente.Tramite l’utilizzo degli Score si possono ottenere statistiche sul tempodi utilizzo delle funzioni e si puó quindi intervenire sulle stesse perottimizzarle e rendere efficiente il sistema.


4.8 implementazione dell’applicazione di test board

Per testare il Gate é stata sviluppata parallelamente una nuova appli-cazione detta Board.Lo scopo del Board é di simulare la condizione di un’applicazione dilivello 2 che necessita di comunicare con il Gate.Esso incorpora le procedure quali la connessione al Gate, la definizio-ne di un Link, la lettura e la scrittura su PLC.Tramite il Board ci si puó connettere al Gate in remoto e si possonovisualizzare molte informazioni utili quali:

• le Transazioni;

• il reistro degli eventi (Log);

• gli Score.

Attraverso lo sviluppo del Board é stato possibile eseguire uno stresstest, il quale si é dimostrato uno strumento fondamentale per testarele funzioni del Gate.Molte altre funzionalitá dovranno essere aggiunte al Board, una fratutte la possibilitá di prelevare le configurazioni dei Link da un data-base.

5I M P L E M E N TA Z I O N E D E L L E I N T E R FA C C E

In questo capitolo verranno illustrate le interfacce prodotte delle ap-plicazioni Gate e Board; inoltre verrá data un’indicazione sul contenu-to delle medesime illustrandone i vari utilizzi possibili. Le interfaccesono state sviluppate in WPF utilizzando una libreria chiamata Xceed,strumento utile per consentire una gestione dinamica delle finestre edei controlli in esse contenuti.

5.1 implementazione dell’interfaccia gate tramite wpf

L’implementazione dell’interfaccia del Gate risulta complessivamentesemplice in quanto verrá utilizzata soltanto da personale specializza-to del livello 2.Di seguito viene riportato uno screenshot dell’applicazione Gate.

Figura 16: Applicazione Gate

L’interfaccia mostrata viene divisa in piú finestre che incorporanogli UserControl; essi includono al proprio interno una classe chia-mata GateViewer la quale, attraverso un thread interno, preleva adintervalli regolari i dati dal Gate e modifica le variabili visualizzate.Attraverso lo schema Model - View - ViewModel l’interfaccia si ac-corge della modifica e i dati vengono automaticamente aggiornati avideo.Gli UserControl sono ancorabili all’interno della finestra e, attraversoil mouse, é possibile sganciarli, chiuderli e modificarne la posizione.I tre UserControl componenti l’interfaccia del Gate sono:

• Driver Status: visualizza i driver in esecuzione, ne indica lostato ed i cicli Execute percorsi da ognuno; nella parte bassadi questa finestra c’é una tabella riservata ai Link attualmentegestiti dai driver, dove viene visualizzato il nome, lo stato ealcune indicazioni utili in caso di errore.

29

30 implementazione delle interfacce

• Pipe Scores: visualizza gli Score relativi alle funzioni del eindica il numero di volte che é stata lanciata la funzione, ladurata media, la durata massima, quella totale e l’esito.

• Driver Scores visualizza gli Score relativi alle funzioni dei dri-ver con gli stessi campi descritti per le funzioni in Pipe Scores.

Tramite il Driver Status é possibile impostare lo stato di Simulazio-ne attraverso un apposito pulsante mentre tramite Reset Driver épossibile riavviare i driver.

5.2 implementazione dell’interfaccia board tramite wpf

Anche nel Board sono presenti gli UserControl tramite i quali é pos-sibile controllare lo stato delle Transazioni similmente all’interfacciadel Gate.

Figura 17: Applicazione Board

Anche qui gli UserControl relativi alle Transazioni includono unaclasse GateViewer contenente a sua volta un thread capace di prelevarei dati delle Transazioni dal Gate e visualizzarli a video.I tre UserControl illustrati sono:

• PLC Comunication: da questa finestra é possibile collegarsi alGate e lanciare delle funzioni attraverso a dei pulsanti e visua-lizzarne l’esito in un riquadro; in particolare é possibile definireun link ad un PLC, leggere e scrivere dati interagendo con lamemoria del suddetto PLC.

• Read Transactions: da questa finestra é possibile osservare lestatistiche di ogni transazione; in particolare vengono mostratilo stato attuale ed il tempo impiegato nei vari stati intermedi.

• Write Transactions: ha la stessa funzionalitá dello UserControlRead Transactions solo che mostra le Transazioni in scrittura.

5.2 implementazione dell’interfaccia board tramite wpf 31

Per prima cosa, per utilizzare il Board, é necessario collegarsi al Gatetramite l’apposito pulsante di connessione, dopo aver inserito l’indi-rizzo IP su cui é in esecuzione il Gate. Fatto ció, vengono visualizzatenella parte bassa le Transazioni in lettura e scrittura sulle quali é possi-bile apprezzarne lo stato. La funzione Reset Drivers contenuta in PLCComunication non viene normalmente utilizzata dalle applicazionima é risultato utile integrarla nel Board per la fase di sviluppo.

6U T I L I Z Z O E T E S T D E L S I S T E M A D IC O M U N I C A Z I O N E G AT E

In questo capitolo verranno illustrati i casi d’uso del software e ver-ranno descritti i test eseguiti sullo stesso.

6.1 casi d’uso del gate

Applicazioni

del livello 2

Scrivere su PLC

Librerie proprietarie

Leggere da PLC

Configurare parametri connessione

Visualizzare lo stato delle

comunicazioni

Tools di configurazione

delle librerieAmministratori

di rete

Figura 18: Casi d’uso UML

6.2 test del gate tramite l’applicazione board

Come giá accennato, tramite il Board é possibile effettuare il test dellefunzionalitá del Gate.Il Board simula le condizioni in cui opera una qualsiasi applicazionedel livello 2.Inoltre offre agli amministratori di rete uno strumento per visualizza-re lo stato delle comunicazioni del Gate.I principali test riguardanti il Gate consistono nel testare il correttouso delle librerie specifiche e della buona riuscita delle letture.Durante il tirocinio é stato utilizzato solo un PLC SIEMENS e quindié stato possibile testare solo questo tipo di driver.Attraverso il Board, come visto nel capitolo precedente, si puó leggeree scrivere su un PLC connesso e configurato.Per testare queste funzionalitá, di lettura e scrittura, é stata accodataprima una richiesta di scrittura su di una porzione della memoria chesuccessivamente é stata letta confrontando la corretta riuscita delleoperazioni tramite gli Score.Per testare il sistema di accodamento delle Transazioni, é stato imple-mentato uno strumento per lo stress test.

33

34 utilizzo e test del sistema di comunicazione gate

Attraverso un apposito pulsante nel Board, l’applicazione accoda 100

richieste di lettura distinte e successivamente accoda una richiesta discrittura.Questo test serve a controllare:

1. Che la Transazione in scrittura venga eseguita prima delle ri-chieste di lettura.

2. Che le Transazioni in lettura, di cui non viene letto il risultato,scadano per timeout.

3. Che l’array delle Transazioni in lettura si ridimensioni per ser-vire il gran numero di richieste.

Questi test del Gate sono stati implementati per garantire che il soft-ware soddisfi le condizioni minime di funzionamento. Altri test do-vranno essere eseguiti soprattutto in fase di collaudo nell’impian-to; questo é conseguenza del fatto che é necessario impostare alcu-ni parametri di connessione adatti all’ambiente su cui il Gate deveoperare.

7C O N C L U S I O N I

Il software sviluppato durante il tirocinio risulta essere un prodottoancora in fase sviluppo.Gli obiettivi prefissati sono stati complessivamente raggiunti nono-stante non si disponesse di tempo sufficiente a consentire la produ-zione di un software completo.Questo software di comunicazione ha reso necessario l’impegno diparticolari attrezzature, quali i PLC, che sono stati condivisi con altrisviluppatori del livello 1; nonostante ció, l’azienda é riuscita a metter-ne a disposizione di tipo SIEMENS S7 durante tutto lo sviluppo diquesto progetto.Per completare il software sarà necessario implementare e testare an-che la funzionalità dei restanti driver proprietari (AllenBradley e Sen-dReceive). Il driver S7 funziona correttamente e l’utilizzo della libre-ria nativa, anche se largamente perfezionabile, avviene in manierasostanzialmente efficiente.Anche se la fase di test, ad esclusione di piccole funzioni di pro-va, deve essere ancora affrontata, il risultato rimane ugualmente piúche soddisfacente in quanto il software prodotto incarna le principalifunzioni di quello attualmente utilizzato.Le tecniche degli automi a stati finiti e l’utilizzo di alcuni design pat-tern rappresentano, nella loro implementazione pratica, i punti diforza del sistema.Sicuramente anche questi modelli dovranno evolversi assieme ai si-stemi.C’é stato un notevole stupore da parte mia nell’apprendere comemodelli matematici e nozioni puramente teoriche, anche di svaria-ta natura, possano trovare spazio in un contesto pratico ed offrire uncontributo cosí essenziale.L’utilizzo del linguaggio C# ha offerto un sostanziale apporto alprogetto soprattutto grazie all’utilizzo delle librerie dotNet con parti-colare riferimento alla serializzazione di oggetti e la comunicazioneclient-server.Le interfacce andranno ulteriormente sviluppate e migliorate soprat-tutto sotto l’aspetto dei modelli, in quanto l’utilizzo di un thread al-l’interno dei ViewModel puó essere classificato come uno dei puntideboli del prodotto.Il software sviluppato ha richiesto molti sforzi, in particolare perquanto riguarda l’interpretazione delle problematiche da affrontaree la loro modellizzazione.Indicativamente sono state prodotte circa 27 classi e 10000 righe dicodice.Il progetto sviluppato all’interno dell’azienda é stato molto stimo-lante in quanto ha messo alla prova le mie capacitá di risolvere iproblemi legati alla programmazione.

35

36 conclusioni

Sono molto soddisfatto di aver lavorato all’interno di un’azienda cheopera in un panorama cosí vasto e questa esperienza é stata impre-ziosita dall’ottimo rapporto instaurato con il team di sviluppo.

B I B L I O G R A F I A

1. Design Patterns - Elements of Resusable Object-Oriented Software

[Erich Gamma, Richard Helm, Ralph Johnson, Jhon Vlissiders];

2. WPF 4 - Unleashed

[Adam Nathan];

3. C# 4 - Espresso

[Bochicchio Daniele, Civera Cristian, De Sanctis Marco, Golia riccar-do];

4. Pro Git

[Scott Chacon];

5. UML 2 e Unified Process - Analisi e progettazione Object-Oriented 2/ed

[Jim Arlow, Ila Neustadt]

6. Manuale - “SIEMENS SIMATIC NET - S7 Programming Interface”:

7. Manuale - “SIEMENS SAPI S7 dotNET INSTRUCTIONS”;

37

Documents

PALUZZANO TESI