Sistema real-time

Da Wikipedia, l'enciclopedia libera.
Jump to navigation Jump to search
Nota disambigua.svg Disambiguazione – Se stai cercando altri significati, vedi Real Time.
Esempi di sistemi real-time. In senso orario dall'alto: il glass cockpit di un C-141, una ECU di un'autovettura, un tabellone di una borsa valori, un lettore MP3.

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 computazioni eseguite dai sistemi real-time ci si riferisce con il termine inglese real-time computing o meno frequentemente con il termine italiano computazioni in tempo reale. A questi sistemi sono spesso associati anche requisiti di affidabilità e interazione con l'ambiente[1].

Definizione[modifica | modifica wikitesto]

Un sistema real-time garantisce un certo tempo di risposta deciso a design-time. Real-time non è quindi sinonimo di velocità o di elevato throughput: un sistema real-time può essere estremamente lento, ma garantisce un upper-bound preciso 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 generano un trade-off. In ottica di scheduling, l'obiettivo di un sistema normale è minimizzare il tempo di esecuzione dei task al fine di aumentare il throughput medio; l'obiettivo di un sistema real-time è il completamento dei task 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.

Sistemi operativi real-time[modifica | modifica wikitesto]

Magnifying glass icon mgx2.svgLo 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

La necessità di tempi di risposta certi[modifica | modifica wikitesto]

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

Classificazione dei sistemi real-time[modifica | modifica wikitesto]

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

Hard Real-Time[modifica | modifica wikitesto]

I sistemi delle centrali nucleari tipicamente necessitano di sistemi hard real-time, in foto la sala della centrale di Leningrado

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 terminata[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].

Requisiti e caratteristiche temporali[modifica | modifica wikitesto]

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.

Soft e Firm Real-Time[modifica | modifica wikitesto]

Un lettore multimediale è un esempio soft real-time

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

Esempi[modifica | modifica wikitesto]

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

Modelli matematici per i sistemi hard real-time[modifica | modifica wikitesto]

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 , ciascuno espresso dalla seguente ennupla:

Real-time scheduling model.svg

dove:

  • è la fase del task, ovvero la distanza tra il tempo 0 e la prima attivazione del task.
  • è il Worst-Case Execution Time (WCET), cioè il tempo massimo che il task impiegherà a computare il risultato, calcolato senza alcuna preemption.
  • è il periodo di esecuzione.
  • è 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 è 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 può essere posticipato senza incorrere in una violazione della deadline:

Il sistema è detto temporalmente corretto se, per qualsiasi job k, il tempo di risposta è minore o uguale della deadline relativa, , o, equivalentemente, se il tempo di fine è minore o uguale della deadline assoluta, .

Difficoltà di realizzazione[modifica | modifica wikitesto]

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)

Stima del WCET[modifica | modifica wikitesto]

Magnifying glass icon mgx2.svgLo 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].

Note[modifica | modifica wikitesto]

  1. ^ 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.
  2. ^ Marco Giancola, Sistemi Real-Time (PDF), su matematicamente.it. URL consultato il luglio 2016.
  3. ^ Rigutini Leonardo, Sistemi operativi Real-Time (PDF), Università di Siena (archiviato dall'url originale il 6 agosto 2016).
  4. ^ (EN) John Stankovic, Misconceptions about real-time computing: a serious problem for next-generation systems, in Computer, vol. 21, n. 10, IEEE, October 1988.
  5. ^ Jürgen Assfalg, Algoritmi di Scheduling (PDF), Università di Firenze. URL consultato il luglio 2016 (archiviato dall'url originale il 14 ottobre 2009).
  6. ^ (EN) Tarek Abdelzaher, Yixin Diao, Joseph L. Hellerstein, Chenyang Lu, Xiaoyun Zhu, Introduction to Control Theory And Its Application to Computing Systems (PDF).
  7. ^ Human Machine Interface (HMI) Guide (PDF), Texas Instruments. URL consultato il 19 luglio 2016 (archiviato dall'url originale il 12 settembre 2015).
  8. ^ a b Stefan M. Petters, Real-Time Systems (PDF), UNSW Australia. URL consultato il luglio 2016.
  9. ^ 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.
  10. ^ Pier Luca Montessoro, I sistemi operativi real-time (PDF), Università degli Studi di Udine. URL consultato il luglio 2016.
  11. ^ Paul Pop, Safety-critical systems, Technical University of Denmark. URL consultato il luglio 2016.
  12. ^ Gianluca Palli, Introduzione ai sistemi real-time (PDF), Università di Bologna. URL consultato il luglio 2016 (archiviato dall'url originale il 22 settembre 2015).
  13. ^ TimeSys Corporation, The Concise Handbook Of Real-Time Systems, 2002.
  14. ^ Tasks in Real Time systems, su geeksforgeeks.org. URL consultato il 6 gennaio 2020.
  15. ^ G. Bernat, A. Burns, A. Llmosi, Weakly Hard Real-Time Systems (PDF), in Transactions on Computers, IEEE, 2001.
  16. ^ Introduction to Real-time Systems, Open Source Robotics Foundation. URL consultato il 7 gennaio 2020.
  17. ^ Scott A. Brandt, Soft real-time systems, su users.soe.ucsc.edu. URL consultato il 7 gennaio 2020.
  18. ^ Hard and Soft Real-Time, Fedora. URL consultato il luglio 2016.
  19. ^ Hard and soft real time, LWN.net. URL consultato il luglio 2016.
  20. ^ 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.
  21. ^ (EN) Tasks in Real Time systems, su geeksforgeeks.org. URL consultato il 5 gennaio 2020.
  22. ^ (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.
  23. ^ a b (EN) Giorgio C. Buttazzo, Hard Real-Time Computing Systems, 2011, ISBN 978-1-4614-0675-4.
  24. ^ (EN) Issues in Real-time System Design, eventhelix.com. URL consultato il 20 luglio 2016.
  25. ^ H Shah, A Raabe, A Knoll, Challenges of WCET analysis in COTS multi-core due to different levels of abstraction (PDF), in hiRES, 2013.
  26. ^ Dakshina Dasari, Benny Akesson, Vincent Nélis, 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.
  27. ^ ECRTS Call for Papers, su ecrts.org, 2020. URL consultato il 6 gennaio 2020.

Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]