Les systèmes en temps réel nécessitent des réponses déterministes, car l'exactitude dépend du délai de livraison des résultats; Les systèmes durs en temps réel nécessitent des délais stricts, manqués entra?nera des catastrophes, tandis que le temps réel doux permet des retards occasionnels; Des facteurs non déterministes tels que la planification, les interruptions, les caches, la gestion de la mémoire, etc. affectent le calendrier; Le plan de construction comprend la sélection des RTO, l'analyse WCET, la gestion des ressources, l'optimisation matérielle et les tests rigoureux.

La raison principale pour laquelle les systèmes en temps réel ont besoin de garanties de réponse déterministe est que leur précision dépend non seulement du résultat du calcul lui-même, mais également du moment où le résultat est livré. Si un système en temps réel ne peut pas terminer les taches et répondre dans une fenêtre de temps stricte prédéfinie, alors même si les résultats du calcul sont complètement corrects, cela peut entra?ner des défaillances du système, des accidents de sécurité et même des conséquences catastrophiques. Cette prévisibilité et cette fiabilité sont la pierre angulaire de la conception et du fonctionnement du système en temps réel.

Le besoin de certitude du temps dans les systèmes en temps réel est en fait ce que j'ai vraiment réalisé lorsque je suis entré en contact avec les champs de contr?le intégré et industriel. Au début, j'ai toujours pensé que ce serait suffisant d'être "rapide", mais plus tard, j'ai réalisé que Fast ne signifie pas une certitude. Un système peut être rapide la plupart du temps, mais un délai occasionnel peut provoquer une écrasement de l'ensemble du système. Ceci est très différent des ordinateurs que nous utilisons habituellement. Si vous branchez le navigateur, ce sera une mauvaise expérience utilisateur au plus. Cependant, pour un système de conduite autonome en cours d'exécution, même un retard inattendu de millisecondes peut faire la différence entre la vie et la mort.

L'assurance de réponse déterministe signifie que le système doit être en mesure de prédire et de s'assurer que dans le pire des cas, ses taches peuvent également être effectuées dans un délai spécifié. Cela ne poursuit pas seulement la performance moyenne, mais aussi la poursuite de la limite de performance dans le pire des cas. Imaginez que si un système de commande de vol ne peut pas ajuster la surface du gouvernail dans un délai précis après l'émission de la commande, l'avion peut perdre le contr?le. C'est pourquoi les systèmes en temps réel, en particulier les systèmes en temps réel dur, ont une poursuite presque parano?aque de la certitude du temps.

Dur en temps réel et en temps réel doux: où est la frontière entre l'assurance de la réponse?

En ce qui concerne les systèmes en temps réel, nous entendons souvent les mots ?en temps réel dur? et ?en temps réel doux?. à mon avis, la distinction la plus intuitive entre eux est la conséquence de "manquer la date limite".

Le système dur en temps réel , comme son nom l'indique, est "dur" et ne peut pas être compromis. Ces systèmes ont une date limite absolue, et si une tache critique manque cette date limite, le système sera considéré comme un échec, et cette échec est souvent désastreuse. Par exemple, le contr?le du mouvement de précision des bras de robot industriel, les systèmes de freinage antiblocage (ABS) des voitures, le contr?le des vols en aérospatiale, le contr?le des réacteurs des centrales nucléaires et certains équipements médicaux (tels que les systèmes de survie). Dans ces scénarios, même un léger retard peut entra?ner des dommages à l'équipement, des victimes et même une pollution de l'environnement. Lors de la conception de ces systèmes, ils doivent subir une analyse WCET stricte et adopter un système d'exploitation en temps réel dédié (RTOS) et une architecture matérielle pour s'assurer que toutes les taches peuvent être effectuées à temps dans les conditions les plus exigeantes. Leur exactitude est l'entrelacement de l'exactitude fonctionnelle et de l'exactitude du temps.

