STUDIO COMPARATO DEI PRINCIPALI SISTEMI OPERATIVI IN TEMPO REALE

1. Università Politecnica delle Marche CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA ELETTRONICA ANNO ACCADEMICO 2005 – 2006 STUDIO COMPARATO DEI PRINCIPALI SISTEMI OPERATIVI IN TEMPO REALE Relatore: Chiar.mo Tesi di Laurea di: Prof. Aldo F. Dragoni Colella Guido

2. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

3. EVOLUZIONEDEI CALCOLATORI ELETTRONICI Introduzione ai sistemi operativi real-time

4. APPLICAZIONI DEI SISTEMI OPERATIVI REAL-TIME (1) Introduzione ai sistemi operativi real-time

5. APPLICAZIONI DEI SISTEMI OPERATIVI REAL-TIME (2) • Controllo sismico • Controllo del microclima in edifici • “Sensing” per la sicurezza e strategico • Domotica & elettronica consumer • Musei interattivi • Agricoltura intelligente • Navigazione robotica • …….e tantissime altre …e ancora : Introduzione ai sistemi operativi real-time

6. SCENARIO DI UN SISTEMA OPERATIVO REAL-TIME • All’interno di tali contesti applicativi gli RTOS (acronimo di Real-Time Operative System) si collocano come: 1. Sistemi operativi capaci di eseguire tutti i propri “tasks” senza violare specifici vincoli temporali; 2. Il tempo di esecuzione dei tasks può essere calcolato a priori e in modo deterministico sulla base della configurazione sia hardware che software del sistema; 3. Sistemi contraddistinti dal fatto che, la correttezza della risposta dipende non solo dai valori che assume l’uscita dell’elaboratore ma anche dal tempo in cui questi vengono prodotti; pertanto, il tempo del sistema deve essere necessariamente sincronizzato con il tempo dell’ambiente circostante Introduzione ai sistemi operativi real-time

7. OSSERVAZIONI SUL REAL-TIME • E’ importante sottolineare alcune caratteristiche che contraddistinguono un RTOS che spesso possono dar luogo ad equivoci o ad interpretazioni errate specie per chi si avvicina per la prima volta in tale contesto: Anzitutto, un sistema in tempo reale non è necessariamente un sistema veloce; ossia “real-time” non è sinonimo di “veloce” ; Il concetto di velocità è sempre relativo ad uno specifico ambiente; La velocità deve comunque garantire la correttezza; L’obiettivo di un RTOS è quello di garantire la tempistica di ogni singolo task, mentre l’obiettivo di un sistema veloce è quello di minimizzare il tempo medio di risposta dei vari tasks; Il tempo medio di risposta non può essere preso come un parametro significativo nel real-time; Introduzione ai sistemi operativi real-time

8. RTOS ALL’INTERNO DELLA SCALA GERARCHICA DEGLI OS • Ha delle periferiche di I/O che sono architetture di calcolatori diffuse in ambiente industriale e biomedico; • La memoria di massa non è un disco fisso bensì una memoria flash; • è un sistema “speciale” che deve solo assolvere il compito specifico per cui è stato programmato • i sistemi Real-time possono essere considerati Embedded ma non viceversa devono soddisfare precisi vincoli temporali per quel che concerne l’esecuzione dei propri tasks; devono essere caratterizzati non dalla velocità di esecuzione (parametro insignificante per il real-time), ma dalla “predicibilità”in quanto real-time non è sinonimo di “veloce” ma di “predicibile”; Introduzione ai sistemi operativi real-time

9. CAUSE DI INDETERMINISMO • Si nota che per realizzare un valido sistema real-time, bisogna cercare di “emarginare”, nella maniera più efficace possibile, o quanto meno ridurre, le cause di indeterminismo che affliggono l’esecuzione di ogni singolo task. Queste ultime possono essere di diversa natura: • Architetturiale - Cache, pipelining, interruptus, DMA; • Operativo - Scheduling, sincronizzazione, comunicazione; 3. Linguaggio - Non hanno esplicito supporto per il tempo; 4. Metodologie progettuali - Mancanza di tecniche di analisi e verifica. Introduzione ai sistemi operativi real-time

10. PREDICIBILITA’ IN FUNZIONE DELLA TIPOLOGIA DI SCHEDULER • da un’analisi superficiale potrebbe risultare che solamente scheduler ciclici garantirebbero un alto valore di predicibilità; • la scelta di uno scheduler diverso da quello ciclico, garantisce ancora predicibilità Scheduler ciclico: tasks attivati sempre in maniera predefinita Determinismo Scheduler basato sulle priorità: tasks attivati in base a priorità e ready queue, ma a livello macroscopico il comportamento può essere predetto La predicibilità è un requisito di correttezza per le applicazioni real-time Introduzione ai sistemi operativi real-time

11. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

12. PREMESSA • Per un’analisi più prolifica delle numerose famiglie di RTOS è opportuno scindere il problema alla base diversificando anzitutto almeno due tipologie implementative: Sistemi RTOS progettati appositamente che non si basano su OS già esistenti sul mercato; Sistemi RTOS ottenuti mediante l’adattamento di OS originari già esistenti sul mercato; • Per la realizzazione di tale elaborato si è fatto riferimento quasi esclusivamente alla prima tipologia implementativa, ed in particolar modo a sistemi derivanti dalla piattaforma Linux consentendo quest’ultima risorse di tipo “Open Source” ed un ottima documentazione di base. Passaggio dagli OS ai sistemi operativi di natura real-time

13. CARATERISTICHE STRUTTURALI DI LINUX OS : LO SCHEDULING • la politica del Time-sharing letteralmente “uccide” il real-time perché in quest’ultimo il tempo di esecuzione deve essere conosciuto a priori, mentre in Time-sharing non è affatto predicibile. Passaggio dagli OS ai sistemi operativi di natura real-time

14. PROBLEMATICHE PER IMPLEMENTAZIONE DI LINUX IN REAL-TIME Dati relativi al kernel 2.4 • Lo scheduler di Linux ha un taglio “general purpose”.Ciò sostanzialmente è fatto per distribuire equamente le risorse ai tasks in esecuzione; • Attualmente Linux non fornisce alcuna interfaccia per comunicare allo scheduler la possibile natura real-time di un task o dati specifici circa il suo timing (deadlines, computational times…); • Il kernel non è preemptable (ciò significa sostanzialmente alta latenza di scheduling per scenari real time); • Kernel Control Path non interrompibili( ma piuttosto reentrant, quindi annidabili) introducono in determinismo nel sistema; • Kernel non ancora 100% reentrant(alcune funzioni disabilitano gli interrupt globalmente sulla CPU corrente per preservare strutture dati condivise). Tali funzioni sono interrompibili solo attraverso un NMI; • La frequenza massima di richiamo della schedule() di Linux è 10ms(corrispondente al minimo time-quantum) che non risulta sufficiente per scenari real-time e oltretutto non vi è alcuna garanzia su tale periodo. Passaggio dagli OS ai sistemi operativi di natura real-time

15. LA LATENZA IN LINUX • Latenza di scheduling : distanza temporale tra il segnale (stimolo) di wakeup che un evento è accaduto e l’istante in cui lo scheduter lancia il thread che è in attesa che quel segnale arrivi (risposta). Interrupt latency; Interrupt Handler duration; Scheduler Latency; Scheduling duration; aumentano Response Time • Preemption patches lanciare più frequentemente la schedule(); • Low latency patches introduzione di punti di prelazione nel codice del kernel riducono Passagio dagli OS ai sistemi operativi di natura real-time

16. CON KERNEL 2.6 SI VA VERSO IL REAL TIME • Punti salienti: • Modifica della struttura generale dello scheduler (ad esempio, invece di un’unica coda per tutti i task del sistema esiste una coda per ognuno dei 140 livelli di priorità su ogni CPU); • Frequenza interna del clock portata da 100 Hz (kernel 2.4) a 1000 Hz; • Parte del kernel è divenuta preemptable; • Eliminati numerosi “Big Locks”; • Compatibilità con Preemption e Low Latency Patches; • Migliorato il sistema di gestione di I/O. • risultati: Linux 2.6.9 with Preemption patch Linux 2.6.9 without Preemption patch Passaggio dagli OS ai sistemi operativi di natura real-time

17. PREDISPOSIZIONE DI LINUX AD UNA POLITICA REAL-TIME • Linux è un sistema operativo di alto livello ed è Open Source; • E’ molto ben documentato; • Nasce nell’ambiente universitario ed è naturalmente inserito in svariati contesti di ricerca; • E’ compatibile con i maggiori standard relativi al software (POSIX etc…); • Ha buone prestazioni già in versioni base (senza modifiche strutturali); • La struttura monolitica lo rende adatto ad essere utilizzato in scenari Embedded; • Il mondo dell’industria è interessato ad applicazioni di Linux in svariati settori: GPS (Global Positioning System), HDTV (High Definition TV), DVB-RCS, cellulari, PDA, space segment, signal processing, radar system, robotica… • Sono attualmente disponibili numerose implementazioni di architetture software Open Source per modificare Linux dotandolo di funzionalità real-time da cui attingere spunto… Passaggio dagli OS ai sistemi operativi di natura real-time

