Sistema real-time

Disambiguazione – Se stai cercando altri significati, vedi Real Time.

Glass cockpit di un C-141

ECU di un'autovettura

Lettore MP3

Tabellone di una borsa valori

Esempi di sistemi real-time

In informatica, un sistema real-time (in italiano "sistema in tempo reale") è un calcolatore in cui la correttezza del risultato delle sue computazioni dipende non solo dalla correttezza logica ma anche dalla correttezza temporale. Quest'ultima è spesso espressa come tempo massimo di risposta^[1][2]. Alle operazioni eseguite dai sistemi real-time ci si riferisce con il termine inglese real-time computing o meno frequentemente con il termine italiano elaborazione in tempo reale. A questi sistemi sono spesso associati anche requisiti di affidabilità e interazione con l'ambiente^[1].

Un sistema real-time garantisce un certo tempo di risposta deciso in fase di progettazione. Real-time non è quindi sinonimo di velocità o di elevato throughput: un sistema real-time può essere estremamente lento, ma garantisce un limite superiore al tempo necessario alla computazione^[3]. I due obiettivi di mantenere un alto throughput e una bassa latenza di risposta sono spesso in contrapposizione e portano a compromessi. In ottica di scheduling, l'obiettivo di un sistema normale è minimizzare il tempo di esecuzione dei processi al fine di aumentare la produttività; l'obiettivo di un sistema real-time è il completamento dei processi nel tempo stabilito. Per questo motivo, un sistema real-time non è un sistema estremamente veloce (come invece lo è un supercomputer) ma un sistema estremamente predicibile^[4].

Nei sistemi real-time critici si usano di solito architetture hardware, sistemi operativi e programmi applicativi dedicati, in contrapposizione alla pratica di affidarsi a componenti Commercial Off-The-Shelf. Le tre componenti (hardware, software di base e software applicativo) sono spesso strettamente legate in fase di progettazione del sistema. In questo modo è possibile eseguire le necessarie analisi dei tempi necessarie al fine di ottenere una eventuale certificazione del prodotto finale.

Lo stesso argomento in dettaglio: Sistema operativo real-time.

I programmi real-time possono essere eseguiti autonomamente (tipico di un sistema embedded) o attraverso un sistema operativo, che in questo caso deve essere un sistema operativo real-time. Nel secondo caso non è quindi sufficiente che il programma sia real-time, ma richiede che anche il sistema operativo fornisca un appropriato scheduling real-time^[5]. Esso permette ad applicazioni real-time multiple di essere eseguite sullo stesso sistema; la fattibilità di trovare una politica di scheduling adeguata deve essere verifica a design-time, pena la perdita di deadline. Le applicazioni possono poi essere fornite di priorità, gestita in maniera opportuna dallo scheduling

Come già detto i sistemi real-time non sono sistemi veloci, bensì sistemi che garantiscono un certo tempo di risposta. L'interpretazione corretta di tempo di risposta dipende dall'applicazione stessa. Si può considerare il tempo necessario ad effettuare il calcolo e stampare su schermo, oppure il tempo necessario a inviare i comandi ad un attuatore.

La correttezza temporale del sistema si rende necessaria quando il sistema interagisce con l'ambiente e deve mantenere una certa sincronia con esso. I sistemi che mostrano all'utente le informazioni dell'ambiente o del sistema stesso (es. sala comandi centrali nucleari, avionica, ecc.) non possono avere un offset temporale rispetto al dato reale. La classificazione in hard,firm e soft non dipende solo dai requisiti temporali, ma soprattutto dall'impatto che un errore avrebbe sull'ambiente. Alcuni sistemi necessitano di real-time precise a causa del loro effetto nell'ambiente nel caso in cui il tempo di risposta fosse troppo ampio; dove vi può essere il pericolo di danno a esseri viventi, diventa vitale un sistema real-time e in particolare hard real-time.

Inoltre, i sistemi informatici che emulano sistemi dinamici di teoria del controllo necessitano di intervalli precisi di campionamento, che se troppo distanti da quelli ideali possono portarlo a essere non stabile^[6]. Questo tipo di controllo è essenziale per tutte le applicazioni dell'automazione industriale^[7].

Una prima classificazione dei sistemi real-time riguarda la tollerabilità del non rispetto delle deadline temporali^[1][8][9]:

