Sistema distribuito per il controllo remoto di Software SCADA HMI Presentazione di Paolo di Francia Reti di Calcolatori LS a.a

Descrizione Il progetto consiste nella realizzazione di un middleware distribuito per la gestione di flussi di dati derivanti da dispositivi hardware adibiti al controllo di processi industriali.

Funzionalità del servizio Possibilità dei Client di effettuare delle richieste al Server che comunica con il software SCADA eseguendo lettura di un Tag scrittura di un Tag esecuzione di una funzione CiCode (linguaggio proprietario di Citect)

Ipotesi di partenza Guasto singolo Fault tolerance: possibilità di affidarsi al sistema per il completamento della richiesta Reliability: sicurezza nella correttezza delle risposte Avalilability: rispondere in un tempo limitato (replicazione con più server)

.Net Remoting Canali bidirezionali su cui gli Application Domain si registrano (TCP, HTTP) Catene di responsabilità di oggetti sink Possibilità di invocazioni sinc e asinc Oggetti attivati da Client (lease) Oggetti attivati da Server (single call, singleton).NET remoting fornisce una struttura che consente agli oggetti di interagire fra loro su domini di applicazione diversi.

Oggetti remoti Tutti gli oggetti locali che devono attraversare il confine dell' application domain devono essere contrassegnati dall'attributo [serializable], oppure devono implementare l'interfaccia ISerializable Per creare un oggetto remoto è necessario derivare MarshalByRefObject Quando un client attiva un oggetto remoto, riceve un proxy per questo oggetto che funge da intermediario Tutti i parametri di chiamata del metodo nello stack vengono convertiti in messaggi e spostati nel application domain remoto, dove i messaggi vengono inseriti in un frame dello stack e il metodo viene richiamato

Channel I client registrano i canali richiamando RegisterChannel sulla classe ChannelService Il canale TCP serializza i messaggi in un flusso binario e trasportare il flusso all' Uniform Resource Identifier (URI)

Archivio Dati Tutti i comandi invocati dai client vengono depositati in un archivio. E’ così possibile mantenere traccia delle chiamate anche in caso di crash Server. L’ archivio è costituito da un DataBase, ciò comporta: Facile inserimento, prelievo ma soprattutto ricerca dei record. Tempi “accettabili” per l’esecuzione di un comando SQL.

Two phase lock protocol Stato di working: gli oggetti sono in stato inconsistente, in caso di caduta dell’elaboratore operazione abortisce Stato di commit: gli oggetti sono nel loro stato finale, l’azione anche in caso di caduta viene completata Stato di aborting: gli oggetti vengono ripristinati al valore iniziale anche in caso di caduta in questo stato Working Aborting Commiting BeginCommitEnd Caduta Abort End

ADO.NET ADO.NET semplifica notevolmente la soluzione di inconvenienti di questo tipo, attraverso la classe OleDBTransaction. Essa dispone di tre metodi che consentono la rapida ed efficace implementazione dell’algoritmo Two Phase Lock, in particolare: BeginTransaction(); Inizia una transazione di database nidificata. Commit(); Esegue il commit della transazione di database. RollBack(); Esegue il rollback di una transazione da uno stato in sospeso.

Sincronizzazione Tutti i client connessi al server utilizzano la stessa istanza dell’oggetto remoto (Singleton) per inserire richieste Le uniche operazioni che devono essere sincronizzate sono l’aggiunta di una richiesta o il prelievo delle risposte Citect non dispone di un meccanismo di schedulazione dei comandi esterni La gestione di chiamate concorrenti spetta al Server

Politiche di Scheduling Algoritmo FIFO Il periodo fra una richiesta e la successiva è a discrezione dell’utente. Un periodo troppo breve può portare ad una congestione dello Scada. Request Request Queue (Max Length 20 request) Request Engine

I client si interfacciano con un RequestList FIFO server preleva tali richieste e le inserisce nell’archivio periodicamente attraverso un thread. 1.1:getAllRequest() Request Engine Request Engine Request DataBase Request List 1:findRequest() 2:insertRequest getRemoteObject() releaseRemoteObject() l’accesso alla sezione critica risulta controllato da un altro mutex presente all’interno dell’oggetto remoto condiviso Ogni richiesta corrisponde a un thread che deve controllare la disponibilità della risorsa, in tal caso prenderne l’uso esclusivo, aggiungere la richiesta e quindi rilasciare la risorsa(mutex)

Response Engine Response Engine ConnectionRequestErrorResponse Scada Command 1:open() 2:extractRequest() 3: > 4:execute() 5: > 6:exctractResult() 7:checkError() 8:storeResponse() 9:deleteRequest() 10:close() Viene creato un nuovo thread “figlio” che si occupa di comunicare con citect e riportare i risultati. Il thread “padre” rimane in attesa della terminazione attraverso un comando di join().

Gestione errori Si può presentare la situazione in cui un client cerca di effettuare una o più delle seguenti operazioni: aggiunta di una richiesta nel caso in cui Citect sia offline: In questo caso il server risponderà con un messaggio indicante l’impossibilità di eseguire al momento tale richiesta. lettura/scrittura di un Tag inesistente. richiesta di esecuzione di una funzione CiCode inesistente Nei casi sopra indicati il server sarà in grado di eseguire la richiesta ma risponderà con un messaggio indicante il fallimento

Conclusioni Replicazione di entità Server per una migliore qualità di servizio Migliorare la sicurezza utilizzando protocolli di cifratura dei messaggi