18. STRATEGIE PER IL REAL-TIME IN LINUX • Esistono due possibili approcci: Il PREEMPTABLE KERNEL sostituisce gran parte del kernel di Linux Il RESURCE KERNEL gestisce il kernel di Linux come un normale task a bassa priorità Passaggio dagli OS ai sistemi operativi di natura real-time

19. PANORAMICA DEI SISTEMI OPERATIVI REAL-TIME PRESENTI SUL MERCATO: DISTRIBUZIONI COMMERCIALI • RTLinuxPro(FSMLabs). RTCore fornisce un ambiente real-time POSIX in cui Linux gira come task a bassa priorità. Limiti prestazionali: quelli dell’ hardware. Latenza di scheduling sotto 20 microsecondi sulla maggior parte delle piattaforme. • MontaVista RTLinux. Basato su miglioramenti a MontaVista Linux. Preemptable kernel + real-time scheduler + frameworks. • BlueCat RT (LynuxWorks). Microsistema operativo real-time (non Linux-based) che gira Linux come processo a bassa priorità. BlueCat RT è incentrato sulle basse latenze di interrupt raggiunte grazie al core ridottissimo e altamente performante. • uLinux (Lineo Solutions). Footprint ridottissimo, tempi di startup e shutdown minimi, prestazioni real-time rendono adatto questo OS made in Japan per l’utilizzo nell’elettronica (dispositivi embedded). • FlightLinux (NASA). Versione real-time di Linux adattata ad applicazioni spaziali al Goddard Space Flight Center e testata sullo Space Shuttle (progetto nato come Open Source ma i sorgenti non sono attualmente pubblicati). Passaggio dagli OS ai sistemi operativi di natura real-time

20. PANORAMICA DEI SISTEMI OPERATIVI REAL-TIME PRESENTI SUL MERCATO: DISTRIBUZIONI OPEN SOURCE • RTLinux. Hard Real Time mini sistema operativo che gira Linux come processo a minima priorità rendendolo totalmente preemptable. L’ultima versione supporta user-space RT programming. La versione MiniRTL è adatta ad utilizzi embedded. • RTAI (Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano). Simile ad RTLinux ma con varie funzionalità in più tra cui LXRT Layer che permette di controllare task real-time dallo user-space memory-protected di Linux . AtomicRTAI è la versione a ridotto footprint. • KURT.The Kansas University RealTime Linux. Implementazione real-time di Linux che permette lo scheduling degli eventi con periodo di 10 microsecondi. • RED-Linux. Ridotti kernel blocking times, rapidi tempi di risposta, scheduler modularizzato “modificabile” a runtime. Università della California, Irvine. • QLinux. Implementazione tagliata per garantire caratteristiche di QoS per task soft real-time. Tagliata per l’utilizzo in applicazioni multimediali, telefonia mobile… Passaggio dagli OS ai sistemi operativi di natura real-time

21. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

22. RTLINUX : UN’AGGIUNTA HARD REAL-TIME A LINUX (1) • RTLinux, sviluppato originariamente nell’Istituto di Tecnologia del New Mexico, si pone in commercio come un prodotto “open-source”. Componenti specifici di RTLinux vengono rilasciati sotto licenza GPL, mentre i componenti di Linux vengono rilasciati sotto la licenza di Linux standard. Il codice sorgente viene liberamente distribuito. Le versioni non a licenza GPL dei componenti di RTLinux sono disponibili tramite gli FSMLabs. • RTLinux è un sistema operativo hard real-time che gira in Linux come il suo thread di esecuzione a più bassa priorità. • Il thread di Linux è reso completamente prelazionabile così che i threads real-time ed i gestori di interrupts non possano venir mai ritardati da operazioni non real-time. • Le applicazioni real-time consistono in tasks real-time che sono incorporati in moduli caricabili del kernel ed in processi di Linux/Unix che si occupano dei registri dati, del display, dell’accesso alla rete, e di altre funzioni che non sono vincolate da una caratterizzazione del comportamento nel caso peggiore (worst case). Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

