RTOS ou pas RTOS est la question

J'ai été invité à écrire cet article par une longue branche de commentaires (malheureusement je ne peux pas appeler cela une discussion) à mon récent article "Le monde diversifié des systèmes embarqués et la place d'Embox dedans" . On m'a reproché à plusieurs endroits de confondre RTOS et Embedded OS, que j'ai appelé LynxOS, QNX et VxWorks pas RTOS, bien qu'à mon avis, bien sûr, je ne l'ai pas fait. J'ai suggéré à plusieurs reprises à l'auteur de ces commentaires d'écrire un article dans lequel il exposerait sa vision du concept de «système d'exploitation en temps réel», mais pour une raison quelconque, il a refusé. Eh bien, je vais présenter ma vision de ce terme, et discutons de ce que RTOS peut être appelé et de ce qui ne peut pas. Au final, cette question est souvent posée par rapport à Embox .

Le terme OS RV (RTOS) fait référence au domaine du marketing!

J'ai pensé commencer de manière scientifique, avec l'introduction de termes, mais j'ai décidé que cette thèse provocatrice serait la bienvenue. Alors, pourquoi est-ce que je soutiens que le terme RTOS (systèmes d'exploitation en temps réel) se réfère au marketing, plus précisément, est un slogan marketing (publicitaire)? Tout est simple. Lorsqu'un produit est fabriqué, il doit être vendu. Mais si vous essayez de vendre uniquement le système d'exploitation, des difficultés surviendront. C'est là que le positionnement sur le marché vient à la rescousse. Par exemple, vous pourriez dire «nous sommes plus rapides qu'eux».


Mais vous pouvez aller en cour pour ça! Et là, vous devrez fournir des preuves. Mais comment prouver que vous êtes plus rapide dans tous les cas? Ce n'est pas une compétition en cours. Mais bien sûr, une telle concurrence pas tout à fait correcte est légèrement hors du positionnement normal du marché.

Le positionnement normal implique la formation d'un portrait du consommateur, l'identification des propriétés du produit les plus demandées et la focalisation sur ces propriétés. Eh bien, ou vous formez ces besoins chez l'utilisateur. Par exemple, notre processeur a une telle fréquence, le smartphone a un processeur N-core, etc.

Étant donné que les classiques du genre ont déjà formulé que les systèmes d'exploitation sont nécessaires non seulement pour les systèmes utilisateur, mais aussi pour contrôler divers processus technologiques en mode automatique, et ont même introduit le concept d'un système d'exploitation en temps réel, alors, vous savez, c'est un péché de ne pas l'utiliser. Introduisant le concept de systèmes en temps réel, les classiques parlaient d'un certain seuil critique de temps. Autrement dit, il diffère des systèmes conventionnels, où si l'utilisateur attend quelque chose, alors il peut attendre, un système dur en temps réel, par exemple, contrôlant une turbine, ne peut pas attendre, sinon vous pouvez passer à quelque chose de mauvais.

Ainsi, vous pouvez dire à l'utilisateur que, contrairement aux systèmes d'exploitation conventionnels, il disposera d'un système garantissant le temps de réponse du système. Naturellement, plus il est petit, plus le nombre de processus technologiques différents que le système peut contrôler est grand. Et beaucoup de tableaux apparaissent où divers paramètres clés de RTOS sont donnés comme paramètre clé.

Comment sont-ils reçus? Ce processus est honnêtement décrit! Ici nous prenons tel ou tel problème de modèle, telle ou telle plateforme matérielle, et appliquons donc l'effet. Eh bien, le marketing, bien sûr, peut simplifier et simplement donner, un temps de réaction de 1 μs. Mais nous n'en tenons pas compte, nous pensons que tout est honnêtement décrit.

Mais excusez-moi, et s'il y a une autre tâche? 10 tâches, 100 tâches? Et si un programmeur ivre verrouille les interruptions? Et si dans le système le programmeur n'a pas correctement priorisé les tâches?

Il y a eu un cas où Embox a réussi des tests en temps réel. Nous nous sommes assis et avons pensé comment prouver qu'il s'agissait d'un système d'exploitation en temps réel. Il y a un laboratoire, il y a un client qui veut qu'il en soit ainsi. Nous constatons que pour le client, le temps de réponse du système est en temps réel de 1 μs. Je demande si l'expérience suivante sera une preuve:

• Nous prenons une certaine plate-forme matérielle
• Appliquer un signal à l'une des entrées GPIO
• Prendre un événement par programme
• A la sortie du GPIO, nous signalons par programmation
• Les mesures sont effectuées à l'aide d'un oscilloscope, le temps de réaction sera la différence entre les fronts d'entrée et de sortie.

