Sistema distribuito per il controllo remoto di Software

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

Descrizione l 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 l Possibilità dei Client di effettuare delle richieste al Server che comunica con il software SCADA eseguendo l lettura di un Tag l scrittura di un Tag l esecuzione di una funzione Ci. Code (linguaggio proprietario di Citect)

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

. Net Remoting l l l 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) l . NET remoting fornisce una struttura che consente agli oggetti di interagire fra loro su domini di applicazione diversi.

Oggetti remoti l Tutti gli oggetti locali che devono attraversare il confine dell' application domain devono essere contrassegnati dall'attributo [serializable], oppure devono implementare l'interfaccia ISerializable l Per creare un oggetto remoto è necessario derivare Marshal. By. Ref. Object l Quando un client attiva un oggetto remoto, riceve un proxy per questo oggetto che funge da intermediario l 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 l I client registrano i canali richiamando Register. Channel sulla classe Channel. Service l Il canale TCP serializza i messaggi in un flusso binario e trasportare il flusso all' Uniform Resource Identifier (URI)

Archivio Dati l l l 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 Data. Base, ciò comporta: l l Facile inserimento, prelievo ma soprattutto ricerca dei record. Tempi “accettabili” per l’esecuzione di un comando SQL.

Two phase lock protocol l 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 Begin Working Commiting Abort Caduta Aborting Caduta End

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

Sincronizzazione l l 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 l Algoritmo FIFO Request Queue (Max Length 20 request) Request l l Request Engine Il periodo fra una richiesta e la successiva è a discrezione dell’utente. Un periodo troppo breve può portare ad una congestione dello Scada.

Request Engine Request List 1: find. Request() 1. 1: get. All. Request() Ogni richiesta corrisponde a un thread che deve controllare la disponibilità della risorsa, in tal caso prenderne 2: insert. Request l’uso esclusivo, aggiungere la richiesta e quindi rilasciare la risorsa(mutex) Request Data. Base • I client si interfacciano con un Request. List FIFO • server preleva tali richieste e le inserisce nell’archivio periodicamente attraverso un thread. get. Remote. Object() release. Remote. Object() l’accesso alla sezione critica risulta controllato da un altro mutex presente all’interno dell’oggetto remoto condiviso

Response Engine Connection Request Error Response 1: open() 2: extract. Request() 3: <<create>> 4: execute() 5: <<destroy>> 6: exctract. Result() 7: check. Error() 8: store. Response() 9: delete. Request() 10: close() Scada Command 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 l Si può presentare la situazione in cui un client cerca di effettuare una o più delle seguenti operazioni: l 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. l l lettura/scrittura di un Tag inesistente. richiesta di esecuzione di una funzione Ci. Code inesistente Nei casi sopra indicati il server sarà in grado di eseguire la richiesta ma risponderà con un messaggio indicante il fallimento

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