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

Question

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

Ou, colocando de outra forma, já que esses sistemas operacionais são projetados especificamente para uso embarcado em tempo real - ao contrário do Linux, que é um sistema mais geral que pode ser adaptado para uso em tempo real - quando você > precisa para usar um desses sistemas operacionais ao invés do Linux?

    

Answer 1

Alguns sistemas embarcados (a) precisam atender a requisitos difíceis em tempo real, e ainda (b) ter hardware muito limitado (o que dificulta ainda mais o atendimento a esses requisitos).

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

• Talvez a CPU não tenha sequer uma MMU, o que torna impossível executar o Linux (exceto o uClinux e, até onde eu sei, o uClinux não é em tempo real).
• Talvez a CPU esteja relativamente lenta e a latência de interrupção de pior caso no Linux não atenda a algum requisito difícil, e alguns outros RTOS sintonizados para latência de interrupção de pior caso extremamente baixa podem atender ao requisito.
• Talvez o sistema tenha muito pouca memória RAM. Há alguns anos, 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 rodar no Linux) exigia cerca de 20 kB de RAM.
• Talvez não exista porta de Linux para o seu hardware, e não há tempo suficiente para portar o Linux antes de você precisar lançar (trocadilho!) seu sistema. Muitos dos RTOS mais simples demoram muito menos tempo para migrar para um novo hardware do que o Linux.

Answer 2

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

Me disseram que há duas categorias de "tempo real": em tempo real e suave em tempo real.

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

"Difícil em tempo real" informalmente significa "faça-o dentro de uma janela de tempo obrigatória". A janela pode ser bem pequena, milissegundos ou algo assim. Sistemas de controle de vôo para mísseis de cruzeiro ou veículos lançadores de satélite parecem o exemplo canônico. Sistemas de controle de processo industrial também podem precisar disso. O worm Stuxnet parece ter interferido em sistemas que fazem esse tipo de controle.

Você usaria o RTOS na última situação. O RTOS geralmente garante a entrega de uma interrupção em menos do que muitas instruções ou marcações de relógio ou o que quer que seja.

Outra consideração pode ser que um RTOS seja projetado, testado e / ou "provado" para não consumir espaço de pilha sem limite. Ele pode viver dentro de uma certa quantidade mínima de memória, e coisas como "OOM Killer" não existem porque provavelmente nunca serão necessárias. Alguns dos recursos mais comuns do FORTRAN inicial vêm desse tipo de requisito. Quando você compilava um programa FORTRAN II, sabia exatamente quanto pilha e quanta pilha precisava, já que não podia reciclar e não podia alocar nada dinamicamente.

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

Eu também imaginaria que, ao remover o processo de seleção da folha de figo de apoio ao palavreado, você descobriria que os engenheiros escolhem um RTOS porque "os requisitos dizem para".