Sistema operativo real-time

Da Wikipedia, l'enciclopedia libera.

Un sistema operativo real-time o in tempo reale (abbreviato in RTOS) è un sistema operativo specializzato per il supporto di applicazioni software 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 determinista, 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 sorgente]

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.

Sistemi Hard real-time e soft real-time[modifica | modifica sorgente]

I sistemi real-time si possono dividere quindi in due categorie:

  • I sistemi "hard" sono quelli che possono garantire la fattibilità di schedulazione di un insieme di task hard e soft real-time.
  • I sistemi "soft" sono quelli che possono garantire la fattibilità di schedulazione di un insieme di soli task soft real-time.

Per chiarire meglio il concetto si può pensare ad un sistema real-time come ad un sistema che, dato un insieme di n task, ognuno con i propri vincoli temporali d_i (deadline del task i-esimo), è in grado di minimizzare la funzione di costo definita come:

K_S = \sum_{i}^nK_i(t)

dove K_i(t) è la funzione di costo del task i-esimo definita come:

K_i(t) = \begin{cases} 0 & t <= d_i \\ \infty & t > d_i \end{cases}

se il task i-esimo è di tipo hard real-time, o come:

K_i(t) = \begin{cases} 0 & t <= d_i \\ f(t) & t > d_i \end{cases}

se il task i-esimo è di tipo soft real-time, dove si è indicato con f(t) una funzione monotona crescente all'aumentare del tempo che scorre.

I task di tipo hard real-time dovranno quindi essere schedulati in modo da terminare ad un istante t' minore della deadline in modo da far valere la funzione di costo 0 e non \infty; mentre i task soft real-time dovranno anche loro far valere 0 la funzione di costo relativa ma, in questo caso, uno sfondamento della deadline t' > d_i non manderà il costo globale del sistema all'infinito (equivalente al disastro).

I sistemi operativi general purpose non supportano la funzionalità hard real-time ma possono supportare quelle di tipo soft (ad esempio Linux è un sistema soft real-time).

Caratteristiche di un sistema real-time[modifica | modifica sorgente]

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 K_S 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 sorgente]

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 sorgente]

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ò rubare il bus alla 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 non sfondare una deadline piuttosto che consumare poca energia, quindi questi meccanismi vengono disattivati.

Scelta del sistema operativo real time[modifica | modifica sorgente]

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 sorgente]

  • Lo schedulatore, 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 sorgente]

Alcuni sistemi operativi in grado di lavorare in real-time su adeguate architetture hardware sono: