Vantaggi dell'utilizzo di un RTOS come QNX o VxWorks anziché Linux?

Quando si sviluppa una soluzione che richiede un sistema operativo in tempo reale, quali vantaggi avrebbe un sistema operativo come un QNX o VxWorks su Linux?

O per dirla in altro modo, dal momento che questi sistemi operativi sono progettati specificamente per l'uso incorporato in tempo reale, al contrario di Linux, che è un sistema più generale che può essere personalizzato per l'uso in tempo reale, quando sarebbe necessario utilizzare uno dei questi sistemi operativi invece di Linux?

Alcuni sistemi embedded (a) devono soddisfare difficili requisiti in tempo reale, eppure (b) hanno hardware molto limitato (il che rende ancora più difficile soddisfare tali requisiti).

Se non riesci a modificare l'hardware, ci sono diverse situazioni in cui sei costretto a escludere Linux e utilizzare qualcos'altro:

• Forse la CPU non ha nemmeno un MMU, il che rende impossibile eseguire Linux (tranne uClinux, e per quanto ne so uClinux non è in tempo reale).
• Forse la CPU è relativamente lenta e la latenza di interruzione nel caso peggiore in Linux non soddisfa alcuni requisiti difficili e alcuni altri RTOS ottimizzati per la latenza di interruzione nel caso peggiore estremamente basso possono soddisfare il requisito.
• Forse il sistema ha pochissima RAM. Alcuni anni fa, una configurazione minima di Linux richiedeva circa 2 MB di RAM; una configurazione minima di eCos (con un livello di compatibilità che gli consente di eseguire alcune applicazioni originariamente progettate per funzionare su Linux) richiedeva circa 20 kB di RAM.
• Forse non c'è una porta di Linux sul tuo hardware e non c'è abbastanza tempo per eseguire il port di Linux prima che tu abbia bisogno di lanciare (pun!) Il tuo sistema. Molti dei RTOS più semplici richiedono molto meno tempo per il porting su nuovo hardware rispetto a Linux.

Non ho fatto alcun lavoro in tempo reale, quindi prendilo con un po 'di sale ...

Mi è stato detto che ci sono due categorie di "real-time": hard real-time e soft real-time.

"Soft in tempo reale" significa informalmente "eseguilo il più velocemente possibile". Penso che Linux su una CPU moderna sia buono per questo genere di cose.

"Difficile in tempo reale" significa informalmente "eseguirlo entro un lasso di tempo richiesto". La finestra può essere piuttosto piccola, millisecondi o qualcosa del genere. I sistemi di controllo di volo per missili da crociera o veicoli di lancio satellitare sembrano l'esempio canonico. Anche i sistemi di controllo dei processi industriali potrebbero aver bisogno di questo. Il worm Stuxnet sembra aver interferito con i sistemi che eseguono questo tipo di controllo.

Utilizzeresti RTOS in quest'ultima situazione. RTOS spesso garantisce la consegna di un interrupt in meno di tante istruzioni o tick di clock o altro.

Un'altra considerazione potrebbe essere che un RTOS è progettato, testato e / o "dimostrato" per non consumare spazio nello stack senza limiti. Può vivere all'interno di una certa quantità minima di memoria e cose come un "OOM Killer" non esistono perché non sono mai necessarie. Alcune delle caratteristiche più sciocche dei primi FORTRAN provengono da questo tipo di requisiti. Quando hai compilato un programma FORTRAN II, sapevi esattamente quanto stack e quanto heap fosse necessario, dal momento che non potevi ricorrere e non puoi allocare dinamicamente nulla.

Realisticamente, la seconda considerazione (consumo massimo di memoria garantito) potrebbe essere più importante in alcune applicazioni critiche per la sicurezza rispetto alla "latenza di interruzione garantita di 0,001 secondi".

Immaginerei anche che spogliando il processo di selezione della foglia di fico di supporto verbale, scopriresti che gli ingegneri scelgono un RTOS perché "i requisiti dicono".