• Sistema hard real-time: il non rispetto delle deadline non è ammesso; il mancato raggiungimento di una sola deadline può portare a conseguenze catastrofiche nell'ambiente in cui il sistema opera. È tipico delle applicazioni safety-critical;
• Sistema firm real-time: il mancato rispetto di alcune deadline è ammesso purché entro certi limiti; se la deadline è mancata, il risultato non è utilizzabile ma non causa eccessivi problemi;
• Sistema soft real-time: il mancato rispetto di alcune deadline è ammesso purché entro certi limiti; se la deadline è mancata, il sistema può utilizzare il risultato, tipicamente degradando in computer performance senza causare eccessivi problemi.

Spesso la distinzione tra firm e soft non viene marcata e i due concetti sono considerati equivalenti^[10].

I sistemi hard real-time trovano applicazione nella maggior parte dei sistemi Mission-Critical e Safety-Critical, a causa della necessità di reazione ad eventi esterni entro tempi prestabiliti^[11]. Questo concetto è spesso espresso in termini di deadline, ovvero il tempo massimo entro in quale la computazione in reazione ad un evento deve avere termine^[12]. La tradizionale caratteristica di un sistema hard real-time è dovuta al fatto che il fallimento nel rispettare una hard deadline può potenzialmente arrecare gravi danni a persone o cose^[13].

I task di un sistema hard-real time si possono classificare in base alla loro caratteristica di attivazione, ovvero come generano i job da eseguire. Ogni job rappresenta una singola unità di computazione, la quale deve rispettare la deadline relativa del task. La più comune suddivisione è la seguente^[14]:

• Task periodici: i job vengono rilasciati a intervalli di tempo regolari, detto periodo.
• Task dinamici
  • Task aperiodici: i job vengono rilasciati a intervalli di tempo irregolari e non noti; la deadline non può essere così garantita per questi task.
  • Task sporadici: i job vengono rilasciati a intervalli di tempo irregolari, ma di cui si conosce l'intervallo massimo; la deadline in questo caso può essere garantita.

I sistemi soft e firm real-time ammettono che alcune delle dealine possano essere violate, seppur devono essere di numero contenuto. La definizione volutamente vaga è la caratteristica principale di questi sistemi. Infatti, non devono essere confusi con i sistemi weakly hard real-time^[15], ovvero sistemi che ammetto un numero massimo preciso di deadline da violare, oltre il quale il sistema è considerato guasto. I requisiti dei sistemi soft real-time vengono di solito espressi con metriche di Quality of Service^[16], ad esempio il throughput medio. I sistemi firm real-time si differenziano dai sistemi soft real-time per il solo fatto che quando una deadline viene violata, il loro risultato è inutilizzabile e deve quindi essere scartato.

A differenza dei sistemi hard real-time, quando una deadline viene violata, essi degradano in termini di performance invece di essere considerati come guasti. Quando una o più deadline vengono violate, alcuni sistemi real-time reagiscono modificando i parametri dei processi real-time in ottica di approximate computing^[17].

Secondo la precedente classificazione alcuni esempi di sistemi real-time sono:

• Hard real-time:
  • Sistemi di controllo delle centrali nucleari
  • Avionica
  • Sistemi Airbag^[18]
  • In generale tutti i sistemi safety-critical
• Firm real-time:
  • Sistemi di previsione^[8]
  • Cruise control^[9]
• Soft real-time:
  • Riproduzione video ^[19]
  • Gestione QoS nelle reti a pacchetto^[20]

Un sistema hard real-time è solitamente espresso attraverso due modelli: il modello dei task e il modello del sistema, ovvero dell'hardware. Si utilizza frequentemente il termine task, in contesto real-time, per ovviare al problema di distinguere tra processo e thread, rimanendo così sufficientemente generali.

Il modello più comune^[21][22][23] dei task è rappresentato dall'insieme dei task ${\displaystyle T=\{\tau _{1},\tau _{2},...,\tau _{n}\}}$, ciascuno espresso dalla seguente ennupla:

${\displaystyle \tau _{i}=(\Phi _{i},C_{i},T_{i},D_{i})}$

dove:

• ${\displaystyle \Phi _{i}}$ è la fase del task, ovvero la distanza tra il tempo 0 e la prima attivazione del task.
• ${\displaystyle C_{i}}$ è il Worst-Case Execution Time (WCET), cioè il tempo massimo che il task impiegherà a computare il risultato, calcolato senza alcuna preemption.
• ${\displaystyle T_{i}}$ è il periodo di esecuzione.
• ${\displaystyle D_{i}}$ è la deadline relativa, ovvero la dimensione dell'intervallo di tempo compreso tra il tempo di attivazione e il tempo entro quale il task deve terminare.

