Un processo realtime non necessariamente deve essere veloce, ma tempi di reazione rapidi permettono di affrontare le problematiche dei processi critici come timing in molteplici comparti industriali.
Nel contesto dell’automazione e del controllo dei processi ci si imbatte spesso nel termite “tempo reale”, caratteristica in genere attribuita a un sistema che è particolarmente veloce, tale da soddisfare, appunto, le esigente “realtime” di un’applicazione. Ma realtime non vuol dire veloce, né tantomeno vale il viceversa. L’espressione “tempo reale” sintetizza due essenze, tempo e reale: per la prima, la validità dei risultati dipende dal tempo entro cui questi sono prodotti; per la seconda, il tempo di sistema deve essere uguale a quello dell'ambiente in cui il sistema opera.
Realtime in many flavour
Il realtime può essere considerato come il livello di reattività di un sistema che un utilizzatore percepisce come sufficientemente immediato o tale da permettere al sistema di tenere il passo con i processi esterni, dalla ricezione dei dati, loro elaborazione, e invio dei risultati dove previsto. Questa definizione evidenzia un senso del tempo riferito più all’operatore che non al sistema in quanto tale, e la necessità che un sistema sia “sufficientemente veloce” nell’acquisire input e aggiornare output senza un “significativo ritardo”, pur ragionevole, è tecnicamente inaccettabile. Meglio allora concentrarsi sui vincoli realtime che un sistema reattivo deve soddisfare, cioè la garanzia che una certa elaborazione termini entro una data deadline o scadenza temporale. Privilegiando questo aspetto è possibile confezionare riferimenti concettuali abbastanza adeguati; per esempio, definire come realtime un sistema in grado di elaborare dati dal campo e generare una risposta entro un tempo predefinito, evitando il rischio di conseguenze anche gravi su un processo (e questo è un altro aspetto da non trascurare). Ma le esigenze temporali, per quanto stringenti possano essere, sono tra loro differenti a seconda delle applicazioni, e allora il concetto di realtime va adeguato a un contesto, da cui, come inevitabile conseguenza il fatto che un sistema possa essere realtime in un’applicazione ma non in un’altra, cosa senza dubbio accettabile. Ma la complessità cresce continuamente e con essa l’esigenza di adeguatezza di prestazioni, e una scelta tecnologica non attenta potrebbe col tempo incidere negativamente sugli investimenti di un’azienda. Il concetto di adeguatezza a un contesto porta poi alla suddivisione tra SRT e HRT. I primi, Soft Real Time, se sfondano la deadline provocano un danno non irreparabile al processo, mentre gli Hard Real Time nel caso superino temporalmente la propria deadline provocano un danno irreparabile.
Il fattore velocità
Si era prima evidenziato che realtime non significa veloce, attributo, quest’ultimo, il cui significato ha poco senso se non è riferito a un’ambientazione. Il punto centrale è che realtime e velocità si riferiscono a qualità diverse: capacità di soddisfare i vincoli temporali di un’applicazione nel primo caso, caratteristica prestazionale comunque, anche numericamente evidenziabile, nel secondo. Ma che un sistema sia veloce non guasta certo, permettendo di affrontare deadline anche estreme, garantendo quindi applicabilità in prospettiva, considerazione non certo secondaria ma non sempre tenuta in debito conto: la competitività di un’azienda si gioca infatti anche sulla sua capacità di saper rispondere con rapidità ed efficacia al crescere delle richieste di prestazioni che arrivano dal mercato, e soluzioni in grado di soddisfare esigenze non solo attuali ma anche future rappresenta un plus per i propri investimenti in tecnologia. Da considerare anche che la velocità permette di affrontare le problematiche di variazione sul tempo ideale dei sistemi realtime, dove il jitter deve essere misurabile a garanzia delle prestazioni.
Il contesto dell’automazione
Quanto finora analizzato può essere più precisamente riferito al contesto dell’automazione e del controllo industriale, considerando per esempio il caso in cui i segnali di I/O arrivano via rete a un controllore centrale, qui elaborati e poi resi disponibili a specifici moduli. Il riferimento all’elemento “rete” non è casuale, in quanto realtime e velocità trovano adeguata collocazione nel concetto di determinismo, tipico, appunto, dell’ambientazione reti e bus di campo: in un bus deterministico è possible garantire un tempo massimo in cui l’informazione di un utente verrà trasmessa, o un intervallo di tempo prevedibile per la reazione del sistema. Ma in generale la capacità di soddisfare le scadenze temporali imposte da un’applicazione è condizionata da un insieme di fattori imputabili alle diverse parti in gioco e alle loro modalità di aggregazione come definito a livello progettuale; in sintesi, le prestazioni della rete o del bus di campo, il numero di nodi partner della rete e il conseguente traffico che li riguarda, le prestazioni del controllore e il suo carico di lavoro. Detto diversamente, il tempo di risposta è da vedersi come somma di più “contributi temporali”. Istintivamente una prima ottimizzazione non può che interessare le prestazioni e la velocità del controllore, spostando l’attenzione sul suo contenuto tecnologico. L’evoluzione della microelettronica propone oramai chip multicore con velocità di clock che erano finora impensabili, ma questo è aggiornamento tecnologico o, se si vuole, innovazione “statica”, nel senso che si dà più spunto ma non si incide sul complesso del sistema in quanto tale, perché, come detto, molto dipende dal carico complessivo del controllore. Un’innovazione “dinamica”, in cui è vincente una nuova idea, non può puntare unicamente o quantomeno principalmente su un’elettronica veloce, ma per proporre soluzioni “ultrafast” deve seguire un percorso che sfrutta certamente la tecnologia allo stato dell’arte privilegiando però una visione non convenzionale.
Un nuovo ruolo per l’I/O
Se si considera il caso generale da cui si è partiti, con segnali che arrivano via rete a un controllore centrale che li elabora per poi renderli disponibili a specifici moduli, tra i diversi player di questo flusso dati il ruolo dell’I/O non è certo da protagonista, e un approccio non convenzionale potrebbe invece portare il focus dell’attenzione proprio su questa parte del sistema, materializzando un’innovazione tangibile in quanto basata su uno schema non tradizionale. Un esempio emblematico al riguardo è quanto è stato fatto da BR Automazione Industriale, con una soluzione denominata “reACTION technology”, che, FPGA-based, permette l’elaborazione di sottoprocessi time-critical direttamente nei moduli di I/O, pur in un’organizazione software che resta centralizzata, eliminando la necessità di trasmissione dati al controllo, con riduzione del tempo di risposta che può attestarsi a livello di un microsecondo. Più in dettaglio, i programmi in ambito reACTION sono sempre sviluppati tramite la piattaforma di programmazione Automation Studio di BR con function block standard IEC 61131, per poi essere assegnati a uno o più moduli reACTION nella configurazione dei moduli, con i dati dell’applicazione memorizzati centralmente nel controllore e trasferiti ai moduli quando necessario. Come alternativa, al posto di avere un programma assegnato in modo permanente a un modulo, da cui una possibile limitazione di flessibilità, il controllore può trasferire in modo dinamico e attivare programmi reACTION diversi, anche nel runtime. Da evidenziare che un programma reACTION può anche essere eseguito, a scopo simulazione, direttamente sul controllore. Come per gli usuali moduli di I/O, si ha il trasferimento di dati ciclici via data point, con numero e tipo di dati definibili nella configurazione dei moduli; tramite cross-communication mapping si ha uno scambio diretto tra moduli reACTION, che possono comunicare anche con normali moduli di I/O, indipendentemente dal controllore, con conseguente sgravio del suo carico di lavoro. Questa tecnologia risolve in modo innovativo le problematiche di molteplici comparti industriali associate a processi critici come timing, evitando la progettazione di soluzioni dedicate spesso complesse ed economicamente impegnative. La reACTION technology di BR Automazione Industriale è disponibile con i moduli di I/O X20 e X67, con la CPU compatta X20, ed è implementata anche nei nuovi moduli SafeIO X20SRT402, X20SRT806 e X20SRT842.
