Sistema real-time: differenze tra le versioni

Versione delle 08:53, 19 lug 2016

Versione attuale delle 02:29, 3 giu 2024

(70 versioni intermedie di 24 utenti non mostrate)

Riga 1:

{{nota disambigua||Real Time}}

{{Immagine multipla

| per riga = 2

| larghezza totale=300

| immagine1 = C-141C Glass Cockpit Upgrade.JPEG

| didascalia1 = [[Glass cockpit]] di un [[C-141]]

| immagine2 = 2008-04-17_ECU.jpg

| didascalia2 = [[Unità di controllo elettronico (elettromeccanica)|ECU]] di un'autovettura

| immagine3 = Zen_mp3_player.JPG

| didascalia3 = [[Lettore MP3]]

| immagine4 = Philippine-stock-market-board.jpg

| didascalia4 = Tabellone di una [[borsa valori]]

| sotto = <div style="text-align:center">Esempi di sistemi real-time</div>

}}

In [[informatica]], un '''sistema real-time''' (in [[lingua italiana|italiano]] "sistema in tempo reale") è un [[Sistema_informatico|calcolatore]] in cui la correttezza del risultato delle sue computazioni dipende

non solo dalla [[Correttezza (logica matematica)|correttezza logica]] ma anche dalla correttezza temporale. Quest'ultima è spesso espressa come [[latenza|tempo massimo di risposta]]<ref name="ShinIEEE">{{cita pubblicazione|titolo=Real-Time Computing: A New Discipline of Computer Science and Engineering|rivista=Proceedings of the IEEE|anno=1994|autore=Shin, Kang G.|coautori=Parameswaran Ramanathan}}</ref><ref>{{cita web|url=http://www.diag.uniroma1.it/deluca/automation/Automazione_SistemiRealTime.pdf|titolo=Sistemi Real-Time|autore=Vincenzo Suraci|accesso=21 febbraio 2023}}</ref>.

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<ref name="ShinIEEE" />.

== Definizione ==

{{F|software|marzo 2013|Nessuna fonte}}

