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 famiglia
ed ai miei amici.

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

INDICE
1
2

3

4

5

6

7

introduzione
1.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . .
reti di comunicazione industriali
2.1 Organizzazione aziendale . . . . . . . . . . . . . . . . .
2.2 Struttura delle reti industriali . . . . . . . . . . . . . . .
2.3 Protocolli utilizzati da SoftNet-S7 . . . . . . . . . . . . .
2.4 Enunciazione dei principi delle comunicazioni . . . . .
2.5 Problematiche legate alla comunicazione . . . . . . . .
2.6 Entitá coinvolte nella comunicazione . . . . . . . . . . .
analisi e progettazione del software di comunicazione
3.1 Analisi delle caratteristiche del software precedente . .
3.2 Analisi del comportamento delle entitá . . . . . . . . .
3.3 Studio del software esistente . . . . . . . . . . . . . . .
3.3.1 Studio del Gate e delle strutture condivise . . .
3.3.2 Studio dei driver di comunicazione . . . . . . .
3.4 Schema UML delle classi . . . . . . . . . . . . . . . . . .
implementazione del gate
4.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . .
4.2 Utilizzo delle eccezioni . . . . . . . . . . . . . . . . . . .
4.3 Implementazione della classe PipeObject . . . . . . . .
4.4 Implementazione della classe PlcDriver . . . . . . . . .
4.5 Riprogettazione del comportamento ancestrale del driver
4.6 Implementazione del sistema remoto . . . . . . . . . .
4.7 Implementazione degli Score . . . . . . . . . . . . . . .
4.8 Implementazione dell’applicazione di test Board . . . .
implementazione delle interfacce
5.1 Implementazione dell’interfaccia Gate tramite WPF . .
5.2 Implementazione dell’interfaccia Board tramite WPF .
utilizzo e test del sistema di comunicazione gate
6.1 Casi d’uso del Gate . . . . . . . . . . . . . . . . . . . . .
6.2 Test del Gate tramite l’applicazione Board . . . . . . . .
conclusioni

bibliografia

1
1
3
3
5
6
6
8
9
11
11
11
13
14
15
18
21
21
21
22
23
23
26
27
28
29
29
30
33
33
33
35
37

v

1

INTRODUZIONE

1.1

premessa

Il lavoro che mi accingo a presentare é stato svolto nell’ambito del
tirocinio all’interno dell’azienda SMS Concast con sede a Tarcento
(UD).
SMS Concast sviluppa e produce apparecchiature per l’intero processo di produzione di acciaio ed in particolare si occupa di fornire software per l’automazione, il controllo e l’ottimizzazione dei processi
siderurgici.
In questa tesi viene presentata la realizzazione di un software di comunicazione per la raccolta dati da periferiche PLC, allo scopo di
alimentare i software di controllo del processo produttivo.
Le applicazioni sviluppate dall’azienda svolgono svariati compiti, dalla visualizzazione dello stato degli impianti al calcolo dei piani di
taglio dell’acciaio.
Per svolgere tutte le loro funzioni, i suddetti applicativi devono poter
comunicare con le macchine di produzione, le quali sono automatizzate e controllate da dei dispositivi che ne gestiscono lo stato e le
comandano.
Questi dispositivi vengono chiamati PLC (Programmable Logic Controller), cioé controllori a logica programmabile.
All’interno di un impianto siderurgico é possibile che vengano installati vari PLC, anche di case produttrici differenti. Per poter gestire
ogni tipo di PLC ogni casa produttrice fornisce un proprio driver, che
utilizza librerie e protocolli proprietari specifici.
Le comunicazioni tra applicazioni e PLC all’interno dell’acciaieria avvengono tramite una rete locale (LAN) alla quale i dispositivi sono connessi; esse hanno un ruolo fondamentale in quanto la loro
interruzione non permetterebbe piú alle applicazioni di controllare
correttamente il processo produttivo.
I motivi che hanno spinto l’azienda a produrre un software di comunicazione che facesse da intermediario tra applicazioni e PLC sono:
1. la difficoltá che comporta il dover comunicare con dispositivi
prodotti da aziende differenti;
2. la necessitá di affidabilitá e robustezza delle comunicazioni in
ambito industriale.
La produzione di questo tipo di software offre notevoli vantaggi poichè l’utilizzo di uno strumento che centralizza le comunicazioni permette ai tecnici di monitorare le richieste delle singole applicazioni,
di cronometrarle e di simularle al fine di testare e diagnosticare funzionalitá e problemi della rete e delle comunicazioni stesse.

1

2

introduzione

Attualmente é giá stato implementato, ed é tutt’ora funzionante in
molti impianti, un software di comunicazione di questo tipo sviluppato in linguaggio Pascal.
Una nuova commessa ha peró imposto il cambiamento del linguaggio
di sviluppo, richiedendo che tutte le applicazioni fossero scritte in
C# ed avessero le interfacce prodotte in WPF (Windows Presentation
Foundation).
Il tirocinio ha avuto come obiettivo quello di analizzare la soluzione
precedente, di migliorarla ove possibile e di riprogettarla utilizzando
il linguaggio C#, sfruttando le librerie dotNet.
I passi intrapresi nello sviluppo della soluzione sono i seguenti:
• introduzione e studio del problema da risolvere con particolare
attenzione alle specifiche di affidabilitá legate all’applicazione
industriale;
• analisi critica della precedente soluzione software, giá sviluppata dall’azienda, al fine di evidenziarne le carenze ed i punti di
forza;
• progettazione e sviluppo di una nuova soluzione software.

2

RETI DI COMUNICAZIONE INDUSTRIALI

In questo capitolo verranno esposti i principali problemi legati alla comunicazione industriale e verranno illustrati i protocolli di piú basso
livello utilizzati. Piú in generale si deﬁniranno i principi, le funzionalitá e l’ambiente in cui il software di comunicazione é stato prodotto
e quello in cui dovrá operare.
2.1

organizzazione aziendale

