30 agosto 2012

HMI design: il Mock-Up

In ogni progetto di automazione o integrazione, giunge il momento di iniziare a pensare all'interfaccia uomo-macchina (HMI - Human Machine Interface).
HMI: Legenda simboli e controlli

L'approccio più razionale, quando il tempo non è troppo tiranno e il cliente finale dimostra una minima serietà, vorrebbe che l'interfaccia fosse oggetto di una progettazione esecutiva piuttosto attenta e dettagliata, che fosse redatto l'albero di navigazione, che tutte le interazioni possibili fossero analizzate sia sulle reazioni normali che su quelle "failure", che il look & feel  possedesse una chiara e inequivocabile tassonomia.

Oggi vorrei condividere una prima bozza di un lavoro che sto portando avanti. Non è di certo una realizzazione perfetta e "da manuale", al momento, ma sono certo che lo sarà in fase esecutiva. Lo scopo, e va ricordato, è comunque quello di ottenere il più rapidamente possibile l'approvazione del cliente (che troverete ovviamente oscurato), e non quello di scrivere un libro di testo sulle migliori teorie di concepimento delle interfacce utente.


Non nascondo che alcune idee vengono da studi personali sul web relativi alla UX, oltre che alle numerosissime pubblicazioni di oltreoceano specifiche per il settore degli HMI industriali.

Ho fatto un po' di "merge", e sono soddisfatto del prototipo che è uscito: adesso lascio ai lettori la parola!

(Il lavoro è interamente realizzato grazie all'ottimo servizio messo a disposizione di moqups.com che potete utilizzare come estensione di Google Chrome:  https://chrome.google.com/webstore/detail/nlfbhphohgafllkjnakmdppmmkjfbnke )

24 agosto 2012

Quando le certificazioni diventano... incerte

Il raggiungimento di certificazioni, serie e prestigiose, ad esempio, come quelle ISASecure, sono un traguardo importante per i grandi produttori di hardware come Honeywell, che devono imporre la propria leadership tecnologica e tenere a bada la concorrenza costringendola alla perpetua rincorsa. Lo spunto ci è fornito dalla notizia riportata con grande eco su tutto il web (citiamo la prima che abbiamo trovato) della certificazione ISASecure ottenuta proprio da due prodotti di automazione Honeywell, ovvero il sistema di controllo distribuito C300 (DCS) e il modulo interfaccia di campo (FIM) entrambi della serie Experion. La certificazione è relativa a due aspetti che abbiamo già trattato in questo post, ovvero quello della sicurezza funzionale e quello della cyber-security.
Diplomas and certifications paper rolls

Ma, come dobbiamo aspettarci in questi casi, non è sempre tutto "rose e fiori", dal momento che abbiamo anche trovato un incipit di polemica, sul DigitalBond.com. La polemica non riguarda il prodotto né il produttore quanto piuttosto l'ente normativo, ovvero ISA stessa. Se siete interessati ad approfondire, questo è il link all'articolo. Non è nel nostro interesse partecipare alla polemica, quanto piuttosto cercare di ricavare dalla vicenda alcune considerazioni, che possiamo cercare di generalizzare ed applicare al vasto ambito delle tecnologie industriali di cui ci occupiamo.


Le certificazioni sono, oltre ad un riconoscimento di pregio tecnico, uno strumento di marketing molto importante. Poter decorare le brochure dei propri prodotti con pacchi di "medaglie" guadagnate sul campo non ha prezzo quando ci si trova alle fiere di settore. Certamente le certificazioni di alta fascia non lasciano adito ad alcun dubbio circa la piena rispondenza ai requisiti più stringenti, ma esistono anche le certificazioni di livello di base che richiedono requisiti inferiori, e sono queste che a volte possono trarre in inganno, facendoci ritenere "sicuro" per un certo aspetto un prodotto che in realtà è "insicuro by design".

Quando ci si trova sull'impianto, sulla piattaforma o nello stabilimento chi è deputato a effettuare una scelta tra prodotti con specifiche similari potrebbe essere tentato dal soppesare la consistenza dell'elenco degli enti normativi che certificano il pezzo. In questo caso si potrebbe trovare nella situazione in cui ritenga di aver fatto una scelta "conservativa", mentre invece una parziale o non precisa conoscenza delle norme di riferimento l'ha trasformata, in realtà, in una scelta inconsapevole e non informata.

Il suggerimento che ci sentiamo di dare, in queste circostanze, è quello non di ignorare le certificazioni che non si hanno ben chiare, ma di indurre lo stesso tecnico-commerciale di riferimento a presentarvi e illustrarvi la documentazione relativa alla certificazione ottenuta. Se non si hanno specifiche competenze o una buona formazione su una specifica norma questo è sicuramente un buon modo per farsi un'idea di quali siano i requisiti progettuali e gli assunti di base di un prodotto: forzare un oggetto ad un uso per cui non è stato pensato è infatti una delle principali cause di incidenti in ambito industriale.

22 agosto 2012

Cybersecurity e Sicurezza funzionale: vicina la fusione?

La cybersecurity in campo industriale è salita vertiginosamente nella classifica dei problemi e degli investimenti, soprattutto nel corso degli ultimi 5 anni, assumendo il volto di una vera propria piaga, in particolar modo nei settori:
Hacker
  • Distribuzione elettrica, Smart-Grids;
  • Trattamento acque;
  • Sistemi di trasporto;
  • Impianti industriali di processo.
I costi che si stimano per la bonifica e le perdite per il mancato servizio dei siti colpiti raggiugono l'ordine dei milioni, talvolta decine di milioni di dollari annui, anche a seconda del servizio e dell'entità, per non parlare di alcune industrie manifatturiere per cui i costi di fermo degli impianti si stimano in milioni di dollari ogni ora.

Come rispondere ai cyber-attacchi?


Cerchiamo innanzitutto di capire perché gli impianti industriali si sono scoperti così vulnerabili.

Le motivazioni degli attacchi sono sostanzialmente le seguenti:
  • Spostamento delle tecnologie di campo da universi chiusi e proprietari a reti IP distribuite
  • Utilizzo di architetture di rete "office" o talvolta "home" senza particolari contromisure di sicurezza (firewall)
  • Interconnessione delle reti di campo con altre reti anche esterne
  • Concessione di accessi remoti senza implementazione di robuste policy di autorizzazione, talvolta anche da web pubblico.
Ma chi potrebbe essere interessato ad attaccare una infrastruttura pubblica o una industria produttiva? Proviamo a enumerare una serie di possibili attentatori:
  • Terroristi (separatismo, estremismi ideologici e/o religiosi);
  • Criminalità comune e/o organizzata (atti intimidatori);
  • Spionaggio industriale (con scopo di acquisizione di segreti industriali, composizioni e processi produttivi);
  • Danneggiamento a matrice politica di asset strategici (si veda, un esempio per tutti, il caso Stuxnet);
Nel mondo più propriamente IT ormai la cultura della difesa dagli attacchi informatici è diffusa ed esistono pratiche efficaci per contrastare le minacce, ma nel mondo industriale le difficoltà si moltiplicano, vuoi per la difficoltà nell'aggiornamento dei sistemi (che richiedono competenze super-specialistiche), vuoi nei requisiti di disponibilità degli impianti (spesso di diversi ordini di grandezza superiori ai sistemi IT), vuoi per le conseguenze spesso disastrose, di possibili violazioni.

E' vero che le violazioni di sistemi industriali colpiscono in prima battuta la privacy e la "security", ma possono portare serie conseguenze, e questo è il timore maggiore, anche nel dominio della "safety", ovvero della sicurezza fisica della vita umana e dell'integrità ambientale. In quanto minacce reali con conseguenze potenzialmente disastrose, questi problemi devono necessariamente iniziare ad entrare nelle analisi dei rischi, tipiche del mondo "safety".

Esistono ovviamente degli standard per la gestione della cyber-security (la serie di standard IEC 62443/ISA99), ma ci auspichiamo che in un prossimo futuro il Comitato spinga, anche dietro lo stimolo di numerosi enti nazionali (soprattutto USA e UK) interessati alla salvaguardia della stabilità produttiva e del PIL, verso una maggiore integrazione con le norme che regolano i sistemi strumentati di sicurezza (IEC 61511/ISA84).

A tal proposito suggeriamo di seguire questo video del 20 Luglio 2012, pubblicato da AutomationWorld (durata circa 45 minuti), che abbiamo usato come spunto per questo post.


Il video propone, in estrema sintesi, un workflow che fornisce spunti utili e in gran parte applicabili da  tutte quelle realtà industriali che oggi sono sotto minaccia:
  • Assessment della sicurezza, individuare i punti deboli assicurandosi di avere a disposizione, internamente o dall'esterno, le competenze in materia
  • Test e valutazione degli strumenti e dei sistemi (in particolare nei produttori di strumenti e sistemi), equivale ad avere una organizzazioni in grado di tenere sotto controllo i processi di produzione, come un sistema di Qualità certificato ed *effettivo* (non bastano le "carte");
  • Accogliere la cybersecurity nel contesto della valutazione dei rischi e nelle successive fasi di scelta e applicazione di misure per eliminarli/ridurli e/o per mitigarne le conseguenze;
  • Formazione ed educazione degli operatori, degli addetti, dei reparti produttivi;
  • Verifiche, Audit, Monitoraggio in continuo degli impianti e dei sistemi;
  • Mettere in pratica (in particolare per i produttori di strumenti e sistemi) il miglioramento continuo e inserire nel ciclo di verifica della progettazione gli eventuali rischi precedentemente trascurati.
Nella prima parte del video potrete comunque trovare alcuni accenni alle misure e alle principali "buone pratiche" dei principali sistemi normativi in merito alla sicurezza funzionale e dei processi, in particolare vengono rapidamente illustrati:


PSM (Process Safety Management) richiesto dalle norme OSHA National Emphasis Program:

  • PHA (Process Hazard Analysis);
  • HAZOP (Hazard and Operability Studies);
  • FMEA (Failure Mode and Effects Analysis);
Good Practices:

  • LOPA;
  • Identificazione degli IPL (Independent Protection Layers).
IEC 61511 / ISA84
  • Generalità;
  • SIL riferito a un prodotto (ovvero che un prodotto è adatto per un SIS con un determinato SIL, dal momento che possiede una precisa Probabilità di Guasto su Richiesta (PFD), ma che non possiede un SIL esso stesso);
  • Modello di sviluppo a V (V-Model) per lo sviluppo di prodotti e software;
  • Rapido sguardo sulla gestione delle modifiche di un SIS.

16 agosto 2012

Automazione: non sempre una questione di costi, ma di buon senso

Quando si considera il motivo per cui alcune Aziende di produzione e di distribuzione hanno implementato sistemi automatizzati di movimentazione dei materiali, spesso si sente parlare, prima di tutto, di previsioni finanziarie, tra cui un forte ritorno degli investimenti [Return Of Investments: ROI, NdT], un breve Periodo di Ritorno [Payback Period: PP, NdT], o  un significativo aumento del Tasso Interno di Rendimento [TIR, oppure Internal Rate of Return: IRR, NdT].

L'automazione flessibile è una scelta di buon senso
Image credits:
KUKA Roboter GmbH, Bachmann [Public domain],
via Wikimedia Commons 
Le Aziende sono spesso alla ricerca di periodi di ROI predefiniti [e affidabili, NdT], e sulla base di questi calcoli finanziari, i dirigenti della società prendono le loro decisioni. Anche se non può essere messo in discussione che la giustificazione finanziaria per un progetto di automazione sia molto importante, questa da sola non dovrebbe essere l'unico criterio che determini la scelta di automatizzare.


Studiando le Aziende più performanti nei settori manifatturiero e distribuzione, emerge una semplice verità: la capacità di produrre costantemente prodotti di alta qualità e processare accuratamente gli ordini, nell'esatto momento in cui il cliente lo richiede e con un costo globalmente competitivo, è la chiave per far sì che l'Azienda superi previsioni di ricavo e di profitto una volta ritenute irraggiungibili. Se la performance finanziaria di una Azienda è il fine ultimo, realizzare e sostenere questo obiettivo non sempre è possibile grazie a un rapido PP [o in generale ad una massimizzazione di tutti i KPI aziendali, NdT], ma si tratta di una missione strategica che implica una considerazione di più ampio respiro circa tutti i possibili vantaggi. Alcuni di questi benefici generati dall'automazione, che non sempre ottengono visibilità nella giustificazione del progetto, sono:

Miglioramento della qualità e dell'accuratezza degli ordini - Produrre prodotti di alta qualità e processare accuratamente gli ordini è un aspetto importante per la soddisfazione del cliente, che potrà decidere di affidare all'Azienda attività aggiuntive. Dimostrando ai clienti che si ha capacità per gestire più e diversi ordini senza creare un senso di isteria e caos, si potranno chiudere più contratti non solo con nuovi clienti, ma anche con clienti esistenti.

Riduzione dei tempi di completamento dell'ordine - Gli utenti finali di quasi ogni industria odierna desiderano avere un minor numero di prodotti a portata di mano all'interno della loro struttura [riduzione del magazzino, NdT]. Le Aziende automobilistiche si stanno muovendo verso il Just-In-Time; Aziende di approvvigionamento di bevande e alimenti richiedono consegne di pallet pronti per lo stoccaggio; quasi tutti stanno richiedono una sempre minore quantità di prodotto. Queste iniziative sono stimoli che richiedono ai fornitori minori tempi di completamento degli ordini. I sistemi di automazione spesso consentono alle aziende che li possiedono una movimentazione dei prodotti con maggiore rapidità, con meno sprechi e con una superiore precisione.

Interessamento dei clienti - I top customers saranno il vero catalizzatore degli sforzi verso l'automazione. Attraverso l'automazione delle attività, i clienti vedranno l'Azienda come sostenibile, all'avanguardia, innovativa e più affidabile nel tempo.

Maggiore flessibilità - Le Aziende con una migliore automazione dei processi saranno meglio in grado di rispondere alle esigenze in continua evoluzione dei clienti. Oggi più che mai, i prodotti e le richieste dei clienti subiscono frequenti cambiamenti [anche in brevi periodi, NdT]. Un processo automatizzato e flessibile, che sia in grado di adattarsi sempre più ad una gamma variabile di prodotti e al loro confezionamento "al volo", sarà in grado di sbaragliare la concorrenza del cliente.

Miglioramento della sicurezza e soddisfazione del personale - I dipendenti all'interno dell'azienda desiderano fare un buon lavoro. L'obiettivo dell'automazione dovrebbe essere quello di sostituire gli sforzi umani in processi in cui si svolgono lavori pericolosi e ripetitivi. Migliorare la sicurezza sul posto di lavoro è spesso difficile da inserire nei calcoli iniziali di giustificazione del progetto, ma la sicurezza deve essere la priorità assoluta della vostra organizzazione e ciò non deve essere dimenticato.

Aumento delle ore di operatività - Con un sistema di automazione vi è una minore necessità di arrestare  le linee produttive; l'obiettivo di ogni nuovo sistema di automazione è, in primis, quello di portare avanti la produzione per il maggior tempo possibile al fine di ottenere il massimo rendimento.

Flessibilità della manodopera - Attraverso l'automazione non solo si potrà far uso di meno manodopera, ma quella che viene impiegata sarà più facilmente impiegata per il solo tempo necessario. Nel corso degli anni, ho visto alcuni dei nostri clienti più efficienti impiegare manodopera temporanea durante la settimana di picco del mese, o per il solo giorno di picco della settimana, o anche nelle le ore di punta di una singola giornata.

Miglioramento delle informazioni a livello di sistema - Attraverso un efficace sistema di controllo magazzino [WCS: Warehouse Control System, NdT] o un sistema informativo di produzione [MIS/MES: Manufactoring Information/Execution System, NdT], la corretta gestione del ciclo produttivi viene effettivamente resa disponibile. Avere accesso tempestivo e in tempo reale allo stato di completamento di  un ordine vi permetterà di pianificare meglio il ciclo, la fase o il processo successivo. Questi servizi includono di solito funzionalità di reporting ottimizzate per la gestione degli impianti produttivi.

Costi minori - Insieme all'alta qualità, i clienti richiedono il prezzo più basso. L'automazione è un ottimo modo per ottenere sia bassi costi operativi che alta qualità. Malgrado l'investimento iniziale di un sistema automatizzato possa essere difficile da giustificare, la possibilità di espandere la vostra offerta di prodotti per una frazione dei costi della concorrenza distinguerà la vostra azienda dalle altre.

Fare di più con meno - Un sistema automatizzato permetterà alla vostra azienda di produrre e consegnare più beni con una riduzione di magazzino. Con l'automazione in atto, ci saranno meno esigenze di inventario nel processo e a più lungo termine, consentendo più spazio per l'aggiunta di clienti, prodotti o servizi (tutti gli elementi che portano delle entrate).

La prossima volta che la vostra azienda dovesse prendere in considerazione di automatizzare, pensate "out-of-the-box" quando vi accingete ad elencare i benefici. Quando la giustificazione inizia con lo studio delle condizioni finanziarie del progetto e si iniziano a sentire  parole come  ROI, Payback, o IRR, cercate di far prendere in cosiderazione alcuni dei benefici di cui sopra e  identificate quelli reali e attuali per la vostra azienda. I vantaggi potrebbero essere molto più considerevoli di quanto inizialmente atteso.


Questo post è la traduzione dell'articolo di Aaron M. Jones dal titolo "Automation: Not Always About the Dollars, But Always About the Sense!", che ringraziamo per il permesso alla traduzione e pubblicazione.

L'articolo si rivolge principalmente alle aziende che desiderino applicare soluzioni automatizzate di "material handling" e "packaging",  ma le considerazioni le riteniamo valide per qualunque settore e processo produttivo.

Ci permettiamo di aggiungere, alla interessantissima disamina degli aspetti positivi, una ulteriore considerazione, relativamente a:

Aumento dell'efficacia degli interventi manutentivi - Un sistema di automazione, per essere considerato tale, non può prescindere dall'essere a conoscenza dei malfunzionamenti degli impianti che gli sono asserviti. Tale consapevolezza può essere trasportata a livello centralizzato e alimentare sistemi per la gestione e pianificazione delle manutenzioni e dei fermi macchina. Il calcolo di opportuni indicatori potrà suggerire alla dirigenza la prioritizzazione degli interventi per massimizzare la produttività e minimizzare i tempi di fermo.

10 agosto 2012

Quanto è vicina la IoT in ambito industriale?

IoT: Internet of Things (Internet delle Cose), tra il serio e il faceto.
Mai un acronimo fu più infelice! Sgraziato, superficiale, cacofonico anche in inglese (chiedo scusa a Kevin, presunto padre... forse non osava sperare in tanto successo!). Eppure nasconde il fuoco della prossima rivoluzione industriale, ancora latente sotto la cenere.

IoT evolution is at a stage to become suitable for industrial applications





Image credits - from Wikipedia, the free Encyclopedia: A technology roadmap of the internet of things, by SRI Consulting Business Intelligence/National Intelligence Council, 4 Aprile 2008



Tutta la considerazione nasce da questo post di ieri, a proposito dei moderni relay che mostrano i muscoli ai PLC, che è servito come spunto per sviluppare il discorso verso una direzione inaspettata (trovate qui il post pubblico su Google+).
Cito il passaggio:

Massimiliano Sarigu 
Sì, ma a questo punto si può ancora parlare di reali differenze tra le varie categorie di apparati? Quando un PLC integra anche un motore web si può ancora considerare un semplice PLC? Se un relé è programmabile è ancora un relé?

Michele Brami 
Un PLC resta sempre un PLC, e un relé sempre un relé. Dargli capacità "pompate" non sempre è un beneficio. Forse colgo quale sarà il successivo passo, ma siamo ancora lontani almeno una decina d'anni e non da un punto di vista tecnico: il tanto osannato "internet delle cose" che per venire alla luce ha bisogno di uno standard applicabile [applicativo] che ne definisca le ontologie e le semantiche, la liberazione dai driver proprietari e dai protocolli e il passaggio ai servizi web con manifesto pubblico. Il solo dubbio è: vorranno/potranno i produttori competere [gli uni contro gli altri] solo per la bontà del prodotto e per il suo prezzo? Ad oggi il trincerarsi dietro tecnologie chiuse e proprietarie ha consentito a questi produttori di vendere anche devices non proprio eccellenti, o di praticare politiche di prezzi del tipo "o così, o stai senza", e o di imporre il proprio engineering.

Anche se non sono stati fatti nomi, i riferimenti sono piuttosto inequivocabili. Il fatto interessante è che tutti i Big a cui si adatta perfettamente la descrizione sono all'interno di commissioni, organismi e fondazioni che promuovono la collaborazione, gli standard aperti e l'interoperabilità. Credo che sia questo il motivo del mio scetticismo a proposito dei 10 anni (ma pensandoci a mente fredda forse sono stato ottimista).

Una ulteriore considerazione segue subito la prima: nel momento in cui dovesse succedere che i provider di tecnologie di base inizino a trovare un accordo sugli standard inizierebbe un difficile interregno, tra i reparti di Ingegneria di Processo e quelli di Information Technology.
I servizi web sono tipicamente dominio degli informatici puri, ma le macchine, i controllori di processo e gli apparati sono invece nella corte degli elettrotecnici/elettronici.

Ma chi sarà a farne le spese?

"I systems integrators e gli SCADA, finalmente!".

Risposta ovvia, ma completamente sbagliata.

"Ovvia" perché normalmente sono questi ultimi a stare in mezzo ai due fuochi, e "sbagliata" esattamente per lo stesso motivo.
Non possiamo, presi dall'eccitazione del momento evolutivo, dimenticare che le best practices di progettazione sia dell'ingegneria elettrica/meccanica che del software prescrivono, tra le misure per limitare la propagazione dei guasti e delle problematiche sistemistiche, la pratica del disaccoppiamento
Gli informatici risponderanno che il disaccoppiamento lo procurano i servizi web, dato che nascono per questo, e gli ingegneri diranno che il disaccoppiamento è intrinseco nella "sublimazione" dal nudo metallo al dato digitale.
Ma risponderò che il dato digitale è parente di primo grado del metallo (ciascun relay avrà la sua CPU, ricordate?) e che il servizio web che viene pubblicato esporrà informazioni che l'informatico non è in grado di comprendere (lo stesso relé saprà solo dire se è aperto o chiuso o i modelli più sofisticati in un eccesso di zelo diranno anche che corrente li attraversa).
In realtà la figura dell'integratore, per sua natura metà elettricista, metà umano e metà informatico, sarà sempre l'anello di congiunzione delle due realtà tecniche (ringrazio Massimiliano Sarigu anche per il paragone azzeccato) avendo la capacità, acquisita da una vita vissuta su un campo minato, di coniugare le esigenze impiantistiche con quelle di networking, di trasformare dati grezzi in KPI, di spremere ogni bit significativo dalle macchine e pigiarlo a forza negli spazi angusti centellinati dai DB administrators, e di tante altre imprese che voi umani non potete capire.

Timoniere, barra al centro e alla via!
Macchine avanti normale!

SCADA Vs MES (en)

Never heard about "Decoupling" or "Modularity" or "Reusability" or "Interoperability"?

Picture of SCADA visualization

SCADA is about collecting and processing data and/or supervising technical equipment, MES is about manufactoring planning and effectiveness. Why binding them toghether should be better? Single machines usually do a fixed (or more often a parameters driven) job for their whole lifetime, but this is not true for the plant, where optimal behaviour, KPIs and production can change from season to season. MES, in our modest opinion, are in the domain of "industrial ITs", not in that of plant engineers: colored meters and bars, or plant areas maps in both interfaces should not be mistaken belonging the same family.

Of course you can push a SCADA being a low-level MES, or a full fledged MES being a sufficient SCADA, but those are two different worlds "by design". Data structures are different, data aggregation is different, calculations are on far different time domains: why you should ask a SCADA to keep track of year-by year deltas on highly processed variables so far from machinery?

In year 2012 the "silo" paradigm has already been deserted by almost everyone. Distribution and specialization is the winner... for the moment... but, of course, it depends also on the target industry.

And you? What do you think?

Relé Vs PLC: diversi punti di vista

The Great Electro-Mechanical BrainIn un articolo di ControlDesign di oggi, si parla di rivincita degli attuatori elettromeccanici (relay o relé che dir si voglia). Il lungo e interessante articolo offre anche numerosi spunti di riflessione niente affatto scontati, per cui suggeriamo di leggerlo attentamente. La nostra attenzione è però stata stimolata da un diverso punto di vista.
Si dice che i relay siano stati vittima di un potente e progressivo oscuramento indotto, a partire da oltre 40 anni fa, dall'avvento dei PLC: potenti, flessibili e a parità di logica meno ingombranti.
Oggi la rivincita: i moderni relay sono dotati di microprocessore, di capacità di comunicazioni bus e rete, di interfacce di programmazione, di display e non temono più il confronto.
Al di là del comprensibile, ma oggettivamente forse non completamente sostenibile, entusiasmo dei commerciali... chi ha veramente vinto questa sfida?
...
Il rame o il silicio?

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

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


06 agosto 2012

Le specifiche del cliente: il Safety Integrity Level

Sempre più spesso capita di trovarmi di fronte a specifiche del cliente che facciano richiesta di sistemi realizzati con uno specifico livello di integrità di sicurezza (SIL, o Safety Integrity Level) secondo le norme IEC 61508, IEC 61511 (per dispositivi e sistemi) e IEC 50128 (per il software ambito ferroviario), etc.
Non sono solito discutere le specifiche, in quanto devo ritenerle prescrittive e vincolanti, ma spesso mi capita di interrogarmi sull'esigenza che le scaturisce, e ogni tanto mi permetto di criticarle.
Ped Safety Gates
Le norme che ho citato, per fare un esempio, riguardano la realizzazione di sistemi che governano determinate e limitate funzioni di sicurezza. La mole di dati e di letteratura che si nasconde dietro al semplice codice della norma è quantomeno sconcertante, pur riguardando componenti e sistemi che nel loro complesso svolgono pochissime e ben definite funzioni nel modo più sicuro possibile per evitare danni agli esseri umani e all'ambiente. La pretesa di chiedere, in una specifica, che un sistema di automazione e supervisione sia completamente soddisfacente i requisiti di un SIL 2 o ancora peggio di un SIL 3, è un cieco abuso di terminologia, molto spesso inconsapevole, di chi scrive la specifica.

Questo post non ha la pretesa di spiegare, in poche righe, come questi requisiti vadano assegnati: sarebbe una materia troppo articolata e comunque esistono già numerosissimi testi consultabili online, appartenenti al dominio che possiamo genericamente individuare con la locuzione "valutazione dei rischi". Più che altro lo scopo di questo articolo è quello di spiegare qualcosa di molto più semplice: ovvero che le specifiche hanno uno scopo e uno solo, e non è quello di prescrivere soluzioni, bensì quello di coprire delle necessità. L'analogia che meglio si adatta al concetto che voglio esprimere è quella del malato (cliente) che lamenta un problema (l'esigenza). Può seguire due strade: va in farmacia e chiede un farmaco ben preciso poiché ha auto-diagnosticato il disturbo (da una specifica all'integratore e si aspetta il rispetto totale), oppure si rivolge ad un medico (progettista) che troverà dalla descrizione del problema (l'esigenza) la migliore cura (specifica) da chiedere al farmacista (integratore). Quale dei due approcci seguire lo può decidere solamente il cliente, ma solo uno dei due sarà quello che gli offre i maggiori benefici.
A volte, però, capita che la specifica non sia fornita con lo scopo di risolvere un problema, ma per garantire determinati tipi di omogeneità (solo di rado anche l'interoperabilità) con quanto già disponibile, talvolta considerando "specifiche necessarie" anche le lacune e le problematiche dei sistemi esistenti. A tal proposito suggerisco di leggere questo interessante articolo di Control Global che spiega cosa si intenda con "resistenza al cambiamento" in ambienti industriali.
In definitiva: il SIL, ovvero il livello di integrità di sicurezza, non è una caratteristica che nasce dall'esperienza di chi scrive una specifica, ma da un processo formale che si chiama "Valutazione dei rischi", espletabile con varie metodologie e modelli cognitivi, e soggetto a verifiche e a controlli. Mettersi al riparo chiedendo il massimo (SIL 4) è molto dispendioso in termini di costo e di impegno e potrebbe causare il rischio di diminuire drasticamente la disponibilità di un impianto o installazione perché occorre ricordare che i sistemi di sicurezza con tali caratteristiche, in genere, tendono al raggiungimento dello stato "sicuro" ad ogni avvisaglia di malfunzionamento, e più il sistema è complesso, più malfunzionamenti possono occorrere. Inoltre, un altro suggerimento che mi permetto di fornire agli "scrittori di specifiche" è quello di scomporre il sistema che stanno valutando in unità funzionali e di allocare il SIL per ognuno sulla base di una solida e completa valutazione dei rischi; non tanto per un sistema completo, quindi, ma per le sole sue funzioni di sicurezza.

04 agosto 2012

Inaugurazione

Eccomi finalmente a decidere di scrivere il primo post inaugurale di questo nuovo blog per a cercare di spiegare le motivazioni che mi hanno spinto a crearlo e le aspettative che ripongo in questo angolino del web.
Anniversario Birthday Cake
Mantengo già un altro blog che uso come camera di decompressione per sfogare i miei pensieri in completa libertà. Quello che mi manca è, invece, un contenitore tematico relativo al mio lavoro, dove poter inserire commenti, constatazioni, "lessons learned", impressioni e idee sul mondo professionale con cui sono ogni giorno a contatto.
Cercherò per quanto possibile di non fare nomi di Clienti, Fornitori e Concorrenti nelle mie elucubrazioni, mentre mi sento libero di farlo quando ne dovessi in qualche modo "parlare bene". Non è una rinuncia alla critica, ma piuttosto un senso di correttezza dettato anche dalla posizione che rivesto in Azienda. Questo non significa che non descriverò situazioni, circostanze, specifiche e atteggiamenti che disapprovo, ma ne ometterò i riferimenti: ci sono già tanti concorrenti "spietati" nel nostro piccolo mondo, e un passo falso potrebbe compromettere la mia credibilità e la mia correttezza professionale.

Quindi se lavorate nel mio campo, che siate clienti, fornitori, concorrenti o semplici passanti vi auguro una buona permanenza e delle letture interessanti. Ho già qualche idea per realizzare alcune rubriche aperiodiche che potrebbero essere interessanti anche per i non addetti ai lavori, ma se avete suggerimenti e/o se volete partecipare ai contenuti con idee, articoli e considerazioni siete tutti quanti i benvenuti. L'ultima nota è per i commenti per cui raccomando:

  • massimo rispetto per tutti;
  • niente bestemmie;
  • niente spam, a mio insindacabile giudizio;
  • niente pubblicità: è consentito linkare a siti di prodotti, produttori e altri blog alle sole pagine inerenti alla questione discussa.

Adesso che anche io mi sono schiarito le idee, vi do appuntamento al prossimo post.

A presto!