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

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?

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.

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.

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.