Per la gestione del processo produttivo l’organizzazione della SMS
Concast é strutturata su piú livelli, ognuno preposto allo sviluppo di
un singolo aspetto del processo.
Il livello gerarchicamente piú basso, denominato “Livello 1”, si occupa dell’automazione e dell’equipaggiamento meccanico delle macchine.
In questo livello viene curata la preparazione per la corretta esecuzione delle istruzioni per la produzione.
I PLC sono dispositivi che hanno il compito di elaborare i segnali provenienti dai rilevatori ed inviare i comandi agli attuatori che
controllano diversi tipi di sistemi (meccanici, ﬁsici, ottici, ecc.).
Al loro interno i PLC incorporano uno o piú processori (CPU) che
leggono e scrivono dati sulla memoria, tipicamente interna, e comandano gli attuatori.
Le applicazioni che necessitano di comunicare con un PLC hanno
la possibilitá di agire sulla memoria, cambiando cosí il suo stato
interno.

PLC
SCHEDA DI RETE

MEMORIA

ATTUATTORI

CPU

RILEVATORI

Figura 1: Organizzazione aziendale.

Il livello superiore, denominato “Livello 2”, si occupa del controllo
del processo produttivo
Il software progettato e descritto in questa tesi é il sistema di comunicazione tra il livello 2 ed i PLC.

3

4


Le applicazioni di livello 2 vengono utilizzate per l’ottimizzazione
della produzione e per il confronto dei dati di produzione con modelli matematici studiati ad hoc, visualizzando graﬁcamente l’andamento dei parametri e calcolando le azioni necessarie.
Alcuni degli utilizzi possibili, in campo siderurgico, sono il controllo
e l’analisi dei parametri chimici durante la fusione, al ﬁne di produrre
la “ricetta chimica” di additivi ottimale per la produzione della lega
voluta.
E’ sostanzialmente il livello che supervisiona e controlla “cosa produrre” e “come produrre”.
Il livello gerarchicamente piú alto, denominato “Livello 3”, si occupa
della gestione delle commesse e di schedulare il lavoro da eseguire
unitamente alla gestione contabile del processo: in poche parole si
occupa del “quando produrre”, “in che ordine temporale” e “per chi”.
PROCESSO
PRODUTTIVO
LIVELLO 3
APP

APP

Scheduling

LIVELLO 2
APP

APP

APP

APP

BOARD

Controllo di
processo

GATE

LIVELLO 1
PLC AB

PLC S7

PLC SR

APP

APP

APP
Automazione

HW

HW

HW

Software presentato nella tesi
Software scviluppato dai team
di livello
Dispositivi programmabili PLC
AB = Allen Bradley
S7 = Siemens
SR = Driver Sand Receive
Macchine meccaniche

Figura 2: Organizzazione aziendale.

2.2 struttura delle reti industriali

2.2

struttura delle reti industriali

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

APPLICAZIONE
Dai processi di rete all’applicazione

PRESENTAZIONE
Presentazione dei dati e criptazione

SESSIONE
Controllo comunicazioni tra applicazioni

TRASPORTO
Connessione end-to-end e affidabilità

7

6

5

PLC GATEWAY

PROTOCOLLI SOFTNET
PROTOCOLLI DRIVER ALLEN BRADLEY
PROTOCOLLI SEND RECEIVE

4
TCP / IP

RETE
Determinazione e traduzione degli indirizzi

COLLEGAMENTO
Indirizzamento fisico

FISICO
Media, segnale e trasmissione binaria

3

2

MAC ADDRESS

1

INTERFACCIA ETHERNET

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

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

5

6


levare e correggere guasti ed errori, che non sono rari in un impianto
siderurgico.
2.3

protocolli utilizzati da softnet-s7

Di seguito viene illustrato il funzionamento delle librerie proprietarie
e dei protocolli di un PLC SIEMENS S7.
Un PLC di questo tipo é stato messo a disposizione dall’azienda durante lo svolgimento del tirocinio per le fasi di progettazione e test
delle funzionalitá del sistema di comunicazione.
Il PLC in questione é stato utilizzato facendo particolare attenzione al
corretto utilizzo delle librerie di comunicazione native del PLC stesso.
La SIEMENS sviluppa pacchetti software e dispositivi hardware per
la comunicazione tra le macchine e gli altri componenti di un impianto di produzione.
Quest’azienda mette a disposizione una collezione di programmi e
funzionalitá chiamata SIMATIC NET di cui fa parte il pacchetto SOFTNET.
SOFTNET fornisce API e tools per la configurazione, all’interno del
sistema operativo, della connessione dei PLC collegati tramite la rete
locale.
L’installazione e la configurazione della SOFTNET sono dei processi
complessi che vengono svolti da tecnici specializzati del livello 2 e
che consentono il corretto funzionamento delle librerie native; tali
processi non verranno trattati in questo documento.
Il software di comunicazione da sviluppare dovrá incorporare ed utilizzare le corrette procedure proprietarie, a seconda del tipo di PLC
con cui l’applicazione richiedente necessita di comunicare.
La stessa SOFTNET mette a disposizione, per la comunicazione con
i dspositivi S7, un’API che risulta accessibile attraverso la libreria
S732.dll.
Questa libreria é stata scritta in linguaggio C e contiene delle funzionalitá per la comunicazione con i PLC SIEMENS.
2.4

enunciazione dei principi delle comunicazioni

Attraverso la configurazione del software SOFTNET e tramite la libreria S732.dll é possibile comunicare con un PLC SIEMENS.
La comunicazione tramite questa libreria rende trasparenti alle applicazioni tutte le problematiche relative ai protocolli di piú basso
livello.
Per esempio, un’applicazione non deve conoscere l’indirizzo di rete
IP o il MAC di un PLC per comunicare con esso, ma é sufficiente
che conosca l’ID del PLC cosí come é stato configurato tramite la
SOFTNET.
Come giá enunciato, i principi di funzionamento della SOFTNET
non verranno trattati; tuttavia, per completezza, vengono descritti
brevemente i protocolli per la comunicazione ai livelli sessione ed
applicazione, implementati dalla SOFTNET stessa.

