I sistemi embedded di ultima generazione hanno fondamentalmente tre caratterizzazioni comuni. Tendono a essere sempre più configurati in rete, a diventare parte integrante di qualsiasi oggetto che ci circonda e soprattutto sono sempre più comuni. Questa caratterizzazione impone nuove esigenze allo sviluppo di sistemi embedded, in particolare la condivisione di standard e di quanto serve alla interoperabilità. Il ruolo del sistema operativo, in particolare del Rtos (Real-time operating system), diventa fondamentale nel garantire l'interoperabilità, oltre ovviamente alla funzionalità tradizionale tipica dei sistemi operativi. Il sistema embedded, anche se intrinsecamente dedicato e basato su un elevato contenuto proprietario a livello ideativo, è comunque sempre più costretto a interagire con altri sistemi embedded e quindi a condividere aspetti funzionali e componenti (protocolli, servizi, driver ecc.). I sistemi operativi Rtos tendono quindi a integrare queste funzionalità e componenti, rendendo così più semplice il lavoro dello sviluppatore sia nel soddisfare i requisiti correnti del progetto, sia quelli futuri che si determineranno durante il ciclo evolutivo del prodotto.
Svilupparlo o comprarlo?
Gli sviluppatori di sistemi embedded sono ancora orientati a sviluppare il software di sistema completamente in casa, ma questo approccio diventa sempre più proibitivo per i requisiti di time-to-market sempre più stringenti e per la crescente complessità delle applicazioni. I real-time operating system sono la soluzione ottimale per perseguire questi obiettivi e trarre vantaggio dal riutilizzo di software già sviluppato da altri.
La prima cosa che uno sviluppatore deve essere in grado di valutare è se il prodotto a cui deve dedicare le sue risorse di progettazione necessita effettivamente di un Rtos. Questa valutazione è strettamente legata alla complessità dell'applicazione stessa. In che modo?
La necessità di utilizzare in un sistema un Rtos piuttosto che un semplice scheduler o un temporizzatore di eventi è la stessa che induce il progettista a scegliere tra un linguaggio di programmazione ad alto livello (in genere il linguaggio C) piuttosto che il linguaggio assembly (il linguaggio nativo di programmazione dei processori). Esiste un livello di complessità del sistema che solo un software di sistema (un Rtos) è in grado di affrontare in maniera adeguata. Ciò significa che ci sono applicazioni abbastanza semplici nella loro funzionalità di sistema che un Rtos costituirebbe solo un inutile appesantimento del sistema. L'evoluzione dei sistemi embedded è comunque tale che anche l'applicazione più semplice diventa complessa. Un esempio emblematico è il telefono cellulare, un sistema in cui pochi e semplici task potevano essere gestiti da un microcontrollore a 8 bit che faceva girare un software di sistema per gestire la tastiera, il display, l'antenna, il microfono e l'altoparlante. Nella quasi totalità dei casi il software di sistema dei telefoni cellulari era sviluppato su misura direttamente dal progettista per quel prodotto. Oggi il telefono cellulare è più un computer che un telefono. La complessità e la problematicità della gestione dei task e dei processi è tale che non adottare un Rtos sarebbe una scelta masochistica da parte del progettista.
Esclusa dunque la pur ampia classe di applicazioni troppo semplici per giustificare l'uso di un Rtos, la maggior parte delle applicazioni impone questa scelta. Il problema a questo punto è: svilupparne uno su misura per la propria applicazione oppure adottarne uno esistente sul mercato? Certamente, se le prestazioni del sistema sono il parametro più importante, la scelta di svilupparlo su misura può essere giustificata. I requisiti real-time di memoria e di tempo di risposta possono essere più facilmente soddisfatti con un Rtos sviluppato ad-hoc. Anche altri requisiti, come quelli degli standard e di regole funzionalità interna di aziende che operano in settori particolari come l'avionica, il medicale, il militare, ecc., sono più facili da soddisfare con un Rtos fatto su misura piuttosto che con uno commerciale.
Molte applicazioni non nascono ex-novo, ma come evoluzione di applicazioni precedentemente sviluppate. Se queste non adottavano in precedenza un Rtos commerciale, difficilmente nella nuova versione dell'applicazione si sceglierà di utilizzare un Rtos commerciale, in quanto ciò costringerebbe il progettista a un oneroso lavoro di porting del software esistente, funzionante e validato, sotto il nuovo ambiente di sistema. Questa scelta diventa sensata o addirittura vantaggiosa quando per l'applicazione c'è una migrazione dell'hardware (per esempio un nuovo microprocessore) e soprattutto se questo microprocessore supporta in forma nativa un suo Rtos.
Come scegliere il Rtos giusto
Se il problema del progettista è di avvalersi di un Rtos da acquisire esternamente piuttosto che svilupparlo in casa, gli elementi che possono contribuire alla decisione sono molteplici, e quindi è opportuno che, data l'enorme e diversificata offerta, esso tenga presente alcuni aspetti.
Un aspetto molto importante è in che modo gli strumenti di cui dispone già il progettista a supporto del suo lavoro di sviluppo (ambiente di emulazione, compilatore, ambiente di modellazione, ecc.) interagiranno con il sistema Rtos scelto. Un aspetto su cui bisogna che il progettista ponga una seria attenzione per quanto riguarda la scelta del Rtos concerne la possibilità di eseguire in maniera efficace ed effettiva il debugging dell'applicazione quando questa sarà integrata con il Rtos. Il Rtos introduce, rispetto al software applicativo, nuove problematiche come i meccanismi di sincronizzazione e la commutazione di contesto, con problematiche conseguenti come il deadlock, il sovraccarico della Cpu, il ritardo di servizio delle interruzioni, ecc. Questi ed altre situazioni critiche non necessariamente sono supportate dagli strumenti di sviluppo di cui dispone il progettista. Questi vanno ricercati nell'offerta di strumenti di debug del produttore di Rtos, oppure attraverso una verifica circa l'utilizzo da parte della comunità degli utilizzatori di tale Rtos o se terze parti mettono a disposizione tali strumenti.
Criteri discriminanti
I principali e più significativi criteri su cui basarsi nella scelta sono:
- proprietario/libero
- politica di licenza
- dimensioni del kernel
- prestazioni real-time
- supporto tecnico
La discriminante proprietario/libero è molto importante in quanto porta alla scelta di Rtos con alcune caratterizzazioni anche molto distanti tra loro. Questa scelta è molto legata allo skill dello sviluppatore in tema di Rtos in quanto, da una parte troverà un'ampia comunità di sviluppatori che hanno sviluppato una significativa esperienza sulle problematiche implementative, dall'altra non possono contare su un vero e proprio supporto tecnico. Una delle principali motivazioni allo scelta di un Rtos libero è la sua intrinseca natura open source, cioè la disponibilità del codice sorgente, e la politica di licenza assolutamente non onerosa (royalty-free).
Queste due caratteristiche degli Rtos free ultimamente non rappresentano una esclusiva di questi. Anche gli Rtos proprietari hanno iniziato a rendere disponibile il codice sorgente e a mitigare la politica di rilascio della licenza e di imposizione delle royalties. Ovviamente quest'evoluzione non coinvolge tutti gli Rtos proprietari, ma si tratta di una tendenza in atto favorita dalla collaborazione tra i produttori di Rtos e i produttori di microcontrollori, i primi interessati a spingere per l'uso del proprio Rtos, i secondi per incentivare la scelta del proprio microcontrollore. Lo sviluppatore, soprattutto se nelle condizioni di scelta di un nuovo microcontrollore per le proprie necessità di progettazione, deve porre particolare attenzione a questa opportunità che può semplificare in maniera sostanziale la scelta del Rtos.