23. RTLINUX : UN’AGGIUNTA HARD REAL-TIME A LINUX (2) • I threads real-time in RTLinux possono comunicare con i processi Linux attraverso una memoria condivisa oppure mediante una particolare interfaccia simile ad un file in tal modo le applicazioni real-time possono far uso di tutti i potenti servizi non real-time di Linux (incluso Networking, Grafica, Sistemi Windowing, Packages per l’analisi dei dati, Drivers per Linux, standard POSIX API). • Per esempio è piuttosto semplice comporre uno script che visualizzi dati in Xwindows, risponda a comandi trasmessi da rete e collezioni dati da un task real-time. • In pratica, l’approccio ad RT-Linux ha avuto molto successo in quanto si è dimostrato essere un approccio vincente. La latenza di interrupt nel caso peggiore su un PC 486 a 33 MHz si assesta ben sotto i 30 µs, vicino al limite dell’hardware. • Molte applicazioni sembrano trarre beneficio da una “sinergia” tra il sistema real-time ed il sistema operativo standard ottimizzato (average case). Per esempio, le applicazioni di acquisizione dati sono spesso composte da un semplice polling o un task real-time di tipo interrupt-driven che conduce i dati attraverso una coda al processo Linux che si occupa di gestire il logging ed il display. Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

24. RTLinux V1. Si tratta di un sistema eccezionalmente stabile che viene utilizzato sia in prodotti commerciale che in ambienti di laboratorio. Fornisce inoltre una semplice libreria API per eseguire, iniziare, e fermare lo scheduling dei tasks real-time. VERSIONI… RTLinux V3 Beta. E’ stato immesso sul mercato il 3 Gennaio del 2000 e rispetto alle precedenti versioni essa aggiunge il supporto PowerPC • RTLinux V2. Offre una versione semplificata dell’ API dei pthreads POSIX ed è conforme allo standard “Minimal Real-time” di POSIX (all’interno del quale un componente real-time è considerato un processo POSIX singolo e multithread). L’obiettivo del kernel V2 è senza dubbio quello di accostarsi il più possibile allo standard POSIX, senza attuare alcun sacrificio dal punto di vista della semplicità e velocità del sistema, ma al tempo stesso fornendo spunti ed aggiunte per realizzare una piena compatibilità con POSIX. V2, messo sul mercato nel Novembre del 1999, è un sistema x86 capace di SMP. Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

25. STORIA DI RTAI • Al fine di rendere Linux utilizzabile per applicazioni hard real-time, i membri del Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano (DIAPM) crearono un livello di astrazione hardware real-time (RTHAL) sul quale poter implementare un interfaccia per applicazioni real-time RTAI. • Sfortunatamente, ulteriori indagini rivelarono che il kernel di Linux disponibile nel vicino 1996, ovvero il 2.0.25, non era ancora pronto ad accogliere tale innovazione. • Nello stesso periodo, un gruppo capeggiato da Victor Yodaiken all’Istituto del New Mexico of Minino and Technology (NMT) , introdusse la sua versione real-time di Linux (RTLinux) che fornì al team DIAPM l’opportunità di apprendere ulteriori nozioni sul kernel di Linux, sull’ hardware e sulle modifiche necessarie a rendere prelazionabile e deterministico lo scheduling. • Il punto di svolta ci fu poi nel 1998 quando fu sviluppato il kernel di Linux 2.2.x che ebbe come punto di forza i noti miglioramenti proposti dall’RTLinux, incluso le molte e necessarie modifiche architetturiali all’interfaccia Linux/hardware. • Tali modifiche, combinate con l’esperienza acquisita dal team DIAPM durante il loro lavoro di evoluzione dell’NMT-RTLinux kernel, e con le nozioni informatiche del 1996, sfociarono nella creazione della piattaforma RTAI. Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

26. CARATTERISTICHE DI RTAI • RTAI è un sistema operativo “guaranteed-based” che assicura uno scheduling hard real-time ed inoltre conserva tutte le caratteristiche ed i servizi del Linux standard. • In aggiunta, RTAI fornisce un supporto sia per UP che per SMP con la capacità di assegnare sia tasks che IRQs alle specifiche CPUs, x486 e Pentiums, schedulers one-shot e periodici, sia inter-Linux che intra-Linux shared memory, compatibilità con lo standard POSIX, supporto FPU, sincronizzazione tra tasks, semafori, sincronizzazione mutua, code per messaggi, RPCs, mailboxes, la possibilità di utilizzare le system call RTAI direttamente da dentro lo user-space standard, e tante altre funzionalità. Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

27. RTAI: REAL-TIME APPLICATION INTERFACE • RTAI supporta ben 5 moduli caricabili del core che conferiscono al sistema le proprietà real-time desiderate “a richiesta”(on-demand) • rtai, che fornisce la struttura base rtai; • rtai_fifos, che altro non è che un adattamento di NMT RTLinux FIFOs (file in, file out); • rtai_sched, che fornisce al sistema uno scheduling one-shot oppure periodico; • rtai_mups, che consente l’uso simultaneo degli schedulers one-shot e periodico oppure di due schedulers periodici, ognuno avente il proprio clock di base differente; • rtai_shm, che alloca la memoria propria di inter-Linux tra i tasks real-time ed i tradizionali processi di Linux, ed anche intra-Linux come sostituto per UNIX V IPC; • Come tutti i moduli del kernel, questi possono essere caricati in memoria e deallocati da essa (usando rispettivamente i comandi standard di Linux insmod ed rmmod) quando le loro rispettive funzionalità sono richieste o meno Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

