Sistema operativo real-time
Un sistema operativo real-time o in tempo reale (abbreviato in RTOS) è un sistema operativo specializzato per il supporto di applicazioni su sistemi real-time. Questi sistemi vengono utilizzati tipicamente in ambito industriale (controllo di processo, pilotaggio di robot, trasferimento dati nelle telecomunicazioni) o comunque dove sia necessario ottenere una risposta dal sistema entro un tempo prefissato.
Un sistema operativo real-time non deve essere necessariamente veloce: non è importante l'intervallo di tempo in cui il sistema operativo/applicativo deve reagire; l'importante è che risponda entro un tempo massimo pre-determinato. In altre parole il sistema deve essere prevedibile o piuttosto deterministico, nel senso che nel sistema si possa conoscere il tempismo reale (nei migliori o peggiori dei casi, termini che vengono dall'inglese best case / worst case) di un determinato processo o elaborazione.
In pratica un sistema real-time deve garantire che una elaborazione (o task) termini entro un dato vincolo temporale o scadenza (detta in gergo deadline). Per garantire questo è richiesto che la schedulazione delle operazioni sia fattibile. Il concetto di fattibilità di schedulazione è alla base della teoria dei sistemi real-time ed è quello che ci permette di dire se un insieme di task sia eseguibile o meno in funzione dei vincoli temporali dati.
Task periodici/aperiodici e hard/soft real-time
[modifica | modifica wikitesto]I task di un sistema real-time possono essere:
- periodici: quando un task consiste in una sequenza di attività attivate con cadenza regolare
- aperiodici: quando un task consiste in una sequenza di attività attivate ad intervalli irregolari.
- sporadici: quando un task consiste in una sequenza di attività attivate in maniera impredicibile (tipicamente task che corrispondono a richieste di utenti)
I task di tipo periodico sono propri di un sistema di controllo tempo discreto.
Quando si ha a che fare con task di tipo periodico si parla anche di periodo di esecuzione con il quale si intende il lasso di tempo che intercorre tra due esecuzioni di un task periodico. È uso comune far coincidere la deadline con l'inverso del periodo poiché questo è il limite massimo di esecuzione di un task.
I task di un sistema real-time possono però essere:
- soft real-time: un task che non rispetta la sua scadenza (in gergo si dice sfondare la deadline) provoca un danno non irreparabile al sistema. Il superamento della deadline produce un degrado delle prestazioni proporzionale al tempo di superamento della deadline.
- hard real-time: un task che nel caso superi temporalmente la sua deadline provoca un danno irreparabile al sistema.
- "anytime" : sono tasks che elaborano iterativamente gli stessi dati per "raffinarli" sempre di più. I dati elaborati dai tasks anytime rispondono a requisiti di qualità minima e qualità massima. Sono quindi considerati "hard" fino a che i dati non raggiungono la qualità minima, diventano "soft" prima di raggiungere la qualità massima, dopodiché non verranno più eseguiti
Sostanzialmente questa distinzione si traduce nella diversa quantificazione dei costi di una possibile inesattezza temporale del sistema. Un esempio di task soft real-time può essere un riproduttore DVD, in cui il mancato rispetto dei vincoli si traduce in un degrado della qualità del filmato, ma non pregiudica il proseguimento della riproduzione; mentre un task hard real-time può essere il controllore della temperatura del nocciolo di una centrale nucleare, dove il mancato rispetto dei vincoli temporali può provocare un evidente disastro.
Caratteristiche di un sistema real-time
[modifica | modifica wikitesto]Un sistema real-time dovrebbe possedere le seguenti caratteristiche:
- Schedulazione ottima: tutti i task sono noti a priori così come i vincoli temporali, dovrebbe essere possibile dunque avere uno schedulatore che implementi una schedulazione che minimizzi al massimo la funzione di costo presentata prima.
- Condivisione delle risorse: i task sono entità separate ma che concorrono ad uno stesso scopo, pertanto non è necessario avere spazi di indirizzamento separati.
- Garanzia di esecuzione: tutti i task di tipo hard real-time devono terminare entro le proprie deadline quindi, nel caso in cui arrivi un nuovo task o un task non possa completare entro la deadline, una notifica anticipata del sistema può essere utilizzata per impedire l'esecuzione del nuovo task o di recuperare l'esecuzione del task che sta per sfondare.
- Prevedibilità delle chiamate di sistema: il sistema deve essere in grado di valutare i tempi di calcolo di ogni task per determinare la schedulazione fattibile, quindi ogni chiamata di sistema deve avere un tempo di esecuzione massimo ben definito in modo da non introdurre ritardi indefiniti.
Scheduling di sistemi Real Time
[modifica | modifica wikitesto]Gli algoritmi di scheduling più utilizzati per i sistemi real time sono essenzialmente tre:
- EDD (Earliest Due Date)
- EDF (Earliest Deadline First)
- RM (Rate Monotonic)
L'EDD ha le seguenti caratteristiche
- Tutti i task arrivano simultaneamente
- La priorità è statica
- Non necessita di prelazione
- Minimizza la latenza.
L'EDF ha le seguenti caratteristiche:
- I task possono arrivare in un qualsiasi istante.
- Priorità dinamica in base alla scadenza imminente.
- Utilizza la capacità dei task di fare prelazione su altri.
- Minimizza la latenza.
RM è utilizzabile solo per task periodici, ha le seguenti caratteristiche:
- Ai task viene assegnata una priorità statica proporzionale alla frequenza di arrivo.
- Un gruppo di task è schedulabile se conosciuta la funzione di utilizzazione U è U_lub<U<1
La funzione U esprime il tasso di utilizzazione del processore, la funzione risulta limitata superiormente ed è SupU=1,indicato con U_lub fattore di utilizzazione minimo. Diremo che una funzione è certamente schedulabile con Rate Monotonic se U<U_lub, risulta invece non schedulabile se U>1. Se U_lub<U<1 non abbiamo certezza sulla schedulabilità. L'algoritmo EDF in alcune circostanze risulta migliore di RM perché garantisce la schedulabilità semplicemente per U<1
I fattori che minano la prevedibilità
[modifica | modifica wikitesto]I prodotti delle famiglie Windows e Unix non soddisfano le caratteristiche tipiche di un sistema real-time: ad esempio, pur gestendo l'esecuzione di più processi con pre-rilascio, non è possibile prevedere in alcun modo quale sarà il tempo di esecuzione di un singolo processo. Inoltre l'utilizzo di hard disk per la conservazione dei dati, dispositivi USB o altri dispositivi che introducono forti latenze di esecuzione da parte della CPU, rende impossibile stabilire con certezza quanto tempo sarà necessario per reperire l'informazione utile alla corretta esecuzione del codice.
Ci sono diversi fattori che causano la non prevedibilità nella risposta del sistema operativo. Tra di essi, i principali sono i seguenti:
- Il DMA: può limitare o bloccare il bus dalla CPU, ritardando l'esecuzione di un task critico. In un sistema real-time si preferisce quindi disattivarlo o usarlo in modalità timeslice dove si assegna in maniera costante e fissa il bus al DMA anche se non ci sono operazioni da fare.
- La cache: può causare non prevedibilità poiché esistono casi in cui essa fallisce e può causare ritardi nell'accesso alla memoria da parte della CPU. Dovendo considerare quindi il caso peggiore si preferisce non usarla affatto.
- Meccanismi di gestione della memoria: queste tecniche non devono introdurre ritardi non prevedibili durante l'esecuzione di task critici, ad esempio la paginazione può causare dei page fault intollerabili per un sistema hard real-time. Tipicamente si usa la segmentazione o la partizione statica della memoria.
- Le interruzioni: sono generate da dispositivi periferici quando hanno qualche informazione da scambiare con la CPU. Queste interruzioni durante l'esecuzione di un task critico generano ritardi non prevedibili e quindi si preferisce disattivarle.
- I sistemi di power management: sono meccanismi hardware che possono rallentare la CPU o far eseguire ad essa del codice utile a dissipare minor energia. È chiaro che in un sistema real-time è importante rispettare una deadline piuttosto che consumare poca energia, quindi questi meccanismi vengono disattivati.
Scelta del sistema operativo real time
[modifica | modifica wikitesto]Tra gli RTOS commerciali troviamo il POSIX-conformant (ad esempio LynxOS che è Unix compatibile) e non POSIX-conformant come ad esempio VxWorks (che supporta in parte gli standard POSIX). Per quanto riguarda i sistemi Open Source è possibile l'uso di Linux, con opportune precauzioni, o di RTAI/Xenomai.
Problemi del real-time in Linux
[modifica | modifica wikitesto]- Lo scheduler, che ha come obiettivo l'assegnazione della CPU ai vari processi, non può conoscere i requisiti temporali dei vari processi real-time.
- Anche se si usa la schedulazione FIFO o FIFO Round Robin che tendono ad aumentare la prevedibilità del sistema, non si hanno comunque garanzie sui ritardi introdotti dalle chiamate di sistema e dalle attività del kernel.
Esempi di sistemi operativi RT
[modifica | modifica wikitesto]Alcuni sistemi operativi in grado di lavorare in real-time su adeguate architetture hardware sono:
Altri progetti
[modifica | modifica wikitesto]
Wikimedia Commons contiene immagini o altri file su sistema operativo real-time
Collegamenti esterni
[modifica | modifica wikitesto]- (EN) hard real-time system, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.
