Esempi di sistemi real-time
In
informatica
, un
sistema real-time
(in
italiano
"sistema in tempo reale") e un
calcolatore
in cui la correttezza del risultato delle sue computazioni dipende
non solo dalla
correttezza logica
ma anche dalla correttezza temporale. Quest'ultima e 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
affidabilita
e
interazione
con l'ambiente
[1]
.
Un sistema real-time garantisce un certo
tempo di risposta
deciso in fase di
progettazione
. Real-time non e quindi sinonimo di velocita o di elevato
throughput
: un sistema real-time puo 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 e minimizzare il tempo di esecuzione dei
processi
al fine di aumentare la
produttivita
; l'obiettivo di un sistema real-time e il completamento dei processi nel tempo stabilito. Per questo motivo, un sistema real-time non e un sistema estremamente veloce (come invece lo e 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 e possibile eseguire le necessarie analisi dei tempi necessarie al fine di ottenere una eventuale
certificazione
del prodotto finale.
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 e 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 fattibilita 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 priorita, gestita in maniera opportuna dallo scheduling
Come gia detto i sistemi real-time non sono sistemi
veloci
, bensi sistemi che garantiscono un certo
tempo di risposta
. L'interpretazione corretta di tempo di risposta dipende dall'applicazione stessa. Si puo 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 puo 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 e essenziale per tutte le applicazioni dell'
automazione industriale
[7]
.
Una prima classificazione dei sistemi real-time riguarda la tollerabilita del non rispetto delle deadline temporali
[1]
[8]
[9]
:
- Sistema hard real-time: il non rispetto delle deadline non e ammesso; il mancato raggiungimento di una sola deadline puo portare a conseguenze catastrofiche nell'ambiente in cui il sistema opera. E tipico delle applicazioni
safety-critical
;
- Sistema firm real-time: il mancato rispetto di alcune deadline e ammesso purche entro certi limiti; se la deadline e mancata, il risultato non e utilizzabile ma non causa eccessivi problemi;
- Sistema soft real-time: il mancato rispetto di alcune deadline e ammesso purche entro certi limiti; se la deadline e mancata, il sistema puo 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 necessita di reazione ad
eventi
esterni entro tempi prestabiliti
[11]
.
Questo concetto e 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 e dovuta al fatto che il fallimento nel rispettare una hard deadline puo 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 unita di computazione, la quale deve rispettare la deadline relativa del task. La piu comune suddivisione e 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 puo essere cosi 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 puo 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 e 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 e 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 e 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 piu 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:
- Firm real-time:
- Soft real-time:
Un sistema hard real-time e 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 cosi sufficientemente generali.
Il modello piu comune
[21]
[22]
[23]
dei task e rappresentato dall'insieme dei task
, ciascuno espresso dalla seguente
ennupla
:
dove:
- e la fase del task, ovvero la distanza tra il tempo 0 e la prima attivazione del task.
- e il
Worst-Case Execution Time (WCET)
, cioe il tempo massimo che il task impieghera a computare il risultato, calcolato senza alcuna
preemption
.
- e il
periodo
di esecuzione.
- e 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
in caso di task non periodici rappresenta il tempo minimo di interarrivo dei job.
Ogni task genera una sequenza di
job
identificati da
. Questa sequenza e 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]
:
- : il tempo di arrivo del k-esimo job (a volte detto di rilascio), computato come
;
- : la deadline assoluta del k-esimo job, calcolata come
;
- : il tempo di start del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job inizia la sua esecuzione;
- : il tempo di fine del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job termina la sua esecuzione;
- : il tempo di risposta del k-esimo job, calcolata come
;
- : il tempo di slack, ovvero il tempo massimo entro il quale lo start puo essere posticipato senza incorrere in una violazione della deadline:
Il sistema e detto
temporalmente corretto
se, per qualsiasi job k, il tempo di risposta e minore o uguale della deadline relativa,
, o, equivalentemente, se il tempo di fine e minore o uguale della deadline assoluta,
.
La progettazione e la realizzazione di sistemi real-time e estremamente complessa e costosa. Per questo motivo la scelta di utilizzare un sistema real-time deve essere dettata da una vera necessita, 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]
:
- Complessita dell'ambiente con cui interagire
- velocita 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)
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 e banale, specialmente nelle architettura moderne che utilizzano componenti
COTS
[25]
. Questi sistemi -- a causa dell'introduzione di funzionalita 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 e ancora un argomento di
ricerca
aperto
[27]
.
- ^
a
b
c
Shin, Kang G., Parameswaran Ramanathan,
Real-Time Computing: A New Discipline of Computer Science and Engineering
, in
Proceedings of the IEEE
, 1994.
- ^
Vincenzo Suraci,
Sistemi Real-Time
(
PDF
), su
diag.uniroma1.it
.
URL consultato il 21 febbraio 2023
.
- ^
Rigutini Leonardo,
Sistemi operativi Real-Time
(
PDF
), su
dii.unisi.it
, Universita di Siena
(archiviato dall'
url originale
il 6 agosto 2016)
.
- ^
(
EN
) John Stankovic,
Misconceptions about real-time computing: a serious problem for next-generation systems
, in
Computer
, vol. 21, n. 10, IEEE, October 1988.
- ^
Jurgen Assfalg,
Algoritmi di Scheduling
(
PDF
), su
dsi.unifi.it
, Universita di Firenze.
URL consultato il luglio 2016
(archiviato dall'
url originale
il 14 ottobre 2009)
.
- ^
(
EN
) Tarek Abdelzaher, Yixin Diao, Joseph L. Hellerstein, Chenyang Lu, Xiaoyun Zhu,
Introduction to Control Theory And Its Application to Computing Systems
(
PDF
).
- ^
Human Machine Interface (HMI) Guide
(
PDF
), su
ti.com
, Texas Instruments.
URL consultato il 19 luglio 2016
(archiviato dall'
url originale
il 12 settembre 2015)
.
- ^
a
b
Stefan M. Petters,
Real-Time Systems
(
PDF
), su
cse.unsw.edu.au
, UNSW Australia.
URL consultato il luglio 2016
.
- ^
a
b
Donglin Liu, Xiaobo Sharon Hu, Senior Member, IEEE, Michael D. Lemmon, Qiang Ling,
Firm Real-Time System Scheduling Based on a Novel QoS Constraint
, in
IEEE Transactions on Computers
, 2006.
- ^
Pier Luca Montessoro,
I sistemi operativi real-time
(
PDF
), su
web.diegm.uniud.it
, Universita degli Studi di Udine.
URL consultato il luglio 2016
(archiviato dall'
url originale
il 14 agosto 2016)
.
- ^
Paul Pop,
Safety-critical systems
, su
imm.dtu.dk
, Technical University of Denmark.
URL consultato il luglio 2016
.
- ^
Gianluca Palli,
Introduzione ai sistemi real-time
(
PDF
), su
www-lar.deis.unibo.it
, Universita di Bologna.
URL consultato il luglio 2016
(archiviato dall'
url originale
il 22 settembre 2015)
.
- ^
TimeSys Corporation,
The Concise Handbook Of Real-Time Systems
, 2002.
- ^
Tasks in Real Time systems
, su
geeksforgeeks.org
.
URL consultato il 6 gennaio 2020
.
- ^
G. Bernat, A. Burns, A. Llmosi,
Weakly Hard Real-Time Systems
(
PDF
), in
Transactions on Computers
, IEEE, 2001.
- ^
Introduction to Real-time Systems
, su
design.ros2.org
, Open Source Robotics Foundation.
URL consultato il 7 gennaio 2020
.
- ^
Scott A. Brandt,
Soft real-time systems
, su
users.soe.ucsc.edu
.
URL consultato il 7 gennaio 2020
.
- ^
Hard and Soft Real-Time
, su
docs.fedoraproject.org
,
Fedora
.
URL consultato il luglio 2016
(archiviato dall'
url originale
il 13 settembre 2016)
.
- ^
Hard and soft real time
, su
lwn.net
.
URL consultato il luglio 2016
.
- ^
Karthik Channakeshava, Kaustubh S. Phanseg, Luiz A. DaSilva Binoy, Ravindran
Scott F. Midkiff, E. Douglas Jensen,
IP Quality of Service Support for Soft Real-Time Applications
, in
IEEE Euromicro Conf. Real-Time Systems
, 2005.
- ^
(
EN
)
Tasks in Real Time systems
, su
geeksforgeeks.org
.
URL consultato il 5 gennaio 2020
.
- ^
(
EN
)
et.engr.iupui.edu
,
http://et.engr.iupui.edu/~dskim/Classes/ESW5004/RTSys%20Lecture%20Note%20-%20ch02%20A%20Reference%20Model%20for%20Real-Time%20Systems.pdf
.
URL consultato il 5 gennaio 2020
.
- ^
a
b
(
EN
) Giorgio C. Buttazzo,
Hard Real-Time Computing Systems
, 2011,
ISBN
978-1-4614-0675-4
.
- ^
(
EN
)
Issues in Real-time System Design
, su
eventhelix.com
.
URL consultato il 20 luglio 2016
.
- ^
H Shah, A Raabe, A Knoll,
Challenges of WCET analysis in COTS multi-core due to different levels of abstraction
(
PDF
), in
hiRES
, 2013.
- ^
Dakshina Dasari, Benny Akesson, Vincent Nelis, Muhammad Ali Awan, Stefan M. Petters,
Identifying the sources of unpredictability in COTS-based multicore systems
(
abstract
), in
8th IEEE International Symposium on Industrial Embedded Systems (SIES)
, IEEE, 2013.
- ^
ECRTS Call for Papers
, su
ecrts.org
, 2020.
URL consultato il 6 gennaio 2020
.