Esiste una differenza tra un sistema in tempo reale e uno solo deterministico?

Question

Al lavoro stiamo discutendo la progettazione di una nuova piattaforma e uno dei tipi di gestione superiore ha affermato che era necessario eseguire la nostra attuale base di codice (C su Linux) ma essere in tempo reale perché doveva rispondere in meno di un secondo a vari input. Ho fatto notare che:

1. Quel punto non significa che ha bisogno di essere "tempo reale" solo che ha bisogno di un clock più veloce e più razionalizzazione nella sua gestione
2. Uno dei punti chiave da prendere in considerazione è interrupt il sistema operativo in uso. Volevano restare con Linux incorporato, ho sottolineato che abbiamo bisogno di un RTOS. L'uso di Linux impedirà il "tempo reale" a causa della memoria dello spazio kernel/utente, quindi l'I/O viene eseguito tramite file e socket che introducono un ritardo
3. Ciò che è veramente necessario determinare è se deve essere deterministico (è necessario per esempio, rispondere a input in < 200ms 90% del tempo).

Davvero nella mia mente se il punto 3 è vero, allora deve essere un sistema in tempo reale, e quindi il punto 2 è la più grande considerazione.

Mi sentivo sicuro di rispondere, ma poi ci pensavo più tardi ... Cosa pensano gli altri? Sono sulla buona strada qui o mi manca qualcosa?

C'è qualche differenza che mi manca tra un sistema "in tempo reale" e uno che è solo "deterministico"? E oltre a un RTC e un RTOS, mi manca qualcosa di importante che è necessario per eseguire un vero sistema in tempo reale?

Attendo con ansia alcune grandi risposte!

EDIT:

ottenuto alcune buone risposte finora, sembra che ci sia un po 'di curiosità per il mio sistema e requisiti in modo io aggiungo qualche nota per coloro che sono interessati:

1. La mia azienda vende unità negli anni '10 di migliaia, quindi non voglio andare a uccidere sul prezzo
2. In genere vendiamo una scheda processore principale e un display indipendente. C'è anche una rete collegata di altri dispositivi CAN.
3. La scheda (attualmente) corre i dispositivi e anche agisce come un server web inviando documenti XML di base per la visualizzazione per gli utenti finali

I requisiti vengono qui dove la gestione vuole il display da aggiornare "in fretta" (< 1s), tuttavia i limiti true provengono dai dispositivi che possono essere collegati su CAN. Questi dispositivi sono spesso dispositivi controllati dal motore con requisiti che includono "devono rispondere in meno di 200 ms".

Answer 1

È necessario distinguere tra:

• hard realtime: c'è un limite assoluto sul tempo di risposta che non deve essere violato (conta come un fallimento) - per esempio questo è appropriato per esempio quando si sta controllando motori robotici o dispositivi medici in cui il mancato rispetto di un termine potrebbe essere catastrofico
• Realtime Soft: v'è un obbligo di rispondere rapidamente la maggior parte del tempo (forse 99,99% +) , ma è accettabile che il limite di tempo venga occasionalmente violato fornendo in media una risposta molto rapida. per esempio. questo è appropriata quando si esegue l'animazione in tempo reale in un gioco per computer - manca una scadenza potrebbe causare una cornice saltato ma non fondamentalmente rovinare l'esperienza di gioco

tempo reale Soft è facilmente realizzabile in maggior parte dei sistemi fino a quando si dispone di un adeguato hardware e prestare sufficiente attenzione all'identificazione e all'ottimizzazione dei colli di bottiglia. Con alcuni tuning, è persino possibile ottenere in sistemi che hanno pause non deterministiche (ad esempio la garbage collection in Java).

Il tempo reale in tempo reale richiede un supporto OS dedicato (per garantire la pianificazione) e algoritmi deterministici (in modo che, una volta programmato, un compito sia garantito per il completamento entro la scadenza). Ottenere questo diritto è difficile e richiede un'attenta progettazione dell'intero stack hardware/software.

E 'importante notare che la maggior parte delle applicazioni di business non richiedono né: in particolare, penso che il targeting di un tempo di risposta < 1 sec è lontano da quello che la maggior parte delle persone considererebbero un requisito "in tempo reale". Detto questo, se un tempo di risposta è specificato esplicitamente nei requisiti, è possibile considerarlo come un soft realtime con una scadenza abbastanza allentata.

Answer 2

Dalla definizione del real-time tag:

Un compito è tempo reale quando il tempestività di completamento delle attività è una condizione requisito e correttezza funzionale, piuttosto che semplicemente una metrica delle prestazioni . Un sistema in tempo reale è uno in cui alcuni (anche se forse non tutti) i compiti sono attività in tempo reale.

In altre parole, se accade qualcosa di brutto se il sistema risponde troppo lentamente per rispettare una scadenza, il sistema deve essere in tempo reale e sarà necessario un RTOS.

Un sistema in tempo reale non ha bisogno di essere deterministico: se il tempo di reazione varia a caso tra 50ms e 150ms ma il tempo di risposta mai supera 150ms allora il sistema è non-deterministico ma è ancora in tempo reale.

Answer 3

Sembra che tu sia sulla strada giusta con RTOS. Diversi RTOS danno priorità a cose diverse, robustezza o velocità o qualcosa del genere. Dovrai capire se hai bisogno di un RTOS duro o morbido e in base a ciò che ti serve, in che modo verrà guidato il tuo programma di pianificazione. Una cosa è certa, c'è una grave differenza tra l'uso di un normale sistema operativo e un RTOS.

Nota: forse per il vero sistema in tempo reale occorrerà una risoluzione basata su eventi complessi in modo da poter garantire che i processi vengano eseguiti quando ci si aspetta anche da loro.

Answer 4

Forse potresti provare a usare RTLinux o RTAI se hai tempo sufficiente per sperimentare. Con questo, è possibile mantenere le applicazioni non in tempo reale su Linux, ma le applicazioni realtime verranno spostate nella parte RTOS. In tal caso, sarà (possibile) ottenere < 1 secondo tempo di risposta.

I vantaggi sono -

• Grande quantità di codice può essere riutilizzato
• È possibile partizionare manualmente in tempo reale e le attività non in tempo reale e cercare di ottenere la risposta < 1s come volete.
• Credo che il tempo di migrazione non sarà molto elevato, dal momento che la maggior parte del codice sarà in linux

Proprio su un sidenote fare attenzione circa i driver hardware che potrebbe essere necessario per l'esecuzione da parte in tempo reale.

La seguente architettura di RTLinux potrebbe aiutare a capire come ciò sia possibile.