2.4 enunciazione dei principi delle comunicazioni

All’interno dei livelli sessione ed applicazione, vengono gestite due
unitá logiche:
1. VFD (Virtual Field Device);
2. Connection.
Tramite la conﬁgurazione di SOFTNET vengono generati uno o piú
dispositivi virtuali con i quali le applicazioni comunicano direttamente (VFD).
Vengono inoltre create una o piú connessioni (Connection) tra questi
dispositivi virtuali e i PLC reali.
Questa tecnica permette un’astrazione del PLC ﬁsico e del canale di
comunicazione, mascherando di fatto i protocolli di piú basso livello
alle applicazioni richiedenti.
Un’applicazione puó comunicare con piú VFD ed ha accesso esclusivo ad ognuno.
A sua volta un VFD puó essere mappata per comunicare con un solo PLC reale e su di esso possono essere aperte varie Connection
utilizzate per lo scambio dei dati.

APPLICAZIONE 1

VFD 1

APPLICAZIONE 2

VFD 3

VFD 2

connessioni

PLC 1

PLC 2

Figura 4: Relazione tra Applicazioni, VFD e PLC.

In sintesi, quando un’applicazione vorrá comunicare con un determinato PLC, comunicherá in realtá con un VFD utilizzando una determinata Connection.
La logica appena descritta vale, in particolare, per i dispositivi PLC
SIEMENS S7 ed é utile per comprendere le funzioni della libreria
associata.
Di seguito viene illustrata (Fig. 5, 7) una tipica sequenza di chiamate alle funzioni della libreria S732.dll per inizializzare e chiudere la
comunicazione con un PLC S7.
E’ importante notare che le funzioni chiamate non sono bloccanti in
quanto ogni funzione restituisce un valore che garantisce l’esecuzione della funzione stessa ma non l’esito effettivo, il quale puó essere
ricevuto con l’esecuzione del polling, tramite la funzione s7r eceive.

7

8


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
alt

s7_get_initate_cnf()

result = S7_INITIATE_CNF

S7_OK

Figura 5: Apertura comunicazioni S7.

2.5

problematiche legate alla comunicazione

Lo sviluppo di un sistema di comunicazione capace di soddisfare le
necessitá delle applicazioni industriali deve affrontare delle problematiche legate soprattutto all’afﬁdabilitá.
In un impianto industriale é necessario che le comunicazioni siano
afﬁdabili ed i sistemi che le gestiscono siano robusti, in quanto informazioni trasmesse male, o in ritardo, oppure non trasmesse affatto,
possono provocare dei danni.
Per questo motivo é importante che il software in questione generi
meno errori possibili e reagisca bene ad eventuali malfunzionamenti.
Il sistema di comunicazione non deve mai bloccare le applicazioni
chiamanti e deve sempre rispondere alle richieste anche in maniera
negativa, oppure deve far scadere le stesse per timeout.
Tra i requisiti del software da produrre non compare la necessitá di
avere una gestione delle prioritá rispetto alle applicazioni che richiedono la comunicazione.
Dal punto di vista delle prioritá rispetto al tipo di richieste che il sistema deve soddisfare, invece, le Transazioni in scrittura devono avere
la precedenza su quelle in lettura: questo é conseguenza del fatto che
le operazioni di lettura avvengono frequentemente per monitorare
lo stato dell’impianto e il ritardo di una di queste comunicazioni é
accettabile.

2.6 entitá coinvolte nella comunicazione

USER PROGRAM

S732.dll
s7_read_request(int cp_desc, int cref,
int order_id, string read_params)
S7_OK
s7_receive(int cp_desc)

result
alt
result = S7_READ_CNF

s7_get_read_cnf(int length, char* buffer)
S7_OK

Figura 6: Lettura dati da un PLC S7.

USER PROGRAM

S732.dll
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 la
produzione, é importante che lo comunichi il piú velocemente possibile ai PLC, altrimenti si puó veriﬁcare un ritardo nel processo di
produzione.
2.6

entitá coinvolte nella comunicazione

Per progettare un software capace di eseguire sistematicamente le
sequenze descritte nel paragrafo 2.4 e che sia concorrenziale per le
applicazioni, é stato necessario deﬁnire delle entitá intermedie tra gli
interlocutori (applicazioni e PLC).
Esse rappresentano, attraverso le loro strutture, il canale di comunicazione, le operazioni di lettura o scrittura ed il driver di comunicazione.
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;

9

10


• PlcDriver: si prende carico delle richieste pervenute dalle applicazioni e di comunicare con i PLC secondo le corrette librerie
native.
Per la gestione delle entitá é stato largamente utilizzato un modello a
stati ﬁniti con l’intenzione di rendere semplice ed adatta la successiva
implementazione delle classi.
Un’applicazione, per comunicare con un PLC, chiede al Gate l’apertura di un Link verso tale PLC e poi accoda, riferendosi al predetto
Link, delle Transazioni di lettura o scrittura.
Il PlcDriver esegue tutte le procedure per aprire il Link e successivamente si prende carido delle richieste accodate, interagendo con i
PLC tramite i driver proprietari.
Questa iterazione con i PLC viene mascherata alle applicazioni liberandole dall’effettivo compito di svolgere le comunicazioni.
Essendo uno dei requisiti il fatto di impegnare per il minor tempo
possibile le applicazioni nella comunicazione, l’accodare richieste e il
prelevarne l’esito sono procedure distinte ed utilizzabili in maniera
asincrona dalle applicazioni.
Un’importante conseguenza di questo fatto é che un’applicazione non
viene impegnata per attendere l’esito delle richieste ai PLC.
Questo procedimento soddisfa un altro requisito, quello di consentire
alle applicazioni la comunicazione con piú PLC contemporaneamente.
Ad esempio, se per monitorare un impianto un’applicazione deve
eseguire delle letture su 10 PLC, prima accoderá tutte e 10 le richieste
di lettura e successivamente inizierá a prelevarne il risultato.

