La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

STUDIO COMPARATO DEI PRINCIPALI SISTEMI OPERATIVI IN TEMPO REALE Relatore: Chiar.mo Tesi di Laurea di: Relatore: Chiar.mo Tesi di Laurea di: Prof. Aldo.

Presentazioni simili


Presentazione sul tema: "STUDIO COMPARATO DEI PRINCIPALI SISTEMI OPERATIVI IN TEMPO REALE Relatore: Chiar.mo Tesi di Laurea di: Relatore: Chiar.mo Tesi di Laurea di: Prof. Aldo."— Transcript della presentazione:

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

2 2 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

3 Introduzione ai sistemi operativi real-time3 EVOLUZIONE DEI CALCOLATORI ELETTRONICI

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

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

6 Introduzione ai sistemi operativi real-time6 SCENARIO DI UN SISTEMA OPERATIVO REAL-TIME Allinterno di tali contesti applicativi gli RTOS (acronimo di Real-Time Operative System) si collocano come: Allinterno 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 luscita dellelaboratore ma anche dal tempo in cui questi vengono prodotti; pertanto, il tempo del sistema deve essere necessariamente sincronizzato con il tempo dellambiente circostante

7 Introduzione ai sistemi operativi real-time7 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: 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 ; 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; Il concetto di velocità è sempre relativo ad uno specifico ambiente; La velocità deve comunque garantire la correttezza; La velocità deve comunque garantire la correttezza; Lobiettivo di un RTOS è quello di garantire la tempistica di ogni singolo task, mentre lobiettivo di un sistema veloce è quello di minimizzare il tempo medio di risposta dei vari tasks; Lobiettivo di un RTOS è quello di garantire la tempistica di ogni singolo task, mentre lobiettivo 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; Il tempo medio di risposta non può essere preso come un parametro significativo nel real-time;

8 Introduzione ai sistemi operativi real-time8 RTOS ALLINTERNO DELLA SCALA GERARCHICA DEGLI OS Ha delle periferiche di I/O che sono architetture di calcolatori diffuse in ambiente industriale e biomedico; 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; 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 è 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 i sistemi Real-time possono essere considerati Embedded ma non viceversa devono soddisfare precisi vincoli temporali per quel che concerne lesecuzione dei propri tasks; devono soddisfare precisi vincoli temporali per quel che concerne lesecuzione 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 ; 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 ;

9 Introduzione ai sistemi operativi real-time9 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 lesecuzione di ogni singolo task. Queste ultime possono essere di diversa natura: 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 lesecuzione di ogni singolo task. Queste ultime possono essere di diversa natura: 1. Architetturiale - Cache, pipelining, interruptus, DMA; - Cache, pipelining, interruptus, DMA; 2. Operativo - Scheduling, sincronizzazione, comunicazione; - Scheduling, sincronizzazione, comunicazione; 3. Linguaggio - Non hanno esplicito supporto per il tempo; - Non hanno esplicito supporto per il tempo; 4. Metodologie progettuali - Mancanza di tecniche di analisi e verifica. - Mancanza di tecniche di analisi e verifica.

10 Introduzione ai sistemi operativi real-time10 PREDICIBILITA IN FUNZIONE DELLA TIPOLOGIA DI SCHEDULER da unanalisi superficiale potrebbe risultare che solamente scheduler ciclici garantirebbero un alto valore di predicibilità; da unanalisi 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à 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

11 11 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

12 Passaggio dagli OS ai sistemi operativi di natura real-time 12 PREMESSA Per unanalisi più prolifica delle numerose famiglie di RTOS è opportuno scindere il problema alla base diversificando anzitutto almeno due tipologie implementative: Per unanalisi 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 progettati appositamente che non si basano su OS già esistenti sul mercato; Sistemi RTOS ottenuti mediante ladattamento di OS originari già esistenti sul mercato; Sistemi RTOS ottenuti mediante ladattamento 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 questultima risorse di tipo Open Source ed un ottima documentazione di base. 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 questultima risorse di tipo Open Source ed un ottima documentazione di base.

13 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 questultimo il tempo di esecuzione deve essere conosciuto a priori, mentre in Time-sharing non è affatto predicibile. la politica del Time-sharing letteralmente uccide il real-time perché in questultimo il tempo di esecuzione deve essere conosciuto a priori, mentre in Time-sharing non è affatto predicibile.

