I processori embedded sono diventati dispositivi complessi e potenti, spesso in grado di soddisfare diversi requisiti in un package dalle dimensioni ridotte. Poiché le applicazioni diventano sempre più complesse, gli ingegneri devono tenere il passo per gestire il conseguente aumento della complessità del software. Nelle applicazioni industriali, questo software viene spesso utilizzato per molti anni (se non decenni) e la gestione delle applicazioni embedded durante il loro intero ciclo di vita rappresenta qualcosa della massima importanza.
Scopri i problemi più comuni e le soluzioni migliori per le applicazioni tipiche dei sistemi operativi in tempo reale (RTOS) embedded, oltre ai problemi di standardizzazione del codice RTOS nelle applicazioni.
Tutti i progetti che necessitano di software di un certo livello, indipendentemente dal fatto che si basino o meno su un RTOS, hanno dei problemi in comune.
Alcuni di questi problemi possono riguardare la gestione di un sistema nell’ottica di un ciclo di vita, oppure sulla portabilità di un determinato software e un’interfaccia di controllo che permetta una facile interazione con il sistema.
Questo articolo tratta alcuni tra i problemi più comuni e i compiti principali che deve essere in grado di gestire un RTOS, oltre ad analizzare la necessità di una standardizzazione e la riusabilità dei software per sistemi embedded.
Sfide che richiedono tempo
Quasi tutti i progetti che includono dei software complessi, richiedono un sistema di compilazione affidabile, indipendentemente dal tipo di soluzione adottata. Mantenere operativo ed aggiornato un sistema complesso durante l’intero ciclo di vita di un’applicazione non è un compito semplice. Aggiornamenti e modifiche apparentemente di poco conto possono portare rapidamente ad infinite ricerche di errori.
Aggiornamenti di software e moduli
Senza uno strumento di gestione dei repository, gli sviluppatori non devono soltanto verificare la presenza di aggiornamenti del nucleo principale dell’RTOS, ma devono anche andare a caccia di ogni singolo cambiamento che riguarda ogni singolo modulo esterno utilizzato nei loro progetti.
Tuttavia, è essenziale tenere presente che alcuni moduli dipendono o si basano su librerie e moduli esterni, di cui gli sviluppatori devono controllare gli aggiornamenti. Gli aggiornamenti mancanti in questi moduli secondari possono potenzialmente portare all’interruzione del funzionamento del sistema e generare degli errori.
Un repository o uno strumento di gestione delle dipendenze permette agli ingegneri di risparmiare molto tempo.
Porting multipiattaforma
Il porting di un software da un dispositivo all’altro può diventare una procedura complicata e laboriosa. Anche se gli ingegneri decidono di utilizzare diversi sistemi dello stesso produttore, il processo può comportare molte operazioni di riconfigurazione che richiedono comunque molto tempo. Inoltre alcune correzioni e implementazioni potrebbero funzionare su un sistema mentre non funzionare quando si utilizzate con un hardware diverso da quello originale.
Prendendo come esempio un programma che scrive dei valori nella memoria flash di un sistema, nel progetto originale, gli ingegneri potrebbero aver utilizzato un determinato microcontrollore (MCU) con una memoria flash on-chip. Tuttavia, a causa della scarsità di forniture, il team di progettazione potrebbe dover cambiare la MCU, con una senza memoria flash integrata ed un modulo di memoria flash esterno.
Poiché il software contiene codice specifico per l’hardware per l’accesso alla memoria flash on-chip, il team non è in grado di fare facilmente il porting del software sulla nuova piattaforma MCU senza prima riprogettare gran parte del codice.
Ciò può portare rapidamente all’ottenimento di più versioni di codice simili ma per dispositivi diversi, con conseguenti problemi ancor più gravi.
Logging dello stato e degli errori
In genere i sistemi più complessi richiedono il salvataggio di errori e dello stato al fine di poter eseguire il debug. Tuttavia, queste funzioni non sono sempre intrinseche dell’RTOS e gli sviluppatori devono implementarle. È importante che le implementazioni personalizzate garantiscano la sicurezza dei thread e per questo motivo devono essere testate prima di essere incluse nella versione operativa del software.
Alcune soluzioni RTOS
Alla luce dei problemi e dei requisiti discussi in precedenza, molti RTOS convenzionali offrono uno scheduler in real-time, un supporto alla sincronizzazione e delle funzioni di gestione delle memorie. Di seguito, esaminiamo alcune opzioni popolari (FreeRTOS, Azure RTOS e Zephyr OS) e i loro potenziali vantaggi e svantaggi.
FreeRTOS
FreeRTOS è nato come un semplice kernel in real-time che prevedeva thread, meccanismi di sincronizzazione e di allocazione della memoria. Grazie alla sua leggerezza, il progetto si è rivelato interessante per diverse applicazioni embedded. Al momento della pubblicazione di questo articolo, il progetto è gestito da Amazon. Gli sviluppatori si concentrano sull’aggiunta di ulteriori integrazioni di servizi cloud, come il supporto per il core Amazon IoT e altri servizi AWS. La licenza MIT assicura che FreeRTOS rimanga libero.
Il leggero core scheduler di FreeRTOS è facile da integrare nei progetti e il sistema operativo è ancora oggi tra i più popolari RTOS. Tuttavia, a differenza di ThreadX, FreeRTOS non è stato progettato per essere utilizzato con sistemi critici per la sicurezza.
Per tali sistemi, gli ingegneri dovranno ricorrere a un prodotto con licenza commerciale chiamato SafeRTOS.
Azure RTOS
Microsoft Azure RTOS, precedentemente noto come ThreadX, è un’alternativa a FreeRTOS. Complessivamente, Azure RTOS garantisce migliori funzionalità hard real-time rispetto a FreeRTOS ed è anche conforme a vari standard di sicurezza. Tuttavia, ci sono alcuni problemi generali che nessuna delle due opzioni riesce a risolvere in modo efficiente.
Un problema è rappresentato dal fatto che sia FreeRTOS che Azure OS sono stati acquisiti da grandi aziende che ne determineranno il futuro. Dal momento che Amazon e Microsoft offrono servizi cloud proprietari, probabilmente renderanno più facile per gli sviluppatori connettersi ai loro specifici servizi di cloud. Tuttavia, le aziende potrebbero cercare di rendere più complicata per gli sviluppatori l’integrazione di un servizio cloud diverso.
Zephyr OS
Zephyr OS è invece un progetto relativamente nuovo nel segmento RTOS che mira a risolvere il problema sopra menzionato. Introduce parti standardizzate che gli sviluppatori possono utilizzare in diversi progetti su varie piattaforme supportate con uno sforzo di riconfigurazione minimo.
Zephyr OS è un progetto open-source gestito dalla comunità che offre soluzioni indipendenti dai fornitori che gli ingegneri possono utilizzare senza dover pagare le licenze.
Grazie alla natura open-source e l’indipendenza dai fornitori del progetto, è improbabile che una singola azienda faccia collidere l’integrazione di Zephyr OS con altri prodotti e servizi.
Il codice sorgente di Zephyr OS, disponibile pubblicamente, e l’ampia documentazione online assicurano inoltre che gli ingegneri embedded possano apprendere tutti i dettagli su Zephyr di cui hanno bisogno, senza dover effettuare il reverse engineering di alcun file sorgente.
I progetti open-source gestiti da molti sviluppatori spesso presentano implementazioni di sicurezza migliori rispetto alle soluzioni interamente closed-source: praticamente qualsiasi sviluppatore e azienda può aggiungere il supporto per nuove architetture e hardware.
Portare i RTOS al livello successivo
In questo articolo sono stati esaminati diversi problemi generali legati all’uso dei tradizionali RTOS embedded. In primo luogo, la gestione di un prodotto software durante il suo intero ciclo di vita non è un compito banale.
I problemi iniziano con la manutenzione e l’aggiornamento delle librerie esterne ufficiali e di terze parti. Gli sviluppatori devono spesso tenere traccia degli aggiornamenti apportati a tali librerie. L’aggiornamento di queste librerie di riferimento comporta sempre un rischio, in quanto può portare a dipendenze non valide o interrotte e a incompatibilità di versione.
I problemi di sicurezza e le potenziali vulnerabilità riguardano praticamente ogni sistema software di grandi dimensioni e i sistemi operativi in tempo reale non fanno eccezione.
Anche i protocolli e i prodotti più consolidati possono essere compromessi, anche dopo molti anni di funzionamento ottimale. Tuttavia, i prodotti software proprietari e a codice chiuso sono più a rischio, poiché un numero minore di sviluppatori può ispezionare il codice e testarne la sicurezza.
Articolo originale: https://www.allaboutcircuits.com/industry-articles/finding-solutions-for-real-time-embedded-software-development/