3

A 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 I
COMUNICAZIONE

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

analisi delle caratteristiche del software precedente

La prima considerazione sul software precedentemente sviluppato
dall’azienda é che quest’ultimo soddisfa le caratteristiche di affidabilitá 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 da
oggetti che ne emulano i comportamenti ed incorporano le strutture
necessarie.
L’utilizzo della programmazione parallela é un punto di forza di questo sistema, che permette ad ogni tipologia di driver proprietario di
poter essere eseguito indipendentemente dagli altri driver e di poter
operare in maniera parallela.
Il sistema é stato predisposto per l’utilizzo da remoto e lo scambio di
informazioni con le applicazioni avviene tramite una serializzazione
dei parametri delle funzioni utilizzate, sottoforma di stringhe.
Il software precedente utilizza un registro degli eventi (LOG), capace di registrarli e dividerli per categoria (ad esempio: Error, Debug,
Warning).
Per quanto riguarda la diagnosi del sistema, questa viene svolta tramite 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 entitá logiche Link e Transazione.
Come precedentemente enunciato la descrizione di questi comportamenti avviene tramite un modello a stati finiti.
Nella progettazione del nuovo sistema di comunicazione, questi schemi sono stati lievemente modificati ed ottimizzati.

11

12


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

Opening

Closed

Opened

Reading

Writing

Chiusura link
richiesta
Timeout

Unused

Timeout

Timeout

Error
Apertura link
rifiutata o fallita

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; si
raggiunge questo stato anche quando si termina un Link.
Opening: é lo stato impostato dal driver nel momento in cui cerca di
aprire il Link e inizializzare la comunicazione con un PLC.
Opened: é lo stato impostato dal driver nel momento in cui riesce ad
aprire la connessione con il PLC; a questo punto é possibile accodare
Transazioni per questo Link.
Reading: é lo stato impostato dal driver nel momento in cui prende
in carico una Transazione di lettura per il Link.
Writing: é lo stato impostato dal driver nel momento in cui prende in
carico una trnasazone di scrittura per il Link.
Error: é lo stato impostato dal driver nel momento in cui non riesce
a 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 Link
rimane nello stato Opened o Closed chiuso per troppo tempo; il Link
viene terminato e poi gli viene impostato questo stato per essere eliminato.

3.3 studio del software esistente

Unused

Queued

Unqueued

Timeout

Ongoing

Success

Error

Figura 9: Diagramma di stato delle Trasazioni.

Lo stato delle Transazioni é gestito dal PipeObject con le seguenti deﬁnizioni:
Unused: viene impostato questo stato quando la Transazione non é
ancora stata utilizzata.
Queued: viene impostato questo stato quando é richiesta una nuova
Transazione verso un Link.
Ongoing: viene impostato questo stato quando il driver si prende carico di eseguire la Transazione.
Success: viene impostato questo stato quando il driver termina di eseguire la Transazione
Unqueued: viene impostato questo stato quando l’applicazione ha
letto il risultato della Transazione.
Timeout: viene impostato questo stato quando una Transazione é rimasta inutilizzata per un determinato periodo.
Error: viene impostato questo stato quando il driver ha riscontrato un
errore 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 Gate
sono:
• PipeObject;
• PlcDirver;
• Link;
• Transazioni;
• GateDeﬁnitions.
La classe PipeObject, che é la classe principale, contiene tutte le istanze delle strutture necessarie al funzionamento del sistema ed é il
tramite tra le richieste delle applicazioni ed il PlcDriver.

13

14


Il compito principale di PipeObject é quello di gestire l’interazione
con tali strutture.
PlcDriver é la classe ancestrale che descrive il comportamento generale che i driver specifici devono ereditare.
Il suo compito é quello di eseguire le richieste delle applicazioni
accodate tramite PipeObject.
GateDefinitions é la classe contenente tutte le definizioni delle strutture condivise e viene utilizzata dalle applicazioni per comunicare
con il Gate.
3.3.1

Studio del Gate e delle strutture condivise

Le applicazioni utilizzano il Gate tramite la classe PipeObject attraverso le funzioni messe a disposizione da quest’ultima.
La descrizione delle funzioni principali di PipeObject utilizzate dalle
applicazioni sono:
• void DefineLink(PlcLinkConfig LinkConfig): definisce un Link
ad un PLC tramite la classe (PlcLinkConfig) che descrvive i parametri di configurazione;
• void RemoveLink(string PlcId): rimuove un Link ad un determinato PLC tramite il suo PlcId;
• int SetReadReq(string PlcId, ushort DB, ushort DW, ushort DL):
inoltra una richiesta di lettura ad un determinato PLC chiedendo di leggere nel blocco DB, nella word DW, una lunghezza
di DL words; restituisce il numero della Transazione necessario
per ricevere i dati della lettura e per capire se é effettivamente
andata a buon fine;
• int SetWriteReq(string PlcId, ushort DB, ushort DW, ushort DL,
ushort[] Data): inoltra una richiesta di scrittura ad un determinato PLC chiedendo di scrivere nel blocco DB, nella word DW,
una lunghezza di DL words i dati contenuti nell’array Data; restituisce un numero identificativo della Transazione utilizzato
per visualizzarne successivamente lo stato;
• bool GetReadRes(int TransNo, out int State, out ushort[] Data): richiede il risultato della lettura della Transazione TransNo
precedentemente accodata; riceve, come risposta, lo stato della
Transazione ed un array con i dati della lettura;
• bool GetWriteRes(int TransNo, out int State): richiede il risultato della scrittura della Transazione TransNo precedentemente
accodata; riceve, come risposta, lo stato della Transazione;
• void ResetDrivers(): questa funzione permette di resettare i driver ed é scarsamente utilizzata dalle applicazioni; viene utilizzata in automatico in presenza di Link che persistono in uno
stato di errore;