14 Passaggio dagli OS ai sistemi operativi di natura real-time 14 PROBLEMATICHE PER IMPLEMENTAZIONE DI LINUX IN REAL-TIME Lo scheduler di Linux ha un taglio general purpose.Ciò sostanzialmente è fatto per distribuire equamente le risorse ai tasks in esecuzione; 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…); 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); 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 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; 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. 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. Dati relativi al kernel 2.4

15 Passagio 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 listante in cui lo scheduter lancia il thread che è in attesa che quel segnale arrivi (risposta). Latenza di scheduling : distanza temporale tra il segnale (stimolo) di wakeup che un evento è accaduto e listante in cui lo scheduter lancia il thread che è in attesa che quel segnale arrivi (risposta). Response Time Interrupt latency; Interrupt latency; Interrupt Handler duration; Interrupt Handler duration; Scheduler Latency; Scheduler Latency; Scheduling duration; Scheduling duration; Preemption patches lanciare più frequentemente la schedule(); Preemption patches lanciare più frequentemente la schedule(); Low latency patches introduzione di punti di prelazione nel codice del kernel Low latency patches introduzione di punti di prelazione nel codice del kernel aumentano riducono

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

17 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; Linux è un sistema operativo di alto livello ed è Open Source; E molto ben documentato; E molto ben documentato; Nasce nellambiente universitario ed è naturalmente inserito in svariati contesti di ricerca; Nasce nellambiente universitario ed è naturalmente inserito in svariati contesti di ricerca; E compatibile con i maggiori standard relativi al software (POSIX etc…); E compatibile con i maggiori standard relativi al software (POSIX etc…); Ha buone prestazioni già in versioni base (senza modifiche strutturali); Ha buone prestazioni già in versioni base (senza modifiche strutturali); La struttura monolitica lo rende adatto ad essere utilizzato in scenari Embedded; La struttura monolitica lo rende adatto ad essere utilizzato in scenari Embedded; Il mondo dellindustria è 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… Il mondo dellindustria è 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… Sono attualmente disponibili numerose implementazioni di architetture software Open Source per modificare Linux dotandolo di funzionalità real- time da cui attingere spunto…

18 Passaggio dagli OS ai sistemi operativi di natura real-time 18 STRATEGIE PER IL REAL-TIME IN LINUX Esistono due possibili approcci: 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à

19 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 lutilizzo nellelettronica (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).

20 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. Lultima versione supporta user-space RT programming. La versione MiniRTL è adatta ad utilizzi embedded. RTLinux. Hard Real Time mini sistema operativo che gira Linux come processo a minima priorità rendendolo totalmente preemptable. Lultima 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. 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. 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. 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 lutilizzo in applicazioni multimediali, telefonia mobile… QLinux. Implementazione tagliata per garantire caratteristiche di QoS per task soft real-time. Tagliata per lutilizzo in applicazioni multimediali, telefonia mobile…

21 21 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

22 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 22 RTLINUX : UNAGGIUNTA HARD REAL-TIME A LINUX (1) RTLinux, sviluppato originariamente nellIstituto 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, sviluppato originariamente nellIstituto 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à. 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. 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, dellaccesso alla rete, e di altre funzioni che non sono vincolate da una caratterizzazione del comportamento nel caso peggiore (worst case). 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, dellaccesso alla rete, e di altre funzioni che non sono vincolate da una caratterizzazione del comportamento nel caso peggiore (worst case).

23 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 23 RTLINUX : UNAGGIUNTA 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 lanalisi dei dati, Drivers per Linux, standard POSIX API). 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 lanalisi 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. 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, lapproccio 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 dellhardware. In pratica, lapproccio 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 dellhardware. 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. 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.

24 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 24 VERSIONI… 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. 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. RTLinux V2. Offre una versione semplificata dell API dei pthreads POSIX ed è conforme allo standard Minimal Real- time di POSIX (allinterno del quale un componente real- time è considerato un processo POSIX singolo e multithread). Lobiettivo 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. RTLinux V2. Offre una versione semplificata dell API dei pthreads POSIX ed è conforme allo standard Minimal Real- time di POSIX (allinterno del quale un componente real- time è considerato un processo POSIX singolo e multithread). Lobiettivo 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. RTLinux V3 Beta. E stato immesso sul mercato il 3 Gennaio del 2000 e rispetto alle precedenti versioni essa aggiunge il supporto PowerPC RTLinux V3 Beta. E stato immesso sul mercato il 3 Gennaio del 2000 e rispetto alle precedenti versioni essa aggiunge il supporto PowerPC

