Un Real Time Operating System (RTOS) è una categoria di sistemi operativi caratterizzata da un tempo di risposta ben definito, deterministico. Questo vuol dire che in un sistema real-time sono ben determinati il suo tempo
massimo ed il suo tempo minimo di risposta, ovvero rispettivamente il worst/best case.
Questa peculiarità dei sistemi real-time viene raggiunta solo sotto certe condizioni:
Deve essere noto il numero di task in esecuzione sul sistema
Deve essere noto, per ogni task in esecuzione, il suo tempo massimo di completamento, anche detto “deadline”, superato il quale il sistema comincia a degradarsi in termini di tempi di risposta
Lo scheduler del sistema deve essere sviluppato in modo tale da far rispettare ad ogni task la sua deadline, cosicché il sistema possa essere sempre un sistema real-time
Nei sistemi RTOS, task è il sinonimo di processo in esecuzione; ci possono essere principalmente due tipologie di task:
Soft real-time - è un task che, qualora non rispettasse la sua deadline, provocherebbe una perdita graduale dell’efficacia del sistema ma comunque un danno recuperabile
Hard real-time – è un task che, qualora non rispettasse la sua deadline, provocherebbe un danno irreversibile al sistema
In base alla generale classificazione appena enunciata, si possono definire due classi di sistemi real-time:
Soft real-time – un sistema si definisce “soft” se garantisce la fattibilità di schedulazione di soli task soft real-time
Hard real-time – un sistema si definisce “hard” se garantisce la fattibilità di schedulazione di task hard e soft real-time
Quindi, un sistema operativo real-time risponderà in un certo intervallo di tempo predeterminato, non importa quanto sia veloce, quanto il fatto che rispetti questa condizione. I sistemi operativi real-time, infatti, sono usati in ambito industriale, sono impiegati nel controllo di robot o più in generale
sono usati in quei campi in cui si ha bisogno di una nota e costante rapidità di risposta del sistema agli stimoli esterni.
Per esempio, un BMS, che ha da acquisire tutte le informazioni sullo stato della batteria in maniera periodica e deve elaborarle per poi andare ad effettuare un controllo sulla gestione della stessa, è un’applicazione tipica per un sistema real-time.
In particolare, i dati che raccoglie un BMS per elaborare lo stato della batteria sono diversi e di varia natura, quindi generalmente provenienti da periferiche hardware differenti. Dunque, un BMS avrà la necessità di essere gestito da un sistema che, in maniera indipendente, acquisisce i dati su tensioni di cella, temperatura e corrente di batteria e poi, successivamente, li elabora per ottenere lo stato globale della batteria. Per soddisfare a queste richieste, sarà necessario l’uso di un sistema di elaborazione basato su sistema operativo RTOS, così da poter gestire separatamente le varie acquisizioni con task diversi ed avere la possibilità di ampliare in maniera semplice e veloce le funzionalità dell’intero sistema.
Per il progetto PROTONE, il firmware del BMS è stato basato sul sistema operativo real-time FreeRTOS. La scelta è stata orientata dal fatto che il sistema operativo in questione è disponibile gratuitamente ed è open-source, il che è in linea con la filosofia dell’intero progetto. Inoltre, è un sistema molto consolidato, affidabile e di semplice utilizzo. Nel paragrafo seguente verrà esaminato più nel dettaglio.
Il FreeRTOS
Il FreeRTOS è un kernel in tempo reale sviluppato appositamente per piccoli sistemi embedded ed ha numerose funzionalità e punti di forza.
Il suo progetto è nato dall’ingegnere informatico Richard Barry intorno al 2003 ed è stato poi portato avanti dalla sua azienda, la Real Time Engineers Ltd. Che, nel 2017 è stata acquisita dalla società Amazon Web Services.
L’obiettivo alla base della sua progettazione è stato quello di realizzare un sistema operativo per applicazioni real-time facile da usare, gratuito, totalmente open source e che potesse offrire una serie di funzionalità almeno equivalenti alle alternative commerciali.
Oggi il FreeRTOS è un sistema stabile, ampiamente diffuso, con un numero altissimo di download e la community dei suoi utenti è in aumento. Esso supporta ufficialmente più di 30 architetture diverse di microcontrollori e dispone di una versione commerciale, l’OpenRTOS, che offre in più un supporto di garanzia ed una protezione legale.
Entrando più nel dettaglio delle potenzialità di questo RTOS, il kernel FreeRTOS è un sistema multitask che permette lo svolgimento di molteplici attività in parallelo. Ha un’impronta di memoria estremamente piccola, infatti occupa uno spazio di ROM che varia tra 4 Kbyte e 9 Kbyte a seconda del compilatore e del microcontrollore utilizzato. Lo scheduler è di tipo Round Robin con time-slicing: è possibile assegnare ad ogni task un livello di priorità, non necessariamente univoco, ed inoltre lo scheduler è di tipo “preemptive” con un quanto di tempo configurabile che definisce un riferimento temporale per l’intero sistema. Tutto il codice sorgente è stato scritto in C per massimizzarne la sua portabilità: in alcuni casi addirittura è stata privilegiata la scelta di un completo sorgente C a discapito di piccoli ritardi di CPU introdotti a causa della non perfetta ottimizzazione di questo linguaggio. È possibile creare code, semafori contatori, semafori binari per la sincronizzazione dei task e per la loro comunicazione, semafori ricorsivi e mutex per la gestione della mutua esclusione della memoria condivisa.
Dopo una rapida carrellata della storia e delle principali caratteristiche di questo kernel RTOS andiamo a vedere le principali API messe a disposizione per il programmatore.
Le principali API
Come abbiamo già detto, essendo un RTOS che supporta il multitasking, sono disponibili delle funzioni di gestione e controllo delle attività del sistema operativo con le quali è possibile creare, controllare, sincronizzare i task. La xTaskCreate è utilizzata per creare un task che esegue un certo codice, che avrà a disposizione una definita quantità di memoria RAM ed una priorità: ognuna di queste informazioni è passata alla funzione durante la sua chiamata. Al contrario, la vTaskDelete viene utilizzata per eliminare un task. Altre funzioni come la vTaskSuspend, o la vTaskResume hanno lo scopo di alterare in maniera forzata l’esecuzione di un task: la prima, ad esempio, sospende il task impedendogli di essere eseguito anche se le sue condizioni glielo permettevano; la seconda, invece, riesuma un task che in precedenza era stato mandato in sospensione tramite la chiamata della prima.
Di seguito in fig. 34 rappresentiamo con un grafico gli stati che possono assumere i task in questo sistema operativo.
Fig. 34 - Grafico di transizione degli stati assumibili dai task nel FreeRTOS
Altre funzioni, come la vTaskDelay o la vTaskDelayUntil, vengono utilizzate per creare dei ritardi o per garantire una certa temporizzazione di un task. Come abbiamo già detto precedentemente, un problema importante è la gestione della memoria condivisa tra più attività e la soluzione più efficace è quella che prevede l’impiego dei semafori: il FreeRTOS ha una sezione di API dedicata all’utilizzo dei semafori e ne mette a disposizione di molti tipi diversi. Il più utile ed indicato per tale impiego è il mutex, un semaforo che ha un numero limitato di valori {0, 1} e con due funzioni con cui è possibile acquisirlo o rilasciarlo. È possibile creare un mutex tramite la funzione xSemaphoreCreateMutex, è possibile cancellarlo con la vSemaphoreDelete ed è possibile acquisirlo e rilasciarlo con due funzioni apposite, rispettivamente la xSemaphoreTake e la xSemaphore Give. Inoltre, è possibile acquisire un semaforo andando a specificare un timeout, come multiplo intero del tick di sistema, raggiunto il quale il semaforo viene automaticamente rilasciato: questo garantisce che un task non resti eternamente bloccato su un semaforo che è stato acquisito da un altro task ma che, per qualche motivo, non è stato rilasciato. Created Ready Running Terminated Blocked Interruzione Schedulazione Evento sbloccante API bloccanti vTaskCreate Suspended vTaskDelate vTaskSuspend vTaskSuspend vTaskSuspend
Per questo progetto di tesi è stato necessario utilizzare le code. In informatica una coda è una serie di oggetti allocati dinamicamente in memoria ed indirizzati in maniera sequenziale: un oggetto contiene un puntatore al suo successivo ed è puntato dal suo precedente. Il kernel FreeRTOS implementa anche una gestione completa di questo strumento software che, essendo molto delicato ma molto potente, è gestito accuratamente dalle sue API. Si possono creare code di N elementi ed è possibile specificare la dimensione di ogni elemento della coda tramite la funzione xQueueCreate. È possibile inserire o estrarre un elemento da una coda con le funzioni xQueueSend e xQueueReceive. Inoltre, si possono conoscere altre informazioni sulla coda, come ad esempio quanto spazio disponibile rimane tramite la funzione uxQueueSpacesAvailable, oppure un gestore d’interruzione (ISR) può invocare la xQueueIsQueueEmptyFromISR o la xQueueIsQueueFullFromISR per sapere se una coda è rispettivamente vuota o piena. Abbiamo appena fatto una carrellata delle principali API che vengono utilizzate in questo progetto ma per l’elenco completo di tutte le API disponibili e per una loro descrizione dettagliata si rimanda al sito ufficiale del sistema operativo [16].
Capitolo 5
Il software di controllo del
BMS per PROTONE
Dopo aver fatto una introduzione generale sul mondo della mobilità elettrica e sul perché sia molto importante sviluppare nuove applicazioni nel settore dell’energia elettrica, abbiamo visto quali sono le specifiche della batteria di Aurora e quali sono le specifiche del BMS per PROTONE che dovrà monitorarne lo stato. Questo lavoro di tesi si è focalizzato sull’implementazione in firmware delle funzionalità della String Management Unit. Le funzionalità di trasmissione dei comandi da parte della PMU sono state emulate da un’interfaccia creata con LABview, un software della National Instrumens, che gira su un PC. Inoltre, per poter effettuare il debug e la fase di test finale delle funzionalità della SMU, tutti i suoi dati vengono trasmessi via CAN-bus esterno all’interfaccia LABview, che li raccoglie, li rende facilmente visibili e li salva in un file di log. Quest’ultimo può essere analizzato ed elaborato con uno script Matlab, che consente di visualizzare con dei grafici l’andamento temporale dei dati raccolti, per poter fare le considerazioni finali sui risultati ottenuti.
La struttura del software di controllo si basa su di un task principale, chiamato task main, che si occupa dell’organizzazione delle attività dell’intera SMU e della loro temporizzazione, garantendo la massima produttività del sistema.
Adesso andiamo in dettaglio ad analizzare il firmware in tutte le sue parti, mettendo in luce il lavoro che è stato fatto in ogni task per il raggiungimento degli obiettivi prefissati.