Negli ultimi cinque anni, il Progetto Zephyr™ ha sviluppato un sistema operativo in tempo reale (RTOS) multi-thread open-source per sistemi embedded.
RTOS supporta attualmente oltre 200 schede con microcontrollori embedded basati su architettura ARM, RISC-V, Tensilica, NIOS e ARC, sia a single-core che multi-core, e connettività wireless con Bluetooth Low Energy, Wi-Fi e 802.15.4 Matter (ex-Zigbee), oltre a standard come 6LoWPAN, CoAP, Ethernet, USB, CAN e Thread. I Board Support Package comprendono librerie che rendono semplice far girare il sistema operativo sulla propria scheda.
Un aspetto importante del Progetto Zephyr è che il sistema operativo real-time è stato progettato pensando alla sicurezza e alla celerità ed efficienza dello sviluppo. Parte di The Linux Foundation®, il progetto è supportato da un team per l’assistenza sui problemi con il prodotto. Il codice è scritto in modo da risultare verificabile nell'ottica delle certificazioni di sicurezza, e di un'assistenza a lungo termine con aggiornamenti di sicurezza.
Tutto questo consente una connessione veloce e sicura a qualsiasi servizio cloud con un'ampia scelta di processori e schede per i mercati industriale, automotive, smart city e domotica. La pandemia di Covid-19 ha aumentato la domanda per dispositivi indossabili per il tracciamento dei contatti, sistemi di tracciamento a distanza e persino scarpe antinfortunistiche intelligenti; sistemi di questo tipo sono stati sviluppati con Zephyr in soli tre mesi, grazie agli ingombri ridotti, agli stack integrati e all'affidabilità della piattaforma.
Uno di questi sistemi di tracciamento indossabili, dotato di più sensori, effettua il tracciamento dei contatti e invia gli eventi registrati ad un gateway, dal quale vengono poi trasferiti al cloud tramite la rete cellulare. Questo sistema rileva i contatti e individua le persone che sono entrate in contatto con un soggetto infetto.
Un altro sviluppatore ha aggiunto alle proprie scarpe intelligenti una funzione di protezione personale per avvisare il lavoratore, mediante una vibrazione, quando rischia di avvicinarsi eccessivamente a un altro soggetto. Quando il lavoratore percepisce il segnale, può scegliere di indossare la mascherina oppure allontanarsi. Un altro nuovo prodotto che utilizza Zephyr è un tracciatore che rileva la distanza fra due o più persone sul luogo di lavoro.
Anche se lo sviluppo è incentrato sulla sicurezza, si possono comunque verificare problemi, sia nel kernel di Zephyr, sia nel codice dell'applicazione. Il progetto Zephyr tiene un registro delle vulnerabilità individuate e corrette, come ad esempio la falla “BadAlloc” e altre vulnerabilità nelle librerie USB e Bluetooth, a conferma delle sfide insite nello sviluppo di un sistema embedded sicuro.
Un sistema embedded con connettività al cloud contiene una quantità rilevante di codice che implica una certa complessità. Un progetto “Hello World” con connettività AWS tramite MQTT e TLS produce un codice binario che pesa centinaia di KB. La maggior parte delle applicazioni RTOS prevede molte interazioni complesse, nelle quali è piuttosto facile riscontrare bug, incluse vulnerabilità che potrebbero essere sfruttate per accedere al dispositivo e, potenzialmente, al resto della rete. Se un sistema non è protetto, non è neanche sicuro, ed eventuali falle possono avere conseguenze disastrose su impianti industriali o sistemi medicali.
Un RTOS come Zephyr aggiunge un ulteriore livello di complessità che i progettisti embedded devono tenere in considerazione: il multi-threading. Il codice può essere diviso in thread separati che
girano autonomamente, almeno in teoria. Nella pratica, spesso vi sono dipendenze fra i thread che aumentano la complessità. Alcune sono intenzionali e necessarie, perché i thread hanno spesso bisogno di comunicare, mentre altre non sono volute e risultano talvolta problematiche. Spesso non sono evidenti nel codice sorgente ed è difficile prevede come incideranno sul comportamento run-time.
Questa sfida riguarda i microcontrollori (MCU) comunemente utilizzati nelle applicazioni IoT, perché non sempre hanno un meccanismo di protezione della memoria. Di conseguenza, i bug non vengono isolati e potrebbero compromettere una parte del sistema run-time tramite la corruzione dei dati. In aggiunta al multi-threading, a causa del quale dei thread possono bloccare l'esecuzione di un task praticamente in qualsiasi punto, e alle dipendenze tra i thread che aumentano la complessità, esiste un maggiore rischio di comportamento non deterministico, bug elusivi e vulnerabilità.
L'esecuzione deterministica è cruciale per la testabilità, la protezione e la sicurezza, e richiede che le variazioni di timing del software siano ridotte al minimo e non incidano sull'ordine di eventi importanti. In caso contrario potrebbe verificarsi un numero esorbitante di scenari di esecuzione impossibili da testare.
Mentre esistono molti metodi per verificare la sicurezza, non c'è un'unica soluzione per identificare tutte le potenziali vulnerabilità. Per garantire l'esecuzione deterministica in un RTOS è necessario analizzarne il comportamento run-time, tracciando le variazioni delle tempistiche di esecuzione e le sequenze di schedulazione del kernel e delle chiamate alle API.
Un modo per esaminare in tempo reale il comportamento di un software multi-thread che gira su RTOS Zephyr è utilizzare uno strumento di tracciamento software. Questi strumenti inseriscono hook (punti di ispezione) in zone strategiche del codice del kernel per registrare eventi e creare una traccia dell'applicazione che gira su Zephyr. Per usare questi strumenti non serve nessuna modifica manuale al codice sorgente Zephyr, è sufficiente fare il rebuild del codice abilitando gli hook.
In Zephyr 2.6.0 il sottosistema di tracciamento è stato ampliato con nuovi hook e strumenti per offrire una migliore analisi dell'esecuzione. Gli strumenti di tracciamento forniscono un riferimento temporale visuale che facilita il debugging, oltre a profilare tempi della CPU, stack e utilizzo della memoria dinamica per ciascun task. Gli strumenti di tracciamento possono inoltre rilevare le variazioni di timing e altre cause di comportamento non deterministico, per ottenere un'applicazione più stabile e testabile a beneficio dell'affidabilità, della protezione e della sicurezza.
Il tracciamento software può essere utilizzato anche per chiamate alle API e per registrare eventi definiti dall'utente, che trovano numerose applicazioni fra cui rilevamento di stalli (deadlock), perdite di memoria (leak) e buffer overflow, di sovente sfruttati per inserire malware.
L'analisi e la visualizzazione dei dati di tracciamento con strumenti avanzati (che chiamiamo diagnostica di tracciamento visuale) abilitano una sorta di "videocamera di sorveglianza" per il software embedded, grazie alla quale gli sviluppatori possono allargare l'inquadratura per ottenere una visuale complessiva sull’esecuzione, oppure “zoomare” per analizzare i dettagli. I dati di tracciamento possono così essere visualizzati da diverse prospettive e con diversi livelli di astrazione, realizzando un flusso di lavoro top-down nel quale le anomalie possono essere individuate tramite una panoramica generale e successivamente investigate attraverso viste più dettagliate.
Un aspetto chiave è che questo tipo di tracciamento può essere implementato interamente nel software, conservando gli eventi più recenti in un buffer circolare (ad anello) nella RAM di destinazione, oppure effettuando uno streaming continuo degli eventi tramite un link TCP/IP o tramite un debugger hardware (via JTAG). Ciò consente ai team di sviluppatori di monitorare il sistema su lunghi periodi di tempo e intercettare difetti anche molto rari. Il tracciamento software è applicabile praticamente a qualsiasi processore e toolchain embedded.
Conclusione
Con un RTOS concepito per uno sviluppo e una messa in esercizio rapidi ed efficienti, essere in grado di individuare potenziali problemi velocemente e facilmente è essenziale per rispettare le tempistiche di un progetto e realizzare un prodotto di alta qualità.
Affidabilità e sicurezza sono requisiti chiave per sistemi embedded. Zephyr v2.6.0 offre un supporto completo per il tracciamento software, che facilita il debugging e garantisce maggiore affidabilità, protezione e sicurezza. La diagnostica di tracciamento visuale agevola il rilevamento di un comportamento caotico e non deterministico del software, che potrebbe compromettere la testabilità e quindi celare bug e vulnerabilità elusivi.
Le informazioni dettagliate fornite dalla diagnostica visuale consentono di aumentare la produttività grazie al debugging più rapido, e di migliorare la testabilità, e quindi l'affidabilità, la protezione e la sicurezza, tutti fattori critici per il successo dei progetti di sviluppo software.
Informazioni sull'autore
Il Dott. Johan Kraft è ceo e fondatore di Percepio AB. Il Dott. Kraft è colui che per primo ha sviluppato Percepio Tracealyzer, uno strumento per la diagnostica di tracciamento visuale che consente di analizzare i sistemi runtime per accelerare lo sviluppo di software embedded. Le sue ricerche accademiche applicate, svolte in collaborazione con le aziende, sono focalizzate sull'analisi del timing del software embedded. Prima di fondare Percepio nel 2009, ha lavorato nello sviluppo di software embedded in ABB Robotics. Il Dott. Kraft è laureato in informatica.
