I sistemi embedded sono diventati una realtà imprescindibile in ogni attività umana. Ma cosa sono e soprattutto come vengono utilizzati nell’automazione industriale?
Tutti abbiamo avuto in casa un televisore CRT (quello grosso, cubico e pesantissimo). Un sistema hardware composto da centinaia di componenti fra loro interconnessi, in grado di ricevere e decodificare un segnale radio e di visua
lizzarne i contenuti su uno schermo a fosfori. Se si raffronta uno di questi vecchi televisori con un moderno apparecchio piatto a LED, al di le delle evidenze fisiche, salta subito all’occhio la diversità fra le due generazioni nell’interfacciamento con lo spettatore: i vecchi sistemi si limitavano ad accendersi e spegnersi e, al più, visualizzavano su un display sette segmenti il canale sintonizzato; i nuovi, al di là della visualizzazione, offrono una serie di opzioni tipiche di un sistema informatico: menù a cascata, scelta fra diverse lingue, correzioni e personalizzazioni “software” del video e dell’audio, possibilità di gestire in maniera integrata l’accesso a periferiche e la connessione in rete, fino alla possibilità di aggiornamento del software di sistema. Si possono ancora chiamare televisori? Sì, se ci si riferisce esclusivamente alla loro funzione principale, no se ci si riferisce all’insieme delle loro proprietà e delle funzionalità. In tal caso sarebbe più corretto definirli “sistemi TV embedded”. Dunque “embedded” (“integrato” o, meglio, “incorporato” in italiano) definisce un sistema integrato hardware-software che, al contrario dei computer general purpose, nasce e viene proposto al mercato per un’unica funzione. Un televisore moderno offre le più complete funzionalità TV, ma non è in grado di (e non è stato progettato per) fare altro, nemmeno a livello elementare.
I sistemi di controllo embedded
Dato il loro elevato livello di specializzazione, i sistemi embedded sono progettualmente definiti da alcune regole:
basso costo di realizzazione; normalmente è conveniente progettare e realizzare un sistema embedded quando il sistema debba essere prodotto in grandi quantità; in tal caso la concorrenza di molti produttori implica la necessità di avere bassi costi realizzativi:
- elevata affidabilità di funzionamento; a nessuno verrebbe in mente di prelevare denaro da uno sportello Bancomat spesso fuori servizio per frequenti crash con l’elevato rischio di perdere la tessera e/o il codice
- elevata velocità di reazione; la specializzazione funzionale del sistema integrato dovrebbe rendere molto elevata la velocità di risposta del sistema (anche se ciò non è sempre garantito)
- software ridotto e ottimizzato per girare su hardware dedicato in grado di effettuare bene e velocemente ciò per cui viene progettato
Ma un conto è utilizzare sistemi embedded per operazioni non critiche come fare il bucato in una lavatrice, altro è sorvegliare e gestire processi automatici con numerose fasi, un elevato numero di variabili tempo-critiche e di anelli di regolazione. In tal caso il sistema operativo embedded non solo deve sovraintendere alle normali operazioni ma, certamente, deve anche trattare una grande mole di dati ed effettuare moltissime operazioni matematiche per l’applicazione di algoritmi di regolazione che possono essere anche notevolmente complessi; si pensi, per esempio, agli algoritmi di regolazione del moto di più assi interpolati. Per evitare grossolani errori di valutazione delle variabili regolate un sistema operativo embedded per il controllo di processo, oltre alle caratteristiche elencate, deve quindi possedere anche quella di essere specializzato per compiti di regolazione o, in altre parole, di essere real-time.
I sistemi operativi real-time
Quali sono le caratteristiche di un sistema real-time (spesso abbreviato in RTOS – Real-time Operating System)? Anche se sembra strano non è tanto la velocità di risposta la caratteristica qualificante quanto, piuttosto, il determinismo del tempo di risposta, intendendo con tale termine la capacità del sistema operativo di rispondere entro un tempo massimo predeterminato. Si può affermare che un sistema real-time deve garantire che una elaborazione (o task) arrivi a conclusione entro un dato vincolo temporale. Tale vincolo, di norma, viene valutato in relazione alla tempo-criticità delle variabili del processo regolato. Per fare un esempio si pensi alla gestione di un ciclo di regolazione della temperatura; se il task è effettuato per un locale, la bassa tempo-criticità della variabile regolata, dovuta all’inerzia del sistema, richiede che il RTOS si in grado di elaborare il ciclo di regolazione in un tempo massimo che può essere dell’ordine dei minuti; se invece il task è effettuato per un fornetto in cui sta avvenendo una reazione chimica dipendente dalla temperatura, può essere richiesto che il tempo di risposta del RTOS sia di pochi decimi o centesimi di secondo. Dunque il concetto di tempo reale non è una nozione assoluta, bensì da contestualizzarsi rispetto all’ambito applicativo. Il corollario al determinismo dei sistemi operativi real-time è costituito dalle loro necessaria abilità di scheduling; posto infatti che per processi non banali sia necessario gestire più task di regolazione, è implicito che un controllore embedded con sistema operativo real-time debba possedere anche capacità di schedulazione. Il verificarsi di più evenienze e necessità di intervento contemporanee, esige che un RTOS sia in grado di valutare aprioristicamente i tempi esecutivi di ogni task e di assegnare dinamicamente le priorità esecutive in funzione della criticità della regolazione e del tempo di risposta da garantire. Il tutto risulta oltretutto complicato dalla necessità di eseguire, oltre a task periodici, anche task aperiodici che possono richiedere l’esecuzione in qualsiasi istante.
I sistemi Windows o Unix based
Per il mercato dei sistemi embedded esistono numerosi S.O. real-time, alcuni diffusi in svariati settori applicativi, altri decisamente meno conosciuti e più di nicchia. Fra i più noti e maggiormente utilizzati ci sono le versioni ad hoc di Windows e di Linux; la necessità di fornire tempi di reazione deterministici e calcolati impedisce infatti di utilizzare sistemi basati su Windows e Unix (Linux) in edizione per PC. Nelle versioni standard di questi sistemi operativi, infatti, sono utilizzate memorie di massa con notevoli (e variabili) tempi di latenza; inoltre i principi di funzionamento su cui si basano Windows e Unix impediscono la completa prevedibilità dei tempi esecutivi dei task: come esempio, basti per tutti l’utilizzo degli interrupt che, in quanto iniziativa delle periferiche, rendono non predeterminabili i tempi di risposta. Il più noto delle due versioni real-time è forse Windows CE che, nel tempo, si è affermato come uno dei S.O. di punta per la realizzazione, soprattutto in ambito industriale, di un gran numero di dispositivi embedded di tipo “non PC”. Molti pannelli operatore e panel-PC utilizzati come HMI e raccolta dati sono per esempio proposti con questo S.O. Windows CE, infatti, offre come prestazioni integrate il real-time e un’interfaccia semplificata rispetto alla versione Windows per PC. Per quanto riguarda Linux real-time, il ritardo nell’affacciarsi sul mercato dei sistemi embedded è stato dovuto in parte alla destrutturazione degli agenti di sviluppo, in parte al notevole numero di distribuzioni disponibili che, in qualche modo, ha polverizzato il lavoro di aggiornamento ma, soprattutto, allo sforzo compiuto per modificare il codice del kernel originario nato con caratteristiche non-preemptive. Con tale termine ci si riferisce a sistemi operativi che non dispongono di scheduler, ovvero che non sono in grado di interrompere temporaneamente un processo per eseguirne uno con priorità più elevata al termine del quale ripristinare e terminare il processo originario. Un sistema operativo non-preemptive, per quanto detto, non può essere real-time e non può quindi essere utilizzato per il controllo di processo. L’adeguamento in tal senso di Linux ha avuto inizio soltanto nel 2000.
Il trend dei sistemi real-time
Così come per i S.O. standard, anche per le versioni real-time gli sviluppi attuali sono in direzione Web, con l’obiettivo della connettibilità completa; con tale termine si intende la possibilità di offrire la totale o parziale visibilità remota dei sistemi controllati ma anche, per esempio, l’accesso a sistemi di archiviazione remota, così da poter strutturare sistemi embedded con hardware ridotto e, quindi, maggiormente affidabile. È evidente che se tale trend di sviluppo è importante per i normali computer general purpose, risulta fondamentale per applicazioni di controllo di processi industriali critici che possano per esempio svolgersi in condizioni ambientali gravose, con inaccessibilità da parte di operatori, in postazioni remote, ecc.
