Sviluppare sistemi embedded real-time

Negli ultimi anni la complessità funzionale dei sistemi embedded è cresciuta enormemente e i requisiti real-time sono diventati sempre più stringenti, di conseguenza l'integrazione di un sistema operativo real-time è diventata un obbligo e non più un'opzione per la maggior parte delle applicazioni. Se in passato integrare in un sistema embedded un kernel di Rtos era sotto vari aspetti una scelta che il progettista poteva permettersi di non fare per ragioni di ottimizzazione del sistema rispetto alle risorse di memoria e a quelle computazionali, oggi la complessità del sistema è tale da non lasciare margini di scelta. Fortunatamente insieme alla complessità sono cresciute anche le risorse di memoria e quelle computazionali, oltre alla velocità di esecuzione dei processi da parte del processore e delle sue periferiche. I kernel Rtos in questi anni sono stati fortemente ottimizzati, tanto da poter essere istallati su microprocessori di piccolissime capacità di memoria e limitata potenza di calcolo. Inoltre, a differenza del passato in cui i Rtos erano prevalentemente proprietari, ora c'è anche una notevole offerta di Rtos non proprietari e open source, favorendo in tal modo la componente di costo del sistema embedded sempre molto critica.

Caratteristiche di un sistema embedded real-time

Un sistema che interagisce con il mondo fisico esterno è per definizione real-time in quanto deve essere in grado di gestire gli eventi fisici nei tempi in cui si manifestano (tempo reale) e non in tempi differiti (non real-time). Ciò implica che il sistema embedded deve essere progettato in modo da rispettare questa condizione tramite meccanismi hardware e/o software adeguati a gestire il tempo di esecuzione dei processi entro intervalli certi. A tale scopo è necessario che la natura dei processi sia nota e i relativi tempi di esecuzione certi, in modo che possa essere programmato un meccanismo di gestione della messa in esecuzione e della relativa terminazione dei processi entro il tempo limite (deadline). Questo meccanismo si chiama “scheduler” e il suo modo di funzionare caratterizza il sistema real-time relativamente al livello di garanzia di esecuzione certa dei processi.
I meccanismi di scheduling più utilizzati sono i seguenti:

• Earliest Due Date - Tutti i processi arrivano allo stesso tempo e la priorità è statica

• Erliest Deadline First - I processi arrivano in qualsiasi momento e la priorità viene modificata in base alla scadenza temporale del processo

• Rate Monitoring - E' il meccanismo di gestione temporale dei processi periodici
Ci sono due approcci fondamentali per lo sviluppo di un sistema embedded real-time:
• Il primo è quello in cui lo sviluppatore implementa direttamente nel software applicativo i meccanismi di gestione della temporizzazione dei processi con lo scopo di ottimizzare al massimo le risorse di sistema (memoria e tempo di elaborazione). Questo approccio implica un grande sforzo di sviluppo in quanto il meccanismo di scheduling può risultare anche molto complesso e la sua messa a punto temporalmente onerosa. In questo caso utilizzare un ambiente di sviluppo per sistemi real-time (vedi box: Sviluppo rapido di sistemi real-time) è la scelta migliore per accelerare i tempi di sviluppo e garantirsi un elevato livello di affidabilità del sistema. Il secondo approccio è quello basato sull'utilizzo di software di sistema per la gestione dei processi real-time, cioè un sistema operativo real-time (Rtos). In questo caso i meccanismi di gestione temporale dei processi sono già implementati e validati, e lo sviluppatore si limita all'integrazione del software applicativo e del software di sistema sulla piattaforma hardware target.

Prevedibilità dei processi real-time
I processi fisici hanno in generale tempi di manifestazione che possono essere stimati preventivamente. Per esempio il campionamento del segnale è un processo sincrono (avviene a intervalli regolari) che richiede un intervallo temporale massimo (intervallo di campionamento) entro cui deve essere eseguito (acquisizione della misura e memorizzazione). La corretta stima di questo intervallo (teorema del campionamento) non è sufficiente a garantire che il processo di campionamento venga eseguito correttamente in termini temporali. Ci sono fattori di sistema (hardware e software) che possono introdurre elementi di non prevedibilità dei tempi nella risposta del software di sistema, per esempio il Dma (Direct Memory Access) che può allocarsi il bus bloccando la Cpu, la memoria cache nel momento in cui deve aggiornarsi e soprattutto le interruzioni asincrone. I sistemi operativi generici (per esempio Window e Unix) non hanno meccanismi per garantire l'esecuzione certa dei processi entro tempi massimi prestabiliti e quindi non sono utili per l'implementazione di sistemi real-time. Questi sistemi operativi, data la loro popolarità, sono stati modificati a livello di kernel e adattati alle applicazioni real-time nella versione embedded (per esempio WindowsCE e RTLinux Open). Molti Rtos sono invece nati come tali (nativi) e quindi sono particolarmente ottimizzati per le applicazioni real-time, soprattutto quelle critiche (hard real-time) e per la natura dei sistemi embedded (ridotto footprint di memoria).

