Differenze tra hard real-time, soft real-time e firm real-time?

Ho letto le definizioni per le diverse nozioni di tempo reale e gli esempi forniti per sistemi in tempo reale hard e soft hanno senso per me. Ma non esiste una vera spiegazione o un esempio di un solido sistema in tempo reale. Secondo il link sopra:

Fermo : le scadenze non frequenti sono tollerabili, ma possono peggiorare la qualità del servizio del sistema. L'utilità di un risultato è zero dopo la sua scadenza.

Esiste una chiara distinzione tra real-time aziendale e real-time hard o soft, e c'è un buon esempio che illustri tale distinzione?

Nei commenti, Charles mi ha chiesto di inviare wiki di tag per i nuovi tag. L'esempio di un "sistema aziendale in tempo reale" che ho fornito perferma-tempo realetag era un sistema di distribuzione del latte. Se il sistema eroga latte dopo il tempo di scadenza, il latte viene considerato "non utile". Si può tollerare di mangiare cereali senza latte, ma la qualità dell'esperienza è degradata.

Questa è solo l'idea che mi sono formato nella mia testa quando inizialmente ho letto la definizione. Sto cercando un esempio molto migliore, e forse una migliore definizione di real-time aziendale che migliorerà la mia idea di esso.

Difficile in tempo reale significa che devi assolutamente rispettare ogni scadenza. Pochissimi sistemi hanno questo requisito. Alcuni esempi sono i sistemi nucleari, alcune applicazioni mediche come pacemaker, un gran numero di applicazioni per la difesa, avionica, ecc.

I sistemi rigidi / flessibili in tempo reale possono non rispettare alcune scadenze, ma alla fine le prestazioni peggioreranno se vengono perse troppe scadenze. Un buon esempio è il sistema audio del tuo computer. Se perdi qualche bit, non è un grosso problema, ma perdi troppi e finirai per degradare il sistema. Simili sarebbero i sensori sismici. Se perdi alcuni punti dati, non è un grosso problema, ma devi catturarne la maggior parte per dare un senso ai dati. Ancora più importante, nessuno morirà se non funzionano correttamente.

La linea è sfocata, perché anche un pacemaker può essere spento di una piccola quantità senza uccidere il paziente, ma questa è l'essenza generale.

È un po 'come la differenza tra caldo e caldo. Non c'è un vero divario, ma lo sai quando lo senti.

Difficile in tempo reale

La definizione rigida in tempo reale considera qualsiasi scadenza mancata come un errore di sistema. Questa programmazione è ampiamente utilizzata nei sistemi mission critical in cui il mancato rispetto dei vincoli temporali si traduce in una perdita di vite umane o di proprietà.

Esempi:

• Il volo Air France 447 si è schiantato nell'oceano dopo che un malfunzionamento del sensore ha causato una serie di errori di sistema. I piloti hanno bloccato l'aereo mentre rispondevano a letture dello strumento obsolete. Tutti i 12 membri dell'equipaggio e 216 passeggeri sono stati uccisi.

• La sonda Mars Pathfinder è stata quasi persa quando un'inversione di priorità ha causato il riavvio del sistema. Un'attività con priorità più alta non è stata completata in tempo perché bloccata da un'attività con priorità più bassa. Il problema è stato risolto e il veicolo spaziale è atterrato con successo.

• Una stampante a getto d'inchiostro ha una testina di stampa con software di controllo per depositare la corretta quantità di inchiostro su una parte specifica della carta. Se una scadenza viene rispettata, il lavoro di stampa è rovinato.

Azienda in tempo reale

La definizione definitiva in tempo reale consente scadenze saltate di rado. In queste applicazioni il sistema può sopravvivere a errori di attività fintanto che sono adeguatamente distanziati, tuttavia il valore del completamento dell'attività scende a zero o diventa impossibile.

Esempi:

• Sistemi di produzione con linee di assemblaggio di robot in cui il mancato rispetto di una scadenza si traduce in un assemblaggio improprio di una parte. Finché le parti rovinate sono abbastanza rare da essere catturate dal controllo di qualità e non troppo costose, la produzione continua.

• Un set-top box digitale via cavo decodifica i timestamp per quando i frame devono apparire sullo schermo. Poiché i frame sono sensibili all'ordine temporale, una scadenza mancata causa jitter, riducendo la qualità del servizio. Se il fotogramma perso in seguito diventa disponibile, la visualizzazione sarà solo più tremolante, quindi è inutile. Lo spettatore può comunque godersi il programma se il jitter non si verifica troppo spesso.

Soft in tempo reale

La definizione soft in tempo reale consente scadenze spesso mancate e, finché le attività vengono eseguite tempestivamente, i risultati continuano ad avere valore. Le attività completate possono aumentare il valore fino alla scadenza e diminuire il valore dopo di essa.

Esempi:

• Le stazioni meteorologiche hanno molti sensori per la lettura di temperatura, umidità, velocità del vento, ecc. Le letture devono essere rilevate e trasmesse a intervalli regolari, tuttavia i sensori non sono sincronizzati. Anche se la lettura di un sensore può essere anticipata o tardiva rispetto alle altre, può comunque essere rilevante fintanto che è abbastanza vicina.

• Una console per videogiochi esegue il software per un motore di gioco. Ci sono molte risorse che devono essere condivise tra i suoi compiti. Allo stesso tempo, le attività devono essere completate secondo il programma affinché il gioco funzioni correttamente. Finché le attività saranno completamente relativamente puntuali, il gioco sarà divertente e, in caso contrario, potrebbe ritardare solo un po '.

^{Siewert: sistemi e componenti incorporati in tempo reale.
Liu & Layland: algoritmi di pianificazione per la multiprogrammazione in un ambiente difficile in tempo reale.
Marchand & Silly-Chetto: pianificazione dinamica di attività soft aperiodiche e attività periodiche con salti.}

Dopo aver letto la pagina di Wikipedia e altre pagine sull'elaborazione in tempo reale. Ho fatto le seguenti deduzioni:

1> Per un sistema Hard real-time , se il sistema non riesce a rispettare la scadenza anche se si considera che il sistema non funziona.

2> Per un sistema in tempo reale aziendale , anche se il sistema non riesce a rispettare la scadenza, possibilmente più di una volta (cioè per più richieste), il sistema non è considerato fallito. Inoltre, le risposte per le richieste (risposte a una query, risultato di un'attività, ecc.) Sono inutili una volta trascorso il termine per quella particolare richiesta ( l'utilità di un risultato è zero dopo la sua scadenza ). Un esempio ipotetico può essere un sistema di previsione della tempesta (se una tempesta è prevista prima dell'arrivo, il sistema ha svolto il suo lavoro, la previsione dopo che l'evento è già accaduto o quando sta accadendo non ha alcun valore).

3> Per un sistema Soft in tempo reale , anche se il sistema non riesce a rispettare la scadenza, possibilmente più di una volta (cioè per più richieste), il sistema non è considerato fallito. Ma, in questo caso, i risultati delle richieste non sono valore inutile per un risultato dopo la sua scadenza, non è zero , anzi degrada col passare del tempo dopo la scadenza. Es .: Streaming audio-video.

Ecco un collegamento a una risorsa che è stata molto utile.

È popolare associare alcune grandi catastrofi alla definizione di hard real-time, ma questo non è rilevante. Qualsiasi mancato rispetto di un vincolo rigido in tempo reale significa semplicemente che il sistema è guasto. La gravità del risultato quando qualcosa è etichettato come "rotto" non è rilevante per la definizione.

Firm e soft semplicemente non possono essere automaticamente dichiarati non funzionanti se non rispettano una singola scadenza.

Per un giusto esempio di hard real-time, dalla pagina che hai collegato:

I primi sistemi di videogiochi come Atari 2600 e la grafica vettoriale Cinematronics avevano requisiti in tempo reale difficili a causa della natura della grafica e dell'hardware di temporizzazione.

Se qualcosa nel ciclo di generazione video non rispettasse una sola scadenza, l'intero display si guasterebbe, il che sarebbe intollerabile, anche se raro. Sarebbe un sistema guasto e lo riporteresti in negozio per un rimborso. Quindi è difficile in tempo reale.

Ovviamente qualsiasi sistema può essere soggetto a situazioni che non è in grado di gestire, quindi è necessario limitare la definizione alle condizioni operative previste, notando che nelle applicazioni critiche per la sicurezza le persone devono pianificare condizioni terribili ("il refrigerante è evaporato", " i freni sono falliti ", ma raramente" il sole è esploso ").

