Comment modifier un logiciel pour devenir en temps réel? [fermé]


9

Pour la première, je voudrais mentionner que je suis novice dans la programmation de systèmes en temps réel. C'est pourquoi je ne suis pas sûr que mes questions soient correctes. Désolé pour cela, mais j'ai besoin d'aide

Question en bref: comment mettre en œuvre un logiciel dur en temps réel pour être sûr qu'il respecte les délais? Il est nécessaire d'utiliser certaines fonctionnalités QNX? Ou est-ce juste suffisant pour l'écrire pour linux, le porter sur QNX et ce sera en temps réel par défaut?

Question complète: Nous avons implémenté un logiciel multiprocessus multiplateforme complexe avec communication inter-processus pour Linux, Windows, Android et QNX. Le langage de programmation est C ++, nous utilisons Boost et planty d'autres bibliothèques. Notre logiciel fait son travail bien et rapidement mais il est toujours prototype. À des fins de production, nous devons le faire en temps réel Certaines de nos fonctionnalités doivent être en temps réel et très robustes car elles sont très importantes et la sécurité des personnes qui utilisent nos logiciels peut en dépendre. Ils fonctionnent assez rapidement - jusqu'à des centaines de millisecondes. Mais je ne suis pas sûr que notre système soit vraiment en temps réel à cause de ce fait (ai-je raison?).

Il y a donc une question principale: comment modifier notre logiciel pour qu'il soit en temps réel? J'ai beaucoup cherché sur Google, mais je ne sais toujours pas comment le faire.

Quelques informations supplémentaires sur nos plateformes: Linux et Windows que nous utilisons actuellement uniquement à des fins de test. Android - nous n'avons toujours pas décidé si nous en avons besoin. QNX - est notre système d'exploitation cible pour la production. Je suppose que la réponse à ma prochaine question est "NON" :) Mais est-il possible d'implémenter un logiciel multiplateforme en temps réel (pour les systèmes d'exploitation en temps réel (RTOS) ainsi que pour les systèmes d'exploitation à usage général (GPOS))?

Peut-être que nous devons faire nos efforts pour implémenter toutes les fonctionnalités en temps réel uniquement pour QNX? Mais je ne comprends toujours pas comment le faire. Quelqu'un pourrait-il éclairer cette question?


55
Si votre projet est critique pour la sécurité, vous avez vraiment besoin de quelqu'un qui comprend les systèmes en temps réel de votre paie.
Blrfl

18
Le système en temps réel est la précision de votre code en termes de temps d'exécution, pas s'il est rapide ou lent.
Pagotti

22
Mon sentiment est que vous ne modifiez pas un logiciel existant pour devenir en temps réel, vous concevez et écrivez à partir de zéro un nouveau logiciel, en tenant compte des contraintes explicites en temps réel. Et votre question est trop large: que fait exactement votre logiciel? Sur quel type précis de système en temps réel, pour quel type concret de système embarqué (à quoi sert: l'infodivertissement en vol dans un avion commercial n'est pas la même chose que le contrôle d'un réacteur nucléaire)? Vous devez éditer votre question pour être beaucoup plus concrète, précise et motivée.
Basile Starynkevitch

24
Relisez le commentaire de Blrfl. Et puis relisez-le encore et encore et encore jusqu'à ce que vous embauchiez une personne ayant l'expérience appropriée. Ou assurez-vous que votre assurance responsabilité civile est libérée. Parce que si vous créez des logiciels critiques pour la sécurité avec des exigences en temps réel et que vous n'avez pas cette expérience, vous êtes criminellement négligent.
kdgregory

4
Vous avez demandé: " est-il possible d'implémenter un logiciel multiplateforme en temps réel (pour les OS en temps réel (RTOS) ainsi que pour les OS à usage général (GPOS))? " Je suppose que non, sinon les RTOS ne le seraient pas exister. "Cross Platform" est assez similaire à "Holy Graal".

Réponses:


38

Rapide ne signifie pas en temps réel et en temps réel ne signifie pas rapide.

En temps réel, la date à laquelle le résultat est livré est aussi importante que sa valeur. En d'autres termes, si le résultat a une valeur correcte mais est livré trop tôt ou trop tard, le résultat global est incorrect.

Par exemple, pensez à un lecteur vidéo. Si les images vidéo ne sont pas affichées au bon taux, les utilisateurs ne seront pas satisfaits. Pire si l'image et le son ne sont pas synchronisés.

Cet exemple montre que certaines applications en temps réel peuvent être implémentées sur les systèmes d'exploitation courants actuels.

Mais il y a une distinction entre le temps réel dur et le temps réel doux en ce qui concerne les conséquences d'une échéance manquée: dans les systèmes temps réel doux, ce n'est qu'une gêne ou un service dégradé (pensez aux images figées pendant plusieurs secondes dans l'exemple du lecteur vidéo), alors qu'il s'agit d'une défaillance (potentiellement catastrophique) dans un système en temps réel dur, comme dans une centrale nucléaire.


M. mouviciel, Merci d'avoir répondu à ma question Nous avons besoin de certaines fonctionnalités pour être dur en temps réel une autre peut être douce en temps réel Je ne comprends pas comment écrire un logiciel pour garantir les délais? Pourriez-vous nous éclairer sur cette question, s'il vous plaît?
user172825

7
@ user172825 - Les réponses à cette question couvrent les étagères des bibliothèques. Les points de départ peuvent être googler "programmation en temps réel", article wikipedia connexe ou tutoriels de RTOS tels que QNX ou RTEMS.
mouviciel