25 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. 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 , non era ancora pronto ad accogliere tale innovazione. Sfortunatamente, ulteriori indagini rivelarono che il kernel di Linux disponibile nel vicino 1996, ovvero il , non era ancora pronto ad accogliere tale innovazione. Nello stesso periodo, un gruppo capeggiato da Victor Yodaiken allIstituto del New Mexico of Minino and Technology (NMT), introdusse la sua versione real-time di Linux (RTLinux) che fornì al team DIAPM lopportunità di apprendere ulteriori nozioni sul kernel di Linux, sull hardware e sulle modifiche necessarie a rendere prelazionabile e deterministico lo scheduling. Nello stesso periodo, un gruppo capeggiato da Victor Yodaiken allIstituto del New Mexico of Minino and Technology (NMT), introdusse la sua versione real-time di Linux (RTLinux) che fornì al team DIAPM lopportunità 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 dallRTLinux, incluso le molte e necessarie modifiche architetturiali allinterfaccia Linux/hardware. 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 dallRTLinux, incluso le molte e necessarie modifiche architetturiali allinterfaccia Linux/hardware. Tali modifiche, combinate con lesperienza acquisita dal team DIAPM durante il loro lavoro di evoluzione dellNMT-RTLinux kernel, e con le nozioni informatiche del 1996, sfociarono nella creazione della piattaforma RTAI. Tali modifiche, combinate con lesperienza acquisita dal team DIAPM durante il loro lavoro di evoluzione dellNMT-RTLinux kernel, e con le nozioni informatiche del 1996, sfociarono nella creazione della piattaforma RTAI.

26 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. 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à. 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à.

27 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 27 RTAI: REAL-TIME APPLICATION INTERFACE rtai, che fornisce la struttura base rtai; rtai, che fornisce la struttura base rtai; rtai_fifos, che altro non è che un adattamento di NMT RTLinux FIFOs (file in, file out); 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_sched, che fornisce al sistema uno scheduling one-shot oppure periodico; rtai_mups, che consente luso simultaneo degli schedulers one-shot e periodico oppure di due schedulers periodici, ognuno avente il proprio clock di base differente; rtai_mups, che consente luso 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; 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; RTAI supporta ben 5 moduli caricabili del core che conferiscono al sistema le proprietà real-time desiderate a richiesta(on-demand) RTAI supporta ben 5 moduli caricabili del core che conferiscono al sistema le proprietà real-time desiderate a richiesta(on-demand) 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 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

28 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. 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 lesecuzione solo quando non ci sono già tasks real-time che devono essere eseguiti. Pertanto Linux non apporta cambiamenti alle sue operazioni sia dal punto di vista utente che dal punto di vista kernel, eccetto quello di permettere lesecuzione solo quando non ci sono già tasks real-time che devono essere eseguiti.

29 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 29 ARCHITETTURA INTERNA 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 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 RTAI riduce i cambiamenti al kernel standard di Linux mediante laggiunta 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 RTAI riduce i cambiamenti al kernel standard di Linux mediante laggiunta 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

30 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 30 STRUTTURA COMPLETA DI RTAI LHAL 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 linvestigazione del kernel standard di Linux e localizza più facilmente il codice di gestione degli interrupt. LHAL 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 linvestigazione 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. 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 limpatto dellHAL sulle performances del kernel è divenuto trascurabile per via della maturità e del progetto del kernel di Linux… …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 limpatto dellHAL sulle performances del kernel è divenuto trascurabile per via della maturità e del progetto del kernel di Linux…

31 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 lAPIC (advanced programmable interrupt controller) timer, esso non può operare sotto SMP e richiede pertanto che ogni task scedulato MUP sia eseguito allinterno 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 Si nota che dal momento che il MUP utilizza lAPIC (advanced programmable interrupt controller) timer, esso non può operare sotto SMP e richiede pertanto che ogni task scedulato MUP sia eseguito allinterno 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

32 Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI 32 RTLinux vs RTAI RTLinuxRTAI CompanyFSM Labs DENX Software Engineering, Pengutronix and Sysgo Realtime Solutions Archi386, PPC, ARMi386, MIPS, PPC, ARM, m68k-nommu LicenseGPL - ComercialLGPL - GPL APIPOSIXcustom Memoryshareddynamic and shared DebugGDB, Event tracerCross GDB, LTT IPCFIFO'sFIFO's, Named FIFO's, Mailboxes, messages, PQueues, net_rpc User space Real TimeSignal handlersLXRT soft, LXRT hard, Mini LXRT MiscRT-Lab Octave, proc, Watchdog, Scripting, Xenomai La seguente tabella riassume in maniera alquanto semplice le principali differenze risultanti dallanalisi svolta dei due RTOS. Ovviamente non vengono incluse le caratteristiche che caratterizzano entrambi i sistemi: La seguente tabella riassume in maniera alquanto semplice le principali differenze risultanti dallanalisi svolta dei due RTOS. Ovviamente non vengono incluse le caratteristiche che caratterizzano entrambi i sistemi:

33 33 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

34 Un'estensione firm real-time di Linux : il KURT34 LRTOS 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. 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 dellapplicazione. Piuttosto che contare su uno scheduling basato su priorità o su rigidi schedules periodici, schedules del sistema operativo KURT sono esplicitamente specificati dal programmatore dellapplicazione. KURT può tuttavia funzionare in due modi: focussed mode, dove solo ad i processi real-time è permessa lesecuzione; ed il mixed mode, dove lesecuzione dei processi real-time ha ancora la precedenza, ma è consentito a tutti i processi non real-time di essere eseguiti purchè allinterno dei buchi dello schedule real-time. KURT può tuttavia funzionare in due modi: focussed mode, dove solo ad i processi real-time è permessa lesecuzione; ed il mixed mode, dove lesecuzione dei processi real-time ha ancora la precedenza, ma è consentito a tutti i processi non real-time di essere eseguiti purchè allinterno dei buchi dello schedule real-time. Una semplice system call permette il passaggio tra le due modalità. 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). 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. Effettuare il porting di KURT ad altre architetture, richiede tuttavia solo minime aggiunte.

35 Un'estensione firm real-time di Linux : il KURT35 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. 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. 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 lRTMod 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, lappropriato gestore degli eventi. Gli sviluppatori del KURT hanno realizzato un semplice programma che genera questo schedule; Lo schedule real-time è un file che specifica come ed in che momento lRTMod 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, lappropriato gestore degli eventi. Gli sviluppatori del KURT hanno realizzato un semplice programma che genera questo schedule; rt-id altro 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_id utilizzandola medesima system call; rt-id altro 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_id utilizzandola medesima system call; Registrazione degli RTMods un RTMod registra se stesso allinterno del framework real-time provvedendo ad un nome, a dei puntatori a funzione per i gestori degli eventi, allinizializzazione, 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; Registrazione degli RTMods un RTMod registra se stesso allinterno del framework real-time provvedendo ad un nome, a dei puntatori a funzione per i gestori degli eventi, allinizializzazione, 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;

36 Un'estensione firm real-time di Linux : il KURT36 KURT: LO SCHEDULING 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 delloperazione di lettura intermittente da disco. 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 delloperazione di lettura intermittente da disco. 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_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. UTIME il 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. Scheduling Modes il framework real-time può schedulare eventi secondo due modalità:

37 Un'estensione firm real-time di Linux : il KURT37 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). 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. 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 lRTMod inizia realmente la sua esecuzione. Le informazioni temporali, inoltre, sono state anche conservate per valutare la differenza tra quando un evento occorre nel tempo e quando lRTMod inizia realmente la sua esecuzione.

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

39 Un'estensione firm real-time di Linux : il KURT39 VALUTAZIONE DELLE PERFORMANCES(1) SCHED_FIFO: performances allaumentare del numero dei processi (interrupts dellhardware esterno considerevole numero di contex switch prelazionabili affligge le prestazioni); SCHED_FIFO: performances allaumentare del numero dei processi (interrupts dellhardware 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: 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è 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 loverloading della CPU. Dal momento che ogni processo setta le sue richieste di processamento a 300µs (è lattuale tempo di CPU richiesto dal processo per completare uniterazione del suo ciclo), non sono permessi più di 30 processi allinterno del sistema. SCHED_KURT: non cè un vero e proprio meccanismo di controllo dell ingresso che previene loverloading della CPU. Dal momento che ogni processo setta le sue richieste di processamento a 300µs (è lattuale tempo di CPU richiesto dal processo per completare uniterazione del suo ciclo), non sono permessi più di 30 processi allinterno del sistema. SCHED_FIFO: qualsiasi numero dei processi dovrebbe essere permesso allinterno del sistema. Questo dovrebbe portare ad un ulteriore degradazione delle performances; SCHED_FIFO: qualsiasi numero dei processi dovrebbe essere permesso allinterno del sistema. Questo dovrebbe portare ad un ulteriore degradazione delle performances; A prescindere dal numero dei processi, il KURT schedula ogni applicazione al tempo appropriato (in rosso). A prescindere dal numero dei processi, il KURT schedula ogni applicazione al tempo appropriato (in rosso). KURT con o senza focalizzazione è unalternativa fattibile per lo scheduling firm real-time dei processi. KURT con o senza focalizzazione è unalternativa fattibile per lo scheduling firm real-time dei processi. quindi…

40 Un'estensione firm real-time di Linux : il KURT40 VALUTAZIONE DELLE PERFORMANCES (2) 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. 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 dallattività di backgraund del disco (infatti in Linux disabilita gli interruptus per la massima durata del tempo) Worst case: interrupts disabilitati dallattività di backgraund del disco (infatti in Linux disabilita gli interruptus per la massima durata del tempo) … ed inoltre… 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. Si può notare che persino in presenza di background disk activity, lo SCHED_KURT funziona ancora molto meglio dello SCED_FIFO.

41 41 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

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

43 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 dalluniversità di Berkeley in California per la tecnologia motes OS di tipo open source specificamente ideato per reti embedded di sensori wireless (attualmente è il più affermato) sviluppato dalluniversità 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 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 allapplicazione: ciò consente una singola applicazione in esecuzione in un dato momento Appartiene al primo approccio, dunque i componenti vengono montati assieme allapplicazione: 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 FIFO run to completion, ovvero un task non può interrompere un altro task) Tuttavia tale sistema permette di avere bassissimi consumi (non esistendo in genere context switch dal momento che gli scheduler seguono una politica FIFO run 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à dellapplicazione Lo svantaggio derivante da tale approccio è la limitata versatilità e i seri vincoli di riconfigurabilità dellapplicazione Mica Mote (Berkeley 2001)

44 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 uninterfaccia per gli eventi (asincroni) e per i comandi (sincroni) Scambia dati per mezzo di una rete di componenti che comunicano tra loro mediante uninterfaccia 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) Utilizza il nesC, ovvero un linguaggio di programmazione evoluto(derivato dal C) per sistemi embedded connessi in rete (per es. Mote) Mica Mote: 128KB di codice, 4KB di dati, ed una flash di 512KB Hardware abstraction mappa le funzionalità sw su quelle hw creando unastrazione dello stesso utilizzabile dai moduli superiori(ad es. un componente che legge/ scrive 1bit sul canale radio) 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) 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) …3 possibili categorie di componenti…

45 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 allinterno 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 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 allinterno 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): laggiunta 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), TinyOS 2.0. (curva in viola): laggiunta 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). 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).

46 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. 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 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 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 lapprendimento della nuova tecnologia e aumenta la versatilità (potendo eseguire più applicazioni in contemporanea), ma pone seri problemi di prestazioni e di consumi. Questo approccio accelera lapprendimento 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 Il componente command server permette di amministrare da remoto il singolo sensore attraverso una shell UNIX-like...si nota la somiglianza dellarchitettura con i sistemi UNIX …

47 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 dellinterfaccia POSIX, in particolare lo scheduler priority-based (secondo lalgoritmo round-robin) Le funzionalità offerte dal kernel di MANTIS OS sono un sottoinsieme dellinterfaccia POSIX, in particolare lo scheduler priority-based (secondo lalgoritmo round-robin) Per la sincronizzazione e la concorrenza il sistema supporta semafori sempre secondo lo standard posix. Per la sincronizzazione e la concorrenza il sistema supporta semafori sempre secondo lo standard posix. La memoria RAM è divisa in due sezioni: La memoria RAM è divisa in due sezioni: statica dove vengono allocate al momento della compilazione le varabili globali; statica dove vengono allocate al momento della compilazione le varabili globali; heap dove vengono allocati i thread al momento dellesecuzione. heap dove vengono allocati i thread al momento dellesecuzione. Non è possibile allocare manualmente memoria dinamica al momento. 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). 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 lelaborazione del singolo pacchetto più lunga, e comportando un continuo scambio di contesto di esecuzione al momento della comunicazione di rete. Questo causa consumi maggiori. Di contro questo sistema è prestazionalmente più scadente dell Active Messages utilizzato dal TinyOS, essendo lelaborazione del singolo pacchetto più lunga, e comportando un continuo scambio di contesto di esecuzione al momento della comunicazione di rete. Questo causa consumi maggiori.