Le système en temps réel doux est relativement "tolérant". Ils ont également des délais, mais s'ils sont manqués occasionnellement, cela ne fera pas échouer complètement le système, mais entra?nera seulement une dégradation des performances ou une expérience utilisateur compromise. Par exemple, la lecture vidéo en ligne, les jeux en ligne, le traitement multimédia et certaines taches de robot non critiques. Si la vidéo est coincée, nous pouvons nous plaindre, mais le film peut toujours être regardé; La fréquence d'images du jeu est réduite et l'opération n'est peut-être pas fluide, mais le jeu lui-même ne s'écrasera pas. Ces systèmes hiérarchisent généralement le débit et le temps de réponse moyen plut?t que des garanties de date limite strictes. Ils peuvent fonctionner sur un système d'exploitation commun (comme Linux ou Windows) et utiliser des optimisations pour améliorer la réactivité, mais ne poursuivez pas la certitude absolue comme les systèmes en temps réel dur.

Par conséquent, la frontière réside dans le "co?t de l'échec". Plus le co?t est élevé, plus la nécessité est ?difficile? de l'activité réelle. Plusieurs fois, un système complexe contiendra à la fois des composants en temps réel dur et doux, ce qui nécessite un équilibre et une isolation encore plus exquis dans la conception.

Facteurs non déterministes: Quels sont les tueurs invisibles confrontés à des systèmes en temps réel?

Lors de la construction de systèmes en temps réel, l'un des plus grands défis que j'ai trouvés était les facteurs non déterministes qui semblent petits mais qui peuvent avoir un impact énorme. Ils sont comme des tueurs invisibles, qui peuvent détruire la garantie de synchronisation du système à tout moment.

• Mécanisme de planification du système d'exploitation : Afin de maximiser le débit et l'équité, son planificateur peut basculer fréquemment entre les taches, introduisant des frais généraux de commutation de contexte imprévisible. Même pour les RTO, si la priorité est réglée de manière incorrecte ou il y a un problème d'inversion prioritaire, les taches de grande priorité peuvent être bloquées par des taches à faible priorité, ce qui entra?ne un non-réponse à temps.
• Traitement d'interruption : les interruptions matérielles sont le mécanisme clé pour que le système réponde aux événements externes, mais le temps d'exécution de la routine de service d'interruption (ISR) et la profondeur de la nidification d'interruption affecteront l'exécution de la tache actuelle et introduiront des retards incertains. Un ISR mal con?u peut prendre beaucoup de temps de CPU, ce qui a fait manquer d'autres taches en temps réel.
• Effet du cache : Afin d'améliorer les performances, les CPU modernes utilisent largement le cache à plusieurs niveaux (L1, L2, L3). L'accès aux données est rapide lorsque les coups de cache sont élevés; Une fois que le cache manque, les données doivent être lues à partir de la mémoire principale ou même des dispositifs de stockage plus lents, ce qui introduit une différence de latence d'ordre de magnitude. Les frappes de cache ou non sont souvent dynamiques et imprévisibles, ce qui pose un énorme défi à l'analyse WCET.
• Gestion de la mémoire : allocation de mémoire dynamique (

   Malloc

  / /

   gratuit

  ) ou la collecte des ordures (GC) est une autre source commune de non-déterminisme. En c / c,

   Malloc

  et

   gratuit

  Le temps d'exécution dépend du degré de fragmentation de la mémoire et de l'algorithme d'allocation de mémoire, qui peut être très incertain. Dans l'hébergement de langues telles que Java ou C #, GC fait périodiquement des applications pour nettoyer la mémoire. Ce comportement "stop-the-world" est un tabou dans les systèmes en temps réel.
• Opérations d'E / S : le temps d'achèvement des opérations d'E / S tels que la lecture et l'écriture du disque, la communication réseau, etc. est souvent très incertain. Le temps de recherche du disque dur, le retard de la transmission du réseau et de la gigue peuvent provoquer des taches qui reposent sur ces opérations pour ne pas être terminées à temps.
• Concours de bus et systèmes multi-c?urs : dans un système où des processeurs multi-c?urs ou des bus partagés multi-appareils, différents processeurs ou appareils seront en concurrence pour l'accès aux ressources partagées. Des mécanismes tels que l'arbitrage de bus et les protocoles de cohérence du cache, bien que garantissant la précision des données, peuvent également introduire des retards supplémentaires et imprévisibles.

