1 / 40

Instrumentation de la commande

Instrumentation de la commande. Objectifs & spécificités Mise en œuvre de loi de commande sur cible RT embarquée. Mise en œuvre de techniques d’obtention de code déterministe. Mise en œuvre sur architecture matérielle spécifique: Les cibles cRIO –NI Programmation graphique avancée.

lexiss
Télécharger la présentation

Instrumentation de la commande

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Instrumentation de la commande Objectifs & spécificités Mise en œuvre de loi de commande sur cible RT embarquée. Mise en œuvre de techniques d’obtention de code déterministe. Mise en œuvre sur architecture matérielle spécifique: Les cibles cRIO –NI Programmation graphique avancée • Volume horaire et évaluation du module: • 4h de cours. • 10h de TD : Ciblage de cRIO + Exercices de programmation graphique avancée • 16h de TP : Programme de pilotage des maquettes sur documents de spécifications. • Travail évalué en autonomie assistée.

  2. Plan du cours

  3. Partie I: Application RT embarquée?/ Le temps-réel. Application temps-réel? Une application temps –réel est une application ayant la capacité de répondre et d’effectuer ses traitements spécifiques dans un intervalle de temps donné, borné, garanti Une application temps-réel doit finir « à temps », « tout le temps ». • Exemple: • la commande en boucle fermée. • Traitement d’images en lignes. • Contrôle commande sécurité de fonctionnement. • Un traitement effectué sous un OS classique (MAC OS, Windows, Linux, iOS…) ne permet pas de garantir un borne supérieure systématique pour sa durée. • Un traitement effectué sous un OS RT (Vxorks, ETS…) n’a pas forcément les caractéristiques du traitement RT. • Il faut respecter certaines règles de conceptions… 3

  4. Partie I: Application RT embarquée?/ Le temps-réel. Déterminisme temporel • Le temps de cycle. • - La plus part des opérations requérants un OS RT sont cycliques. • - Le temps de cycle est le temps entre les départs de 2 traitements consécutifs. • Le jitter • - Le jitter est la variation du temps de cycle à partir du temps de cycle de référence. • Origine du jitter: • Jitter à l’éxécution. • Jitter matériel • Jitter d’ordonnancement … • Le déterminisme. • - Le déterminisme est un caractéristique des systèmes dont le jitter est borné. Le temps réel s’identifie à la robustesse du code et au déterminisme temporel. 4

  5. Partie I: Application RT embarquée?/ Embarquée. Système et application embarquée? - Système électronique piloté par logiciel et intégré au système qu’il contrôle. Exemples: Automobile, sonde, satellite, Téléphone, imprimante, photocopieur, Distributeur de billet DAB, API, capteurs TEDS, Machine à laver etc, etc…… • Système et applications soumises à des restrictions (souvent…) • RAM disponible • Espace physique • Consommation énergétique.. • Application sans IHM classique (souvent…) • Pas de clavier, souris, écran: interaction non déterministe. • Interactions continues et/ou non bloquantes • Application intégrant un protocole de communication (souvent…) • Historisation, data logging • Recette, et modification de paramètres. 5

  6. Partie I: Application RT embarquée?/ OS OS RT vs OS classique L’OS gère l’accès des tâches au temps processeur. OS classique OS RT • Gère les interruptions : • port USB, souris, clavier, périphériques, Ethernet etc.. • Ne gère pas les priorités. • Gère les priorités entre thread. • Garantie que les tâches de plus grande priorité s’exécute en 1eer. • Permet une maîtrise de l’accès aux ressources matérielles. Pas de déterminisme à l’exécution Déterminisme possible à l’exécution - Analyse de données hors ligne. - Représentation des données - Acquisition de données • Commande en boucle fermée • Tâche de contrôle et sécurité de fonctionnement • Application en exécution permanente • Application autonome 6

  7. Partie II: Présentation de la cible RT mise en oeuvre La cible d’exécution RT utilisée. - Le compact RIO (cRIO): Acronyme pour Compact Reconfigurable Input-Output - Architecture matérielle et outils logiciel tout à fait spécifique (National Instruments) • Contrôleur d’automatismes programmable ( PAC) • Il ne s’agit pas d’un automate qui répond aux spécifications de la CEI 6-1131. 7

  8. Partie II: Le compact RIO Constitution Un Contrôleur RT Chassis FPGA Modules d’E/S 8

  9. Partie II: Le compact RIO Qu’est ce qu’un cRIO? • Cible d’exécution de code déterministe dans un environnement embarqué et sévère. • Cible: Cible d’exécution de code compilé. • Déterministe: OS RT embarqué (VxWorks) • Embarqué: Alimentation double 9-35Vcc/20Wmax • Environnement Sévère: 50G & -50°C->+70° • Système modulaire et autonome d’acquisition et de génération rapide de signaux digitaux et analogiques • Modulaire: Module métier généraux ou assez spécifique (Cf énumération ultérieure) • Rapide: Horloge hardware FPGA 40MHz (25ns...) • Digitaux: TTL et analogique (courant, tension sur différentes gamme d’entrée) • Système communiquant sur port Ethernet – série + Port USB. • Ethernet pour programmation et Communication (serveur Web et ftp). • Série RS 232 pour adresser des périphériques + Mode débogage • USB pour stockage des flux de données. • Possibilités d’incorporer d’autres protocoles (CAN, modbus…) 9

  10. Partie II: Le compact RIO Spécifications du cRIO mis en œuvre. 10

  11. Partie II: Le compact RIO Les modules d’E/S 11

  12. Partie II: Le compact RIO Structure d’une application sur cRIO (1/2) Un application conçue pour une cible cRIO consiste en 3 programmes fondamentaux : • un programme hôte (host) pour interagir avec un utilisateur. • un programme temps réel (target) pour effectuer des traitements et des communications • un programme FPGA pour exécuter des fonctions d’E/S et contrôles très rapides. Le programme hôte est optionnel via serveur Web ou sans objet. Le programme FPGA peut être omis via l’utilisation du Scan Mode 12

  13. Partie II: Le compact RIO Structure d’une application sur cRIO (2/2) 13

  14. Partie II: Le compact RIO A propos des FPGA et LabVIEW FPGA FPGA: Circuit de blocs logiques reconfigurables Programmation FPGA (V erilog, VHDL) Intégration de code au niveau hardware LV FPGA: Compilation de code LV en bitfile Le FPGA est au coeur de l’architecture cRIO 14

  15. Partie II: Le compact RIO Traitement FPGA vs Traitement logiciel RT Utilisation FPGA: Pas d’OS: Vrai parallélisme! Horloge HW 40MHz! Boucles multi-cadencées réelles • Code FPGA: • Niveau de code « reflexe » imbattable en terme de déterminisme et rapidité par du ‘code logiciel ’. • Possibilités restreintes (Quid USB, Com Ethernet, Calcul complexe, Format numérique spécif., Accès disque etc…?) • Le nombre de portes est une facteur limitant. Le Scan mode permet de s’affranchir du programme LV FPGA

  16. Partie II: Le compact RIO Le scan mode (1/2) Le scan engine est un moteur de balayage des E/S des modules supportés. 1. rafraichit une table de mémoire partagée Chassis/contrôleur (canaux DMA) 2. fournit une horloge de synchronisation des boucles de traitement RT. 3. publie sur le réseau le contenu de la table mémoire 4. outils spécifiques « sur étagères » selon modules E/S présents (compteur 1MHz, PWM, Encodeur, Mesure de fréquence…) 16

  17. Partie II: Le compact RIO Le scan mode (2/2) Le scan mode simplifie la conception d’une application complète, au prix d’une limitation des performances temporelles accessibles 17

  18. Partie II: Le compact RIO Les boucles cadencées sous LV RT - Sous LabVIEW RT, une boucle cadencée constitue un thread. - Une boucle cadencée exécute le code inclus par période spécifiée et avec le niveau de priorité spécifié et sur le processeur spécifié (si plusieurs disponibles…). 18

  19. Partie II: Le compact RIO Configuration d’une boucle cadencée Les boucles de plus hautes priorités préemptent celle de plus basse priorité La configuration judicieuse des cadencement et des priorités des différents threads est une condition nécessaire (et non suffisante) pour l’obtention d’une application déterministe. 19

  20. Partie III: Conception d’une application cRIO déterministe Conditions d’obtention de code déterministe: Découpage pertinent des différents threads Cadencement des threads pour autoriser l’accès de chaque thread au processeur Eviter les recours aux ressources partagées. Optimiser le transfert de données entre les threads Prendre en compte quelques techniques pour augmenter la vitesse d’exécution du code. Vérifier l’obtention du temps de cycle ciblé via des outils d’analyses fournis et réajuster si nécessaire. 20

  21. Partie III: Conception d’une application cRIO déterministe Architecture d’une application standard: Hôte et cible. 21

  22. Partie III: Conception d’une application cRIO déterministe Découpage pertinent de l’application cible en threads. • Multithreading pour l’application cible: • Découpage de l’application en des flux d’exécution complètement indépendant. • L’application RT gère l’accès de ces flux à l’unité de traitement par priorité et cadencement Principe: Un seul thread prioritaire par cœur (TCL: Time CriticalLoop) Uniquement des opérations déterministes dans ce thread prioritaire. Répartition des tâches secondaires sur différents threads de priorité inférieure (NPL: Normal PriorityLoop) 22

  23. Partie III: Conception d’une application cRIO déterministe VI standard affecté à un thread Il est possible d’affecter un VI standard, et donc une boucle de tâche while classique, à un flux d’exécution particulier: Affectation à l’un des 5 threads possibles: Critique, haute, supérieure à la normale, normal, arrière-plan • Les boucles cadencées s’exécutent avec une priorité entre critique et haute. 23

  24. Partie III: Conception d’une application cRIO déterministe Solution possible TCL Comm. CAN Comm. CAN Commande en BF Interaction utilisateur Analyse en ligne Monitoring de sécurité Acquisition DAQ Forme d’onde Comm. UDP NPL (s) I/O sur Fichier Analyse de données I/O sur Fichier Comm. TCP Analyse en ligne Comm. TCP Affichage graphique Com. Série, GPIB etc… Monitoring de sécurité VI Hôte Commande en BF Affichage graphique Comm. UDP Com. Série, GPIB etc… Interaction utilisateur Analyse de données 24

  25. Partie III: Conception d’une application cRIO déterministe Principe d’ordonnancement des threads sous LV-RT: Un thread de plus haute priorité interrompt immédiatement tout thread de priorité inférieure pour s’exécuter (Preemptivescheduling). Tout thread de même priorité partage un même temps processeur (Round robin Scheduling) : Famine thread B et C : Famine thread C : Chaque thread a accès à l’unité de traitement Chaque thread, hors celui de plus petite priorité, doit être mis en sommeil. 25

  26. Partie III: Conception d’une application cRIO déterministe Mise d’un thread en sommeil 1er Méthode: Fonction « Waituntilnext multiple » (ms) « WaitUntilNext multiple » permet de masquer le jitter d’exécution, contrairement à « Wait » 2nd Méthode: une boucle cadencée 26

  27. Partie III: Conception d’une application cRIO déterministe Eviter les ressources partagées - Les ressources partagées désignent tout ce qui peut-être utilisé par plus d’un processus à la fois • Variables globales. • Variables processus • Variables réseaux • VI non réentrant (une seule instance) • Gestionnaire de mémoire • Session de communication • Fichier d’E/S • Sémaphores • Chaque ressource ne pouvant être utilisé simultanément, • Un thread utilisant une ressource le verrouille (mutex). • Avant qu’une thread de plus haute priorité puisse préempter, le thread préempté doit déverrouiller le mutex, c’est à dire terminer son exécution. On a une inversion de priorité. Les ressources partagées peuvent inverser les priorités et affecter le déterminisme du thread critique (si la ressource concerne le thread critique). 27

  28. Partie III: Conception d’une application cRIO déterministe Ressource partagée: Gestionnaire de mémoire • Le gestionnaire de mémoire est une ressource partagée. • L’allocation de mémoire n’est pas déterministe. = 2 raisons pour éviter utiliser le gestionnaire de mémoire dans les boucles Pré allocation de mémoire, hors boucle Pas de conversion implicite de type, qui utilise le gestionnaire de mémoire Utilisation de la structure« Éléments en place » 28

  29. Partie III: Conception d’une application cRIO déterministe Ressource partagée: Encapsulation sous VI - Si une encapsulation est appelé par plusieurs processus, Il faut le paramétrer réentrant pour créer plusieurs instances indépendants. • Il faut éviter les VI Express pour réduire le jitter. • Déselectionner toutes options inutiles à l’exécution… 29

  30. Partie III: Conception d’une application cRIO déterministe Passer les données entre threads 1/5 - Plusieurs techniques pour envoyer et recevoir des données entre VI et thread sur une cible: Variables globales FGV : Variables Globales Fonctionnelles Des RT FIFO : buffer first in, first out. Des variables partagées Single-Process avec RT FIFO activé Les variables globales sont des emplacements mémoires partagés • Source de jitter par inversion de priorité.Peut compromettre le déterminisme • Peut perdre des données. Il est possible d’écrire une variable globale plus fréquemment que de la lire • Pas adaptée au streaming • OK pour des données de petites tailles <32bits, A éviter pour des structures de données plus lourdes (cluster) 30

  31. Partie III: Conception d’une application cRIO déterministe Passer les données entre threads: Les FGV. 2/5 On peut implémenter des FGV qui ne sont pas des ressources partagées. Principe: • FGV est un sous VI qui n’itère qu’une seule fois à chaque appel. • une FGV est de priorité subroutine et paramétrée en « Skip if busy  » • Des shift-registers NON initialisés stockent les données. • On accède au contenu des registres via une structure CASE En écriture En lecture Appel d’une FGV: On accède aux données écrites les plus récentes, sans mutex. 31

  32. Partie III: Conception d’une application cRIO déterministe Passer les données entre threads: RT FIFO. 3/5 On peut implémenter des buffers FIFO • Allocation d’une taille de file • Possibilité de perte de données sur buffer plein • Informations « buffer vide » et « overwrite ». • Ecriture et Lecture peuvent être simultanée. • Fonctionnement déterministe • Fonctions utiles pour gérer dynamiquement les files RT. • Les « Single processShared variables , RT FIFO enabled » plus simpls d’utilisation 32

  33. Partie III: Conception d’une application cRIO déterministe Passer les données entre threads: Single-processShared Variables. 4/5 Single-ProcessShared variables with RT FIFO Enabled • Méthode déterministe de transfert de données entre VI et boucles sur cible RT • Utilisation d’un buffer à un seul élément ou à éléments multiples • Possibilité d’utiliser un timeout et horodatage en lecture. • Possibilité de gestion des « Overflow » (code -2221) et « underflow » (code -2220) Initialisation de la FIFO pour éviter un jitter sur 1er itération Ecriture dans un thread Lecture dans un autre thread 33

  34. Partie III: Conception d’une application cRIO déterministe Passer les données entre threads: Single-processShared Variables. 5/5 • La lecture et l’écriture simultanée est déterministe. • Le buffer FIFO reste une ressource partagée (mutex) pour de multiples nœuds d’écriture ou de multiples nœuds de lecture • -> un buffer FIFO lue dans la TCL de doit pas être lue ailleurs. • -> un buffer FIFO affecté dans la TCL ne doit pas être affecté ailleurs. • Un buffer FIFO avec plusieurs lecteurs retourne une valeur particulière, une seule fois, à chacun des lecteurs. Si chaque lecteur doit avoir accès à chaque valeur, il faut dédoubler le buffer. 34

  35. Partie III: Conception d’une application cRIO déterministe Communication hôte-Cible: Network PublishedShared Variable ou TCP Pour Communiquer sur le réseau avec un programme hôte LV : Variable partagée publiée sur le réseau - Il faut créer des bibliothèques de variables partagées publiées sur le réseau • - Assez similaire aux Single-ProcessShared variables with RT FIFO Enabled. • - Le publication n’est pas déterministe et doit être implantée entre une NPL et l’hôte. Pour Communiquer sur le réseau avec une application tierce: Protocole TCP Protocole UDP 35

  36. Partie III: Validation du déterminisme Valider une application RT • Vérification des performances d’une application: • Outils de débogage classique de LabVIEW Sonde, point d’arrêt, Step etc.. • Outils de vérification des spécifications temporelles. • Fonctions de « Comptage d’horloge » et d’horodatage. • Outils d’affichage des allocations mémoires • Outils de traçage d’exécution temps réel. (Real-timeExecution Trace Toolkit). • L’oscilloscope 36

  37. Partie III: Validation du déterminisme Outils de comptage d’horloge et d’horodatage. Principe: 1er Méthode: Fonction « Tick count » 2nd Méthode: Fonctions d’horodatage de la Palette « RT utilities » • Horodatage sur 64 bits. • Enregistrement à l’index spécifié sur tableau pré alloué • Analyse statistique sur le tableau obtenu 37

  38. Partie III: Validation du déterminisme Outils d’affichage des allocations de mémoire • Outils/Profil/ Afficher les allocations de buffer. • La connaissance de l’ensemble des allocations de mémoires effectuées (point en noir sur le diagramme) permet éventuellement d’optimiser les performances. • Il faut étudier plus spécifiquement les allocations dans les boucles. 38

  39. Partie III: Validation du déterminisme Real-timeExecution Trace Toolkit - Outils de traçage du cadencement et d’évènements survenant aux VI et aux threads • Basculement de thread: Quel thread est actif? Couleur par priorité • les mutex. • Drapeaux indicateurs d’événements spécifiés (VIEW/Configure flag) • Les allocations de mémoire 39

  40. Partie III: Validation du déterminisme Real-timeExecution Trace Toolkit Principe de fonctionnement • Modifier le code embarqué à tracer. • Ajout de VI d’ouverture et de fermeture de session d’enregistrement (buffer d’enregistrement) • Envoi d’un fichier de log en TCP après fermeture de la session. • Analyse Off-Line du fonctionnement intime du code espionné, s’exécutant sur la cible 40

More Related