E non dimentichiamo che a volte c'è una condizione operativa implicita "mentre qualcuno sta guardando". Se nessuno ti vede infrangere le regole (o se lo hanno fatto ma muore nel fuoco prima di dirlo a qualcuno), e nessuno può dimostrare che hai infranto le regole dopo il fatto, allora è come se non avessi mai infranto le regole!

Il modo più semplice per distinguere tra i diversi tipi di tipi di sistema in tempo reale è rispondere alla domanda:

Una risposta del sistema ritardata (dopo la scadenza) è ancora utile o no?

Quindi, a seconda della risposta che ottieni per questa domanda, il tuo sistema potrebbe essere incluso in una delle seguenti categorie:

1. Difficile : no e le risposte ritardate sono considerate un errore di sistema

Questo è il caso in cui il mancato rispetto della scadenza renderà il sistema inutilizzabile. Ad esempio, il sistema che controlla il sistema Airbag dell'auto dovrebbe rilevare l'urto e gonfiare rapidamente la borsa. L'intero processo richiede più o meno un venticinquesimo di secondo. Pertanto, se il sistema, ad esempio, reagisce con 1 secondo di ritardo, le conseguenze potrebbero essere mortali e non sarà di alcun beneficio avere il bagaglio gonfiato una volta che l'auto è già caduta.

2. Ditta : no, ma le risposte ritardate non sono necessarie per un guasto del sistema