28. SCHEMA ARCHITETTURIALE • Per ogni implementazione, il sistema operativo Linux è eseguito come il task a più bassa priorità di un piccolo sistema operativo real-time. • Pertanto Linux non apporta cambiamenti alle sue operazioni sia dal punto di vista utente che dal punto di vista kernel, eccetto quello di permettere l’esecuzione solo quando non ci sono già tasks real-time che devono essere eseguiti. Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

29. ARCHITETTURA INTERNA RTAI riduce i cambiamenti al kernel standard di Linux mediante l’aggiunta di un livello di astrazione hardware (HAL) composto da una struttura di puntatori a vettori di interrupt e da funzioni che permettono di abilitare/disabilitare gli interruptus RTLinux applica molti cambiamenti ai file di source del kernel che si manifestano in modifiche ed aggiunte ai numerosissimi files sorgenti del kernel di Linux aumento del codice da memorizzare Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

30. STRUTTURA COMPLETA DI RTAI • L’HAL viene implementato modificando meno di 20 linee di codice esistente, ed aggiungendo circa 50 linee di nuovo codice. Questo approccio è sicuramente più elegante in quanto minimizza l’investigazione del kernel standard di Linux e localizza più facilmente il codice di gestione degli interrupt. • Un altro vantaggio della tecnica HAL è che mediante essa è possibile far tornare Linux al suo ruolo standard (general-purpose) cambiando semplicemente la posizione dei suoi puntatori dalla struttura RTHAL (real-time) a quella originale. Ciò si è dimostrato abbastanza utile quando le operazioni real-time sono inattive o quando si prova ad isolare virus di natura oscura. • “…Molti studiosi suppongono che il livello HAL possa causare inaccettabili ritardi e latenze per via del percorso di analisi e monitoraggio dei tasks real-time. In realtà negli ultimi anni l’impatto dell’HAL sulle performances del kernel è divenuto trascurabile per via della maturità e del progetto del kernel di Linux…” Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

31. RTAI: SCHEDULERS E TIMERS SUPPORTATI • Si nota che dal momento che il MUP utilizza l’APIC (advanced programmable interrupt controller) timer, esso non può operare sotto SMP e richiede pertanto che ogni task scedulato MUP sia eseguito all’interno di una specifica CPU (da qui la designazione MultiUniProcessor). Comunque il MUP conserva tutte le coordinate ed i servizi IPC in modo che le altre proprietà non vengano perse Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

32. RTLinux vs RTAI • La seguente tabella riassume in maniera alquanto semplice le principali differenze risultanti dall’analisi svolta dei due RTOS. Ovviamente non vengono incluse le caratteristiche che caratterizzano entrambi i sistemi: Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI

33. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

34. L’RTOS KURT • Il KURT (acronimo di Kansas University Real Time Linux) altro non è che una modifica real-time (firm) al sistema operativo Linux, che consente lo scheduling di eventi real-time alla risoluzione di 10µs. • Piuttosto che contare su uno scheduling basato su priorità o su “rigidi” schedules periodici, schedules del sistema operativo KURT sono esplicitamente specificati dal programmatore dell’applicazione. • KURT può tuttavia funzionare in due modi: “focussed mode”, dove solo ad i processi real-time è permessa l’esecuzione; ed il “mixed mode”, dove l’esecuzione dei processi real-time ha ancora la precedenza, ma è consentito a tutti i processi non real-time di essere eseguiti purchè all’interno dei “buchi” dello schedule real-time. • Una semplice system call permette il passaggio tra le due modalità. • Il KURT “gira” su una piattaforma compatibile x86 con un contatore di tipo “time-stamp” (ossia i processori Pentium o i loro equivalenti). • Effettuare il “porting” di KURT ad altre architetture, richiede tuttavia solo minime aggiunte. Un'estensione firm real-time di Linux : il KURT

35. KURT: CONCETTI CHIAVE • Real time framework il KURT si compone di una struttura real-time (framework) che si preoccupa di realizzare lo scheduling di eventi real-time. Quando un evento real-time sta per essere eseguito, la struttura real-time chiama il gestore degli eventi (event handler) dell’ RTmod associato. • RTMods moduli real time, ovvero moduli del kernel che possono essere caricati a “runtime” ottimizzando così certe azioni quando vengono invocati. Gli sviluppatori della piattaforma KURT hanno scritto un RTMod che cambia il contesto al processo utente specificato non appena è invocato. • Lo schedule real-timeè un file che specifica come ed in che momento l’RTMod necessiti di essere invocato. Questo schedule viene poi passato al framework real-time che si prende cura dello scheduling di ogni evento invocando, nel momento giusto, l’appropriato gestore degli eventi. Gli sviluppatori del KURT hanno realizzato un semplice programma che genera questo schedule; • rt-idaltro non è che il numero identificativo associato ad ogni processo del KURT. Ogni processo del KURT può infatti richiedere (o essere dato da) un rt-id non appena esso viene registrato nel modulo di processo settando set_rtparams. Un processo KURT può modificare il suo rt_idutilizzandola medesima system call; • Registrazione degli RTModsun RTMod registra se stesso all’interno del framework real-time provvedendo ad un nome, a dei puntatori a funzione per i gestori degli eventi, all’inizializzazione, ed alla sua eventuale ripulitura(clean up). Quando un modulo real-time viene registrato, gli viene assegnato un numero identificativo che viene utilizzato per schedulare i suoi eventi; Un'estensione firm real-time di Linux : il KURT

36. KURT: LO SCHEDULING • Scheduling Modes il framework real-time può schedulare eventi secondo due modalità: FROM_MEM : Nella seguente modalità , il file di schedule viene completamente letto nella memoria del kernel e solo poi lo scheduling di ogni evento ha luogo. E’ possibile ripetere questo schedule per un numero di volte in maniera ciclica. Lo svantaggio di questa modalità è che richiede abbastanza memoria per occupare il file di schedule completo. Si pensi infatti che ogni evento occupa circa 24 bytes di memoria. FROM_DISK : In questa modalità, il file di schedule viene letto nella memoria del kernel una pagina per volta. Arbitrariamente, lunghi schedules possono essere presentati al framework real-time per lo scheduling. Lo svantaggio di questa modalità è che ci potrebbero essere alcune distorsioni nello scheduling degli eventi a causa dell’operazione di lettura intermittente da disco. UTIMEil KURT utilizza un sistema “utime” per schedulare gli eventi con una risoluzione in termini di microsecondi (µs). Gli eventi possono anche esser schedulati con una risoluzione di 10 ms se UTIME non è installato. Un'estensione firm real-time di Linux : il KURT

37. PERFORMANCES: DISPATCH TIME PER I MODULI DEL KERNEL E PER I PROCESSI REAL-TIME • Per testare il tempo richiesto ad invocare un modulo del kernel ed un processo real-time, basta un semplice processo real-time KURT che viene eseguito ogni 10ms (nella modalità periodica). • Ogni volta che cicla, il programma restituisce il tempo corrente e lo immagazzina in memoria. Dopo che il programma ha terminato la sua esecuzione, i tempi vengono stampati al fine di permettere un immediato confronto. • Le informazioni temporali, inoltre, sono state anche conservate per valutare la differenza tra quando un evento occorre nel tempo e quando l’RTMod inizia realmente la sua esecuzione. Un'estensione firm real-time di Linux : il KURT

38. PERFORMANCES: KURT vs SCHED FIFO SOFT REAL TIME SCHED_KURT_PROCS (modalità focus ) …efficienza di scheduling SCED_FIFO Un'estensione firm real-time di Linux : il KURT SCHED_ALL_PROCS (modalità mixed)

39. VALUTAZIONE DELLE PERFORMANCES(1) • SCHED_FIFO: performances all’aumentare del numero dei processi (interrupts dell’hardware esterno considerevole numero di contex switch prelazionabili affligge le prestazioni); • SCHED_KURT: le performances sostanzialmente restano invariate quando viene aumentato il numero dei processi (c’è un minimo contex switch tra queste applicazioni); • SCHED_KURT: non c’è quasi differenza tra la modalità SCHED_KURT_PROCS e SCHED_ALL_PROCS (Ciò si verifica perché il sistema è essenzialmente idle eccetto per i processi da testare); • SCHED_KURT: non c’è un vero e proprio meccanismo di controllo dell’ ingresso che previene l’overloading della CPU. Dal momento che ogni processo setta le sue richieste di processamento a 300µs (è l’attuale tempo di CPU richiesto dal processo per completare un’iterazione del suo ciclo), non sono permessi più di 30 processi all’interno del sistema. SCHED_FIFO: qualsiasi numero dei processi dovrebbe essere permesso all’interno del sistema. Questo dovrebbe portare ad un ulteriore degradazione delle performances; quindi… A prescindere dal numero dei processi, il KURT schedula ogni applicazione al tempo appropriato (in rosso). KURT con o senza focalizzazione è un’alternativa fattibile per lo scheduling firm real-time dei processi. Un'estensione firm real-time di Linux : il KURT

