Sistemi embedded per applicazioni in tempo reale

1 
 
INTRODUZIONE 
Ogni giorno entriamo in contatto con centinaia di sistemi basati su microprocessore senza 
nemmeno rendercene conto. Si parla di sistemi invisibili, ubiqui e pervasivi, per 
rappresentare la loro invasività nella vita quotidiana. Questi sistemi sono detti dedicati o 
embedded, la loro complessità e delle relative applicazioni si è enormemente amplificata 
negli ultimi anni, sia a causa delle esigenze crescenti dei requisiti applicativi, che per la 
complessità dei dispositivi hardware che si sono resi disponibili. Si tratta infatti di sistemi 
fortemente specializzati e ottimizzati per svolgere un ristretto numero di compiti. 
La maggior parte di tali sistemi sono di natura real-time, con requisiti di affidabilità molto 
stringenti e trovano applicazione in campi come quello automotive, industriale e della 
comunicazione e in settori applicativi emergenti come il medicale e il consumer. 
Nel primo capitolo sono riassunte le principali caratteristiche dei sistemi embedded, 
focalizzando poi l’attenzione su quelli real-time descrivendo le architetture, i vari tipi e i 
metodi di funzionamento sul loro utilizzo. 
Nel secondo capitolo sono descritti e spiegati gli ambenti in cui hanno trovato sviluppo 
ponendo l’attenzione sulle loro modalità di progettazione.
2 
 
1.SISTEMI IN TEMPO REALE PER APPLICAZIONI EMBEDDED 
 
1.1 INTRODUZIONE AI SISTEMI EMBEDDED 
 
1.1.1 CARATTERISTICHE GENERALI 
 
I sistemi embedded sono definiti come sistemi basati su processore progettati per eseguire 
alcune funzioni dedicate, spesso in tempo reale. Di solito costruiti su unità di 
microcontrollori (abbreviati come MCU) o processori di segnali digitali (abbreviati come 
DSP), a seconda dell'applicazione. In letteratura, quando parliamo di Sistemi Embedded 
vogliamo indicare un qualsiasi dispositivo elettronico corredato di appositi sensori e attuatori 
per la comunicazione con l’ambiente circostante, che sia stato progettato per svolgere una 
ben determinata funzionalità. 
Poiché i sistemi embedded sono progettati per attività specifiche e spesso prodotte in massa 
sono ottimizzati in termini di dimensioni, costi di produzione, prestazioni e affidabilità. 
Alcuni sono semplici, hanno solo pochi ingressi e uscite, altri sono più complessi e sono 
collegati tra loro tramite una rete di comunicazione con altri sistemi embedded. [1] 
Sistemi embedded si possono riscontrare in automobili, treni, aerei e apparecchiature di 
telecomunicazione o di fabbricazione. Tali sistemi sono dotati di un gran numero di 
caratteristiche comuni, inclusi vincoli in tempo reale, affidabilità e requisiti di efficienza. Per 
tali sistemi, il collegamento con la fisica ed i sistemi fisici è piuttosto importante. Questo 
collegamento è evidenziato nella seguente citazione: 
“Embedded software is software integrated with physical processes. The technical 
problem is managing time and concurrency in computational systems”. [2] 
Questa citazione può essere utilizzata come definizione di software embedded e può essere 
estesa a una definizione di sistemi embedded semplicemente sostituendo software con 
sistema. Tuttavia, il forte legame con la fisica è stato recentemente sottolineato anche 
dall'introduzione del termine "sistemi cyber-fisici" (sistemi CPS o cy-phy). [3] 
I sistemi embedded sono chiamati special purpose, a differenza dei personal computer 
detti general purpose, poiché essi devono svolgere uno specifico compito o un insieme 
limitato di compiti stabilito a priori. Costituiti da una combinazione hardware-software
3 
 