Questo è il caso in cui il mancato rispetto della scadenza è tollerabile ma influirà sulla qualità del servizio. Come semplice esempio si consideri un sistema di crittografia video. Normalmente la password di crittografia viene generata nel server (video Head end) e inviata al set-top box del cliente. Questo processo dovrebbe essere sincronizzato in modo che normalmente il set-top box riceva la passwordprima di iniziare a ricevere i fotogrammi video crittografati. In questo caso un ritardo può portare a glitch video poiché il set-top box non è in grado di decodificare i frame perché non ha ancora ricevuto la password. In questo caso il servizio (film, un'interessante partita di calcio, ecc.) Potrebbe risentire del mancato rispetto della scadenza. Ricevere la password con ritardo in questo caso non è utile poiché i frame crittografati con la stessa hanno già causato i glitch.

3. Soft : Sì, ma il servizio di sistema è degradato

A partire dalla descrizione di wikipedia l'utilità di un risultato degrada dopo la sua scadenza . Ciò significa che ottenere una risposta dal sistema al di fuori della scadenza è ancora utile per l'utente finale, ma la sua utilità diminuisce una volta raggiunta la scadenza. Un semplice esempio per questo caso è un software che controlla automaticamente la temperatura di una stanza (o di un edificio). In questo caso se il sistema ha dei ritardi nella lettura dei sensori di temperatura sarà un po 'lento reagire a brusche variazioni di temperatura. Tuttavia, alla fine finirà per reagire al cambiamento e regolare di conseguenza la temperatura per mantenerla costante, ad esempio. Quindi in questo caso la reazione ritardata è utile, ma degrada la qualità del servizio del sistema.

Il più semplice da capire è un soft real time , in cui anche se il risultato viene ottenuto oltre la scadenza, i risultati sono comunque considerati validi.

Esempio: browser Web : richiediamo un determinato URL, il caricamento della pagina richiede del tempo. Se il sistema impiega più tempo del previsto per fornirci la pagina, la pagina ottenuta non è considerata non valida, diciamo solo che le prestazioni del sistema non erano all'altezza (il sistema ha dato prestazioni basse!).

Nel sistema hard real time , se il risultato è ottenuto dopo la scadenza, il sistema si considera completamente fallito.

Esempio: nel caso in cui un robot svolga un lavoro come il tracciamento della linea, ecc. Se si verifica un ostacolo sul suo percorso e il robot non elabora queste informazioni entro una scadenza programmata (quasi istantanea!), Si dice che il robot ha fallito nel suo compito (il sistema robotico potrebbe anche essere completamente distrutto!).

In un sistema stabile in tempo reale , se il risultato dell'esecuzione del processo arriva dopo la scadenza, il risultato viene scartato, ma il sistema non è definito come fallito.

Esempio: comunicazione satellitare per il monitoraggio della posizione del nemico o qualche altro compito. Se la stazione del computer di terra a cui i satelliti inviano periodicamente i frame è sovraccarica e il frame corrente (pacchetto) non viene elaborato in tempo e viene visualizzato il frame successivo, il pacchetto corrente (quello che ha mancato la scadenza) non ha importanza se l'elaborazione è stata completata (o metà o quasi) viene eliminata / scartata. Ma il computer di terra non è definito come completamente fallito.

Per definire "soft real-time", è più facile confrontarlo con "hard real-time". Di seguito vedremo che il termine "tempo reale dell'azienda" costituisce un malinteso riguardo al "tempo reale morbido".

Parlando in modo casuale, la maggior parte delle persone ha implicitamente un modello mentale informale che considera le informazioni o un evento come "in tempo reale"

• se, o nella misura in cui, si manifesta loro con un ritardo (latenza) che può essere correlato alla sua valuta percepita

• cioè, in un lasso di tempo in cui l'informazione o l'evento ha un valore accettabilmente soddisfacente per loro.

Esistono numerose e differenti definizioni ad hoc di "hard real-time", ma in quel modello mentale, hard real-time è rappresentato dal termine "if". In particolare, supponendo che le azioni in tempo reale (come le attività) abbiano scadenze di completamento, il valore accettabilmente soddisfacente dell'evento che tutte le attività completano è limitato al caso speciale in cui tutte le attività rispettano le loro scadenze.

I sistemi hard real-time fanno l'ipotesi molto forte che tutto ciò che riguarda l'applicazione, il sistema e l'ambiente sia statico e noto a priori, ad esempio quali attività, che sono periodiche, i loro tempi di arrivo, i loro periodi, le loro scadenze, che hanno vinto non ci sono conflitti di risorse e, nel complesso, l'evoluzione temporale del sistema. In un sistema di controllo del volo di un aeromobile o in un sistema di frenatura automobilistica e in molti altri casi, tali presupposti possono essere generalmente soddisfatti in modo da rispettare tutte le scadenze.

Questo modello mentale è deliberatamente e molto utilmente abbastanza generale da comprendere sia hard che soft in tempo reale - soft è adattato dalla frase "nella misura in cui". Ad esempio, si supponga che l'evento di completamento dell'attività abbia un valore non ottimale ma accettabile if

• non più del 10% delle attività non rispettano le scadenze
• oppure nessuna attività è in ritardo di oltre il 20%
• o il ritardo medio di tutte le attività non è superiore al 15%
• o il ritardo massimo tra tutte le attività è inferiore al 10%

Questi sono tutti esempi comuni di casi soft in tempo reale in moltissime applicazioni.

Considera l'applicazione single-task di andare a prendere tuo figlio dopo la scuola. Questo probabilmente non ha una scadenza effettiva, invece c'è un valore per te e tuo figlio in base al momento in cui si verifica l'evento. Troppo presto spreca risorse (come il tuo tempo) e troppo tardi ha un valore negativo perché tuo figlio potrebbe essere lasciato solo e potenzialmente in pericolo (o almeno disturbato).

A differenza del caso speciale hard real-time statico, il soft real-time fa solo le ipotesi specifiche dell'applicazione minime necessarie sulle attività e sul sistema e sono previste incertezze. Per andare a prendere tuo figlio, devi andare a scuola in auto e il tempo per farlo è dinamico a seconda del tempo, delle condizioni del traffico, ecc. Potresti essere tentato di rifornire eccessivamente il tuo sistema tempo di guida nel caso peggiore) ma ancora una volta questo è sprecare risorse (il tuo tempo e occupare il veicolo di famiglia, forse negandone l'uso da parte di altri membri della famiglia).

Questo esempio potrebbe non sembrare costoso in termini di risorse sprecate, ma considera altri esempi. Tutti i sistemi di combattimento militari sono soft in tempo reale. Ad esempio, considera di eseguire un attacco aereo su un veicolo terrestre ostile usando un missile guidato con aggiornamenti mentre il bersaglio manovra. La massima soddisfazione per il completamento delle attività di aggiornamento del corso si ottiene con un colpo distruttivo diretto sul bersaglio. Ma un tentativo di fornire risorse eccessive per accertarsi di questo risultato è solitamente troppo costoso e può anche essere impossibile. In questo caso, potresti essere meno ma sufficientemente soddisfatto se il missile colpisce abbastanza vicino al bersaglio da disabilitarlo.

Ovviamente gli scenari di combattimento hanno molte possibili incertezze dinamiche che devono essere soddisfatte dalla gestione delle risorse. I sistemi soft real-time sono anche molto comuni in molti sistemi civili, come l'automazione industriale, sebbene ovviamente quelli militari siano i più pericolosi e urgenti in cui ottenere un valore accettabilmente soddisfacente.