C'était la question la plus compliquée pour moi. J'ai trouvé beaucoup de gros livres sur ce sujet. Mais j'espérais qu'il serait possible de l'expliquer en quelques phrases. :)
user172825

5
« Il n'y a que deux choses difficiles en informatique: l'invalidation du cache et les noms. » - Phil Karlton OK, et en temps réel. Là, une phrase explique pourquoi elle ne peut pas être expliquée en deux phrases. Nous vous renvoyons maintenant à votre programmation régulière.

1
Je trouve qu'appeler «temps réel dur» «temps déterministe» aide généralement à faire passer le message aux gens.
whatsisname

15

Comme @mouviciel l'a déjà dit, le temps réel et le rapide sont vraiment deux propriétés indépendantes, même si de nombreux délais en temps réel impliquent qu'une réponse relativement rapide est nécessaire.

Lors de l'écriture d'un logiciel en temps réel, la propriété la plus importante à côté d'une réponse correcte est que vous pouvez prédire avec précision la vitesse à laquelle la réponse sera donnée. Pour les fonctionnalités matérielles en temps réel, vous devez même être en mesure de garantir que le délai sera respecté dans toutes les conditions possibles à moins d'une panne de courant complète.

Des sources typiques d'imprévisibilité peuvent être trouvées dans

  • Allocation dynamique de mémoire et collecte des ordures
  • (Priorité plus élevée) interrompt
  • Le planificateur dans l'OS
  • Création et destruction dynamiques d'objets
  • De grandes quantités de code exécuté sous condition

Je ne dis pas que vous devez éviter ces zones (comme vous ne le pouvez probablement pas), mais vous devez savoir comment elles peuvent affecter la facilité avec laquelle vous pouvez prédire que vous respecterez les délais en temps réel pour les fonctionnalités pertinentes.


4
Dans le code exécuté de manière conditionnelle, faites attention aux algorithmes amortis, où la plupart du temps l'opération est bon marché mais peut parfois se transformer en une opération beaucoup plus coûteuse, par exemple lorsqu'un vecteur s'ajoute quand il a besoin de se réallouer.
monstre à cliquet

2
Dans certains cas, vous devrez peut-être effectuer une analyse WCET , en prédisant le temps d'exécution à la milliseconde
Basile Starynkevitch

3
@ user172825: Le profilage peut aider, mais cela se résume en grande partie à l'expérience et à la connaissance du langage et des bibliothèques.
Bart van Ingen Schenau

3
Le profilage peut ne pas être suffisant si vous avez des exigences difficiles en temps réel. Si le temps d'exécution n'est pas entièrement déterministe, le profilage peut vous donner l'impression qu'il se terminera toujours avant la date limite, alors qu'en fait il ne respecte le délai que 99 fois sur 100. Si vous avez une exigence difficile en temps réel, il doit le rencontrer 100 fois sur 100.
James_pic

2
@ user172825 Le temps réel est pour le logiciel ce qu'est la chirurgie cérébrale pour la médecine - vous avez besoin de beaucoup d'expérience et de compétences pour réussir correctement et vous devez être vraiment, vraiment sûr de ce que vous faites. Ces projets sont mieux réalisés sous la supervision d'un professionnel qualifié de la région. Ce n'est pas quelque chose que vous pouvez envoyer à un développeur régulier et dire "faire fonctionner cette chose comme un système en temps réel".
T. Sar

8

Je suppose que l'explication en deux temps du temps réel est qu'un système en temps réel est conçu pour comprendre et contrôler le temps de réponse le plus défavorable des entrées changeant aux sorties changeant.

Cela nécessite une analyse qui couvre l'ensemble du système. Disons que vous avez un système trivial qui se compose d'un clavier USB et d'un servofrein. Quelle réactivité pouvez-vous obtenir avec ce système? Vous devrez peut-être considérer:

  • fréquence d'interrogation d'entrée, et combien de temps cela prend
  • latence d'interruption d'entrée
  • heure de changement de contexte du système d'exploitation une fois que vous avez un événement d'entrée
  • hiérarchisation des tâches par le système d'exploitation
  • éviter l'utilisation d'allocation dynamique ou de mémoire virtuelle dans le programme, pour éviter un délai de réponse imprévisible ou des événements OOM
  • éviter l'utilisation de la collecte des ordures
  • éviter d'utiliser O (n) ou des algorithmes pires avec un N élevé ou imprévisible (le chargement d'une très grande liste de lecture dans le système de divertissement de votre voiture ralentit-il sa réponse de freinage?)
  • considérer la latence du disque ou du réseau (par exemple, utilisation du bus CAN dans les voitures)
  • latence de contrôle de sortie

Dans ce type d'environnement, il y a généralement une attention particulière pour la fiabilité, comme les normes MISRA C.


Est-il également vrai que le fait d'être en temps réel implique de déterminer si une opération est déterministe, peut-être récursive ou même calculable dans certains cas?

Oui, tout cela serait "illimité". Les algorithmes récursifs peuvent être autorisés à condition que leur utilisation de pile soit soumise à une limite supérieure.
pjc50

5
avoiding use of garbage collection- Ça devrait l'être avoiding use of non-deterministic memory management. La récupération de place peut être effectuée en temps réel et la gestion manuelle de la mémoire n'est pas nécessairement déterministe (voir l' mallocimplémentation typique de C).
8bittree
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.