Il parametro ${\displaystyle T_{i}}$ in caso di task non periodici rappresenta il tempo minimo di interarrivo dei job. Ogni task genera una sequenza di job identificati da ${\displaystyle \tau _{i,1},\tau _{i,2},...}$. Questa sequenza è spesso considerata illimitata ai fini delle analisi, assumendo che il sistema real-time sia costantemente in esecuzione.

Ad ogni job, vengono poi associati dei parametri calcolati da quelli precedentemente mostrati per i task^[23]:

• ${\displaystyle a_{i,k}}$: il tempo di arrivo del k-esimo job (a volte detto di rilascio), computato come ${\displaystyle \Phi _{i}+k\cdot T_{i}}$;
• ${\displaystyle d_{i,k}}$: la deadline assoluta del k-esimo job, calcolata come ${\displaystyle d_{i,k}=a_{i,k}+D_{i}}$;
• ${\displaystyle s_{i,k}}$: il tempo di start del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job inizia la sua esecuzione;
• ${\displaystyle f_{i,k}}$: il tempo di fine del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job termina la sua esecuzione;
• ${\displaystyle R_{i,k}}$: il tempo di risposta del k-esimo job, calcolata come ${\displaystyle R_{i,k}=f_{i,k}-a_{i,k}}$;
• ${\displaystyle X_{i,k}}$: il tempo di slack, ovvero il tempo massimo entro il quale lo start può essere posticipato senza incorrere in una violazione della deadline: ${\displaystyle X_{i,k}=d_{i,k}-a_{i,k}-C_{i}}$

Il sistema è detto temporalmente corretto se, per qualsiasi job k, il tempo di risposta è minore o uguale della deadline relativa, ${\displaystyle R_{i,k}\leq D_{i,k}}$, o, equivalentemente, se il tempo di fine è minore o uguale della deadline assoluta, ${\displaystyle f_{i,k}\leq d_{i,k}}$.

La progettazione e la realizzazione di sistemi real-time è estremamente complessa e costosa. Per questo motivo la scelta di utilizzare un sistema real-time deve essere dettata da una vera necessità, in particolare per i sistemi hard real-time. La progettazione di questi sistemi richiede diverse analisi approfondite di timing e di verifica della correttezza del programma stesso.

I vari scogli ai sistemi real-time sono di diversa natura e possono essere riassunti nella seguente classificazione^[24]:

• Complessità dell'ambiente con cui interagire
  • velocità richiesta, numero di task da eseguire, ecc.
  • gestione degli interrupt
• Ripristino dopo un guasto
  • riconoscimento, isolamento e risoluzione di un guasto, che sia hardware, software, ecc.
  • utilizzo di speciali routine
• Architetture distribuite
  • gestione della comunicazione con altri sistemi
  • consistenza delle informazioni
  • Load balancing
• Race condition (Corsa critica)
  • problemi tipici degli scheduler: evitare in modo assoluto deadlock e starvation.

Lo stesso argomento in dettaglio: Worst-case execution time.

Il Worst-Case Execution Time (WCET) rappresenta la stima del tempo di esecuzione massimo necessaria a costruire la prova formale che il sistema sia corretto temporalmente. La stima di questo valore non è banale, specialmente nelle architettura moderne che utilizzano componenti COTS^[25]. Questi sistemi -- a causa dell'introduzione di funzionalità complesse come multi-core, cache, pipeline, ecc. -- sono difficilmente predicibili in tempo, rendendo la computazione del WCET estremamente difficile e/o troppo computazionalmente complessa^[26]. Per questo motivo si calcolano solitamente delle stime, che tuttavia, al fine di garantire la sicurezza, risultano spesso essere esageramente pessimistiche, rendendo quindi il WCET stimato troppo lontano dal WCET reale e, conseguentemente, inutilizzabile ai fini di scheduling. Al 2020, la stima di WCET per architetture complesse è ancora un argomento di ricerca aperto^[27].

• Sistema operativo in tempo reale
• Base di dati in tempo reale

• Mauro Cappelli, Sistemi real-time, in Enciclopedia della scienza e della tecnica, Istituto dell'Enciclopedia Italiana, 2007-2008.
• (EN) hard real-time system, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.

Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica