Vantagens de usar um RTOS, como QNX ou VxWorks, em vez de Linux?

Ao desenvolver uma solução que requer um sistema operacional em tempo real, quais vantagens um sistema operacional como um QNX ou VxWorks teria sobre o Linux?

Ou, dito de outra forma, como esses sistemas operacionais são projetados especificamente para uso incorporado em tempo real - em oposição ao Linux, que é um sistema mais geral que pode ser personalizado para uso em tempo real - quando é necessário usar um dos esses sistemas operacionais em vez do Linux?

Alguns sistemas embarcados (a) precisam atender a requisitos difíceis em tempo real e, no entanto (b) possuem hardware muito limitado (o que torna ainda mais difícil atender a esses requisitos).

Se você não pode alterar o hardware, há várias situações em que você é forçado a descartar o Linux e usar outra coisa:

• Talvez a CPU nem tenha um MMU, o que impossibilita a execução do Linux (exceto o uClinux e, até onde eu sei, o uClinux não é em tempo real).
• Talvez a CPU seja relativamente lenta e a latência de interrupção do pior caso no Linux não atenda a alguns requisitos rígidos, e outros RTOS ajustados para uma latência de interrupção do pior caso extremamente baixa podem atender ao requisito.
• Talvez o sistema tenha muito pouca memória RAM. Alguns anos atrás, uma configuração mínima do Linux exigia cerca de 2 MB de RAM; uma configuração mínima do eCos (com uma camada de compatibilidade permitindo a execução de alguns aplicativos originalmente projetados para execução no Linux) exigia cerca de 20 kB de RAM.
• Talvez não exista porta do Linux para o seu hardware e não haja tempo suficiente para portar o Linux antes que você precise iniciar (trocadilho!) Seu sistema. Muitos dos RTOS mais simples levam muito menos tempo para portar para um novo hardware que o Linux.

Eu não fiz nenhum trabalho em tempo real, então leve isso com um pouco de sal ...

Disseram-me que há duas categorias de "tempo real": tempo real difícil e tempo real suave.

"Tempo real suave" informalmente significa "fazê-lo o mais rápido possível". Eu acho que o Linux em uma CPU moderna é bom para esse tipo de coisa.

"Tempo real difícil" informalmente significa "fazê-lo dentro de uma janela de tempo necessária". A janela pode ser bem pequena, milissegundos ou algo assim. Os sistemas de controle de vôo para mísseis de cruzeiro ou veículos lançadores de satélites parecem ser o exemplo canônico. Os sistemas de controle de processos industriais também podem precisar disso. O worm Stuxnet parece ter interferido nos sistemas que fazem esse tipo de controle.

Você usaria o RTOS na última situação. O RTOS geralmente garante a interrupção em menos de tantas instruções ou marcações de relógio ou o que for.

Outra consideração pode ser que um RTOS seja projetado, testado e / ou "comprovado" para não consumir espaço na pilha sem vincular. Ele pode viver dentro de uma certa quantidade mínima de memória e coisas como um "OOM Killer" não existem porque provavelmente nunca são necessárias. Alguns dos recursos mais engraçados do FORTRAN antigo vêm desse tipo de requisito. Ao compilar um programa FORTRAN II, você sabia exatamente quanta pilha e quantidade de pilha precisava, pois não era possível recursar e não podia alocar dinamicamente nada.

Realisticamente, a segunda consideração (consumo máximo garantido de memória) pode ser mais importante em algumas aplicações críticas de segurança do que "latência de interrupção garantida de 0,001 segundos".

Eu também imaginaria que, retirando o processo de seleção da folha de figueira da verborragia de suporte, você descobriria que os engenheiros escolhem um RTOS porque "os requisitos dizem".