07 agosto 2012

Architetture: Simple Bus

In questa serie di post "Architetture" cercheremo di confrontare e analizzare alcune delle architetture più comuni. Nei PRO e CONTRO cercheremo di dare degli spunti anche per valutare le problematiche che potrebbero proporsi nello sviluppo, anche se in buona parte la loro risoluzione dipende dall'hardware e dal software che abbiamo a disposizione per il progetto: conoscere le esigenze porta a trovare gli strumenti giusti e non il vice-versa. 

Diagramma a blocchi illustrativo del Simple Bus

Nota: le terminologie che utilizziamo per la designazione sono completamente arbitrarie.

Descrizione dell'architettura

L'architettura SIMPLE BUS è la più semplice da realizzare e prevede, in prima approssimazione, che i controller in campo (siano essi PLC, DDC, RTU, etc...) si comportino autonomamente gli uni rispetto agli altri. La supervisione effettua il polling per i dati di interesse da ciascuna unità di campo. A seconda poi dei protocolli e dei trasporti che decideremo di adottare, le funzionalità di raccolta dati potranno essere migliorate, velocizzate e distribuite tra più unità di supervisione.

Utilizzando ad esempio protocolli che supportano modalità di "push" (come ad esempio le trap SNMP o l'IEC 60870-5-101/104) sarà possibile far sì che i controller inviino, spontaneamente e senza attendere il successivo turno di polling, determinati subset di dati al verificarsi delle condizioni impostate, rendendole subito disponibili al sistema di supervisione.
Bisogna inoltre considerare che normalmente il sistema di supervisione è installato su sistemi operativi con notevoli risorse di memoria e grandi capacità di comunicazione. Utilizzando gli strumenti opportuni (come ad esempio una rete TCP/IP e dei gateway (software) o driver specifici) diventa possibile effettuare polling in parallelo anche su ciascun dispositivo. 
Inoltre, se si decide di consentire comunicazioni tra le unità di campo (e in questo caso riteniamo opportuno utilizzare un trasporto TCP, possibilmente con una configurazione fisica ad anello) sarà possibile distribuire la logica e rendere ciascuna unità consapevole delle attività delle altre. Non sempre questa caratteristica è utile, ma nel caso di numerose unità identiche o che asservono elementi diversi di uno stesso processo o impianto, si potranno prevedere comportamenti ottimizzati di tipo sistemico (lo chiamo "boost sistemico"). Nel caso in cui si verifichino malfunzionamenti del bus, ciascuna unità dovrà però tornare in modalità  autonoma e adottare logiche individuali, magari meno efficienti o efficaci, ma comunque "safe".
Le difficoltà nel realizzare una architettura simile, risiedono quasi esclusivamente nella progettazione e implementazione del software delle unità di campo. Bisogna progettare le logiche affinché distinguano i due scenari ("sistema" + "autonomo") e per ciascuno prevedere algoritmi differenti. Per fare questo occorre avere una profonda conoscenza dell'impianto da automatizzare, compresi i dettagli realizzativi. Trattandosi di un sistema in realtà "distribuito" il malfunzionamento di una unità non pregiudica la possibilità di monitorare controllare il resto del sistema.

Pro

  • Pochi controller necessari
  • Bus semplice da realizzare e implementabile con qualunque standard industriale
  • Distribuzione della logica e "boost sistemico"
  • Possibilità di polling in parallelo su un numero molto elevato di nodi

Contro

  • Stretta dipendenza dalle funzionalità dell'impianto
  • Non sempre possibile trovare logiche di sistema efficaci
  • Rischio di progetto accumulato nella fase di analisi
  • Ridotta stratificazione e scarsa riusabilità

Conclusioni

In conclusione ci sentiamo di affermare che l'architettura descritta presenta diversi e importanti benefici di ordine tecnico, a scapito di alcune complicazioni si project management. Ci sentiamo di suggerirne l'impiego in progetti che presentano un elevato numero di controller in campo (>10) e con un alto tasso di ripetizione (nessuna o poche differenze periferiche nel software delle unità). Suggeriamo l'utilizzo in accoppiata del trasporto ethernet con devices che supportino nativamente protocolli spontenei, possibilmente su LAN dedicate o su VLAN protette.

Link utili