La chiave di volta dei sistemi in tempo reale è la "prevedibilità". Il caso difficile in tempo reale è interessato solo a un caso speciale di prevedibilità, ovvero che tutti i compiti rispettino le loro scadenze e che l'evento raggiunga il massimo valore possibile. Quel caso speciale è denominato "deterministico".

Esiste uno spettro di prevedibilità. Il deterministico (determinismo) è un punto finale (massima prevedibilità) nello spettro di prevedibilità; l'altro punto finale è la minima prevedibilità (massimo non determinismo). La metrica e gli endpoint dello spettro devono essere interpretati in termini di un modello di prevedibilità scelto; tutto ciò che si trova tra questi due punti finali è gradi di imprevedibilità (= gradi di non determinismo).

La maggior parte dei sistemi in tempo reale (ovvero quelli soft) hanno una prevedibilità non deterministica, ad esempio, dei tempi di completamento delle attività e quindi dei valori ottenuti da quegli eventi.

In generale (in teoria), la prevedibilità, e quindi un valore accettabilmente soddisfacente, può essere resa il più vicino possibile al punto finale deterministico, ma a un prezzo che può essere fisicamente impossibile o eccessivamente costoso (come in combattimento o forse anche in andare a prendere tuo figlio a scuola).

Il soft real-time richiede una scelta specifica dell'applicazione di un modello di probabilità (non il modello frequentista comune) e quindi un modello di prevedibilità per il ragionamento sulle latenze degli eventi e sui valori risultanti.

Facendo riferimento all'elenco di eventi sopra riportato che forniscono un valore accettabile, ora possiamo aggiungere casi non deterministici, come

• la probabilità che nessuna attività manchi la sua scadenza di oltre il 5% è maggiore di 0,87. (Notare il numero di criteri di programmazione qui espressi.)

In un'applicazione di difesa missilistica, dato che in combattimento l'offesa ha sempre il vantaggio sulla difesa, quale di questi due scenari di elaborazione in tempo reale preferiresti:

• poiché la distruzione perfetta di tutti i missili ostili è molto improbabile o impossibile, assegna le tue risorse difensive per massimizzare la probabilità che molti dei missili ostili più minacciosi (ad esempio, in base ai loro obiettivi) vengano intercettati con successo (l'intercettazione ravvicinata conta perché può spostare il missile ostile fuori rotta);

• lamentarsi del fatto che questo non è un problema di elaborazione in tempo reale perché è dinamico anziché statico e i concetti e le tecniche tradizionali in tempo reale non si applicano e suona più difficile dello statico difficile in tempo reale, quindi non ti interessa .

Nonostante le varie incomprensioni sul soft real-time nella comunità dei real-time computing, il soft real-time è molto generico e potente, sebbene potenzialmente complesso rispetto all'hard real-time. I sistemi soft real-time come riassunti qui hanno una lunga storia di utilizzo di successo al di fuori della comunità informatica in tempo reale .

Per rispondere direttamente alla domanda OP:

Un sistema hard real-time può fornire garanzie deterministiche - più comunemente che tutte le attività rispetteranno le loro scadenze, il tempo di risposta all'interruzione o alla chiamata di sistema sarà sempre inferiore a x, ecc. - SE E SOLO SE vengono fatte ipotesi molto forti e corrette che tutto ciò che conta è statico e noto a priori (in generale, tali garanzie per sistemi hard real-time sono un problema di ricerca aperta tranne che per casi piuttosto semplici)

Un sistema soft real-time non fornisce garanzie deterministiche, è inteso a fornire la migliore tempestività probabilistica analiticamente specificata e compiuta e la prevedibilità della tempestività che siano fattibili nelle attuali circostanze dinamiche, secondo criteri specifici dell'applicazione.

Ovviamente hard real-time è un semplice caso speciale di soft real-time. Ovviamente le assicurazioni analitiche non deterministiche di soft real-time possono essere molto complesse da fornire, ma sono obbligatorie nei casi in tempo reale più comuni (inclusi quelli critici per la sicurezza più pericolosi come il combattimento) poiché la maggior parte dei casi in tempo reale non sono dinamici statico.

"Firm real-time" è un caso speciale mal definito di "soft real-time". Non è necessario questo termine se il termine "soft real-time" è compreso e utilizzato correttamente.

Ho una discussione più dettagliata e molto più precisa su real-time, hard real-time, soft real-time, prevedibilità, determinismo e argomenti correlati sul mio sito web real-time.org.

tempo reale - Relativo a un sistema o modalità di funzionamento in cui il calcolo viene eseguito durante il tempo effettivo in cui si verifica un processo esterno, in modo che i risultati del calcolo possano essere utilizzati per controllare, monitorare o rispondere al processo esterno in modo tempestivo maniera. [IEEE Standard 610.12.1990]

So che questa definizione è vecchia, molto vecchia. Non riesco, tuttavia, a trovare una definizione più recente da parte dell'IEEE (Institute of Electrical and Electronics Engineers).

Considera un'attività che immette dati dalla porta seriale. Quando arrivano nuovi dati, la porta seriale attiva un evento. Quando il software serve quell'evento, legge ed elabora i nuovi dati. La porta seriale dispone di un hardware per memorizzare i dati in ingresso (2 su MSP432, 16 su TM4C123) in modo tale che se il buffer è pieno e arrivano più dati, i nuovi dati vengono persi. Questo sistema è duro, solido o morbido in tempo reale?

È difficile il tempo reale perché se la risposta è in ritardo, i dati potrebbero andare persi.

Considera un apparecchio acustico che immette i suoni da un microfono, manipola i dati audio e quindi invia i dati a un altoparlante. Il sistema di solito ha un jitter limitato e limitato, ma occasionalmente altre attività nell'apparecchio acustico causano il ritardo di alcuni dati, causando un impulso di rumore sull'altoparlante. Questo sistema è duro, solido o morbido in tempo reale?

È fermo in tempo reale perché provoca un errore percepibile ma l'effetto è innocuo e non altera in modo significativo la qualità dell'esperienza.

Considera un'attività che invia dati a una stampante. Quando la stampante è inattiva, la stampante attiva un evento. Quando il software serve quell'evento, invia più dati alla stampante. Questo sistema è duro, solido o morbido in tempo reale?

È soft real time perché più velocemente risponde meglio è, ma il valore del sistema (la larghezza di banda è la quantità di dati stampati al secondo) diminuisce con la latenza.

UTAustinX: UT.RTBN.12.01x Reti Bluetooth in tempo reale

Forse è colpa della definizione.

Dalla mia esperienza, separerei i due in quanto dipendenti dall'hardware e dal software.

Se hai 200 ms per servire un interrupt guidato dall'hardware, questo è quello che hai. Metti 300 ms di codice lì dentro e il sistema non è rotto, non è stato sviluppato. Verrai escluso prima di aver finito. Il tuo codice non funziona o non è adatto allo scopo. Molti sistemi hanno periodi di elaborazione definiti in modo rigido. Video, telecomunicazioni ecc.

Se stai scrivendo un'applicazione che è in tempo reale, questo potrebbe essere considerato morbido . Se si esaurisce il tempo si può sperare in un carico inferiore la prossima volta, è possibile regolare il sistema operativo, aggiungere memoria o persino aggiornare l'hardware. Hai delle opzioni.

Guardarlo da una prospettiva UX non è utile. Una Skoda potrebbe non essere rotta se si guasta, ma una BMW sicuramente lo sarà.

La definizione si è ampliata negli anni a scapito del termine. Quello che ora viene chiamato "Hard" in tempo reale è quello che veniva chiamato semplicemente in tempo reale. Pertanto, i sistemi in cui le finestre temporali mancanti (piuttosto che le scadenze temporali unilaterali) risulterebbero dati errati o comportamenti errati dovrebbero essere considerati in tempo reale. I sistemi senza questa caratteristica sarebbero considerati non in tempo reale.

Questo non vuol dire che il tempo non sia di interesse nei sistemi non in tempo reale, significa semplicemente che i requisiti di tempo in tali sistemi non si traducono in risultati fondamentalmente errati.

I sistemi hard real time utilizzano la versione preventiva della pianificazione prioritaria, in modo che le attività critiche vengano programmate immediatamente, mentre i sistemi soft real time utilizzano una versione non preventiva della pianificazione prioritaria, che consente di terminare l'attività corrente prima che il controllo venga trasferito alla priorità più alta attività, causando ulteriori ritardi. Pertanto, le scadenze delle attività vengono seguite in modo critico nei sistemi Hard real time, mentre nei sistemi soft real time vengono gestite non così seriamente.