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: 

01 aprile 2013

System Integrators: ostaggi delle “majors”?

Integratore legato come un salame
Il panorama internazionale dei tools di integrazione non è mai stato così vasto e ricco di offerte come al momento: negli ultimi anni si è assistito a importanti acquisizioni, fusioni e incorporazioni che hanno di fatto ridotto il numero dei marchi “storici”, consentendo alle cosiddette “majors” di dotarsi di numerosi strumenti, plug-in e verticalizzazioni tali da riuscire a coprire tutti i maggiori temi dell’integrazione. E’ singolare osservare come le parole chiave che descrivono i benefici di questi prodotti siano più o meno ovunque le stesse. Ho tentato di creare una sorta di tag cloud con principali parole chiave identificate sui svariati siti web:
Scalability Flexibility Real-time Intelligent Connectivity Integration Reliability Simple Easy Solution Product Open

Questo risultato (empirico), insieme ovviamente ad una lettura piuttosto approfondita dei vari contenuti, brochures e white-papers, al confronto con gli agenti che il mio lavoro mi porta costantemente a intrattenere, e alla tendenze di mercato che posso quotidianamente verificare sul campo, mi porta a voler condividere alcune considerazioni volutamente provocatorie...

+ Facile, +Semplice e + Flessibile
1. “Simple”, “Easy” e “Flexibility”: in base alla mia esperienza solitamente questi sono termini che sviluppano una forte frizione quando usati a breve distanza fra loro. La flessibilità comporta la disponibilità di una gamma di strumenti per poter affrontare diverse variabilità dei progetti, e più vasta è tale gamma maggiori sono le possibili criticità a cui si va incontro. Pretendere che uno strumento sia flessibile e semplice è in effetti la pietra filosofale dell’IT!

Scalabilita e affidabilità
2. Altro punto di riflessione è la minore importanza di termini quali “Scalability” o “Reliability”… quasi come se fossero ormai termini così tanto inflazionati da essere scontati, ovvi e superflui… del resto il cliente “deve” volere un sistema “chiavi in mano” e chi offre una soluzione deve anche avere la capacità di assumersi i rischi derivanti da una carenza di queste doti. Nell’immaginario collettivo il grande marchio è in grado di farlo, mentre la piccola azienda o il professionista non possono… in realtà è il contrario, ma l’arcano sarà, forse, un po’ più chiaro solo dopo aver letto l’ultimo punto di questo articolo… portate pazienza!

aperto?
3. La presenza del termine “open” porta a facili supposizioni di apertura delle soluzioni proposte. Di fatto questo termine è spesso associato non tanto al termine “strumento”, ma con il termine “architettura”, che di per sé aggiunge un ben magro valore: una architettura aperta è una caratteristica tutto sommato aleatoria: cosa significa di preciso? Non sono riuscito a capirlo esattamente, ma so che uno strumento aperto consente integrazioni spinte entro ambienti, applicazioni, sistemi con la stessa caratteristica di apertura. Spesso mi sono trovato ad approfondire questo argomento con i tecnici commerciali, ma le risposte vanno spesso in un unico senso: “Questa integrazione è semplicissima: basta acquistare il modulo X” oppure “Se vuoi pubblicare le pagine web occorre avere l’opzione Web-Server”, etc, etc...


4. Last but not least “Integration” e “Solution”: i grandi del mercato dei prodotti di integazione, ormai sempre di più, si vedono come providers di Soluzioni e di Integrazione, e dove volessimo vedere il termine “solution” in contrapposizione con “product” (ovvero l’offerta di un prodotto è meno pubblicizzata dell’offerta di soluzioni) le politiche di marketing parlano puttosto chiaro in merito: i produttori di software si stanno ponendo sul mercato come solution providers invece che come sviluppatori di strumenti, questione che mi lascia profondamente perplesso. Molti integratori si configurano ormai come partner indissolubilmente legati ad un prodotto e alle sue sorti, costretti ad accettare commesse per cui il fornitore di una volta è divenuto il cliente di oggi, trovandosi di colpo il coltello dalla parte del manico: non solo devono sviluppare, a volte sottocosto, le soluzioni così ampiamente pubblicizzate dal big di turno, ma, per poterlo fare, devono spesso anche qualificarsi con corsi molto costosi e rinunciare alla concorrenza in determinati settori. Paradossale, eh? E lo è ancora di più se ricordate il secondo punto di riflessione, dove dicevo che in realtà è il piccolo che è in grado di affrontare i rischi del successo del progetto…


Soluzioni a questa situazione verranno con il tempo, quando le piattaforme inizieranno a distaccarsi dalle esigenze, vuoi perché gli integratori “ammansiti” non stresseranno più i servizi di assistenza tecnica a valutare criticamente i loro prodotti, vuoi perché le tecnologie, già oggi estremamente stratificate dal tempo e solo in pochi casi (guarda il caso: sono le realtà più piccole!) costantemente aggiornate, non potranno più reggere l’impatto con esigenze di performance, analisi e integrazione sempre maggiori, vuoi perché le promesse di scalabilità e flessibilità pagate a peso d’oro dimostreranno i loro limiti. 

Chi avrà invece mantenuto la capacità di integrare veramente potrà, come sempre, continuare a progettare e a risolvere problemi.