40. VALUTAZIONE DELLE PERFORMANCES (2) … ed inoltre… • Se un sistema è caricato, le performances dello scheduler esplicito nella modalità SCHED_ALL_PROCS potrebbero essere distorte nel momento in cui gli interrupts vengono disabilitati da altre parti del sistema operativo. • Worst case: interrupts disabilitati dall’attività di backgraund del disco (infatti in Linux disabilita gli interruptus per la massima durata del tempo) effetto sulle performances degli schedulers FIFO e KURT • Si può notare che persino in presenza di “background disk activity”, lo SCHED_KURT funziona ancora molto meglio dello SCED_FIFO. Un'estensione firm real-time di Linux : il KURT

41. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

42. OS PER APPLICAZIONI EMBEDDED Sviluppare un sistema i cui componenti vengono compilati insieme all’applicazione (come TinyOS e BTnode system software) • Un sistema operativo realizzato per un ambito embedded, deve avere alcune caratteristiche di base: .…si distinguono generalmente due approcci: Ridotte dimensioni Basso consumo durante l’elaborazione Consumo pressoché nullo in stato di “idle” Deve gestire la concorrenza Implementare protocolli di rete a seconda della periferica di rete utilizzata Protocolli poco dispendiosi in termini di energia(TCP/IP è in genere inapplicabile) Deve inoltre fornire un’astrazione per i dispositivi hardware (sensori e attuatori) montati sul sensore Sviluppare un sistema che includa i tradizionali strati di software dei sistemi general purpose in versione ridotta (ad es. BerthaOS e MANTIS) TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

43. IL PRIMO APPROCCIO: IL TINYOS • OS di tipo “open source” specificamente ideato per reti “embedded” di sensori wireless (attualmente è il più affermato) sviluppato dall’università di Berkeley in California per la tecnologia motes • Modello di programmazione tagliato per applicazioni attivate da eventi e con una occupazione ridottissima (il core richiede solo 400 byte di dati) essendo realmente inserite nel sistema solo le funzionalità richieste • Appartiene al primo approccio, dunque i componenti vengono montati assieme all’applicazione: ciò consente una singola applicazione in esecuzione in un dato momento • Tuttavia tale sistema permette di avere bassissimi consumi (non esistendo in genere context switch dal momento che gli scheduler seguono una politica FIFOrun to completion, ovvero un task non può interrompere un altro task) • Lo svantaggio derivante da tale approccio è la limitata versatilità e i seri vincoli di riconfigurabilità dell’applicazione Mica Mote (Berkeley 2001) TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

44. IL MODELLO A COMPONENTI DEL TINYOS • Scambia dati per mezzo di una rete di componenti che comunicano tra loro mediante un’interfaccia per gli “eventi” (asincroni) e per i “comandi” (sincroni) • Utilizza il nesC, ovvero un linguaggio di programmazione evoluto(derivato dal C) per sistemi embedded connessi in rete (per es. Mote) High level software component sono quelli di livello più alto e si occupano di eseguire algoritmi che prescindono dal particolare hardware(ad es. il componente che implementa il protocollo di routing) Mica Mote: 128KB di codice, 4KB di dati, ed una flash di 512KB Synthetic hardware simulano il comportamento di hardware più sofisticato di quello realmente presente sul sensore(ad es un componente che compone 8 bit e li invia a quelli di livello superiore) Hardware abstraction mappa le funzionalità sw su quelle hw creando un’astrazione dello stesso utilizzabile dai moduli superiori(ad es. un componente che legge/ scrive 1bit sul canale radio) …3 possibili categorie di componenti… TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

45. MIGLIORAMENTO DELLO SCHEDULER DELLA VERSIONE 1.0 CONCETTO DI PRIORITA’ • TinyOS 1.0. (curva in blue): si nota come la resa dei pacchetti (throughput) si riduca in presenza di un task locale ad 8Hz (125 ms) con tempi di esecuzione variabili all’interno di una piattaforma TinyOS 1.0. Non appena il tempo di esecuzione di un task locale aumenta (overload del sistema), il throughput dei pacchetti radio diminuisce sensibilmente (scheduler FIFO per tutti i tasks). • TinyOS 2.0. (curva in viola): l’aggiunta della priorità per i tasks, per differenziare i tasks real-time dai tasks ordinari, migliora sostanzialmente il throughput in caso di overload del sistema (perché magari è in esecuzione un task locale, e quindi il processamento di tale pacchetto bloccherebbe completamente un nodo sensore), Attualmente presenta uno scheduler FIFO run to completion con due livelli di priorità: quello normale per i task e quello più alto per gli eventi, che possono interrompere i task (preemption). TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