Le client confirme que c'est exactement ce dont il a besoin. Je pose une question de clarification, et nous concevons un système modèle et ne pouvons pas le démarrer (pas le charger) avec d'autres tâches. Autrement dit, il est normal que le système ne fasse qu'une tâche de test aussi simple. Le client a déclaré que cela nécessite des tâches de test. Vous comprenez probablement vous-même que le système a passé les tests! Naturellement, avec la confirmation des caractéristiques, c'est-à-dire que l'impact a été répété.

Cette section n'est en aucun cas écrite afin de minimiser tout OS ou développeur. Mais uniquement pour montrer toute l'incomplétude de l'image. Je n'ai pas prétendu que les caractéristiques de certains systèmes d'exploitation ne permettaient pas de les attribuer au RTOS, mais juste ce terme est utilisé par les spécialistes du marketing. J'ai vu d'autres tests lorsque j'ai commandé le choix du système d'exploitation d'un laboratoire indépendant en fonction des exigences de la tâche. Il y avait un ensemble complexe de tâches de modèle, et l'interaction du réseau a été considérée, et comment les paramètres changent si le système est chargé, et le comportement dans diverses situations d'urgence.

Définition de l'expression «système d'exploitation en temps réel»

Je vais maintenant introduire le terme «système d'exploitation en temps réel». Non, je ne le ferai pas. Le fait est qu'il existe de nombreuses définitions de ce terme. Prenez au moins les commentaires sur l'article original:

Dans les systèmes en temps réel, une personne est généralement superflue et, en conséquence, la vitesse d'un système en temps réel doit être comparée aux processus qu'il contrôle, qu'il s'agisse d'une voiture autonome ou d'un système de contrôle de processus dans une usine.

SRV / RTOS - il s'agit uniquement d'un classement sur la prévisibilité de la réponse aux événements critiques.

RTOS est un tel système d'exploitation dans lequel l'exactitude d'une tâche est caractérisée non seulement par l'exactitude logique, mais par le temps qu'il faut pour terminer cette tâche.

Définissez le critère de commutation du contexte de toute tâche à 1 μs par processeur 100 MHz avec un coprocesseur à virgule flottante avec une détermination de 0,1 μs et tout se mettra en place.
Vous verrez clairement où RTOS et où pas.

Eh bien, je ne peux pas ignorer l’opinion dont j’ai parlé dans un article qui a été exprimé lors d’une des conférences de l’OSDAY :

Un système peut être considéré comme un système en temps réel difficile s'il n'a aucun endroit où, avec des interruptions verrouillées, il y a des cycles avec un nombre inconnu d'itérations.

Mais c'est peut-être tout simplement particulier, et comme suggéré dans les commentaires , il vous suffit d'utiliser les classiques et de ne pas proposer de vélos. Je citerai le classique spécifié (Andrew Tanenbaum, si quelqu'un n'a pas deviné):

«Un autre type de système d'exploitation est le système en temps réel. Ces systèmes se caractérisent par le fait que le temps est un paramètre clé. Par exemple, dans les systèmes de contrôle des processus industriels, les ordinateurs en temps réel doivent collecter des données sur le processus de production et les utiliser pour contrôler les machines en usine. Il y a souvent des délais durs à respecter. Par exemple, si une voiture descend une chaîne de montage, certaines actions doivent avoir lieu à certains instants. Si un robot de soudage soude trop tôt ou trop tard, la voiture sera ruinée. Si l'action doit absolument se produire à un certain moment (ou dans une certaine plage), nous avons un système difficile en temps réel. Beaucoup d'entre eux se trouvent dans le contrôle des processus industriels, l'avionique, l'armée et des domaines d'application similaires. Ces systèmes doivent fournir des garanties absolues qu'une certaine action se produira à un certain moment.

Un autre type de système en temps réel est un système en temps réel doux, dans lequel le fait de manquer un délai occasionnel, bien que non souhaitable, est acceptable et ne cause aucun dommage permanent. Les systèmes audio ou multimédia numériques entrent dans cette catégorie. Les téléphones numériques sont également des systèmes en temps réel doux.

Étant donné que le respect de délais stricts est crucial dans les systèmes en temps réel, le système d'exploitation est parfois simplement une bibliothèque liée aux programmes d'application, avec tout étroitement couplé et aucune protection entre les parties du système. E-Cos est un exemple de ce type de système en temps réel.

