RealOS è un sistema operativo real-time che risponde alle specifiche ITRON e T-Kernel ed è particolarmente indicato per le applicazioni dove sono richiesti precisi vincoli in termini di safety del sistema.
Fujitsu Semiconductor è una società che ricopre una posizione di primaria importanza nel segmento delle soluzioni automotive tanto da conseguire il secondo livello di Spice per la maturità della sua tecnologia, in particolare di quella software, per il settore automobilistico. In effetti, questo riconoscimento rappresenta per Fujitsu Semiconductor Europe un formale atto di valutazione che si esprime in base all’Automotive SPICE HIS Scope con l’esclusione dell’ACQ.4. La società, infatti, con il suo cuore pulsante in Asia, è attualmente uno dei maggiori fornitori di prodotti a semiconduttori, insieme alle sue piattaforme software, per un segmento tanto particolare anche per via delle implicazioni, in termini di safety, coinvolte.
Fujitsu Semiconductor non offre solo realizzazioni hardware integrabili in un generico sistema ma è anche, soprattutto per le esigenze di safety, un fornitore di tecnologie software. In particolare, la società asiatica fornisce un sistema operativo real-time per lo sviluppo di software per microcontrollori Fujitsu (famiglia FR e F2MC16LX) identificato come RealOs. Secondo le specifiche diffuse dal costruttore, REALOS, o meglio la serie RealOS, è un sistema operativo realtime conforme alle specifiche ITRON e T-Kernel.
RealOS: un sistema real-time per ogni esigenza
Occorre subito precisare che Fujitsu Semiconductor con RealOs, nelle sue differenti accezioni, ha cercato di rispettare ogni particolare normativa di riferimento in un settore dove l’importanza della security e della safety ha assunto un’importanza non più trascurabile per via, in primis, della mutata esigenza sociale e per il particolare ruolo e implicazione tecnologica delle garanzie di safety. In effetti, con la versione µT-REALOS/FR, Fujitsu intende rispettare la norma di riferimento T-Kernel, ovvero il real-time operating system (RTOS) appositamente realizzato per le soluzioni da 16 e 8 bit; la piattaforma T-Kernel è seguito da T-Engine Forum anche attraverso precise normative di riferimento. Questa variante permette di utilizzare fino a 32,767 task con 1,024 livelli di priorità, mentre il TCB allocato per ogni task occupa una porzione di memoria pari a 96 byte con una dimensione del codice del kernel tra 15 e i 57 KB. Così come le altre varianti, anche questa versione garantisce la presenza dei tool di lavoro REALOS configurator e REALOS analyzer con la piena disponibilità del codice sorgente. Ad ogni modo, il progresso tecnologico spinge la piattaforma T-Kernel verso T-Kernel, un sistema operativo realizzato per piattaforme da 32 bit, anch’esso standardizzato da T-Engine Forum. Proseguendo con le varianti di RealOs si scopre che con la versione RealOS/907 il sistema si presenta perfettamente compatibile con le specifiche µITRON della versione 2.0. Questa variante è abbastanza contenuta tanto da essere così utilizzata su dispositivi da 16 bit, ossia famiglia F2NC-16LX, con potenzialità inferiori rispetto alle altre versioni; in effetti, ad esempio, questa versione rende possibile all’applicazione la gestione fino a 255 task con 16 livelli di priorità e utilizza un Task Control Block, TCB, di soli 21 byte con un’occupazione tra 0.8 e 5.7 KB. Questa variante permette di utilizzare gli stessi tool per lo sviluppo della versione precedente, oltre alla caratteristica di offrire il codice sorgente del kernel all’acquirente. Al contrario, con la versione RealOS/FR il costruttore assicura la perfetta aderenza verso la versione 3.0 di µITRON assicurando, nel frattempo, la presenza di diversi moduli operativi inclusi Fixed-size memorypool o variable-size memorypool con un numero di 32,767 task con 32 livelli di priorità ed un Task Control Block (TCB) di 44 byte e una dimensione del codice tra 2,7 e 8,3 Kb. Non solo, Fujitsu suggerisce anche la variante REALOS/FR Spec. 4 con il pieno supporto di µITRON nella versione 4.0, con la possibilità di supportare le funzionalità di “Dynamic generation of objects” (allocazione e gestione dinamica della memoria), le politiche di Mutex, Fixed-size memorypool, Variable-size memorypool e di un sottoinsieme di funzionalità legate al power-saving del processore. Questa variante permette le gestione di 76 byte del TCB, o task control block, con una dimensione del codice tra 11 e 44 Kb e con la possibilità di gestire fino a 32,767 task con 1,024 livelli di priorità. È utile ricordare che, se non espressamente specificato, le ultime realizzazioni possono tranquillamente lavorare con processori della serie FR di Fujitsu Semiconductor. Infine, la suite, se così si può chiamare, si conclude con la variante REALOS/FRV basata su µITRON 4.0, in grado di supportare i processori della linea FR-V. Questa particolare variante assicura la presenza del modulo funzionale Dynamic generation of objects, le politiche di Mutex e, come nella variante precedente, del Fixed-size memory-pool, Variable-size memorypool e di un sottoinsieme di funzionalità legate al power-saving del processore. Il Task Control Block richiede una dimensione di 76 byte con la possibilità di utilizzare 32,767 task con 1,024 livelli di priorità, con una dimensione del kernel da un minimo di 20 KB fino ad un massimo di 60 KB. A questo riguardo, la tabella 1 pone in risalto le diverse proposte di casa Fujitsu del suo kernel RealOs.
Tabella 1: lista delle differenze tra le differenti versioni.
μTRON
Il tutto prende avvio dal progetto TRON, in altre parole “The Realtime Operating Nucleus”. Secondo diversi riferimenti, TRON è il sistema operativo più diffuso in ambiente embedded dove sono richiesti precisi vincoli temporali ed il pieno rispetto verso i criteri di safety e non ha nulla a che vedere con i sistemi più blasonati quali Windows, Linux o Unix. Non solo, ITRON OS è il cuore dei sistemi integrati utilizzati nell’industria dell’elettronica di consumo, ovvero, secondo l’accezione, è un tipico real-time kernel for small-scale embedded systems”. Il padre di TRON è senza dubbio il professore Ken Sakamura, docente dell’Università di Tokyo che nell’anno 1984 pensò di realizzare un sogno: definire un sistema operativo di tipo aperto che riuscisse a coniugare diversi requisisti in un unico oggetto con il fine di poter sostituire tutti gli altri. Il progetto fu sostenuto sin dall’inizio dalla TRON Association, organismo fondato nel 1988, che si occupava, attraverso gruppi di lavoro articolati, dell’aspetto della standardizzazione e dello sviluppo. Oggi tutto il lavoro è svolto dalla T-Engine project (2). Questo particolare sistema operativo real-time aperto è, di fatto, un punto di riferimento delle aziende giapponesi tanto da essere utilizzato per realizzare la quasi totalità delle applicazioni del Sol Levante. L’idea di Sakamura è quello di creare un sistema di tipo distribuito, presente in ogni applicazione reale, al fine di assicurare un costante dialogo per ottimizzare il carico di lavoro tra i diversi dispositivi hardware presenti. La chiave di volta del progetto, tanto da influire in maniera diretta sul suo successo, è stata la sua architettura aperta, prestazioni non trascurabili e una ricaduta diretta sul versante industriale: l’industria giapponese è riuscita così a realizzare un prodotto senza dover anche garantire l’interoperabilità tra diverse piattaforme. ITRON si presenta sul mercato come una soluzione aperta di tipo real-time e si pone in diretta concorrenza alle varianti real-time di Linux con tempi di switch tra task ridotti al minimo grazie anche, e soprattutto, alle nuove piattaforme hardware. Non solo, rispetto a Linux, ITRON si offre con una dimensione di solo qualche decina di Kbyte, mentre Linux occupa una dimensione più rilevante. Le altre aziende, al fine di contrastare questa iniziativa e in modo particolare quelle USA, hanno sempre cercato di contrastare questo progetto, proponendo il loro T-Linux, una estensione del kernel di MontaVista, anche se poi l’idea futuribile è quella di utilizzare chip in grado di utilizzare, a seconda dell’esigenza, Linux o ITRON.
T-Kernel
T-Kernel/OS (Operating System), si veda la figura 3, rappresenta un’altra proposta del settore o, se si preferisce, è l’evoluzione delle macchine a 16 bit verso soluzioni a 32 bit. In effetti, con questo particolare sistema operativo embedded è possibile creare meccanismi di coordinamento e gestione per la presenza dell’unità concettuale di esecuzione denominata ‘task management’. Infatti con T-Kernel è possibile creare o eliminare task dal nostro sistema , attivarli o cancellarli dalla coda di esecuzione o dal sistema oltre a influire sulla loro priorità. Non solo: l’ambiente T-Kernel è veramente completo tanto da offrire anche funzioni per la sincronizzazione e la comunicazione tra processi, o la possibilità di intervenire sullo stato di un task: da Run a Wait o da Wait a Ready, come pone in evidenza la figura 1.
Figura 1: l’ambiente T-Kernel offre anche funzioni per la sincronizzazione e la comunicazione tra processi, o la possibilità di intervenire sullo stato di un task da Run a Wait o da Wait a Ready.
Dalla figura si mostrano le differenti interfacce software utilizzate e presenti nel sistema, utilizzate per pilotare i cambiamenti di stato. In effetti, con la chiamata alla funzione software tk_ter_tsk si forza il task a terminare cambiando il suo stato interno togliendolo dalla coda dei task ready. In T-Kernel, un task è un’unità logica di programma in esecuzione concorrente: programmi assegnati a task differenti possono essere eseguiti in concorrenza sulla CPU. L’idea, quindi, non si discosta dall’idea tradizionale di un sistema multitasking commerciale. I task si possono trovare, in ogni istante, in uno e uno solo di questi stati: Run, Ready, Wait, Suspend, Wait-Suspended, Dormant, Non-Existent. A questo riguardo nella tabella 2 si mostrano le possibili transizioni di stato, così come riportato dalla specifica di riferimento del kernel.
Tabella 2: transizioni di stato ammesse
In T-Kernel si realizza una politica di scheduling di tipo preemptive basato su priorità: il livello di priorità è assegnato dal programmatore nel momento della creazione di un task. Lo scheduler ha il compito di selezionare il task da mandare in esecuzione tra i diversi task che si trovano in uno stato RUN o READY al momento del cambio di contesto. Al fine di discriminare il task che ha diritto ad essere messo in esecuzione, occorre definire un preciso criterio di precedenza. In effetti, in questo senso, lo scheduler adotta le seguenti regole: se due task hanno differenti livelli di priorità, quello con priorità maggiore ha la precedenza sull’altro, ma se due task hanno lo stesso livello di priorità, allora quello che consegue lo stato di Run o Ready per primo ha la precedenza sull’altro (in questo caso si adotta la politica FCFS, ossia il primo task arrivato è il primo ad essere servito). La figura 2 mostra l’ordine di esecuzione dei task in un caso iniziale, dove i task B, C e D hanno la stessa priorità: in questo caso, come la figura pone in evidenza, il task A, quello che possiede la priorità maggiore, sarà messo in esecuzione e, alla sua timeline, saranno posti in esecuzione, con una certa gradualità, gli altri task. Come nella maggior parte delle politiche di schedulazione, quando il task ha un livello di priorità maggiori degli altri in stato di Run, gli altri task che si trovano nello stato di Ready non possono essere messi in esecuzione. Attualmente T-Kernel è giunto alla versione 2.0 ed offre, oltre alle tradizionali interfacce per la gestione ed il controllo dei task, anche la possibilità di gestire un monitor con funzionalità di debugger.
Figura 2: ordine di esecuzione dove i task B, C e D hanno la stessa priorità: il task A, con priorità maggiore, sarà messo in esecuzione e, alla sua timeline, saranno posti in esecuzione, con una certa gradualità, gli altri task.
Figura 3: struttura del kernel.