48 48 SOMMARIO Introduzione ai sistemi operativi real-time; Introduzione ai sistemi operativi real-time; Passaggio dagli OS ai sistemi operativi di natura 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; Le più diffuse alternative hard real-time oggi sul mercato: RTLinux ed RTAI; Unestensione firm real-time di Linux: il KURT; Unestensione firm real-time di Linux: il KURT; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; TinyOS e Mantis: uno sguardo allimmediato futuro degli RTOS; Conclusioni sullo studio dei sistemi operativi real- time; Conclusioni sullo studio dei sistemi operativi real- time;

49 Conclusioni sullo studio dei sistemi operativi real-time 49 CONSIDERAZIONI FINALI:PANORAMICA COMPLETA Fare un confronto tra sistemi hard, soft e firm real-time è alquanto difficile Fare un confronto tra sistemi hard, soft e firm real-time è alquanto difficile Tabella finalizzata a permettere un immediato confronto allinterno di un contesto specificatamente real-time Tabella finalizzata a permettere un immediato confronto allinterno di un contesto specificatamente real-time aggiunge funzionalità al sistema per mezzo di un resurce kernel implementato come un modulo caricabile aggiunge funzionalità al sistema per mezzo di un resurce kernel implementato come un modulo caricabile 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 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 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 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..Conclusione..

50 Conclusioni sullo studio dei sistemi operativi real-time 50 CONSIDERAZIONI FINALI: OS vs 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 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 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. Utilizzando un più semplice processore come quello RISC a 8-bit, si potrebbe ulteriormente ridurre la dimensione della memoria ed il consumo di potenza. CaratteristicheGeneral purpose OSEvent-driven OS Models of Computation(MOC)Multi-taskingComunicazione tra macchine a stati finiti estese (EFSM) Scopo dusoGeneraleRivolto a sistemi event- driven Costi di comunicazioneAltiBassi Frequenza di comunicazioneBassaAlta Richiesta di memoriaAmpiaBassa OS typeProcessoreApplicazione Memoria totale istruzioni Memoria dati General Purpose ARM7 thumb Event-drivenARM7 thumb Event-driven8 bit RISC confronto generale tra le caratteristiche degli OS general purpose e quelle degli event- driven confronto generale tra le caratteristiche degli OS general purpose e quelle degli event- driven confronto tra la diversa richiesta di memoria tra le due differenti politiche di OS confronto tra la diversa richiesta di memoria tra le due differenti politiche di OS quindi..

51 Conclusioni sullo studio dei sistemi operativi real-time 51 CONSIDERAZIONI SULLE PERFORMANCE: OS vs EVENT-DRIVEN confronta il conteggio dei cicli totali del processore: ben del general purpose contro i 2554 del TinyOS. confronta il conteggio dei cicli totali del processore: ben del general purpose contro i 2554 del TinyOS. questultimo mostra un fattore di ben 8 miglioramenti, che si traduce in un fattore di 8 riduzioni nel consumo di potenza del processore. questultimo mostra un fattore di ben 8 miglioramenti, che si traduce in un fattore di 8 riduzioni nel consumo di potenza del processore. confronta i costi dei due OS (le porzioni piu basse della barra) in termini di percentuale dei cicli totali. confronta i costi dei due OS (le porzioni piu basse della barra) in termini di percentuale dei cicli totali. come indicazione della propria inefficienza, il sistema operativo general- purpose presenta un costo di OS pari all86% mentre TinyOS circa del 10%. come indicazione della propria inefficienza, il sistema operativo general- purpose presenta un costo di OS pari all86% mentre TinyOS circa del 10%. Esempio: stima di potenza realmente risparmiata da un processore e da i suoi blocchi di memoria: Con tecnologia di 0.18µm e tensione di 1.8V, un ARM7 consuma circa 0.25mW/MHz. Per una memoria di dimensione pari a 64KB per lacceso alla lettura si consuma circa 0.407mW/MHz mentre per laccesso alla scrittura circa 0.447mW/MHz. Se si suppone che il 10% delle istruzioni coinvolgono le operazioni di lettura da memoria ed il 10% quelle di scrittura e di allocazione della memoria, oltre alla scalatura del conteggio del ciclo del processore, il consumo di potenza dei due OSs sono rispettivamente: 0.608mW/MHz e 0.053mW/MHz. Cioè, in altri termini, TinyOS presenta un fattore di miglioramento di potenza pari a 12.


Scaricare ppt "STUDIO COMPARATO DEI PRINCIPALI SISTEMI OPERATIVI IN TEMPO REALE Relatore: Chiar.mo Tesi di Laurea di: Relatore: Chiar.mo Tesi di Laurea di: Prof. Aldo."

Presentazioni simili


Annunci Google