Les catégories d'ordinateurs de poche, de systèmes embarqués et de systèmes en temps réel se chevauchent considérablement. Presque tous ont au moins quelques aspects doux en temps réel. Les systèmes embarqués et en temps réel ne fonctionnent qu'avec des logiciels fournis par les concepteurs de systèmes; les utilisateurs ne peuvent pas ajouter leur propre logiciel, ce qui facilite la protection. Les ordinateurs de poche et les systèmes embarqués sont destinés aux consommateurs, tandis que les systèmes en temps réel sont davantage destinés à un usage industriel. Néanmoins, ils ont un certain nombre de points communs. »

Mais de cette description, il s'ensuit seulement que les systèmes peuvent être utilisés dans des systèmes où l'absence de réaction dans une période donnée peut entraîner des conséquences désastreuses. Eh bien, pour atteindre un paramètre clé (ne dépassant pas le temps de réaction), l'OS peut être une bibliothèque, un exemple d'eCos.

Comment obtenir des caractéristiques en temps réel

Je ne pourrais pas donner une définition stricte (si quelqu'un est prêt à donner, écrivez dans les commentaires). Mais dans toutes les définitions ci-dessus, quelques propriétés sont visibles (cette fois et la prévisibilité). Si vous traduisez le temps en option de prévisibilité (le poids de l'arc lors du passage d'un état à un autre), alors seule la prévisibilité reste!

Réfléchissons à la façon d'y parvenir.

Il sera évident de supprimer tous les éléments inutiles du système critique. Il est peu probable qu'un système universel soit stable. Même le camarade Tanenbaum en a parlé, je veux dire, quand il a parlé des eCos.

Une autre approche qui augmente la prévisibilité du système, encore une fois, proposée par Tanenbaum , est l'utilisation d'algorithmes spéciaux (simples) pour la planification des ressources, principalement le temps processeur, c'est-à-dire des planificateurs de tâches spéciales. Il a suggéré plusieurs approches de planification, mais je voudrais d'abord me concentrer sur la table statique pilotée par table.

Le développeur doit s'assurer que toutes les tâches réussissent à terminer leur tranche de temps. Pour ce faire, il est proposé d'analyser statiquement la tâche critique et de déterminer ses valeurs seuils. Cette approche est définie dans la norme ARINC-653. La norme pour les systèmes embarqués, et vous comprenez vous-même, si quelque chose n'a soudainement pas le temps de travailler dans l'avion, alors une catastrophe peut se produire.

La prochaine approche est un calendrier statique, mais basé sur des priorités. Autrement dit, le développeur doit à nouveau analyser toutes les situations et, après avoir attribué toutes les tâches dans les priorités du système, s'assurer que les tâches critiques sont terminées à un moment donné.

Je ne veux pas continuer, car il y a un original! Il est écrit, bien sûr, mieux que je ne peux le faire, et d'ailleurs, ils peuvent à nouveau être accusés de dénaturer les faits. J'ai cité précisément ces approches afin de montrer qu'en tout état de cause, le développeur du système final a la responsabilité d'assurer les caractéristiques du système. Et le système d'exploitation ne devrait fournir que les capacités appropriées.

Poursuivant la discussion sur les méthodes pour augmenter la prévisibilité, je veux faire un autre commentaire

"Vous pouvez atteindre le temps réel sur une framboise, mais pas avec RTOS, mais avec une petite machine d'état pénétrant dans son cache."

Ici, je veux prêter attention aux points suivants:

• prévisibilité accrue (propriétés en temps réel) en raison de l'exclusion de tout RTOS du système
• représentation d'un programme par une machine d'état
• Eh bien, la dépendance des systèmes en temps réel non seulement sur les propriétés du logiciel, mais aussi sur le matériel.

Avec une diminution du niveau d'imprévisibilité en cas de diminution du nombre de lignes de code, je pense que tout le monde est d'accord. Bien que, comme toujours, je ne suis pas d'accord, mais j'y reviendrai plus tard.

Quelle est l'influence du matériel ne fait également aucun doute. En particulier, lorsqu'il a été question de l'absence de cycles avec un nombre arbitraire d'itérations dans l'état d'interruptions verrouillées, il a semblé que sur certains cortex-m dans le RTOS décrit, il n'y avait aucune déconnexion des interruptions. C'est un peu rusé, car là le contrôleur d'interruption désactive les interruptions avec une priorité égale ou inférieure, indépendamment, mais le fait de l'influence est évident. Et bien sûr, la présence de cache, de traduction d'adresse (ou plutôt de manque sur les pages), contribue à l'incertitude. En particulier, je voulais attirer l'attention sur le fait qu'en fait, personne ne peut garantir à 100% le bon fonctionnement de l'équipement. Eh bien, les messages sont tombés de vous, comment la présence d'un RTOS aidera-t-elle à éviter une issue catastrophique des événements?

Représentation du programme comme une machine à états, je voudrais proposer de le considérer d'un côté non évident. À savoir, qu'un programme de prévisibilité peut être analysé. Et puisque nous parlons de toutes les conditions, il faut alors l'analyser, et statiquement, pour toutes les situations possibles. Eh bien, puisque les langages de programmation fonctionnels sont beaucoup mieux adaptés à l'analyse statique, il est possible de développer un programme dans un langage spécial, ou d'ajouter l'utilisation de langages de programmation spéciaux. La première approche est utilisée, par exemple, dans le noyau seL4 vérifié. Un exemple de la deuxième approche est la même norme ARINC-653 , avec sa formation obligatoire d'exigences en XML.

Il existe d'autres méthodes qui augmentent la prévisibilité ou, si vous le souhaitez, les facteurs affectant la prévisibilité du système. J'ai fait un rapport sur ce sujet lors d'une des conférences OSDay . En particulier, en plus de celles déjà répertoriées, j'ai mis en avant une approche architecturale. Après tout, il est bien connu que, par exemple, l'architecture micro-noyau peut augmenter la prévisibilité du système. Mais même dans le même rapport, une approche organisationnelle quelque peu non évidente a été mise en évidence. C'est à peu près le point où je n'étais pas d'accord que le manque de RTOS conduit à une prévisibilité accrue. Si vous y réfléchissez, alors en général, le concept d'un système d'exploitation a considérablement réduit le nombre d'erreurs dues à la réutilisation du code. Autrement dit, si vous n'avez pas de code qui s'intègre vraiment dans un commutateur / boîtier, il est préférable d'utiliser des modules prêts à l'emploi. Après tout, le paramètre "nombre d'erreurs pour 1000 lignes de code" n'a pas été annulé, et quel que soit le débogage de votre nouveau code, il y a des erreurs.

RTOS existe-t-il du tout?

Ayant établi sur la déclaration dans la section précédente qu'il y a des erreurs dans n'importe quel code, je veux faire une thèse plus provocante. RTOS existe-t-il du tout?

Voyons cela. En discutant avec un ami des systèmes en temps réel, nous avons convenu dans la mesure où un système d'exploitation en temps réel (nous parlons de systèmes en temps réel dur) peut difficilement exister. Il a proposé de représenter l'ensemble du système comme une machine à états ou un graphique avec une description du temps de transition maximum d'un état à un autre. De plus, le système peut être considéré comme stable s'il est prouvé que pour tous les états d'entrée et internes, il existe un arc conduisant à un état donné avec une limite de temps. Eh bien, vous comprenez, cela n'est possible que pour un très petit système, juste la machine même des États mentionnée dans le commentaire, mais dans le monde moderne, peu de gens ont besoin d'un tel système.

Mais nous ne doutons pas qu'il existe des systèmes en temps réel. Et bien sûr, RTOS aussi. Si ce n'était pas le cas, le premier pic volant volerait la civilisation, il n'y aurait plus d'avionique, d'astronautique, de robotique, d'ACS-TP et bien plus encore.

Comment sortir de la situation. C'est très simple, bien qu'en général le problème soit très probablement insoluble, mais pour un problème spécifique, il est possible d'introduire des restrictions qui le rendent résoluble, avec une sorte de probabilité significative d'erreur.

Par exemple, des normes sont introduites: POSIX en temps réel , ARINC-653 , ITRON . En fait, ces normes distinguent une classe de tâches qui peuvent être résolues si vous respectez cette norme. Ou des études sont menées par des laboratoires indépendants qui étudient si les propriétés d'un système d'exploitation particulier sont appropriées pour résoudre le problème cible.

Alors Embox RTOS ou pas RTOS?

À mon avis, pour répondre à une question similaire, à la fois pour Embox et pour tout autre système d'exploitation, vous ne pouvez que demander: "Que voulez-vous dire?". Plus précisément: «Que voulez-vous dire par le concept de temps réel?». Autrement dit, si le temps de traitement des interruptions est intéressant et s'il est possible d'appeler directement le gestionnaire d'interruptions, c'est une chose, si vous devez augmenter la fiabilité du travail, quoique lentement, mais il est certainement beaucoup moins susceptible d'échouer, c'est une autre, la conformité à n'importe quelle norme est la troisième, La vérification est la quatrième. Ce n'est pas un hasard si le grand classique Andrei Tanenbaum, bien qu'il ait proposé des méthodes pour augmenter la prévisibilité, a utilisé le concept même d'un système en temps réel, mais s'est abstenu de toute définition stricte.

PS Au moment d'écrire ces lignes, aucun RTOS n'a été affecté.