• void RemoveUnusedLinks(): questa funzione elimina i Link non
utilizzati se scaduti per timeout;
• void SetSimulationOn(): setta lo stato di simulazione delle Transazioni;
• void SetSimulationOff(): permette di uscire dallo stato di simulazione delle Transazioni.
Le definizioni delle funzioni appena descritte sono state tratte dal
software sviluppato in questa tesi e non dal precedente, in quanto
non hanno subito sostanziali modifiche.
Di seguito vengono rappresentate le sequenze di chiamate alle funzioni del PipeObject da parte delle applicazioni per aprire un Link ed
accodare una richiesta di lettura oppure di scrittura.

APPLICAZIONE

PipeObject

DefineLink(PlcLinkConfig LinkConfig)
SetWriteRequest(string PlcId, ushort DB, ushort DW,
ushort DL, ushort[] data)
int TransactionNumber
loop

GetWriteResult(int TransactionNumber)

return = false

bool result

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

3.3.2

Studio dei driver di comunicazione

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

15

16


APPLICAZIONE

PipeObject

DefineLink(PlcLinkConfig LinkConfig)
SetReadRequest(string PlcId, ushort DB, ushort DW, ushort DL)
int TransactionNumber
loop

GetReadResult(int TransactionNumber)

return = false

bool result, TransState State, ushort[] Data

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

In questo ciclo il driver controlla se sono presenti Link da servire e in
caso affermativo carica le librerie native e le inizializza.
Successivamente, se l’inizializzazione é andata a buon fine, il driver
controlla se su tali Link sono pervenute Transazioni da eseguire ed in
caso affermativo le esegue.
Dopo un certo tempo, se non sopraggiungono nuove Transazioni, il
driver elimina dalla propria lista i Link inattivi, rilascia le librerie e si
mette in attesa di nuovi Link da servire.
La gestione dei Link all’interno del Gate assume, quindi, una notevole
importanza soprattutto per quanto riguarda l’interazione PipeObject
- PlcDriver.
Quando una richiesta di apertura di un Link arriva da un’applicazione 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 lista
all’interno del driver a cui appartiene.
PipeObject a questo punto mantiene la definizione del Link nelle
proprie 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 da
guardia”): esso altro non é che un thread che scorre la lista dei Link
ed elimina quelli inutilizzati, a intervalli regolari.
Le Transazioni, invece, vengono memorizzate in due array all’interno
di PipeObject: uno preposto alla scrittura ed uno alla lettura, i quali
inizialmente vengono dimensionati a 30 elementi ciascuno.
A differenza dei Link, le Transazioni vengono memorizzate in un array per poter riutilizzare le istanze esistenti senza ricrearne di nuove; ció consente di visualizzare ed accedere alle Transazioni anche se
queste sono giá state eseguite e scodate.
La grandezza degli array, in realtá, non é fissa e a fronte di carichi
particolarmente gravosi puó aumentare per servire il grosso carico di
richieste.


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 propria lista dei Link e per ognuno di esso, attraverso una funzione del
PipeObject, preleva, se presente, una Transazione accodata e la esegue
prima di passare al Link successivo.
L’array delle Transazioni in scrittura viene controllato per primo in
quanto servire tali Transazioni é prioritario rispetto a servire quelle
in lettura.
L’utilizzo delle strutture dei Link e delle Transazioni da parte di piú
interlocutori in maniera asincrona e concorrente impone l’utilizzo di
semafori a mutua esclusione per garantire il corretto accesso ad esse.
GATE
PIPEOBJECT

PLCDRIVER
SOFTNET

PLC

ALLEN-BRADLEY
LINK

ALLNBRADLEY

PLC

SENDRECEIVE LINK

SENDRECEIVE

PLC

SOFTNET LINK

LINK
APPLICAZIONI
TRANSAZIONI

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

17

18


3.4

schema uml delle classi

Thread
PlcTrans
Read Trans

PlcLinkList

public Start()
public Thread(ThreadStart start)
Watch dog

Write Trans

PlcTransData

<<Enumeration>>

PlcLinkState
Closed
Opening
Opened
Reading
Writing
Unused
Error

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()

PlcLink

PlcLinkData

<<Enumeration>>

PlcTransState
Unused
Queued
Unqueued
Ongoing
Success
Error
Timeout

Figura 13: Diagramma delle classi PipeObject.

3.4 schema uml delle classi

<<Enumeration>>

PlcDriverState
Unused
Active
Stopped

Thread

Closed
Error

public Start()
public Thread(ThreadStart start)

Simulation
Restarting
1:1

PlcLinkList

1:1

1:M

PlcDriver
public bool AddLink(PlcLink Link)
public bool RemoveLink(PlcLink Link)
public PlcDriverData GetDriverDtata()
public void ResetDriver()
public void ResetDriverPreservingLinks()
public void terminateDriver()

PlcLink

PlcDriverSoftnet

PlcDriverSendReceive

PlcDriverAllenBradley

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)
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)

Figura 14: Diagramma delle classi PlcDriver

19

4

I 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’implementazione. Verrá presentata la soluzione adottata, approfondendone i
passi piú rilevanti, sottolineando le principali funzionalitá introdotte
ed 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, come
quella prodotta dal livello 2 per l’automazione del processo produttivo, richiede l’utilizzo di strumenti di sviluppo avanzati: essi cercano
di risolvere alcune problematiche legate principalmente alla necessitá
di operare in team e all’organizzazione del codice.
Questi aspetti sono rilevanti soprattutto perchè un’implementazione
del software ordinata e ben organizzata permette di produrre meno
errori e consente un’efficiente ed efficace manutenzione del software.
Quest’ultimo aspetto, in particolare, é molto importante in quanto le
applicazioni all’interno di un’acciaieria necessitano di uno sviluppo
continuo.
Per far fronte a tutte queste necessitá, all’interno del livello 2 si utilizza l’ambiente di sviluppo integrato (IDE) Visual Studio 2010 ed
il sistema software di controllo di versione distribuito GIT (con la
relativa estensione per Visual Studio).
Con GIT é possibile controllare e gestire lo sviluppo del software
attraverso 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 possiede
una copia locale interna della cronologia di sviluppo;
• gestire efficientemente grandi progetti: GIT é molto veloce e
scalabile.
GIT possiede una licenza GNU GPL (General Public License) e la sua
distribuzione é libera.
4.2

utilizzo delle eccezioni

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

21

22


software e questo ha portato evidenti benefici rispetto alla precedente
soluzione.
Nel software oggetto della tesi, ogni qual volta si verifica un errore
viene lanciata un’eccezione che deve essere gestita in maniera opportuna.
L’utilizzo delle eccezioni é stata una parte molto delicata dello sviluppo, in quanto se non gestite correttamente fanno terminare l’applicazione in maniera errata.
4.3

implementazione della classe pipeobject

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

4.4 implementazione della classe plcdriver

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

implementazione della classe plcdriver

La classe PlcDriver é la classe ancestrale del driver che definisce le
funzioni per interagire con PipeObject.
PlcDriver contiene al suo interno un thread che ciclicamente percorre
la funzione Execute.
Rispetto alla versione precedente, questa funzione ha subito una notevole trasformazione facendo in modo che PlcDriver assumesse un
modello diverso, ovverosia a stati finiti.
Con tale modifica é stato possibile ordinare il comportamento del driver e rendere il codice molto piú chiaro; questo modello ha permesso di riscontrare piccoli errori e ridondanze all’interno del progetto
precedente.
4.5

riprogettazione del comportamento ancestrale del
driver

La riprogettazione del comportamento ancestrale del driver é la modifica piú rilevante del nuovo software di comunicazione; tale modifica
comportamentale é locata interamente nella funzione di esecuzione
(Execute).
Questa funzione é stata totalmente riscritta aggiungendone all’inizio
uno switch capace di differenziare le operazioni da eseguire in base
allo stato del driver.
Il comportamento del driver é gestito dai seguenti stati:
Unused: in questo stato il driver non ha inizializzato le librerie e attende che PipeObject gli assegni un Link da servire.
Active: in questo stato, cioé quando un Link necessita di essere servito, il driver carica le librerie native e cerca se in PipeObject sono state
accodate nuove Transazioni per i Link aperti.
Error: se l’inizializzazione della libreria é fallita, il driver entra in questo stato e, a seguito di un tempo di attesa, cerca di re-inizializzarla.
Restarting: in questo stato il driver rilascia le librerie, se caricate, elimina tutti i Link e si riavvia. Questa modalitá é stata inserita a seguito
di alcuni problemi con una serie di reti, riscontrate in alcuni impianti:
a volte accadeva che all’interno di reti particolari un Link persistesse
nello stato di Error ed il driver non riuscisse piú a servire alcun Link;
in tal caso si rendeva necessario un riavvio per poter nuovamente interagire con i PLC.

23

24


UNUSED
Entry / Link da servire = 0
Do / Attende e inizial. driver
Exit / Link da servire > 0

INIZIO

SIMULATION
Entry / Mod. sim. richiesta
Do / Finalizza il driver e attende
Exit / Mod. live richiesta

ERROR
Entry / Inizial. driver fallita
Do / Aspetta timeout

RESTARTING

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

Do / Finalizza driver e terimina link

STOPPED

FINE

Do / Finalizza il driver e
rimuove i link.

Figura 15: Diagramma degli stati di PlcDriver

Simulation: se il PipeObject é in modalitá simulazione il driver rilascia le librerie, se caricate, e attende che PipeObject esca dalla modalitá simulazione ed entri in modalitá reale.
Stopped: il driver entra in questo stato se é richiesta la chiusura del
driver; in questo stato vengono rilasciate le librerie, terminati tutti i
thread di esecuzione e viene chiuso il sistema.
Questa gestione del driver risulta molto pulita dal punto di vista del
codice e permette una certa sincronia nelle operazioni; essendo l’esecuzione della funzione Execute ciclica, il driver ad ogni ciclo controlla
e gestisce il suo stato che puó eventualmente venirgli imposto da
alcune condizioni esterne.
Una caratteristica rilevante di PlcDriver é che eventi di natura asincrona vengono rilevati dal driver solo al ciclo successivo e quindi in
maniera sincrona dal suo punto di vista.
Di seguito viene riportato una porzione del codice della funzione Execute che rappresenta le operazioni che il driver esegue quando é nello
stato ATTIVO.
Listing 1: “Porzione della funzione Execute. Viene eseguita dal driver
quando 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

6

11

16

21

26

31

36

41

46

51

if (_Links.Count == 0)
{
if (_Initialized)
{
FinalizeDriver();
}
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));
}
else
{
// Detection of reset cycles requirement
if (_Links.OverallErrorTime > GateConstants.
MaxDriverLinksErrorTime)
{
SetDriverState(PlcDriverState.Restarting, "Driver automatic−
reset . . . " );
break;
}
for (int i = 0; i < _Links.Count; i++)
{
if (_Links[i].IsLinkInactive())
{
PlcLink Link = _Links[i];
RemoveLink(Link);
}
else
{
// Try to Open Closed Links
switch (_Links[i].State)
{
case PlcLinkState.Error:
case PlcLinkState.Closed:
case PlcLinkState.Opening:
if (_Links[i].CanStartNewOperation())
{
// Check if link has finished opening or else
submit a open request
OpenLink(_Links[i]);
}
break;
case PlcLinkState.Opened:
// Serve a new transaction to an open link. Writes
have priority
if (_Links[i].CanStartNewOperation())
{
if (PipeObject.CurrGate().NextWriteRequest(_Links
[i]))
{
WriteLink(_Links[i]);
}
else

25

26


{
if (PipeObject.CurrGate().NextReadRequest(
_Links[i]))
{
ReadLink(_Links[i]);
}

56

}
}
break;
case PlcLinkState.Writing:
// Check if reading finished
WriteLink(_Links[i]);
break;
case PlcLinkState.Reading:
// Check if reading finished
ReadLink(_Links[i]);
break;

61

66

}
}

71

}
Thread.Sleep(20);
}
ScoreState.IncSucceded();
76
break;
#endregion
}

