Les avantages d'utiliser un RTOS tel que QNX ou VxWorks au lieu de Linux?

Lors du développement d'une solution qui nécessite un système d'exploitation en temps réel, quels avantages un système d'exploitation tel qu'un QNX ou VxWorks aurait-il par rapport à Linux?

Ou pour le dire autrement, puisque ces systèmes d'exploitation sont conçus spécifiquement pour une utilisation intégrée en temps réel - par opposition à Linux qui est un système plus général qui peut être adapté à une utilisation en temps réel - quand auriez-vous besoin d'utiliser l'un des ces systèmes d'exploitation au lieu de Linux?

Certains systèmes embarqués (a) doivent répondre à des exigences difficiles en temps réel, et pourtant (b) ont un matériel très limité (ce qui rend encore plus difficile de répondre à ces exigences).

Si vous ne pouvez pas changer le matériel, il y a plusieurs situations où vous êtes obligé d'exclure Linux et d'utiliser autre chose à la place:

• Peut-être que le CPU n'a même pas de MMU, ce qui rend impossible l'exécution de Linux (sauf uClinux, et pour autant que je sache, uClinux n'est pas en temps réel).
• Peut-être que le processeur est relativement lent, et la latence d'interruption du pire cas sous Linux ne répond pas à certaines exigences strictes, et certains autres RTOS réglés pour une latence d'interruption du pire cas extrêmement faible peuvent répondre à cette exigence.
• Peut-être que le système a très peu de RAM. Il y a quelques années, une configuration Linux minimale nécessitait environ 2 Mo de RAM; une configuration minimale d'eCos (avec une couche de compatibilité lui permettant d'exécuter certaines applications conçues à l'origine pour fonctionner sur Linux) nécessitait environ 20 Ko de RAM.
• Peut-être qu'il n'y a pas de portage de Linux sur votre matériel, et qu'il n'y a pas assez de temps pour porter Linux avant de devoir lancer (jeu de mots!) Votre système. Beaucoup de RTOS plus simples prennent beaucoup moins de temps à porter sur un nouveau matériel que Linux.

Je n'ai pas du tout fait de travail en temps réel alors prenez ça avec un grain de sel ...

On me dit qu'il existe deux catégories de «temps réel»: en temps réel dur et en temps réel doux.

«Doux en temps réel» signifie officieusement «faites-le le plus rapidement possible». Je pense que Linux sur un processeur moderne est bon pour ce genre de chose.

«Dur en temps réel» signifie de manière informelle «faites-le dans les délais requis». La fenêtre peut être assez petite, en millisecondes ou quelque chose. Les systèmes de contrôle de vol pour les missiles de croisière ou les lanceurs de satellites semblent être l'exemple canonique. Les systèmes de contrôle des processus industriels pourraient également en avoir besoin. Le ver Stuxnet semble avoir interféré avec les systèmes qui effectuent ce type de contrôle.

Vous utiliseriez RTOS dans cette dernière situation. RTOS garantit souvent la livraison d'une interruption en moins de tant d'instructions ou d'horloge ou autre.

Une autre considération pourrait être qu'un RTOS est conçu, testé et / ou «prouvé» pour ne pas consommer d'espace de pile sans limite. Il peut vivre dans une certaine quantité minimale de mémoire, et des choses comme un "OOM Killer" n'existent pas car elles ne sont pas nécessaires. Certaines des caractéristiques les plus loufoques du début de FORTRAN proviennent de ce type d'exigence. Lorsque vous avez compilé un programme FORTRAN II, vous saviez exactement combien de pile et combien de tas il fallait, car vous ne pouviez pas recurer, et vous ne pouviez rien allouer dynamiquement.

De manière réaliste, la deuxième considération (consommation maximale de mémoire garantie) peut être plus importante dans certaines applications critiques pour la sécurité que la "latence d'interruption garantie de 0,001 seconde".

J'imagine également qu'en supprimant le processus de sélection de la feuille de vigne du support du verbiage, vous constateriez que les ingénieurs choisissent un RTOS parce que "les exigences le disent".