Ces facteurs se sont entrelacés, ce qui rend l'analyse de synchronisation des systèmes en temps réel extrêmement complexe. Nous ne pouvons pas seulement considérer le temps d'exécution d'une seule tache, mais aussi leur interaction dans le système, la concurrence des ressources et les effets de superposition dans divers pires scénarios.

Comment construire un système en temps réel avec des réponses déterministes? Analyse de la technologie et de la stratégie

Il n'est en aucun cas une tache facile de créer un système en temps réel avec des réponses déterministes, et nécessite une considération complète du matériel, du système d'exploitation, de la conception de logiciels pour tester et vérification.

Tout d'abord, le choix du bon système d'exploitation en temps réel (RTOS) est la pierre angulaire. La plus grande différence entre les RTO et les systèmes d'exploitation généraux est sa certitude dans la planification des taches. Ils adoptent généralement des stratégies de planification préventives et basées sur la priorité et fournissent une réponse d'interruption à faible latence, des mécanismes de synchronisation prévisibles (tels que les mutexes, les sémaphores) et le temps d'allocation de mémoire fixe. RTOSS commun inclut Freertos, VxWorks, QNX et RT-Linux (implémenté via des correctifs en temps réel). Lors du choix des RTO, vous devez prêter attention à ses indicateurs clés tels que le contexte de la surcharge, le retard d'interruption et la précision de la minuterie.

Deuxièmement, effectuez une analyse de temps d'exécution (WCET) en profondeur . Ceci est obligatoire pour les systèmes en temps réel dur. L'objectif de l'analyse WCET est de déterminer le temps d'exécution maximal d'un segment de code dans toutes les entrées et états système possibles. Cela implique souvent des outils d'analyse de code statique, des simulateurs et même de nombreux tests et mesures sur le matériel réel. Essayez d'éviter les structures de code avec une forte incertitude du temps d'exécution, telles que des boucles complexes, des appels récursifs et des opérations qui reposent sur des E / S externes non déterministes.

De plus, concevez soigneusement les stratégies de gestion des ressources . Pour éviter l'inversion prioritaire, vous pouvez utiliser le protocole de héritage prioritaire ou le protocole de plafond prioritaire pour protéger les ressources partagées. En termes de gestion de la mémoire, essayez d'éviter l'allocation de mémoire dynamique dans les taches clés en temps réel, mais utilisez un pool de mémoire ou une pré-allocation pour vous assurer que la surcharge de temps de la mémoire est prévisible et constante. De plus, la routine de service d'interruption (ISR) devrait être aussi courte et concise que possible, ne faisant que le traitement le plus urgent, et le report complexe et la logique longue aux taches de grande priorité.

Les considérations au niveau matériel sont également cruciales. Certains processeurs fournissent une fonction de cache verrouillable (verrouillage du cache) qui peut verrouiller le code critique ou les données dans le cache pour éviter les retards provoqués par les ratés de cache. Utilisez des E / S mappées de mémoire pour accéder directement aux registres matériels, en réduisant les frais généraux des appels du système d'exploitation. Pour les systèmes multi-core, l'affinité CPU (affinité CPU) peut être prise en compte, liant les taches en temps réel à des noyaux CPU spécifiques, réduisant la surcharge de la planification croisée et la synchronisation du cache.

Enfin, des tests et une vérification rigoureux sont indispensables. Tester dans des conditions idéales ne suffit pas, et il doit être testé sous diverses charges extrêmes, entrées les pires cas et même les injections de défaut pour vérifier la réactivité déterministe du système. Cela peut inclure les tests de contrainte, les tests de gigue, le mode de défaillance et l'analyse d'impact (FMEA), etc. Parfois, afin de respecter les normes de sécurité les plus élevées, une vérification formelle est également nécessaire pour prouver mathématiquement l'exactitude du système.

La construction d'un système en temps réel avec une réponse déterministe est un projet système qui nécessite une compréhension approfondie du matériel, des logiciels, du système d'exploitation et des algorithmes. Il oblige les développeurs à toujours considérer la dimension du ?temps? aussi important que la ?correction? tout en poursuivant la mise en ?uvre fonctionnelle.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!