appositamente studiata per una specifica applicazione, permettono così di ridurre l’hardware 
ai minimi termini in modo da poter risparmiare spazio occupato, diminuire i consumi e i 
costi di produzione. 
Quindi è essenzialmente un sistema a microprocessore come un PC, ma dedicato a svolgere 
un particolare compito, ha risorse e dispositivi strettamente necessari, hardware dedicato, 
frequenze di CPU inferiori, basso consumo e poca memoria (anche di massa). 
Devono essere sistemi privi di interazione umana, con capacità di resistere ad eventi dannosi, 
a vibrazioni e shock e in grado di ripartire in modo autonomo. 
Possibilmente di dimensioni ridotte, raggiungibili tramite connessione di vario tipo e devono 
avere risorse necessarie per l'esecuzione dei processi indispensabili al loro funzionamento 
spesso con vincoli temporali (sistema real-time). 
La maggior parte dei sistemi embedded sono sistemi reattivi gestiti da un micro-controller: 
devono ricevere segnali dal loro ambiente, elaborarli e implementare azioni corrispondenti.  
Un sistema può essere suddiviso come, nella Figura1, orizzontalmente nel software (kernel, 
driver e firmware) e hardware (μ C, interfaccia e ASIC) e verticalmente nei microcontrollori 
(μ C), componenti hardware specifici per l'utente (ASIC) e interfacce (Interfaccia) tra i 
singoli componenti e l'ambiente. [4] 
 
 
                                   Figura1.Struttura astratta di un sistema embedded
4 
 
Le caratteristiche di un Sistema Embedded sono molte ed ognuna impone uno specifico 
vincolo ai progettisti del sistema. 
•Sistemi per specifiche applicazioni: si parte del presupposto che i Sistemi   Embedded sono 
progettati per specifiche applicazioni. Molte delle caratteristiche del lavoro che deve essere 
eseguito sono conosciute prima che l’hardware sia progettato; ciò permette al progettista di 
focalizzarsi sugli specifici vincoli di progetto di un’applicazione ben nota. Inoltre c’è una 
limitata riprogrammabilità del sistema, anche se per alcuni sistemi è richiesta flessibilità 
sotto questo aspetto. 
•Sistemi reattivi: un tipico Sistema Embedded interagisce con l’ambiente tramite sensori e 
attuatori: con i sensori si “osserva”, con gli attuatori si “comanda”.  
Ciò richiede che il sistema abbia la stessa velocità dell’ambiente. Questa caratteristica è detta 
reattività. Un’elaborazione reattiva indica che il sistema (principalmente i componenti 
software) la esegua in risposta ad eventi esterni, che possono essere sia periodici che 
aperiodici. Gli eventi periodici rendono più facile la programmazione per garantire le 
prestazioni desiderate, mentre gli eventi aperiodici sono difficili da schedulare e il massimo 
ritardo di un evento deve essere valutato per conoscere il worst-case. Molti Sistemi 
Embedded hanno una significativa componente di reattività. Una delle più grandi sfide per i 
progettisti è fare in modo che le performance dei worst-case siano in linea con le aspettative. 
 
•Sistemi distribuiti: una caratteristica comune per i Sistemi Embedded è quella di ospitare 
diversi processi comunicanti, che risiedono su diverse CPU o ASIC, le quali sono connesse 
attraverso canali di comunicazione in modo tale da ottenere risparmio economico. 
Microcontrollori a 4-8 bit possono essere più convenenti rispetto ad un processore a 32 bit. 
Anche andando ad aggiungere i costi per la comunicazione, questo approccio risulta 
conveniente. Con questo sistema più processori sono richiesti per occuparsi di vari processi, 
che hanno come fattore critico il tempo. I dispositivi sotto il controllo del Sistema Embedded 
devono essere fisicamente distribuiti. 
 
•Architetture eterogenee: i Sistemi Embedded sono sempre più spesso architetture 
eterogenee. Queste architetture possono avere processori differenti e trattare segnali 
eterogenei. La combinazione delle interfacce I/O, delle memorie locali e remote, degli 
attuatori e sensori rendono il progetto del sistema veramente unico. Come già sottolineato, i 
Sistemi Embedded possono avere vincoli stringenti, ma l’eterogeneità può fornire più 
flessibilità al progetto.
5 
 
 
•Sistemi affidabili: così come la complessità dei sistemi, anche la potenza d’elaborazione è 
in continua crescita, e ci sono sempre più aspetti di safety da dover controllare. Queste misure 
di sicurezza possono essere sia controlli software che controlli hardware, come ad esempio 
i meccanismi di backup che sono normalmente attivati quando il sistema perde il controllo 
in relazione alle azioni di shut-down del sistema senza correre rischi. Un “guasto” software 
non è inteso nello stesso senso di un guasto hardware. Tuttavia il software può essere così 
complesso che un insieme di circostanze inaspettate può portare ad un fallimento software, 
causando una condizione di non funzionamento per il sistema. 
 
•Controllo di sistemi fisici: una delle principali caratteristiche di un Sistema Embedded è 
l’interazione con l’ambiente circostante, ottenibile controllando e monitorando macchinari 
esterni. I segnali analogici sono trasformati in segnali digitali per essere elaborati, e gli output 
devono essere convertiti nuovamente in segnali analogici. Quando si interagisce con 
macchinari esterni si deve poter generare e controllare valori di corrente elevati per poter far 
funzionare i motori e gli attuatori; per venire incontro a tale esigenza i Sistemi Embedded 
hanno bisogno sovente di piattaforme, con molti componenti non digitali che elaborano 
opportunamente i segnali in modo da renderli conformi con le necessità. Il progettista del 
Sistema Embedded deve bilanciare accuratamente l’interazione tra i vari componenti 
analogici, di potenza, meccanici, di rete e hardware digitale con il corrispondente software. 
 
•Sistemi leggeri: molti Sistemi Embedded sono fisicamente posti in sistemi più grandi. La 
forma che deve assumere il sistema contenuto è dettata dalla geometria del sistema in cui va 
a porsi. Le dimensioni possono essere dei vincoli critici: per esempio i Sistemi Embedded di 
controllo per automobili devono essere” leggeri” per non alzare i consumi di combustibile, 
mentre i player cd portatili devono avere dimensioni ridotte per permetterne la trasportabilità. 
 
•Costi: i costi sono un aspetto importante nella maggior parte dei sistemi, ma la sensibilità 
ai costi può variare significativamente nei Sistemi Embedded. Infatti, bisogna considerare 
l’impatto che una modifica del sistema ha sulla redditività, cioè quanto è conveniente 
apportare la modifica in relazione al costo da sostenere, tenendo presente che quest’ultima è 
strettamente legata ai requisiti e caratteristiche del sistema stesso.
6 
 
•Consumo di potenza: i Sistemi Embedded hanno vincoli stringenti sulla potenza. Perché un 
sistema sia portabile vi è la necessità di risparmiare energia, in modo che la batteria duri il 
più a lungo possibile. Anche la minimizzazione della produzione di calore ricopre un ruolo 
importante nel progetto dei Sistemi Embedded. 
 
 
1.1.2 HARDWARE E SOFTWARE 
 
Una delle caratteristiche dei sistemi embedded è che sia l'hardware che il software devono 
essere presi in considerazione. Figura2 
 La progettazione di hardware e le parti del software non possono essere eseguite 
singolarmente ma devono essere trattate uniformemente. Il riutilizzo dei componenti 
hardware e software disponibili è al centro della metodologia di progettazione basata sulla 
piattaforma. 
L'hardware per i sistemi embedded è molto meno standardizzato rispetto all'hardware per i 
personal computer. A causa della grande varietà di hardware dei sistemi embedded, è 
impossibile fornire una panoramica completa di tutti i tipi di componenti hardware.  
Nell'infrastruttura hardware, il riutilizzo di blocchi o componenti preesistenti è un modo 
comune per lo sviluppo rapido del sistema. L'obiettivo principale è quello di ridurre i costi 
elevati dello sviluppo hardware utilizzando elementi esistenti. Ci sono grandi librerie o 
cataloghi che forniscono elenchi di componenti disponibili insieme alle loro specifiche o 
addirittura il loro codice sorgente o la realizzazione (cioè le descrizioni dei circuiti elettronici 
dettagliati). Da un punto di vista storico questo processo di riutilizzo si è evoluto nel tempo, 
dai transistori e dai registri ai complessi microcontrollori, che oggi si espande nel mondo del 
software (cioè, i blocchi di costruzione eseguono compiti complessi e sono sistemi a loro 
diritto). Quindi, essi possono essere considerati come componenti e, di fatto, lo sono.  
Qui l'idea di sviluppare componenti basati su sistemi embedded, che comprende componenti 
hardware e software. Purtroppo, esistono alcune differenze concettuali tra i componenti                                 
hardware e software che complicano il compito di uno sviluppo unificato. 
Secondo Szyperski, "Una componente software è un'unità di composizione con interfacce 
contrattualmente specificate e dipendenze di contesto esplicite. Un componente software può 
essere distribuito in modo indipendente e soggetto a composizione da parte di terzi”. [5]