Un sistema real-time garantisce un certo [[latenza|tempo di risposta]] deciso in fase di [[Progettazione (ingegneria del software)|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<ref>{{cita web|url=http://www.dii.unisi.it/~rigutini/teaching/talks/Sistemi%20Real-Time.pdf|autore=Rigutini Leonardo|editore=Università di Siena|titolo=Sistemi operativi Real-Time|urlmorto=sì|urlarchivio=https://web.archive.org/web/20160806180858/http://www.dii.unisi.it/~rigutini/teaching/talks/Sistemi%20Real-Time.pdf|dataarchivio=6 agosto 2016}}</ref>.

'''Real-time''' (in [[lingua italiana| italiano]] "''tempo reale''"), più precisamente '''real-time computing (RTC)''', è un termine utilizzato in ambito [[informatica|informatico]] per indicare le [[computazione|computazioni]] per i quali la correttezza del risultato dipende non solo dalla [[Correttezza (logica matematica)|correttezza logica]] ma anche dal [[tempo di risposta]]<ref name="ShinIEEE">{{cita pubblicazione|titolo=Real-Time Computing: A New Discipline of Computer Science and Engineering|rivista=Proceedings of the IEEE|anno=1994|autore=Shin, Kang G.|coautori=Parameswaran Ramanathan}}</ref><ref>{{cita web|url=http://www.matematicamente.it/staticfiles/approfondimenti/Giancola-SistemiRT.pdf|titolo=Sistemi Real-Time|autore=Marco Giancola|accesso=luglio 2016}}</ref>. Estendendo la definizione, possono essere anche aggiunti requisiti di [[affidabilità]] e [[interazione]] con l'ambiente <ref name="ShinIEEE" />.

I due obiettivi di mantenere un alto [[throughput]] e una bassa [[latenza]] di risposta sono spesso in contrapposizione e portano a [[trade-off|compromessi]].

In ottica di ''[[scheduling]]'', l'obiettivo di un sistema normale è minimizzare il tempo di esecuzione dei [[Processo (informatica)|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 [[Determinismo|predicibile]]<ref>{{cita pubblicazione|nome=John|cognome=Stankovic|titolo=Misconceptions about real-time computing: a serious problem for next-generation systems|rivista=Computer|editore=IEEE|volume=21|numero=10|anno=1988|mese=October|url=https://ieeexplore.ieee.org/document/7053|lingua=inglese}}</ref>.

Nei sistemi real-time [[sistema critico|critici]] si usano di solito [[Architettura (computer)|architetture hardware]], [[Sistema operativo|sistemi operativi]] e programmi applicativi dedicati, in contrapposizione alla pratica di affidarsi a componenti [[COTS|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.

Un sistema in grado di esegure computazioni real-time, considerato sia dalla parte [[hardware]] che quella [[software]], è detto '''sistema real-time'''. Trovano applicazione nella maggior parte dei sistemi [[Mission Critical System|Mission Critical]] e [[Sistema critico|Safety Critical]], a causa della necessità di reazione ad [[Programmazione ad eventi|eventi]] esterni entro tempi prestabiliti<ref>{{cita web|url=http://www.imm.dtu.dk/~paupo/safety_critical.html|titolo=Safety-critical systems|autore=Paul Pop|editore=Technical University of Denmark|accesso=luglio 2016}}</ref>. In questo caso si parla di '''deadline''', ovvero il tempo entro in quale la computazione in reazione ad un evento deve avere terminato<ref>{{cita web|url=http://www-lar.deis.unibo.it/people/gpalli/files/SEC-E01-Introduzione_ai_sistemi_realtime.pdf|titolo=Introduzione ai sistemi real-time|autore=Gianluca Palli|editore=Università di Bologna|accesso=luglio 2016}}</ref>.

=== Sistemi operativi real-time ===

== Concetti introduttivi ==

{{vedi anche|Sistema operativo real-time}}

Un sistema real-time garantisce un certo [[tempo di risposta]] deciso a [[Progettazione (ingegneria del software)|design-time]]. Real-time non è quindi sinonimo di '''velocità''': un sistema real-time può essere estremamente lento, ma garantisce un upper-bound preciso al tempo necessario alla computazione<ref>{{cita web|url=http://www.dii.unisi.it/~rigutini/teaching/talks/Sistemi%20Real-Time.pdf|</ref>. In ottica di [[scheduling]], l'obiettivo di un sistema normale è minimizzare il tempo di esecuzione dei [[Processo (informatica)|task]]; l'obiettivo di un sistema real-time è il completamento dei [[Processo (informatica)|task]] nel tempo stabilito.

I [[Programma (informatica)|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 [[Sistema operativo real-time#Scheduling di sistemi Real Time|scheduling real-time]]<ref>{{cita web|titolo=Algoritmi di Scheduling|url=http://www.dsi.unifi.it/~assfalg/SO/20042005/scheduling-rt.pdf|autore=Jürgen Assfalg|editore=Università di Firenze|accesso=luglio 2016|urlmorto=sì|urlarchivio=https://web.archive.org/web/20091014185829/http://www.dsi.unifi.it/~assfalg/SO/20042005/scheduling-rt.pdf|dataarchivio=14 ottobre 2009}}</ref>. Esso permette ad [[applicazione (informatica)|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 ===

I [[Programma (informatica)|programmi]] real-time possono essere eseguiti autonomamente (tipico dei [[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 [[Sistema_operativo_real-time#Scheduling_di_sistemi_Real_Time|scheduling real-time]]<ref>{{cita web|url=http://www.dsi.unifi.it/~assfalg/SO/20042005/scheduling-rt.pdf|autore=Jürgen Assfalg|editore=Università di Firenze|accesso=luglio 2016}}</ref>.

Come già detto i sistemi real-time non sono sistemi ''veloci'', bensì sistemi che garantiscono un certo [[latenza|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''.

Per quanto il termine real-time venga spesso riferito ai [[sistema operativo| sistemi operativi]] (vedi ''[[sistema operativo real-time]]'' ), la necessità di una risposta real-time è intrinseca al problema da risolvere prima che essere caratteristica della soluzione trovata. Una tipica applicazione in tempo reale è il controllo di .

Inoltre, i sistemi informatici che emulano [[Sistema dinamico|sistemi dinamici]] di [[teoria del controllo]] necessitano di intervalli precisi di campionamento, che se troppo distanti da quelli ideali possono portarlo a essere non [[Stabilità interna|stabile]]<ref>{{cita pubblicazione|titolo=Introduction to Control Theory And Its Application to Computing Systems|lingua=en|autore=Tarek Abdelzaher|coautori=Yixin Diao, Joseph L. Hellerstein, Chenyang Lu, Xiaoyun Zhu|url=https://www.eecs.umich.edu/courses/eecs571/reading/control-to-computer-zaher.pdf}}</ref>. Questo tipo di controllo è essenziale per tutte le applicazioni dell'[[automazione industriale]]<ref>{{cita web|url=https://www.ti.com/lit/sl/slyy049a/slyy049a.pdf|titolo=Human Machine Interface (HMI) Guide|editore=Texas Instruments|accesso=19 luglio 2016|urlarchivio=https://web.archive.org/web/20150912040716/http://www.ti.com/lit/sl/slyy049a/slyy049a.pdf|dataarchivio=12 settembre 2015|urlmorto=sì}}</ref>.

Se a rigore tutte le [[applicazione (informatica)|applicazioni]] sono real-time, perché comunque ci si aspetta una risposta entro un tempo finito, in pratica il termine viene usato per quelle [[applicazione|applicazioni]] dove i problemi relativi ai tempi di risposta sono preponderanti rispetto alla [[complessità]] dell'[[algoritmo]] da utilizzare.

== Classificazione dei sistemi real-time ==

All'interno dei problemi da trattare in tempo reale si tende a distinguere le applicazioni in ''tempo reale stretto'' in cui i tempi di risposta si esprimono tipicamente in [[Millisecondo|millisecondi]], o comunque in frazioni di secondo, da un tempo reale più [[Wikt:lasco|lasco]], in cui i tempi di risposta sono normalmente esprimibili in secondi.

Una prima classificazione dei sistemi real-time riguarda la tollerabilità del non rispetto delle deadline temporali<ref name="ShinIEEE" /><ref name="Petters">{{cita web|url=https://www.cse.unsw.edu.au/~cs9242/08/lectures/09-realtimex2.pdf|titolo=Real-Time Systems|autore=Stefan M. Petters|accesso=luglio 2016|editore=UNSW Australia}}</ref><ref name="XiaoboIEEE">{{cita pubblicazione|titolo=Firm Real-Time System Scheduling

Based on a Novel QoS Constraint|autore=Donglin Liu|coautori=Xiaobo Sharon Hu, Senior Member, IEEE, Michael D. Lemmon, Qiang Ling|url=http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1583561|rivista=IEEE Transactions on Computers|anno=2006}}</ref>:

* 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 [[Sistema critico|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<ref>{{cita web|url=http://web.diegm.uniud.it/pierluca/public_html/teaching/fpac/materiale_didattico/08_embedded_systems/lezioni/colori/F02_software.pdf|titolo=I sistemi operativi real-time|autore=Pier Luca Montessoro|editore=Università degli Studi di Udine|accesso=luglio 2016|dataarchivio=14 agosto 2016|urlarchivio=https://web.archive.org/web/20160814220113/http://web.diegm.uniud.it/pierluca/public_html/teaching/fpac/materiale_didattico/08_embedded_systems/lezioni/colori/F02_software.pdf|urlmorto=sì}}</ref>.

Per la risoluzione di problemi real-time si usano di solito [[Architettura (computer)|architetture hardware]], sistemi operativi e programmi applicativi dedicati. Le tre componenti ([[hardware]], [[software]] di base e software applicativo) sono spesso strettamente legate, in modo da conseguire le necessarie ottimizzazioni sui tempi.

=== Hard Real-Time ===

Così come in altri settori, con l'evoluzione della tecnologia informatica molti problemi hardware sono state gradualmente riportate sul software (e quindi facilmente rimediabili tramite aggiornamenti opportuni).

[[File:RIAN archive 344291 Leningrad Nuclear Power Plant near St.Petersburg.jpg|thumb|I sistemi delle centrali nucleari tipicamente necessitano di sistemi hard real-time, in foto la sala della [[Centrale nucleare di Leningrado|centrale di Leningrado]]]]

I sistemi hard real-time trovano applicazione nella maggior parte dei sistemi [[Mission Critical System|Mission-Critical]] e [[Sistema critico|Safety-Critical]], a causa della necessità di reazione ad [[Programmazione ad eventi|eventi]] esterni entro tempi prestabiliti<ref>{{cita web|url=http://www.imm.dtu.dk/~paupo/safety_critical.html|titolo=Safety-critical systems|autore=Paul Pop|editore=Technical University of Denmark|accesso=luglio 2016}}</ref>.

Negli ultimi tempi questa terminologia è stata associata all'utilizzo di alcuni servizi della [[Rete informatica|rete]], quando in effetti i presupposti per poter realmente fruire di un servizio in modalità real-time sono davvero lontani dagli ambienti operativi d'uso comune.

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<ref>{{cita web|url=http://www-lar.deis.unibo.it/people/gpalli/files/SEC-E01-Introduzione_ai_sistemi_realtime.pdf|titolo=Introduzione ai sistemi real-time|autore=Gianluca Palli|editore=Università di Bologna|accesso=luglio 2016|urlarchivio=https://web.archive.org/web/20150922021133/http://www-lar.deis.unibo.it/people/gpalli/files/SEC-E01-Introduzione_ai_sistemi_realtime.pdf|dataarchivio=22 settembre 2015|urlmorto=sì}}</ref>.

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<ref>

{{cita libro|titolo=The Concise Handbook Of Real-Time Systems|autore=TimeSys Corporation|anno=2002}}</ref>.

==== Requisiti e caratteristiche temporali ====

=== Classificazione dei sistemi real-time ===

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<ref>{{cita web|url=https://www.geeksforgeeks.org/tasks-in-real-time-systems/|titolo=Tasks in Real Time systems|accesso=6 gennaio 2020}}</ref>:

Una prima classificazione dei sistemi real-time riguarda la tollerabilità del non rispetto delle deadline temporali<ref name="ShinIEEE" /><ref name="Petters">{{cita web|url=http://www.cse.unsw.edu.au/~cs9242/08/lectures/09-realtimex2.pdf|titolo=Real-Time Systems|autore=Stefan M. Petters|accesso=luglio 2016|editore=UNSW Australia}}</ref><ref name="XiaoboIEEE">{{cita pubblicazione|titolo=Firm Real-Time System Scheduling

* ''Task periodici'': i job vengono rilasciati a intervalli di tempo regolari, detto [[Funzione periodica|periodo]].

Based on a Novel QoS Constraint|autore=Donglin Liu|coautori=Xiaobo Sharon Hu, Senior Member, IEEE, Michael D. Lemmon, Qiang Ling|url=http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1583561|rivista=IEEE Transactions on Computers|anno=2006}}</ref>:

* ''Task dinamici''

* '''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. E' tipico delle applicazioni [[Sistema critico|safety-critical]];

** ''Task aperiodici'': i job vengono rilasciati a intervalli di tempo irregolari e non noti; la deadline non può essere così garantita per questi task.

* '''Sistema firm real-time''': il mancato rispetto di alcune deadline '''è amesso''' purchè entro certi limiti; se la deadline è mancata, il risultato non è utilizzabile ma non causa eccessivi problemi;

** ''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.

* '''Sistema soft real-time''': il mancato rispetto di alcune deadline '''è amesso''' purchè entro certi limiti; se la deadline è mancata, il sistema può utilizzare il risultato, tipicamente degradando in [[performance]] senza causare eccessivi problemi.

=== Soft e Firm Real-Time ===

Spesso la distinzione tra ''firm'' e ''soft'' non viene marcata e i due concetti sono considerati equivalenti<ref>{{cita web|url=http://web.diegm.uniud.it/pierluca/public_html/teaching/fpac/materiale_didattico/08_embedded_systems/lezioni/colori/F02_software.pdf|titolo=I sistemi operativi real-time|autore=Pier Luca Montessoro|editore=Università degli Studi di Udine|accesso=luglio 2016}}</ref>.

[[File:Parole-0.2.0.2-de.png|thumb|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''<ref>{{cita pubblicazione|titolo=Weakly Hard Real-Time Systems|autore=G. Bernat, A. Burns, A. Llmosi|anno=2001|rivista=Transactions on Computers|editore=IEEE|url=https://people.cs.pitt.edu/~melhem/courses/3530/papers/bernat.pdf}}</ref>, 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]]<ref>{{cita web|url=https://design.ros2.org/articles/realtime_background.html|titolo=Introduction to Real-time Systems

|editore=Open Source Robotics Foundation|accesso=7 gennaio 2020}}</ref>, 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 [[computer performance|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 [[Calcolo approssimato|approximate computing]]<ref>{{cita web|url=https://users.soe.ucsc.edu/~sbrandt/courses/Winter00/290S/SRT.html|titolo=Soft real-time systems|autore=Scott A. Brandt|accesso=7 gennaio 2020}}</ref>.

==== Esempi ====

=== Esempi ===

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

* Hard real-time:

** Sistemi di controllo delle [[centrali nucleari]]

** [[Avionica]]

** Sistemi [[Airbag]]<ref>{{cita web|1=https://docs.fedoraproject.org/en-US/Fedora/14/html/Musicians_Guide/sect-Musicians_Guide-Hard_and_Soft_Real_Time.html|editore=[[Fedora (informatica)|Fedora]]|accesso=luglio 2016|titolo=Hard and Soft Real-Time|dataarchivio=13 settembre 2016|urlarchivio=https://web.archive.org/web/20160913042419/https://docs.fedoraproject.org/en-US/Fedora/14/html/Musicians_Guide/sect-Musicians_Guide-Hard_and_Soft_Real_Time.html|urlmorto=sì}}</ref>

** In generale tutti i sistemi [[Sistema critico|safety-critical]]

* Firm real-time:

Riga 48 ⟶ 83:

Scott F. Midkiff, E. Douglas Jensen|rivista=IEEE Euromicro Conf. Real-Time Systems|anno=2005}}</ref>

== PerchéModelli matematici per i sistemi hard ''real-time''? ==

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 (informatica)|processo]] e [[thread (informatica)|thread]], rimanendo così sufficientemente generali.

''Rispondere ad un evento in tempo reale significa farlo ad una [[velocità]] che sia possibile predeterminare'', quali che siano i contesti operativi dell'apparato. Questo richiede un'architettura hardware in grado di gestire e registrare gli eventi esterni e di un software in grado di reagire su più processi per attuare una reazione adeguata.

Il modello più comune<ref>{{cita web|url=https://www.geeksforgeeks.org/tasks-in-real-time-systems/|titolo=Tasks in Real Time systems|accesso=5 gennaio 2020|lingua=en}}</ref><ref>{{cita web|url=http://et.engr.iupui.edu/~dskim/Classes/ESW5004/RTSys%20Lecture%20Note%20-%20ch02%20A%20Reference%20Model%20for%20Real-Time%20Systems.pdf|accesso=5 gennaio 2020|lingua=en}}</ref><ref name="buttazzo-book">

=== Esempio ===

{{cita libro|titolo=Hard Real-Time Computing Systems|autore=Giorgio C. Buttazzo|lingua=en|isbn=978-1-4614-0675-4|anno=2011}}</ref> dei task è rappresentato dall'insieme dei task <math>T = \{ \tau_1, \tau_2, ..., \tau_n \}</math>, ciascuno espresso dalla seguente [[ennupla]]:

Un esempio pratico è quello del [[sistema di controllo]] di [[volo]] di un [[aereo]] o di una [[centrale nucleare]]: è impensabile che un sistema del genere non reagisca ad un evento in real-time perché il sistema è impegnato in chissà quali operazioni: sarebbe come dire che l'aereo è caduto perché il sistema di controllo d'assetto stava facendo un [[defrag]] del [[disco rigido]].

<math>\tau_i = (\Phi_i, C_i, T_i, D_i)</math>

Per questo genere di sistemi viene utilizzata anche la terminologia di "''hard real-time''".

[[File:Real-time scheduling model.svg|center]]

== Problemi correlati ==

Solitamente le caratteristiche real-time sono richieste insieme ad altre particolarità. Un requisito che compare frequentemente associato è quello della ''continuità operativa'': alcuni sistemi real-time devono lavorare in modo continuativo per lunghi periodi senza alcuna interruzione: è il caso del controllo di centrali nucleari o del [[controllo del traffico aereo]].

dove:

In altri casi la caratteristica del tempo reale è associata a calcolatori incorporati (''[[Sistema embedded|embedded]]'') con il dispositivo che devono controllare. È questo il caso di alcune applicazioni militari (per esempio in [[artiglieria]]).

* <math>\Phi_i</math> è la fase del task, ovvero la distanza tra il tempo 0 e la prima attivazione del task.

* <math>C_i</math> è il [[Worst-case execution time|Worst-Case Execution Time (WCET)]], cioè il tempo massimo che il task impiegherà a computare il risultato, calcolato senza alcuna [[preemption]].

* <math>T_i</math> è il [[Funzione_periodica|periodo]] di esecuzione.

* <math>D_i</math> è 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 <math>T_i</math> in caso di task non periodici rappresenta il tempo minimo di interarrivo dei job.

Ogni task genera una sequenza di '''job''' identificati da <math>\tau_{i,1}, \tau_{i,2}, ...</math>. 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<ref name="buttazzo-book"/>:

* <math>a_{i,k}</math>: il tempo di arrivo del k-esimo job (a volte detto di rilascio), computato come <math>\Phi_i + k \cdot T_i</math>;

* <math>d_{i,k}</math>: la deadline assoluta del k-esimo job, calcolata come <math>d_{i,k} = a_{i,k} + D_i</math>;

* <math>s_{i,k}</math>: il tempo di start del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job inizia la sua esecuzione;

* <math>f_{i,k}</math>: il tempo di fine del k-esimo job, assegnato dal sistema operativo, ovvero il tempo al quale il job termina la sua esecuzione;

* <math>R_{i,k}</math>: il tempo di risposta del k-esimo job, calcolata come <math>R_{i,k} = f_{i,k} - a_{i,k}</math>;

* <math>X_{i,k}</math>: il tempo di slack, ovvero il tempo massimo entro il quale lo start può essere posticipato senza incorrere in una violazione della deadline: <math>X_{i,k} = d_{i,k} - a_{i,k} - C_i</math>

Il sistema è detto ''temporalmente corretto'' se, per qualsiasi job k, il tempo di risposta è minore o uguale della deadline relativa, <math>R_{i,k} \le D_{i,k}</math>, o, equivalentemente, se il tempo di fine è minore o uguale della deadline assoluta, <math>f_{i,k} \le d_{i,k}</math>.

== Difficoltà di realizzazione ==

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<ref>{{cita web|url=http://www.eventhelix.com/RealtimeMantra/IssuesInRealtimeSystemDesign.htm#.V46puLpS2V4|titolo=Issues in Real-time System Design|editore=eventhelix.com|accesso=20 luglio 2016|lingua=en}}</ref>:

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

=== Stima del WCET ===

{{vedi anche|Worst-case execution time}}

Il Worst-Case Execution Time (WCET) rappresenta la stima del tempo di esecuzione massimo necessaria a costruire la [[Dimostrazione matematica|prova formale]] che il sistema sia corretto temporalmente. La stima di questo valore non è banale, specialmente nelle architettura moderne che utilizzano componenti [[COTS]]<ref>{{Cita pubblicazione|titolo=Challenges of WCET analysis in COTS multi-core due to different levels of abstraction|autore=H Shah, A Raabe, A Knoll|rivista=hiRES|anno=2013|url=https://mediatum.ub.tum.de/doc/1283874/file.pdf}}</ref>. Questi sistemi -- a causa dell'introduzione di funzionalità complesse come [[multi-core]], [[cache]], [[pipeline dati|pipeline]], ecc. -- sono difficilmente [[determinismo|predicibili in tempo]], rendendo la computazione del WCET estremamente difficile e/o troppo [[Complessità_temporale|computazionalmente complessa]]<ref>{{cita pubblicazione|titolo=Identifying the sources of unpredictability in COTS-based multicore systems|autore=Dakshina Dasari, Benny Akesson, Vincent Nélis, Muhammad Ali Awan, Stefan M. Petters|url=https://ieeexplore.ieee.org/abstract/document/6601469|editore=IEEE|rivista=8th IEEE International Symposium on Industrial Embedded Systems (SIES)|anno=2013|abstract=si}}</ref>. Per questo motivo si calcolano solitamente delle [[stima|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 scientifica|ricerca]] aperto<ref>{{cita web|titolo=ECRTS Call for Papers|url=https://www.ecrts.org/call-for-papers/|anno=2020|accesso=6 gennaio 2020}}</ref>.

== Note ==

<references />

== Voci correlate ==

*[[Sistema operativo in tempo reale]]

*[[Base di dati in tempo reale]]

== Collegamenti esterni ==

[[Categoria:Software real-time]]

* {{Collegamenti esterni}}

{{Portale|informatica}}

[[nl:Real-time]]

[[Categoria:Software real-time]]