Quale Rtos?
Un sistema operativo real-time è un sistema operativo specializzato per la gestione del software applicativo e di un intero sistema real-time, normalmente di natura embedded. Il tipico utilizzo è di natura industriale (controllo di processo, robotica, telecomunicazioni, biomedicale, ecc.) e anche (soprattutto recentemente) di natura consumer (smartphone, automotive, domotica, ecc.). Il compito di un Rtos è quello di gestire la complessità di un sistema embedded in modo che l'interazione tra i processi risulti temporizzata così da rispettare le priorità e soprattutto garantire in maniera deterministica che un processo venga eseguito entro un tempo massimo (deadline). In funzione dell'importanza dei processi che devono essere gestiti relativamente alla gravità del possibile malfunzionamento che il sistema embedded potrebbe avere, i Rtos si classificano su tre livelli:

1. Hard Rtos: garantiscono la certezza di esecuzione del processo entro la deadline.

2. Firm Rtos: garantiscono la quasi certezza di esecuzione del processo entro la deadline

3. Soft Rtos: non è garantita la certezza di esecuzione del processo entro la deadline
Questa classificazione dei Rtos è strettamente legata a quella dei sistemi embedded. Quelli che implementano applicazioni in cui mancare la deadline di servizio di un processo porta a una conseguenza disastrosa, per esempio il sistema di frenaggio automatico di un convoglio ferroviario, necessitano di un Hard Rtos. Al contrario, un sistema embedded in cui il mancato servizio di un processo entro la deadline, per esempio l'estrazione di un dato da un archivio entro un tempo massimo, si avvale di un Soft Rtos.

Proprietario od open-source?
I sistemi operativi Rtos si suddividono fondamentalmente in due categorie: proprietari e non proprietari (open source). Tra i sistemi Rtos proprietari uno dei più noti è VxWorks di Wind River. Questo è un sistema operativo basato su Unix e include un kernel multitasking con scheduler di tipo preemptive (lo scheduler ha diritto di prelazione sulla Cpu e quindi può sottrarla forzosamente a un processo per garantire la deadline in scadenza di un altro processo). È un Rtos che deriva dal sistema operativo real-time VRTX della Ready Systems, uno dei primi sistemi Rtos che risale agli anni '80, cioè quando l'architettura dei processori erano a 8, massimo 16 bit, il clock dell'ordine dei MHz e il footprint di memoria era dell'ordine dei Kbyte. WxWorks supporta numerose architetture di computing, tra cui l'architettura Arm di Arm Holdings, quella Mips di Mips Computer Systems, il Coldfire/68K di Freescale, l'H8 ed SH (SuperH) di Hitachi. Tra i sistemi operativi open source uno dei più noti è FreeRtos, sviluppato da Real-time Engineers, il cui codice è disponibile per decine di microcontrollori. Viene distribuito con licenza Gpl (General Public License) che consente di utilizzare liberamente il software, di studiarlo, di modificarlo e di condividerlo, ma anche di mantenerlo chiuso nella parte applicativa proprietaria alla condizione di mantenere aperto il kernel. In questa maniera viene favorito l'uso di FreeRtos nelle applicazioni proprietarie senza alterarne la natura open source del sistema operativo. Oltre ad essere open source, FreeRtos ha la peculiarità di essere piccolo e non complesso, quindi di facile interpretazione da parte dello sviluppatore relativamente ai suoi meccanismi funzionali e alla sua integrazione sulla specifica piattaforma di riferimento. E' completamente scritto in linguaggio C (in assembler sono scritte solo alcune funzioni strettamente legate ad architetture specifiche), quindi compilabile virtualmente per qualsiasi piattaforma di elaborazione. FreeRtos è molto essenziale, quindi non copre tutta la funzionalità di un sistema operativo (per esempio i driver) ed è concentrato soprattutto nell'implementazione dello scheduler, per cui ne deriva un memory footprint estremamente ridotto, un bassissimo sovraccarico della Cpu e soprattutto una velocissima esecuzione. Lo scheduler può essere preemptive o cooperative.

Lo sviluppo rapido di sistemi real-time

Lo sviluppo di sistemi real-time che devono garantire prestazioni certe e precise implica l'integrazione tra tre componenti fondamentali, il codice applicativo, un Rtos e un hardware. Dato che questa integrazione del software richiede tempo ed è molto costosa, è possibile utilizzare ambienti di programmazione grafica dei sistemi real-time come LabView di National Instruments. Questi ambienti consentono di creare applicazioni in maniera rapida e intuitiva tramite la programmazione grafica.
LabView, combinato con LabView Real-Time Module, consente di creare sistemi hard real-time caratterizzati da temporizzazioni precise, processi di I/O deterministici e funzioni di comunicazione affidabili, in tempi estremamente più brevi di quelli richiesti dal metodo tradizionale di sviluppo e integrazione del software. Il LabView Real-Time Module è una soluzione di progettazione completa per la creazione di sistemi stand-alone affidabili. LabView Real-Time Module è un add-on di LabView per lo sviluppo e il debug di applicazioni grafiche che possono essere scaricate ed eseguite su dispositivi hardware embedded come NI CompactRIO, NI Single-Board Rio, Pxi, sistemi di visione e Pc di terze parti. LabView Real-Time Module rende disponibile allo sviluppatore centinaia di librerie LabView precompilate, incluso controllo Pid (Proportional integral derivative) e Fft (Fast Fourier Transforms) e una serie di driver hardware real-time. Per sviluppare programmi real-time è possibile utilizzare sia LabView Real-Time Graphical Programming oppure LabWindows/Cvi Ansi C environment.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome