L'automazione classica entra nel mondo alieno dell'IT – Parte 2
Nella Parte 1 ho descritto le principali differenze di obiettivi e architettura di sistema tra automazione classica e IT classico: l'automazione richiede sistemi altamente affidabili, veloci e predittivi, mentre il mondo IT deve essere più "sociale", versatile, adattativo e predisposto alla comunicazione. In questa seconda parte, cercherò di spiegare le principali differenze nella comunicazione.
Bus di campo rispetto a protocolli Internet
Un PLC (vedere la Parte 1 per la spiegazione) campiona i suoi ingressi e li combina con gli stati interni in un'istantanea denominata "immagine di processo". Questa istantanea viene utilizzata per calcoli e decisioni. Essa comporta un contemporaneo rinnovo (cambiamento) di stato di tutte le uscite. I segnali di ingresso e di uscita sono tipicamente segnali digitali a 24 V o segnali analogici con tensione da 0 a 10 V o loop di corrente da 4 a 20 mA. Ma se si hanno centinaia di ingressi sensore, non sarà più possibile collegarli tutti fisicamente con cavi singoli. La soluzione è un "bus" con solo alcuni fili che trasportano le informazioni tra il PLC e molti sensori e attuatori in sequenza (funziona in modo "seriale" invece che "parallelo", Figura 1). I sensori e gli attuatori devono essere più "intelligenti": devono avere un processore di comunicazione integrato per scambiare i loro valori con il controller.
Fig. 1: cablaggio convenzionale (sinistra) rispetto al cablaggio del bus di campo (destra).
I cosiddetti "bus di campo" o "bus industriali" devono trasportare le informazioni in modo predittivo. La prevedibilità nella comunicazione significa che è necessario conoscere con precisione il tempo massimo di reazione tra una richiesta e la risposta a tale richiesta (a proposito, questa è la definizione di "capacità in tempo reale" e non un limite di tempo assoluto definito arbitrariamente). Qualunque sia questo tempo di reazione, qualsiasi deviazione del suo valore nominale è chiamata "jitter" e rende un sistema meno predittivo. Un piccolo e noto jitter massimo è la proprietà cruciale di un sistema in tempo reale nell'automazione. Questo è il motivo per cui ridurre il tempo di reazione utilizzando interrupt non è un'idea intelligente: qualsiasi interruzione introduce un fattore probabilistico e tutto il sistema perde la sua proprietà deterministica. Non c'è da meravigliarsi, i bus di campo spesso lavorano ciclicamente e deterministicamente, proprio come i controller (PLC) a cui sono collegati. Un sistema funzionante ciclicamente offre un jitter definito. Si può immaginare che la combinazione di diversi sistemi ciclici asincroni (come un PLC e un bus di campo) sommi i relativi jitter. La sincronizzazione del ciclo del bus con il ciclo PLC è un modo semplice per risolvere questo problema.
Fig. 2: tempo di reazione e jitter nell'automazione.
I "protocolli" sono accordi tra partner di comunicazione che definiscono le fasi e il comportamento durante la comunicazione. Un problema enorme è la diversità storicamente aumentata di questi protocolli nell'automazione. Le macchine parlano spesso in diverse "lingue" e c'è un intero settore coinvolto nella traduzione di queste lingue. Diamo un'occhiata più da vicino ad uno dei classici bus di campo, definiti nella norma IEC 61784 / EN 50170: il Profibus DP (Process Field Bus for Decentralized Peripherals, Bus di campo di processo per periferiche decentralizzate). Il bus utilizza un segnale digitale differenziale su due fili, basato sullo standard RS485, ma con un bitrate molto elevato (fino a 12 Mbit/s). Funziona con una costellazione master-slave rigorosa e la parte di protocollo DP V0 utilizza il trasporto ciclico dei dati (vedi Figura 3). Il controller (PLC) è master e gli IO periferici sono dispositivi slave che possono rispondere solo alle richieste provenienti ciclicamente dal master.
Durante la configurazione, il progettista deve indicare al controller il numero di IO e il tipo di IO collegati. Dopo una sequenza di avvio ("parametrizzazione" e "configurazione") in cui ogni dispositivo slave deve "collegarsi" alla rete, il PLC esegue ciclicamente il polling di tutti gli IO con una frequenza di polling definita ("frame di richiesta"). Gli slave (IO periferici) riconoscono la ricezione dei loro dati e rispondono immediatamente con i loro stati IO ("frame di risposta").
Fig. 3: scambio ciclico di dati su un Profibus
Non voglio complicare questa breve introduzione, quindi ricordo solo che può esserci una comunicazione Token Ring per consentire la presenza di più master su un Profibus (solo il master con il token è autorizzato a eseguire il polling e quando ha completato il suo ciclo passa il token al master successivo). C'è molta sicurezza incorporata: ad esempio, se uno slave non viene interrogato in un tempo predefinito, cambia la sua uscita in "stati sicuri" predefiniti. Se uno slave rileva un malfunzionamento, può impostare il bit di allarme ("diagnostica") nella sua risposta al PLC che a sua volta consente al master di richiedere i dati diagnostici con il successivo polling.
Ci sono anche metodi integrati per affrontare il "problema di coerenza" di un bus seriale. Nella Parte 1, ho introdotto l'"immagine di processo" e ho accennato a quanto sia importante nell'automazione ottenere un'istantanea congelata coerente degli stati degli ingressi (o commutare le uscite simultaneamente). Ma come è possibile ottenere un'istantanea di questo tipo quando le informazioni di ingresso di diversi sensori vengono trasmesse in una sequenza? Quando il secondo valore del sensore risponde alla richiesta di polling, il primo valore del sensore potrebbe essere già stato modificato. Profibus conosce un comando di "congelamento". Il PLC trasmette questo comando e tutti gli slave congelano i loro valori di input fino a quando non sono stati interrogati. In questo modo si ottiene un'istantanea del momento in cui il PLC ha inviato il "freeze frame" (telegramma).
Il bitrate del bus limita la velocità di polling, e in caso di errori di trasmissione, potrebbero esserci cicli di polling che non riflettono lo stato IO effettivo. Ma alla fine questo tipo di comunicazione è eccezionalmente affidabile e deterministico. Profibus è stato introdotto negli anni '90 e con oltre 40 milioni di dispositivi certificati è ancora uno dei protocolli di comunicazione più utilizzati nel settore dell'automazione. La sua affidabilità lo rende perfetto per la tecnologia della sicurezza (daremo un'occhiata a questo argomento nella Parte 3 di questa serie).
Questo concetto master-slave ciclico può sembrare in qualche modo strano per i progettisti IT: perché chiedere la posizione di un interruttore continuamente e perché dovrebbe un interruttore continuamente dire al controller che il suo stato è "attivo" invece di inviare un solo messaggio quando cambia il suo stato da "inattivo" a "attivo"? Perché sarebbe difficile costruire un sistema deterministico quando si utilizza una comunicazione basata su eventi.
Quando un programma applicativo comunica con un database ed entrambi vengono eseguiti su hardware diversi, spesso si dispone di un'architettura server-client. Un singolo server deve elaborare i dati per molti client. Vedete la differenza principale? Molti client devono essere in grado di avviare la comunicazione - sono master di comunicazione - e il server centrale reagisce come un sistema slave nei loro confronti. L'uso di un dialogo innescato da un messaggio sembra molto più naturale in un tale ambiente. Naturalmente, si potrebbe pensare a una rete deterministica basata sui messaggi (ad esempio Token Ring), ma a causa della loro velocità dati complessiva statisticamente molto elevata, le reti probabilistiche come Ethernet hanno prevalso. Tali reti consentono a qualsiasi partecipante di avviare la comunicazione in qualsiasi momento in cui abbia bisogno di inviare un messaggio. Questa libertà determina possibili "collisioni" quando due client iniziano simultaneamente. Tuttavia, con una rapida strategia di rilevamento e reazione delle collisioni, si ottiene ancora con una velocità ottimale. Nelle moderne topologie di rete (a stella invece di bus o mash), si evitano collisioni mediante potenti "interruttori" che consentono di spostare simultaneamente i messaggi in una "concatenazione a margherita".
Le reti IT e i loro protocolli non solo sono in grado di trasportare gigabit al secondo invece che megabit come Profibus, ma anche la loro topologia è flessibile. Tecnicamente non c'è alcun problema nel distribuire una tale rete a livello globale, come Internet. Una chiave di questa flessibilità è l'astrazione del protocollo in "livelli" che costruiscono uno "stack". Il modello di riferimento OSI definisce sette livelli (vedere Figura 4). Profibus, ad esempio, ne definisce solo tre (livelli 1, 2 e 7). Internet con il suo protocollo TCP/IP li utilizza tutti.
Fig. 4: livelli di protocollo OSI; HTTP come esempio.
La flessibilità di tale architettura di comunicazione deriva dal fatto che due partner possono comunicare utilizzando lo stesso livello ma non hanno bisogno di sapere nulla sui processi di comunicazione nei livelli inferiori. Essi ricevono i loro messaggi dal livello inferiore successivo come comunicassero direttamente con il loro partner di rete allo stesso livello (Figura 5). È possibile considerarla una "comunicazione virtualizzata" con il livello vicino (partner).
Fig. 5: comunicazione da livello a livello utilizzando stack di protocollo.
L'utilizzo di un livello di rete (OSI livello 5) offre la possibilità di un instradamento a commutazione di pacchetto: ciascun nodo di rete può prendere la propria decisione a quale nodo confinante inoltrare un pacchetto di informazioni ricevuto per portarlo all'indirizzo destinatario desiderato (IP). Questa è la base di Internet e significa semplicemente che non si può mai sapere in che modo i pacchetti di informazioni viaggeranno da IP mittente a IP destinatario.
L'incertezza di questa flessibilità sta nella perdita di "abilità in tempo reale". Non è più possibile prevedere o definire con precisione il tempo di risposta massimo del partner di comunicazione. Se si utilizza una rete basata su TCP/IP per comunicare un cambiamento di stato di un interruttore, potrebbero essere necessari alcuni microsecondi o decine di millisecondi affinché il controller riceva il messaggio. Le "TSN" (time sensitive network, reti sensibili al tempo) affrontano queste probabilità e mirano a stabilire la capacità in tempo reale dei protocolli di rete IT.
La buona notizia è che non abbiamo bisogno della capacità in tempo reale per l'IIoT. La latenza non è il criterio principale. Ma c'è una particolare limitazione nella pianificazione per portare una macchina industriale in Internet: per gli stack di protocollo di comunicazione azionati da eventi, sono sempre necessari sistemi operativi threading o multi-tasking. I PLC classici di solito non hanno un sistema operativo di questo tipo. I moderni cosiddetti "soft PLC" sono applicazioni eseguite su IPC ("PC industriali" basati su Linux, computer che spesso sono montati su guide DIN e non utilizzano tastiere, mouse e monitor). Sebbene tali sistemi possano gestire in modo efficiente stack di protocolli TCP/IP, è consigliabile separare nettamente la comunicazione IIoT basata su messaggi dal software di controllo. I gateway sono un perfetto mezzo di separazione di rete e software. Un gateway può comportarsi come qualsiasi periferica IO al PLC (comunicando il suo protocollo di bus di campo) e si connette a internet basata sui messaggi dall'altro lato. I gateway sono spesso il punto in cui la protezione incontra la sicurezza, ma questo è l'argomento della Parte 3…
Started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (where I researched for my PhD). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.
Leggi l’articolo originale su DesignSpark
