I sistemi embedded raggiungono complessità funzionali molto elevate soprattutto quando sono basati su core processor ad altissima integrazione come quelli della famiglia Arm. Lo sviluppatore di sistemi embedded si trova oggi di fronte a un’elevata complessità funzionale e una serie di requisiti applicativi che richiedono lo sviluppo del cosiddetto software e firmware di sistema, nonché a garantire comportamenti deterministici e real-time. A parte la possibilità di sviluppare software ad hoc per il sistema embedded di tipo cosiddetto “bare metal”, l’alternativa è quella di adottare un sistema operativo Rtos (Real-time operating system) che offre, attraverso librerie e supporto tecnico, in particolare il cosiddetto Bsp (Board support package) che consente allo sviluppatore di accelerare in maniera enorme lo sviluppo del sistema, sia a livello software che a livello hardware. Lo sviluppo ad hoc del software e del firmware di sistema è estremamente impegnativo e oneroso in termini di risorse umane, normalmente già ampiamente impegnate nello sviluppo del sistema embedded stesso. Sistemi complessi, come ad esempio lo smarthphone, senza un sistema operativo sarebbero difficili da configurare in termini applicativi, e non a caso sono stati sviluppati sistemi operativi o con caratteristiche compatibili con la natura embedded di un sistema di comunicazione ad elevato contenuto multimediale e un elevato orientamento all’interazione gestuale tramite dispositivi sensoriali ed operatività real-time, cioè i Rtos. I sistemi operativi per le applicazioni embedded si distinguono dai sistemi operativi classici in quanto garantiscono i requisiti tipici dei sistemi embedded: ridotto ingombro, prestazioni real-time deterministiche, basso costo. I Rtos in alcuni casi sono stati sviluppati appositamente per soddisfare i requisiti applicativi dei sistemi embedded in varie aree applicative come l’automazione industriale, l’automotive, le comunicazioni, il medicale, ecc. In Altri casi sono stati derivati da kernel di sistemi operativi preesistenti non Rtos e noti agli sviluppatori in altri contesti applicativi non embedded. WindRiver è stato uno dei primi sviluppatori di Rtos orientati ai sistemi embedded con il sistema operativo VxWorks dotato di un supporto esteso per le applicazioni embedded di Internet. Mentor Graphics, particolarmente attenta al mondo embedded dell’automotive, ha sviluppato invece Nucleus Rtos.
Rtos in automotive
L’automotive è un ambito applicativo di natura embedded con requisiti molto stringenti. VxWorks di WindRiver è particolarmente apprezzato per le sue caratteristiche di modularità, scalabilità, sicurezza. In particolare VxWorks Plus, mantenendo le principali peculiarità di VxWorks, ne esalta le capacità aggiungendo una serie di caratteristiche middleware e di supporto allo sviluppo in ambito industriale embedded. Oltre al kernel di un Rtos lo sviluppatore necessita di altri strumenti collegai al Rtos allo scopo di rendere efficiente ed efficace lo sviluppo finale del sistema embedded. WindRiver propone allo sviluppatore un workbench, cioè un ambiente integrato per monitorare e correggere il codice per anticipare i possibili malfunzionamenti. Il workbench è basato su Eclipse. La sicurezza è una delle funzionalità che nei sistemi embedded sta assumendo sempre maggiore importanza, soprattutto quando le applicazioni coinvolgono Internet nella sua versione più evoluta, l’Internet of Things. Nel caso di VxWorks Plus il profilo safety si concretizza tramite capabilities di time-partitioning e il consolidamento di applicazioni con differenti livelli di criticità su una singola piattaforma o su multicore.
Sicurezza per l’automotive
La sicurezza, oltre che in ambito IoT, è in primo piano anche nel contesto applicativo embedded dell’automotive, soprattutto per l’emergente tecnologie Adas. Mentor Automotive Safety è un’architettura software implementata su multicore e su single core di natura system-on-chip e si caratterizza per una elevata velocità di boot. Queste nuove soluzioni di natura software di sistema vanno a soddisfare problematiche chiave cui devono confrontarsi gli sviluppatori Oem in ambito automotive: cioè, come migrare informazioni critiche in termini di sicurezza verso i complessi cluster di strumentazione digitale soddisfacendo gli standard di sicurezza (per esempio lo standard Iso 26262). Gli Oem in ambito automotive devono sviluppare cluster di strumenti digitali che trattano informazioni grafiche relative ad avvisi diretti al guidatore concernenti lo stato dei freni, dei pneumatici, del motore, attraverso icone o grafica 3D avanzata. Questo tipo di software consente di gestire la visualizzazione di informazioni critiche e non critiche contemporaneamente sullo stesso display, soddisfacendo gli standard di sicurezza. Il vantaggio che ne deriva è in termini di costi e di complessità del sistema embedded, nonché di uso efficiente delle risorse (soprattutto quelle di Cpu).
Rtos e middleware
Altri produttori di strumenti di sviluppo embedded come Segger offrono software (middleware) per sistemi embedded. Questi strumenti soddisfano in maniera più leggera la richiesta di software di sistema Rtos da parte degli sviluppatori che programmano in Ansi C. Il middleware è l’insieme dei programmi che svolgono la funzione di intermediazione tra applicazioni e componenti diversi tra loro di un sistema embedded. In parte contenuto nel Rtos, il middleware è l’emblematica dimostrazione della importanza del software di sistema caratterizzato per la natura del sistema embedded a supporto dello sviluppatore orientato a contesti applicativi distribuiti. Segger ha portato questa integrazione nel suo Rtos embOS, un sistema operativo real-time priority-controlled pensato per essere alla base della progettazione dei sistemi embedded real-time. Si caratterizza per essere zero-interrupt latency, e per richiedere un’occupazione di memoria minima, sia a livello di Ram che di Rom. embOS tiene conto delle risorse limitate tipiche dei processori alla base dei sistemi embedded, i microcontrollori, pur essendo compatibile con svariate piattaforme da 8 fino a 32 bit. È altamente modulare e ottimizzato in quanto garantisce che solo le funzioni necessarie vengano integrate nel codice finale. Tutte queste caratteristiche e la connotazione middleware consentono l’applicazione in contesti come i sistemi alimentati a batteria, i sistemi basati su singoli chip e con requisiti di risposta ultraveloce, la strumentazione industriale, i componenti medicali, ecc. embOS è disponibile come libreria di funzioni di OS o come codice sorgente. La versione codice sorgente è un insieme di librerie fornite in codice sorgente. È disponibile anche un Bsp e un ambiente denominato embOSView. Le librerie, pur offrendo comunque la funzionalità completa, non consentono il source-level debug sulle routine e sul kernel.