L’implementazione dei driver specifici tramite l’ereditarietá della classe PlcDriver é stata completata per il driver Softnet, per il quale si
disponeva di un PLC.
Per quanto riguarda il driver AllenBradley é stato implementato solo
il codice e del driver non si é potuto testare alcuna funzionalitá, non
disponendo di un PLC di quel tipo.
Nessun aspetto di SendReceive r stato considerato e sviluppato.
´
Nella realizzazione del driver Softnet, il quale utilizza le funzioni
della libreria SIEMENS scritta in C (S732.dll), sono state riscontrate
grandi difficoltá in quanto l’ambiente C# rientra nella famiglia dei
codici managed i quali gestiscono automaticamente l’allocazione delle
strutture in memoria.
L’uso dei puntatori in questo tipo di codici é deprecabile e quindi é
stato necessario un grosso sforzo per riuscire ad utilizzare le librerie
citate con i tipi di variabili offerti da C#.
Le principali tecniche utilizzate per consentire al software di includere 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 codice
dette unsafe, che sono porzioni di codice gestite in maniera diversa
dal compilatore, ovverosia come se fossero state scritte con un codice
di tipo unmanaged.
4.6

implementazione del sistema remoto

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

4.7 implementazione degli score

WCF (Windows Comunication Foundation) ed il Gate é stato una
buona piattaforma su cui testare tale tecnologia.
Questo é servito per avere una panoramica sul futuro sviluppo delle
applicazioni del livello stesso, non solo per quanto riguarda quello
del Gate.
Dal punto di vista del sistema di comunicazione prodotto, l’utilizzo
di queste funzionalitá é stato implementato ed é funzionante.
Non é stato possibile approfondire tale parte del progetto in quanto
non avrebbe avuto senso nel quadro generale dello sviluppo software
del livello, principalmente perchè al momento non era ancora stata
studiata alcuna strategia in merito.
Il sistema remoto del Gate non fa altro che rendere pubbliche alle
applicazioni i metodi del PipeObject.
Attraverso un indirizzo é possibile collegarsi all’oggetto PipeObject e
riuscire a comunicare con esso; in questa parte vengono omesse tutte
le strategie adottate nel dettaglio.
Il problema piú rilevante é stato riscontrato nel lancio delle eccezioni in remoto; si é reso indispensabile incapsulare le normali eccezioni sollevate dal Gate in altre modellate appositamente per viaggiare
sulla rete, in modo che evitino di bloccarlo.
Sebbene lo sviluppo é stato solo marginale, sono stati tratti ottimi
spunti per le successive implementazioni da parte di tutte le applicazioni, anche se permangono alcune riserve per quanto riguarda i dati
trasmessi in rete e le modalitá con cui vengono serializzati.
L’ultima modifica al progetto é stata fatta inserendo la classe GateDefinitions in una libreria chiamata Pipe che dovrá essere inclusa in ogni
applicazione che vuole comunicare con il Gate, in quanto contiene le
definizioni 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 di
registrare la durata e l’esito di gran parte delle funzioni esaminate.
Attraverso questa classe é possibile visualizzare dettagli sull’efficienza 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 registra l’esito delle funzioni permette di localizzare l’errore molto semplicemente.
Tramite l’utilizzo degli Score si possono ottenere statistiche sul tempo
di utilizzo delle funzioni e si puó quindi intervenire sulle stesse per
ottimizzarle e rendere efficiente il sistema.

27

28


4.8

implementazione dell’applicazione di test board

Per testare il Gate é stata sviluppata parallelamente una nuova applicazione detta Board.
Lo scopo del Board é di simulare la condizione di un’applicazione di
livello 2 che necessita di comunicare con il Gate.
Esso incorpora le procedure quali la connessione al Gate, la deﬁnizione di un Link, la lettura e la scrittura su PLC.
Tramite il Board ci si puó connettere al Gate in remoto e si possono
visualizzare molte informazioni utili quali:
• le Transazioni;
• il reistro degli eventi (Log);
• gli Score.
Attraverso lo sviluppo del Board é stato possibile eseguire uno stress
test, il quale si é dimostrato uno strumento fondamentale per testare
le funzioni del Gate.
Molte altre funzionalitá dovranno essere aggiunte al Board, una fra
tutte la possibilitá di prelevare le conﬁgurazioni dei Link da un database.

5

I 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 applicazioni Gate e Board; inoltre verrá data un’indicazione sul contenuto delle medesime illustrandone i vari utilizzi possibili. Le interfacce
sono state sviluppate in WPF utilizzando una libreria chiamata Xceed,
strumento utile per consentire una gestione dinamica delle finestre e
dei controlli in esse contenuti.
5.1

implementazione dell’interfaccia gate tramite wpf

L’implementazione dell’interfaccia del Gate risulta complessivamente
semplice in quanto verrá utilizzata soltanto da personale specializzato 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 incorporano
gli UserControl; essi includono al proprio interno una classe chiamata GateViewer la quale, attraverso un thread interno, preleva ad
intervalli regolari i dati dal Gate e modifica le variabili visualizzate.
Attraverso lo schema Model - View - ViewModel l’interfaccia si accorge della modifica e i dati vengono automaticamente aggiornati a
video.
Gli UserControl sono ancorabili all’interno della finestra e, attraverso
il 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 lo
stato ed i cicli Execute percorsi da ognuno; nella parte bassa
di questa finestra c’é una tabella riservata ai Link attualmente
gestiti dai driver, dove viene visualizzato il nome, lo stato e
alcune indicazioni utili in caso di errore.

29

30

implementazione delle interfacce

• Pipe Scores: visualizza gli Score relativi alle funzioni del e
indica il numero di volte che é stata lanciata la funzione, la
durata media, la durata massima, quella totale e l’esito.
• Driver Scores visualizza gli Score relativi alle funzioni dei driver con gli stessi campi descritti per le funzioni in Pipe Scores.
Tramite il Driver Status é possibile impostare lo stato di Simulazione 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 é possibile controllare lo stato delle Transazioni similmente all’interfaccia
del Gate.

Figura 17: Applicazione Board

Anche qui gli UserControl relativi alle Transazioni includono una
classe GateViewer contenente a sua volta un thread capace di prelevare
i dati delle Transazioni dal Gate e visualizzarli a video.
I tre UserControl illustrati sono:
• PLC Comunication: da questa finestra é possibile collegarsi al
Gate e lanciare delle funzioni attraverso a dei pulsanti e visualizzarne l’esito in un riquadro; in particolare é possibile definire
un link ad un PLC, leggere e scrivere dati interagendo con la
memoria del suddetto PLC.
• Read Transactions: da questa finestra é possibile osservare le
statistiche di ogni transazione; in particolare vengono mostrati
lo stato attuale ed il tempo impiegato nei vari stati intermedi.
• Write Transactions: ha la stessa funzionalitá dello UserControl
Read Transactions solo che mostra le Transazioni in scrittura.

5.2 implementazione dell’interfaccia board tramite wpf

Per prima cosa, per utilizzare il Board, é necessario collegarsi al Gate
tramite l’apposito pulsante di connessione, dopo aver inserito l’indirizzo IP su cui é in esecuzione il Gate. Fatto ció, vengono visualizzate
nella parte bassa le Transazioni in lettura e scrittura sulle quali é possibile apprezzarne lo stato. La funzione Reset Drivers contenuta in PLC
Comunication non viene normalmente utilizzata dalle applicazioni
ma é risultato utile integrarla nel Board per la fase di sviluppo.

31

6

UTILIZZO E TEST DEL SISTEMA DI
C 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 verranno descritti i test eseguiti sullo stesso.
6.1

casi d’uso del gate

Leggere da PLC
Scrivere su PLC
Applicazioni
del livello 2

Librerie proprietarie
Configurare parametri connessione
Visualizzare lo stato delle
comunicazioni
Tools di configurazione
delle librerie

Amministratori
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 delle
funzionalitá del Gate.
Il Board simula le condizioni in cui opera una qualsiasi applicazione
del livello 2.
Inoltre offre agli amministratori di rete uno strumento per visualizzare lo stato delle comunicazioni del Gate.
I principali test riguardanti il Gate consistono nel testare il corretto
uso delle librerie speciﬁche 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ó leggere
e scrivere su un PLC connesso e conﬁgurato.
Per testare queste funzionalitá, di lettura e scrittura, é stata accodata
prima una richiesta di scrittura su di una porzione della memoria che
successivamente é stata letta confrontando la corretta riuscita delle
operazioni tramite gli Score.
Per testare il sistema di accodamento delle Transazioni, é stato implementato 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 di
scrittura.
Questo test serve a controllare:
1. Che la Transazione in scrittura venga eseguita prima delle richieste 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 servire il gran numero di richieste.
Questi test del Gate sono stati implementati per garantire che il software soddisﬁ le condizioni minime di funzionamento. Altri test dovranno essere eseguiti soprattutto in fase di collaudo nell’impianto; questo é conseguenza del fatto che é necessario impostare alcuni parametri di connessione adatti all’ambiente su cui il Gate deve
operare.

7

CONCLUSIONI

Il software sviluppato durante il tirocinio risulta essere un prodotto
ancora in fase sviluppo.
Gli obiettivi prefissati sono stati complessivamente raggiunti nonostante non si disponesse di tempo sufficiente a consentire la produzione di un software completo.
Questo software di comunicazione ha reso necessario l’impegno di
particolari attrezzature, quali i PLC, che sono stati condivisi con altri
sviluppatori del livello 1; nonostante ció, l’azienda é riuscita a metterne a disposizione di tipo SIEMENS S7 durante tutto lo sviluppo di
questo progetto.
Per completare il software sarà necessario implementare e testare anche la funzionalità dei restanti driver proprietari (AllenBradley e SendReceive). Il driver S7 funziona correttamente e l’utilizzo della libreria nativa, anche se largamente perfezionabile, avviene in maniera
sostanzialmente efficiente.
Anche se la fase di test, ad esclusione di piccole funzioni di prova, deve essere ancora affrontata, il risultato rimane ugualmente piú
che soddisfacente in quanto il software prodotto incarna le principali
funzioni di quello attualmente utilizzato.
Le tecniche degli automi a stati finiti e l’utilizzo di alcuni design pattern rappresentano, nella loro implementazione pratica, i punti di
forza del sistema.
Sicuramente anche questi modelli dovranno evolversi assieme ai sistemi.
C’é stato un notevole stupore da parte mia nell’apprendere come
modelli matematici e nozioni puramente teoriche, anche di svariata natura, possano trovare spazio in un contesto pratico ed offrire un
contributo cosí essenziale.
L’utilizzo del linguaggio C# ha offerto un sostanziale apporto al
progetto soprattutto grazie all’utilizzo delle librerie dotNet con particolare riferimento alla serializzazione di oggetti e la comunicazione
client-server.
Le interfacce andranno ulteriormente sviluppate e migliorate soprattutto sotto l’aspetto dei modelli, in quanto l’utilizzo di un thread all’interno dei ViewModel puó essere classificato come uno dei punti
deboli del prodotto.
Il software sviluppato ha richiesto molti sforzi, in particolare per
quanto riguarda l’interpretazione delle problematiche da affrontare
e la loro modellizzazione.
Indicativamente sono state prodotte circa 27 classi e 10000 righe di
codice.
Il progetto sviluppato all’interno dell’azienda é stato molto stimolante in quanto ha messo alla prova le mie capacitá di risolvere i
problemi legati alla programmazione.

35

36

conclusioni

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

BIBLIOGRAFIA

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 riccardo];
4. Pro Git
[Scott Chacon];
5. UML 2 e Uniﬁed 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

PALUZZANO TESI

Recommended

Recommended

More Related Content

Similar to PALUZZANO TESI

Similar to PALUZZANO TESI (20)

PALUZZANO TESI