Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PALUZZANO TESI

700 views

Published on

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

  • Be the first to comment

  • Be the first to like this

PALUZZANO TESI

  1. 1. 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
  2. 2. Ai miei genitori, alla mia famiglia ed ai miei amici.
  3. 3. Si ringrazia il team di livello 2 e tutto il personale della SMS Concast.
  4. 4. 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
  5. 5. 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
  6. 6. 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.
  7. 7. 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 definiranno 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, fisici, 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
  8. 8. 4 reti di comunicazione industriali 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 graficamente 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 fine 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.
  9. 9. 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
  10. 10. 6 reti di comunicazione industriali 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.
  11. 11. 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 configurazione 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 fisico 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
  12. 12. 8 reti di comunicazione industriali 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’affidabilitá. In un impianto industriale é necessario che le comunicazioni siano affidabili 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.
  13. 13. 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ó verificare 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 definire 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
  14. 14. 10 reti di comunicazione industriali • 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 finiti 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.
  15. 15. 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
  16. 16. 12 analisi e progettazione del software di comunicazione 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.
  17. 17. 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 definizioni: 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; • GateDefinitions. 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
  18. 18. 14 analisi e progettazione del software di comunicazione 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;
  19. 19. 3.3 studio del software esistente • 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
  20. 20. 16 analisi e progettazione del software di comunicazione 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.
  21. 21. 3.3 studio del software esistente 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
  22. 22. 18 analisi e progettazione del software di comunicazione 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.
  23. 23. 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
  24. 24. 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
  25. 25. 22 implementazione del gate 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.
  26. 26. 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
  27. 27. 24 implementazione del gate 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();
  28. 28. 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
  29. 29. 26 implementazione del gate { 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
  30. 30. 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
  31. 31. 28 implementazione del gate 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 definizione 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 configurazioni dei Link da un database.
  32. 32. 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
  33. 33. 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.
  34. 34. 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
  35. 35. 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 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ó leggere e scrivere su un PLC connesso e configurato. 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
  36. 36. 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 soddisfi 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.
  37. 37. 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
  38. 38. 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.
  39. 39. 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 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

×