Sistema distribuito per il
controllo remoto di
Software SCADA HMI
Presentazione di
Paolo di Francia
Reti di Calcolatori LS
a.a 2004-05
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)
Client
Server
Client
Client
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
Begin
Working
Commit
Commiting
Abort
Caduta
Caduta
Aborting
Caduta
End
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
Request Queue (Max Length 20 request)
Request
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
Engine
Request
List
Request
DataBase
1:findRequest()
1.1:getAllRequest()
Ogni richiesta
corrisponde a un thread
che deve controllare la
disponibilità della risorsa,
in tal caso prenderne
2:insertRequest
l’uso esclusivo,
aggiungere la richiesta e
quindi rilasciare la
risorsa(mutex)
• I client si
interfacciano con un
RequestList FIFO
•server preleva tali
richieste e le
inserisce
nell’archivio
periodicamente
attraverso un
thread.
getRemoteObject()
releaseRemoteObject()
l’accesso alla sezione
critica risulta controllato
da un altro mutex
presente all’interno
dell’oggetto remoto
condiviso
Response Engine
Response
Engine
Connection
Request
Error
Response
1:open()
2:extractRequest()
3:<<create>>
4:execute()
5:<<destroy>>
6:exctractResult()
7:checkError()
8:storeResponse()
9:deleteRequest()
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

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