08 agosto 2012

Architetture: Managed Bus


Diagramma a blocchi illustrativo del Simple Bus

Descrizione dell'architettura

L'architettura MANAGED BUS, a differenza della SIMPLE BUS, comporta l'inserimento di un livello intermedio che si frappone tra il sistema di supervisione e i controller in campo. Prevede la più totale separazione logica, tra i PLC/RTU. Le unità master sono tra loro ridondanti (spiegheremo più avanti il motivo della scelta che potrebbe apparire troppo conservativa) e si occupano di effettuare polling in campo e di implementare logiche di sistema. La supervisione, comunica solamente con l'unità Master in servizio che fornirà i dati richiesti.
L'aver previsto una coppia di unità Master (che possono essere posizionate anche a distanza, premessa l'esistenza di un collegamento efficiente diretto o dedicato) ha il solo scopo di impedire che un guasto singolo sull'unità Master precluda il fluire dei dati necessari alla supervisione o che si interrompano le ottimizzazioni introdotte con "boost sistemico" che vi risiede. Lo scopo del layer logico aggiuntivo, sempre rispetto al Simple Bus, è quello di fornire al sistema un maggiore separazione di funzionalità e consentire un processo di analisi e sviluppo semplificato, parallelabile e riusabile. Ovviamente, in una tale configurazione, le comunicazioni tra le singole unità in campo sono da considerarsi indesiderabili, al pari di logiche che prevedano una reciproca conoscenza dello stato; funzioni che saranno a carico delle unità Master.
Dal punto di vista dei protocolli di comunicazione tra Layer 1 (controller in campo) e Layer 2 (Master), valgono le stesse considerazioni fatte per il Simple Bus, con una ulteriore avvertenza: occorre valutare con attenzione le capacità di comunicazione della piattaforma HW/SW dell'Unità master. Nel caso precedente le comunicazioni erano gestite da un S.O. per PC, capace di creare e sostenere un elevato numero di canali anche in parallelo; se per questa soluzione si decide di optare per un PLC fisico si potrebbe incorrere in limitazioni consistenti nella quantità, ad esempio, dei socket TCP. Il tutto dipende, quindi da quante sono le unità in campo e quanti segnali conta ciascuna di esse. Come esempio numerico ci sentiamo di affermare entro la decina di unità (con un payload di, grossomodo, 50 segnali ciascuno in media) il problema non sussiste o può essere eventualmente risolto implementando un semplice sistema di slot temporali opportunamente calibrati. Quando invece ci si trova di fronte a quantità superiori sarà opportuno prendere in considerazione l'impiegabilità di SoftPLC installati su piattaforme con S.O. PC (ambienti XPe, anche se ormai alla soglia dell'obsolescenza sono eccezionalmente stabili, ma abbiamo avuto ottimi risultati anche con sistemi Win 7 Embedded).
In casi particolari, dove è anche richiesta una elevata frequenza di polling (<200 ms) occorerà valutare sicuramente la seconda alternativa, oppure tornare ad architetture come il Simple Bus, in grado di garantire velocità superiori, rinunciando ad una separazione funzionale più spinta, e contestualmente ricorrere a protocolli più snelli e meno strutturati di SNMP o IEC 60870-5, come ad esempio l'inossidabile Modbus.

Le difficoltà nel realizzare una architettura simile, risiedono quasi esclusivamente nella corretta progettazione e configurazione delle comunicazioni e nella strutturazione delle mappe dei dati da scambiare. La separazione, su piattaforme distinte, tra logiche locali e logiche di sistema rende più snelle e semplici da sviluppare e testare tutte le applicazioni. Occorre, come al solito, una buona conoscenza dell'impianto e sarebbe opportuno che il progettista fornisse delle descrizioni dettagliate delle logiche previste. Il Managed Bus è un sistema distribuito a intelligenza centralizzata, che gode di una maggiore scalabilità e manutenibilità.

Pro

  • Separazione delle logiche (ridotta complessità)
  • Possibilità di implementare bus con trasporti diversi
  • Bus semplice da realizzare e implementabile con qualunque standard industriale
  • Scalabilità
  • Manutenibilità

Contro

  • Accumulo del rischio sul networking
  • Più controller necessari, anche su piattaforma diverse
  • Minore flessibilità di scelta su protocolli
  • Pollig con bassa frequenza

Conclusioni

In conclusione riteniamo che l'architettura descritta si presenta coerente con i più adottati canoni di buona progettazione, rispettando le necessità di separazione, manutenibilità e scalabilità, andando ad incidere su alcuni aspetti di performance e di economicità. Sotto l'aspetto del Project Management  presenta indubbi benefici relativi alla pianificabilità in parallelo delle attività di sviluppo.
Ci sentiamo di suggerirne l'impiego in progetti che presentano un non eccessivo numero di controller in campo (<50, utilizzando Master implementati su SoftPLC) e con un elevatissimo tasso di ripetizione (nessuna differenza 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