46. UNO SGUARDO AL SECONDO APPROCCIO: MANTIS OS • Mantis OS è il sistema operativo della piattaforma MANTIS che si basa sui sensori nymph. • Appartiene al secondo approccio, quindi include i tradizionali strati di software dei sistemi general purpose in versione “ridotta” • Concettualmente è opposto a TinyOS, infatti esso ha la struttura di un OS general purpose, è organizzato in livelli, è multithread e contiene uno scheduler preemptive con time slicing, meccanismi di sincronizzazione attraverso sezioni in mutua esclusione, uno stack protocollare standard per la rete e device drivers • Questo approccio accelera l’apprendimento della nuova tecnologia e aumenta la versatilità (potendo eseguire più applicazioni in contemporanea), ma pone seri problemi di prestazioni e di consumi. Il componente “command server” permette di amministrare da remoto il singolo sensore attraverso una shell UNIX-like ...si nota la somiglianza dell’architettura con i sistemi UNIX … TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

47. MANTIS: KERNEL, SCHEDULER & STACK • Le funzionalità offerte dal kernel di MANTIS OS sono un sottoinsieme dell’interfaccia POSIX, in particolare lo scheduler priority-based (secondo l’algoritmo round-robin) • Per la sincronizzazione e la concorrenza il sistema supporta semafori sempre secondo lo standard posix. • La memoria RAM è divisa in due sezioni: statica dove vengono allocate al momento della compilazione le varabili globali; heap dove vengono allocati i thread al momento dell’esecuzione. • Non è possibile allocare manualmente memoria dinamica al momento. • Per quanto riguarda la comunicazione di rete, MANTIS OS prevede uno stack protocollare strutturato su quattro livelli: fisico, MAC, network e applicazione. Il sistema è molto più sofisticato e versatile di quello di TinyOS, infatti possono coesistere meccanismi di routing diversi (unicast, flooding, multicast). • Di contro questo sistema è prestazionalmente più scadente dell’ Active Messages utilizzato dal TinyOS, essendo l’elaborazione del singolo pacchetto più lunga, e comportando un continuo scambio di contesto di esecuzione al momento della comunicazione di rete. Questo causa consumi maggiori. TinyOS e Mantis: uno sguardo all'immediato futuro degli RTOS

48. SOMMARIO • Introduzione ai sistemi operativi real-time; • Passaggio dagli OS ai sistemi operativi di natura real-time; • Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; • Un’estensione firm real-time di Linux: il KURT; • TinyOS e Mantis: uno sguardo all’immediato futuro degli RTOS; • Conclusioni sullo studio dei sistemi operativi real-time;

49. CONSIDERAZIONI FINALI:PANORAMICA COMPLETA • aggiunge funzionalità al sistema per mezzo di un “resurce kernel” implementato come un modulo caricabile • Fare un confronto tra sistemi hard, soft e firm real-time è alquanto difficile • Tabella finalizzata a permettere un immediato confronto all’interno di un contesto specificatamente “real-time” • proprietà fornita ai tasks che fa uso della API RK, ma che non può far uso di RK(e della sua API) se si sta gia utilizzando RTAI, vista la mutua esclusività tra i due ..Conclusione.. non c’è un singolo prodotto che offra un set “all-inclusive” di proprietà RT, pertanto molte società offrono tecnologie alternative mutiple (come più miglioramenti per lo scheduler di RTLinux ed RTAI) in modo da soddisfare un range sicuramente più ampio di esigenze real-time Conclusioni sullo studio dei sistemi operativi real-time

50. CONSIDERAZIONI FINALI: OS vs EVENT-DRIVEN confronto generale tra le caratteristiche degli OS “general purpose” e quelle degli “event-driven” • Con la medesima scelta del processore(ARM7 a 16 bit), TinyOS necessita di metà memoria istruzioni e di circa 1/30 di memoria dati. Gli studi dimostrano che il consumo di potenza di una SRAM scala approssimativamente con la • Questo significa che in TinyOS la potenza della memoria istruzioni può essere ridotta di 1.6x e quella della memoria dati rispettivamente di 4.2x • Utilizzando un più semplice processore come quello RISC a 8-bit, si potrebbe ulteriormente ridurre la dimensione della memoria ed il consumo di potenza. confronto tra la diversa richiesta di memoria tra le due differenti politiche di OS quindi.. Conclusioni sullo studio dei sistemi operativi real-time