12 aprile 2013

PLC Vs PAC: ancora?!?!

Premesse:



  • Questo è un post in risposta all'articolo su AutomazioneNews.it "PLC e PAC, cosa scegliere?"
  • Non si tratta di un post di polemica, ma solo il punto di vista dell'autore sulla questione. Sarei felicissimo di intavolare una discussione per cercare di crescere e superare magari visioni che sono ingiustificate o troppo "reazionarie": nessuno ha il dono della Verità e il confronto aiuta ad arrivarci un po' più vicini...





Onestamente io mi posiziono tra coloro che in prima battuta non vedono grandissime differenze funzionali tra PAC e PLCAnche PLC a basso costo dispongono di innumerevoli "add-on" per svolgere molti ruoli diversi e la linea di demarcazione è così sottile che forse rappresentata solo dal sistema operativo e da un reale multitasking (prerogativa primaria dei PAC), a scapito di un determinismo e una rigidità (che dona in cambio sicurezza) che invece regna assoluto nel mondo dei PLC. E' giustissima la considerazione che si tratti solo di strumenti: chi lavora come integratore deve avere la capacità di discriminare quando e dove usare PAC o PLC o DCS o RTU...

Se invece affrontiamo il discorso da un punto di vista diverso, ovvero quello dell'architettura e delle "best practices", dobbiamo essere sempre all'erta.
Uno dei principi che, personalissimamente, ho sempre adottato è quello del disaccoppiamento funzionale: se ho da far svolgere a un sistema due funzioni diverse, dal mio punto di vista, è generalmente preferibile che siano due device diversi e specializzati a svolgerle: ognuno deve fare ciò che sa fare meglio, nell'impianto non regna la democrazia.

Faccio un esempio: desiderare che un controller si connetta al database aziendale è probabilmente una forzatura dovuta o alle circostanze obbligate ("non possiamo fare diversamente") o ad una scarsa progettazione architetturale di partenza. Il database per sua natura è uno strumento asincrono che deve restare il più possibile disaccoppiato da uno strumento che lavora nel dominio dei millisecondi. Un lock su una tabella o su un record potrebbe significare disastro dal lato IT come dal lato Campo.

Altro esempio: salvare dati su un controller può avere senso solamente se il controller è totalmente disconnesso da una rete, oppure se ha un funzionamento a "burst" di invio/ricezione (ad esempio invia i dati una volta al giorno con una connessione satellitare o cellulare) oppure se desideriamo un buffer in caso di assenza di connessione per guasto alla rete, ma in reti industriali cablate (ad anello, magari) questa caratteristica è superflua oppure è possibile implementarla sufficientemente bene anche su un PLC: una rete cablata e organizzata come si deve è davvero difficile che vada giù, e se va giù deve essere per pochi minuti... 

Ho fatto volutamente due esempi in cui un PAC potrebbe essere superfluo. Chi mi fa degli esempi in cui è indispensabile?

Confermo i complimenti alla redazione di AutomazioneNews per l'interessante spunto di riflessione rappresentato dal loro articolo!

Volete invece un paio di ottime risorse per scegliere e capire meglio di cosa stiamo parlando: