Un protocole pour la génération automatique d'interfaces Web pour les applications LabVIEW utilisant le protocole d'interopérabilité à distance

Résumé

Cette étude valide une génération automatique d'interface utilisateur Web fondée sur un protocole d'interopérabilité à distance (RIP) à l'aide de deux systèmes LabVIEW distincts — un modèle de ventilateur et un modèle de commande de position de moteur à courant continu — et fournit une procédure reproductible pour la construction, l'enregistrement, le déploiement et les tests des deux exemples.

Résumé

Les plates-formes expérimentales à distance permettent d'accéder à des modèles de simulation locaux ou à des dispositifs physiques via un réseau, mais les interfaces Web classiques nécessitent généralement une page distincte, une disposition des commandes et une logique de communication de données spécifiques à chaque expérience, ce qui augmente les coûts de développement. Ce travail valide un flux de travail établi permettant de générer automatiquement une interface utilisateur (IU) Web à partir d'instruments virtuels LabVIEW (VIs) en utilisant le protocole d'interopérabilité à distance (RIP) et fournit un protocole reproductible pour sa mise en œuvre. Le flux de travail construit des VIs LabVIEW qui définissent des commandes d'entrée et des indicateurs de sortie sur le panneau avant, enregistre chaque VI dans la configuration du serveur RIP, lit les métadonnées de variables résultantes et génère les commandes Web et affichages de sortie correspondants. Caddy est utilisé comme serveur mandataire inverse afin d'unifier le chemin d'accès aux fichiers statiques de l'interface frontale et le chemin des requêtes vers l'interface de programmation d'applications (API) RIP. Le flux de travail est évalué à l'aide de deux systèmes distincts : un modèle de vitesse de ventilateur et un modèle de commande de position proportionnelle-intégrale-dérivée (PID) pour un moteur à courant continu (CC). Dans les deux cas, la page Web identifie les variables exposées, écrit les entrées utilisateur vers le module LabVIEW central, lit les sorties du modèle et génère l'interface à partir des métadonnées RIP. Ces résultats valident le même processus de génération automatique d'IU sur deux systèmes dynamiques différents et documentent les étapes nécessaires pour le reproduire.

Introduction

Avec le développement des expériences à distance, de l'enseignement en ligne et des technologies de l'Internet des objets, la mise à disposition d'un accès Web à des modèles de simulation locaux ou à des dispositifs expérimentaux est devenue une direction importante dans le développement des plateformes expérimentales^1,2,3,4. Des travaux récents ont davantage intégré des laboratoires équipés de l'Internet des objets à des apprentissages par projets et à des accès locaux ou distants, démontrant ainsi l'évolution continue vers des plateformes expérimentales flexibles et interconnectées dans l'enseignement du génie⁵. Pour les expériences sur les systèmes de contrôle, les utilisateurs doivent généralement ajuster les paramètres d'entrée via un navigateur et observer les états de sortie en temps réel^6,7. Les méthodes classiques exigent habituellement une page Web distincte, une logique de liaison de commande et une interface de communication de données pour chaque objet expérimental^8,9. Lorsque les variables du modèle en arrière-plan changent, la page frontale doit souvent être modifiée en conséquence, ce qui entraîne des travaux de développement répétitifs importants et limite l'expansion rapide de la plateforme expérimentale.

Le protocole d'interopérabilité à distance (RIP) fournit une couche intermédiaire entre les modèles expérimentaux en aval et les interfaces Web en amont^10,11. Dans l'approche de génération automatique d'interface utilisateur fondée sur le RIP décrite dans des travaux antérieurs, le serveur RIP fournit des métadonnées pour chaque expérience, notamment les noms des variables, les attributs d'entrée/sortie, les types de données, les valeurs minimales, les valeurs maximales, la précision, les descriptions, ainsi que les méthodes de lecture/écriture disponibles¹¹. Un client Web peut ensuite utiliser ces métadonnées pour créer les éléments HTML correspondants, tels que des libellés, des champs numériques, des curseurs, des commandes booléennes et des affichages de sortie, lors du chargement ou de l'actualisation de la page¹¹. Le présent protocole ne réimplémente ni ne redéfinit pas la spécification RIP. Il s'appuie plutôt sur le service RIP open source existant et sur la logique de génération d'interface utilisateur HTML à partir des métadonnées basée sur le RIP comme fondement pour la communication et la création d'interfaces, en mettant l'accent sur la construction reproductible, l'enregistrement, le déploiement par proxy et la vérification de deux exemples de VI LabVIEW.

Par rapport au développement traditionnel d'interfaces Web personnalisées, la génération automatique d'interfaces utilisateur basée sur RIP réduit la nécessité de mettre en œuvre des agencements de commandes, une logique de liaison de variables et des fonctions de communication de base lorsque plusieurs expériences LabVIEW exposent des variables d'entrée et de sortie scalaires comparables^8,9,10,11. Une fois qu'une nouvelle VI est enregistrée et que ses variables sont accessibles au serveur RIP, la même logique de lecture des métadonnées et de génération de commandes peut être réutilisée pour construire l'interface Web de base^10,11. Cette fonctionnalité est utile pour un déploiement rapide, des démonstrations pédagogiques et des plateformes de laboratoires à distance nécessitant un accès cohérent à plusieurs expériences similaires^3,8,9. Toutefois, l'interface générée automatiquement présente également des limitations. Elle n'infère pas entièrement les relations physiques entre les variables, ne détermine pas automatiquement les affectations des graphiques, ni ne conçoit des visualisations ou des interactions de sécurité spécifiques au domaine¹¹. Par conséquent, le développement manuel d'interfaces Web reste préférable lorsque l'expérience requiert des graphiques fortement personnalisés, des flux de travail utilisateurs complexes, une visualisation avancée, des verrouillages de sécurité matériels ou une arbitrage d'écriture multiutilisateurs.

Le flux de travail global du protocole est résumé dans la Figure 1. Dans ce flux de travail, un VI LabVIEW définit d'abord les commandes d'entrée et les indicateurs de sortie requis sur le panneau frontal. Le VI est ensuite enregistré dans la configuration du serveur RIP en spécifiant le nom de l'expérience et le chemin d'accès du VI. Après l'enregistrement, le serveur RIP lit les métadonnées de l'expérience sélectionnée et fournit un accès en lecture/écriture aux variables disponibles. La page Web XHTML utilise les métadonnées retournées pour générer automatiquement les commandes d'entrée et les affichages de sortie correspondants, tandis que Caddy fournit un chemin d'accès unifié pour la page Web statique et les routes de communication RIP. Les modèles de ventilateur et de moteur à courant continu sont utilisés dans cette étude comme deux implémentations du même flux de travail. Pour d'autres expériences LabVIEW fournissant des variables scalaires, numériques et booléennes compatibles, les développeurs peuvent suivre le même flux de travail de création-enregistrement-déploiement-vérification afin de créer une interface Web générée automatiquement, tout en ajoutant, si nécessaire, une visualisation propre à l'expérience, une logique de sécurité ou une gestion complexe des données.

Cet article ne propose pas une nouvelle architecture RIP ni n'étend la gamme des types de données déjà pris en charge par RIP. Il utilise plutôt RIP comme mécanisme établi de communication et de génération d'interface utilisateur basée sur des métadonnées, en se concentrant sur la validation de ce même processus avec deux systèmes LabVIEW différents, tout en documentant un protocole de mise en œuvre reproductible. Des travaux antérieurs ont présenté une méthode de base pour la génération automatique d'une interface Web basée sur les métadonnées RIP, en utilisant une expérience en ligne sur un moteur servo comme étude de cas¹¹. Des architectures de laboratoires distants accessibles via le Web, combinant des interfaces interactives avec des logiciels d'ingénierie et LabVIEW, ont également été décrites dans des études antérieures^9,12. Toutefois, lors de la reproduction pratique, certains modèles LabVIEW du cas initial ont été affectés par des problèmes de compatibilité entre versions logicielles et modules, ce qui les rend difficilement utilisables directement dans un environnement plus récent. Ce travail reconstruit donc deux VIs compatibles en backend — un modèle de ventilateur et un modèle de contrôle de position proportionnel-intégral-dérivé (PID) pour un moteur à courant continu (DC) — et applique à chacun le même processus de génération d'interface utilisateur piloté par les métadonnées. La contribution réside dans la validation croisée du flux de travail RIP établi et dans un protocole détaillé permettant de reproduire ce processus, plutôt que dans une extension de la généralité de RIP.

Les utilisateurs visés par ce protocole sont des chercheurs, des enseignants et des développeurs de laboratoires qui utilisent déjà des VIs LabVIEW et qui ont besoin d'exposer des modèles de simulation ou des systèmes expérimentaux à faible risque via un navigateur Web, sans devoir mettre en œuvre indépendamment une interface personnalisée complète pour chaque modèle. Ce protocole convient particulièrement aux expériences utilisant des variables numériques et booléennes standard, l'ajustement de paramètres et la surveillance en temps réel de l'état du système^10,11. Il est moins adapté comme solution autonome pour des expériences nécessitant des structures de données complexes, des visualisations spécialisées, des interverrouillages stricts de sécurité matérielle ou une arbitrage d'écriture multiutilisateurs¹¹. L'objectif de ce travail est de valider la génération automatique d'une interface Web basée sur RIP à l'aide de deux systèmes LabVIEW différents, et de fournir un protocole complet et reproductible, allant de la construction du VI en backend jusqu'à l'interaction via un navigateur. Le protocole comprend la définition des variables d'entrée et de sortie, l'enregistrement de l'expérience sur le serveur RIP, la génération d'interface utilisateur basée sur les métadonnées, le déploiement d'un proxy Caddy, ainsi que la vérification des accès distants en lecture/écriture. L'application de ce même flux de travail aux modèles de ventilateur et de moteur à courant continu démontre que le processus établi peut être reproduit sans avoir à réécrire manuellement une interface Web complète pour chaque exemple^9,10,11.

Protocole

Effectuez les étapes suivantes pour créer, enregistrer, déployer et vérifier deux expériences LabVIEW accessibles via RIP selon le flux de travail résumé dans la Figure 1. Tous les outils et plateformes utilisés dans cette étude sont répertoriés dans le Tableau des matériaux.

1. Construire et déployer l'expérience du modèle d'éventail

1. Construire le VI du modèle de ventilateur.
   1. Ouvrir LabVIEW, créer un nouveau VI et enregistrer le fichier sous le nom fengshan.vi. Enregistrer le VI dans un répertoire accessible par le processus RIP WebService. Le dossier Private est utilisé uniquement comme exemple de répertoire et n'est pas codé en dur dans RIP. Entrer le chemin réel du VI sélectionné lors de l'inscription de l'expérience RIP.
   2. Sur le panneau avant, ajouter les commandes d'entrée pour le modèle de ventilateur. Dans cet exemple, nommer les commandes d'entrée Enable, PWM, Load, Tau, KMaxRPM et Disturbance. Définir Enable comme commande booléenne, et définir PWM, Load, Tau, KMaxRPM et Disturbance comme commandes numériques à virgule flottante double précision (DBL). Voir Tableau supplémentaire 1 pour la signification physique et le rôle dans le modèle des variables du ventilateur.
   3. Ajouter les indicateurs de sortie pour le modèle de ventilateur. Dans cet exemple, nommer les indicateurs de sortie SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA et PowerW. Définir tous les indicateurs de sortie comme indicateurs DBL.
      ​REMARQUE : Le Tableau 1 décrit la signification physique et le rôle dans le modèle de ces variables de sortie. Le panneau avant complet du ventilateur est illustré dans la Figure 2. Les noms de variables, plages et pas indiqués dans le Tableau 1 décrivent les deux exemples mis en œuvre dans ce protocole. Ils ne sont pas des exigences codées en dur dans RIP. Pour d'autres expériences LabVIEW, les développeurs peuvent définir d'autres noms de variables et propriétés numériques sur le panneau avant. Le serveur RIP lit les noms de variables réels, les types de données, les attributs entrée/sortie et les propriétés numériques disponibles à partir des métadonnées du VI, et la page Web génère les commandes et affichages correspondants à partir des métadonnées retournées.
   4. Ajouter une boucle While au diagramme bloc. Ajouter deux registres à décalage pour stocker speed_prev et time_prev, et initialiser les deux valeurs à 0.
   5. Ajouter un nœud de formule à l'intérieur de la boucle While. Connecter Enable, PWM, Load, Tau, KMaxRPM, Disturbance, speed_prev et time_prev aux bornes d'entrée gauche du nœud de formule, et définir SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW et time_next comme bornes de sortie droite.
   6. Construire la logique de commande Enable à l'extérieur du nœud de formule. Utiliser Enable comme signal de sélection de sorte que u = PWM lorsque Enable est Vrai et u = 0 lorsque Enable est Faux.
   7. Saisir le code du modèle de ventilateur dans le nœud de formule. Utiliser ce code pour calculer la vitesse en régime permanent, la vitesse réelle, la vitesse normalisée, le courant, la puissance et le temps d'exécution ; voir le fichier de code supplémentaire 1 pour le code complet.
   8. Connecter la sortie speed_next du nœud de formule à l'indicateur SpeedRPM, et reconnecter speed_next au registre à décalage droit pour speed_prev. Connecter SteadyRPM à l'indicateur SteadyRPM.
   9. Connecter time_next à l'indicateur TimeS, et reconnecter time_next au registre à décalage droit pour time_prev. Connecter SpeedNorm, CurrentA et PowerW aux indicateurs de sortie correspondants.
   10. Ajouter une fonction d'attente à l'intérieur de la boucle While et régler le temps d'attente à 50 ms. Ajouter un bouton d'arrêt local et le connecter à la borne conditionnelle de la boucle While.
   11. Enregistrer fengshan.vi. Le diagramme bloc complet du ventilateur est illustré dans la Figure 3.
       POINT DE PAUSE : Après avoir enregistré le VI du ventilateur terminé, le flux de travail peut être interrompu. Reprendre ultérieurement en rouvrant le VI enregistré et en confirmant que toutes les commandes, indicateurs du panneau avant et connexions du diagramme bloc sont toujours présents.
2. Inscrire l'expérience du ventilateur sur le serveur RIP.
   1. Ouvrir RIPWebService.lvproj dans l'explorateur de projet LabVIEW
      .
   2. Ouvrir Configuration.vi depuis l'arborescence du projet et localiser le tableau de configuration de l'expérience.
   3. Ajouter une nouvelle ligne d'expérience. Définir le nom sur fan. Indiquer le chemin complet vers le fichier fengshan.vi enregistré. Les champs d'inscription pour l'expérience du ventilateur sont illustrés dans la Figure 4.
   4. Remplir les champs de configuration restants. Définir Authors comme l'auteur de l'expérience, Keywords comme Fan, Description comme modèle de vitesse de ventilateur, et Sampling Freq comme 200.
   5. Dans le menu LabVIEW, sélectionner Éditer > Définir les valeurs actuelles comme valeurs par défaut. Enregistrer Configuration.vi.
   6. Redémarrer RIP WebService et confirmer que l'expérience du ventilateur reste listée dans l'interface de configuration après redémarrage.
      REMARQUE : Le nom de l'expérience respecte la casse. La valeur fan dans la configuration RIP doit correspondre exactement à l'ID d'expérience utilisé dans le fichier XHTML frontal. Pour déployer un autre VI LabVIEW avec la même logique de génération automatique d'interface utilisateur, ajouter une nouvelle entrée d'expérience dans la configuration RIP, définir une nouvelle valeur de nom, et définir Path vers le fichier VI correspondant. Ensuite, utiliser la même valeur de nom comme ID d'expérience dans le fichier XHTML. La page frontale n'a pas besoin d'être réécrite pour chaque variable.
      ​POINT DE PAUSE : Après avoir enregistré Configuration.vi et défini les valeurs actuelles comme valeurs par défaut, le flux de travail peut être interrompu. Reprendre ultérieurement en redémarrant RIP WebService et en confirmant que l'expérience du ventilateur est toujours inscrite.
3. Préparer la page frontale pour l'expérience du ventilateur.
   1. Placer Fan_Automatic_UI.xhtml dans le répertoire Client utilisé comme répertoire racine frontal.
   2. Ouvrir Fan_Automatic_UI.xhtml avec un éditeur de texte.
   3. Localiser la variable d'ID d'expérience dans la section de script et la définir sur fan.
      REMARQUE : Cette valeur doit correspondre exactement au champ Nom de l'expérience du ventilateur dans la configuration RIP. Les paramètres d'ID d'expérience et la logique de génération d'interface utilisateur partagée basée sur les métadonnées pour les fichiers XHTML frontaux sont illustrés dans la Figure 5.
   4. Vérifier que la page obtient l'origine d'accès actuelle via window.location.origin, demande les métadonnées de l'expérience via rip.info(), et transmet les métadonnées retournées à autobuildUI().
      REMARQUE : La page ne doit pas coder manuellement les noms, plages ou pas des variables du ventilateur. Au lieu de cela, les variables modifiables sont générées à partir de meta.writables.list, les variables lisibles à partir de meta.readables.list, et les attributs numériques tels que min, max et step sont obtenus à partir des métadonnées retournées par le serveur RIP.
   5. Enregistrer Fan_Automatic_UI.xhtml.
      ​REMARQUE : Pour utiliser la même logique de génération frontale pour un autre VI LabVIEW, définir un nouvel ID d'expérience dans le fichier XHTML et inscrire le nom d'expérience correspondant et le chemin du VI dans la configuration RIP. Les commandes Web et affichages de sortie sont générés selon les métadonnées retournées par l'expérience sélectionnée.
4. Configurer le chemin d'accès Caddy pour l'expérience du ventilateur.
   1. Ouvrir le Caddyfile avec un éditeur de texte.
   2. Définir le répertoire racine frontal comme le répertoire Client contenant Fan_Automatic_UI.xhtml.
   3. Sélectionner un port local inutilisé pour que Caddy permette l'accès via navigateur à la page Web et aux routes RIP. Dans ce protocole, le port 8090 est utilisé comme exemple de port d'accès proxy.
      REMARQUE : Le port 8090 n'est pas requis par RIP ou Caddy. Si le port 8090 est occupé, le remplacer par un autre port local inutilisé et utiliser le même port dans l'adresse du navigateur.
   4. Ajouter une route qui réécrit /fan en Fan_Automatic_UI.xhtml.
   5. Identifier le port du service Web RIP configuré dans LabVIEW. Dans ce protocole, http://localhost:8001 est utilisé comme adresse du service Web RIP.
      REMARQUE : Le port 8001 est le port arrière de LabVIEW/RIP WebService utilisé dans l'environnement de test. Il peut être modifié dans la configuration de LabVIEW/RIP WebService. Si un port différent est utilisé, remplacer http://localhost:8001 dans le Caddyfile par l'adresse correspondante du service Web RIP.
   6. Ajouter une règle de proxy inverse qui envoie les requêtes /RIP/SSE* à l'adresse du service Web RIP, par exemple http://localhost:8001.
   7. Ajouter une règle de proxy inverse qui envoie les requêtes /RIP* à l'adresse du service Web RIP, par exemple http://localhost:8001. La configuration du Caddyfile est illustrée dans la Figure 6.
   8. Ouvrir l'invite de commandes sous Windows. Accéder au répertoire local de téléchargement ou d'installation de Caddy en entrant la commande suivante :
      cd /d D:\caddy
      REMARQUE : Dans ce protocole, D:\caddy est le chemin local de téléchargement ou d'installation de Caddy utilisé dans l'environnement de test. Si Caddy est stocké dans un autre répertoire, remplacer D:\caddy par le chemin local correspondant.
   9. Démarrer Caddy avec le Caddyfile spécifié en entrant la commande suivante :
      caddy.exe run --config Caddyfile
   10. Confirmer que Caddy démarre sans erreur de configuration. Ouvrir http://localhost:8090/fan dans un navigateur Web et vérifier que l'interface utilisateur Web du ventilateur est générée, comme illustré dans la Figure 7.
       ​REMARQUE : Si le navigateur renvoie une erreur 502, vérifier que RIP WebService est en cours d'exécution, que le port du service Web RIP dans LabVIEW correspond à l'adresse du proxy inverse dans le Caddyfile, et que le port d'accès Caddy sélectionné n'est pas occupé.
5. Vérifier les résultats de fonctionnement de l'expérience du ventilateur.
   1. Vérifier que la page frontale génère automatiquement les commandes d'entrée Enable, PWM, Load, Tau, KMaxRPM et Disturbance.
   2. Vérifier que la page frontale affiche les variables de sortie SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA et PowerW.
   3. Régler PWM et observer si SpeedRPM augmente lorsque PWM augmente et diminue lorsque PWM diminue.
   4. Régler Load et observer si SteadyRPM et SpeedRPM diminuent lorsque la charge augmente.
   5. Régler la perturbation et observer si SpeedRPM, CurrentA et PowerW changent en réponse à l'entrée de perturbation.
   6. Vérifier que TimeS continue d'augmenter, confirmant ainsi que le VI du ventilateur en arrière-plan s'exécute en continu.

2. Construire et déployer l'expérience de contrôle de position PID d'un moteur à courant continu

1. Construire le modèle VI de commande de position PID du moteur à courant continu.
   1. Ouvrez LabVIEW, créez un nouveau VI et enregistrez le fichier sous le nom Motor.vi. Enregistrez le VI dans un répertoire accessible par le processus RIP WebService.
      REMARQUE : Le dossier Private est utilisé uniquement comme exemple de répertoire et n'est pas enregistré en dur dans RIP. Saisissez le chemin réel du VI sélectionné lors de l'enregistrement de l'expérience RIP.
   2. Sur le panneau avant, ajoutez les commandes d'entrée pour le modèle de contrôle de position PID du moteur à courant continu. Dans cet exemple, nommez les commandes d'entrée Consigne, Kc, Ti, Td, Perturbation, et Réinitialiser le contrôle. Régler Consigne, Kc, Ti, Td et Perturbation comme contrôles numériques DBL, et définir le contrôle Reset comme un contrôle booléen.
      REMARQUE : Tableau 1 décrit la signification physique, le rôle dans le modèle et la plage recommandée des variables utilisées dans cet exemple.
   3. Ajouter les indicateurs de sortie pour le modèle de commande PID de position du moteur à courant continu. Dans cet exemple, nommer les indicateurs de sortie Position, Tension, Temps et Vitesse angulaire mesurée. Réglez tous les indicateurs de sortie en tant qu'indicateurs DBL. Tableau 1 décrit la signification physique et le rôle du modèle de ces variables de sortie. Le panneau avant complété pour le moteur est illustré dans Figure 8.
      REMARQUE : Les noms et plages de variables énumérés dans Tableau 1 décrivent les deux exemples mis en œuvre dans ce protocole. Ils ne constituent pas des exigences fixes pour le flux de travail de génération automatique d'interface utilisateur basé sur RIP. Lorsqu'un autre VI LabVIEW est utilisé, RIP lit les noms réels des variables, les types de données, les attributs d'entrée/sortie et les propriétés numériques disponibles à partir des métadonnées du VI. Par conséquent, la logique de génération de l'interface frontale n'a pas besoin d'intégrer en dur les noms des variables, les valeurs maximales, les valeurs minimales ou les pas pour chaque expérience.
   4. Ajouter une boucle While au diagramme bloc. Ajouter six registres à décalage pour stocker theta, omega, im, e_prev, integ et temps, et initialiser les six valeurs à 0.
   5. Ajouter un nœud de formule à l'intérieur de la boucle While. Selon le diagramme du modèle de contrôle de position PID du moteur à courant continu illustré dans Figure 9, utilisez ce nœud de formule comme module de calcul central pour le calcul d'erreur, la commande PID, la limitation de tension, le modèle électrique, le modèle mécanique et la mise à jour de la position.
      REMARQUE : Les paramètres internes du moteur utilisés dans ce modèle, tels que R, L, J, b, Kt, Ke, et Vmax, sont des paramètres normalisés de modèle pédagogique plutôt que des paramètres étalonnés d'un moteur physique spécifique. Ils ont été choisis afin de produire une réponse simulée stable et observable avec le pas de temps et la limite de tension sélectionnés, de manière à ce que les effets de Consigne, Kc, Ti, Td et Perturbation peut être clairement démontré lors d'une opération en ligne.
   6. Réglez sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, perturbation, réinitialisation et dt asont les bornes d'entrée du nœud de formule. Régler theta_suivant, omega_suivant, im_suivant, e_suivant, integ_suivant et tension comme les bornes de sortie du nœud de formule.
   7. Connecter le Consigne contrôle au sp borne d'entrée du nœud formule. Connecter Kc, Ti, Td et Perturbation au Kc, Ti, Td et dperturbation ibornes d'entrée du nœud Formule, respectivement.
   8. Convertir le signal booléen de contrôle Reset en un signal numérique et le connecter à la réinitialiser entrée du nœud formule. Exécuter la réinitialisation de l'état lorsque réinitialiser n'est pas égal à 0, et exécuter la commande PID et la mise à jour de l'état du moteur lorsque réinitialiser est égal à 0.
   9. Ajouter la constante numérique dt et régler sa valeur sur 0,001 s. Connecter le dt au dt entrée du nœud formule et utilisez-la pour la mise à jour du temps.
   10. Définir les paramètres du modèle interne du moteur à courant continu dans le nœud de formule. Voir Tableau supplémentaire 2 pour la signification physique et le rôle du modèle des variables du moteur.
   11. Saisir le code de commande de position PID du moteur à courant continu dans le nœud de formule. Utiliser ce code pour implémenter la logique de réinitialisation, le calcul de l'erreur, le calcul du terme intégral, le calcul du terme dérivé, la commande PID, la limitation de tension, la mise à jour du courant, la mise à jour de la vitesse angulaire et la mise à jour de la position ; consulter les fichiers de code supplémentaires pour obtenir le code complet.
   12. Connecter theta_suivant au Position indicateur, et connecter theta_suivant retour au registre à décalage droit pour theta Connecter omega_next au Indicateur de vitesse angulaire mesurée, et connecter omega_next retour au registre à décalage droit pour omega
   13. Connectez la tension à l'indicateur de tension. Connectez im_next, e_next et integ_next retour aux registres à décalage droits pour im, e_préc, et integ, respectivement.
   14. Utiliser une fonction Add à l'extérieur du nœud de formule pour effectuer le calcul temps_suivant = temps + dt. Connecter temps_suivant au Temps indicateur, et connecter time_next retour au registre à décalage droit pour la durée.
   15. Ajouter une fonction d'attente à l'intérieur de la boucle Tant que et régler le temps d'attente sur 1 ms. Ajouter un bouton Arrêt et le relier au terminal conditionnel de la boucle Tant que.
   16. Enregistrez Motor.vi. Le diagramme des blocs du moteur terminé est illustré dans Figure 10.
       POINT DE PAUSE : Après avoir enregistré le VI moteur terminé, le workflow peut être interrompu. Reprenez ultérieurement en rouvrant le VI enregistré et en vérifiant que tous les contrôles, indicateurs du panneau avant et connexions du diagramme des blocs sont toujours présents.
2. Enregistrez l'expérience motrice dans le serveur RIP.
   1. Ouvrez RIPWebService.lvproj dans l'Explorateur de projets LabVIEW.
   2. Ouvrez Configuration.vi depuis l'arborescence du projet et localisez le tableau de configuration de l'expérience.
   3. Ajouter une nouvelle ligne d'expérience. Définir le nom sur Moteur. Définir le chemin d'accès au chemin complet du fichier Motor.vi enregistré. Les champs d'inscription de l'expérience moteur sont indiqués dans Figure 11.
   4. Remplissez les champs de configuration restants. Définissez Auteurs sur l'auteur de l'expérience, Mots-clés sur Moteur, Description sur modèle de commande de position du moteur à courant continu, et Fréquence d'échantillonnage sur 200.
   5. Dans le menu LabVIEW, sélectionnez Modifier > Définir les valeurs actuelles comme valeurs par défaut. Enregistrer Configuration.vi.
   6. Redémarrez le service Web RIP et vérifiez que l'expérience Motor reste répertoriée dans l'interface de configuration après le redémarrage.
      REMARQUE : Le nom de l'expérience respecte la casse. La valeur Motor dans la configuration de RIP doit correspondre exactement à l'identifiant d'expérience utilisé dans Motor_Automatic_UI.xhtml. Pour déployer un autre VI LabVIEW utilisant la même logique de génération automatique d'interface utilisateur, ajoutez une nouvelle entrée d'expérience dans la configuration de RIP, définissez une nouvelle valeur pour Nom et indiquez dans Chemin le fichier VI correspondant. Utilisez ensuite la même valeur de Nom comme identifiant d'expérience dans le fichier XHTML. La page frontale n'a pas besoin d'être réécrite pour chaque variable.
      ​POINT DE PAUSE : Après avoir enregistré Configuration.vi et défini les valeurs actuelles comme valeurs par défaut, le flux de travail peut être interrompu. Reprenez ultérieurement en redémarrant RIP WebService et en confirmant que l'expérience Motor est toujours enregistrée.
3. Préparer la page d'accueil pour l'expérience sur le moteur.
   1. Placer le fichier Motor_Automatic_UI.xhtml dans le répertoire Client utilisé comme répertoire racine de l'interface.
   2. Ouvrir Motor_Automatic_UI.xhtml avec un éditeur de texte.
   3. Localisez la variable d'identifiant d'expérience dans la section de script et définissez-la sur Motor. Cette valeur doit correspondre exactement au champ Nom de l'expérience moteur dans la configuration de RIP. La page frontale du moteur utilise la même logique de génération d'interface utilisateur basée sur les métadonnées illustrée dans Figure 5; seul l'identifiant de l'expérience est modifié pour correspondre à l'entrée Motor dans la configuration de RIP.
   4. Vérifiez que la page contient la logique de lecture des métadonnées RIP, la logique de génération des contrôles HTML, la fonction d'écriture RIP et la fonction de mise à jour de la sortie.
      REMARQUE : La page ne doit pas encoder manuellement les noms des variables moteur, leurs plages ou leurs pas. Ces propriétés sont obtenues à partir des métadonnées renvoyées par le serveur RIP, conformément au mécanisme décrit précédemment de génération de HTML à partir des métadonnées basé sur RIP.¹¹.
   5. Enregistrer Motor_Automatic_UI.xhtml.
      ​REMARQUE : Pour utiliser la même logique de génération frontale avec un autre VI LabVIEW, définissez un nouvel identifiant d'expérience dans le fichier XHTML et enregistrez le nom de l'expérience correspondant ainsi que le chemin du VI dans la configuration de RIP. Les contrôles web et les affichages de sortie sont générés selon les métadonnées renvoyées par l'expérience sélectionnée.
4. Configurer le chemin d'accès Caddy pour l'expérience sur le moteur.
   1. Ouvrez le fichier Caddyfile avec un éditeur de texte.
   2. Définir le répertoire racine frontal sur le répertoire Client contenant Motor_Automatic_UI.xhtml.
   3. Sélectionnez un port local inutilisé pour Caddy afin de permettre l'accès via navigateur à la page web et aux routes RIP. Dans ce protocole, le port 8090 est utilisé comme exemple de port d'accès proxy.
      REMARQUE : Le port 8090 n'est pas requis par RIP ou Caddy. Si le port 8090 est occupé, remplacez-le par un autre port local inutilisé et utilisez ce même port dans l'adresse du navigateur.
   4. Ajouter une route qui réécrit /motor vers Motor_Automatic_UI.xhtml.
   5. Identifier le port du service Web RIP configuré dans LabVIEW. Dans ce protocole, l'adresse http://localhost:8001 est utilisée comme adresse du service Web RIP.
      REMARQUE : Le port 8001 est le port backend du service Web LabVIEW/RIP utilisé dans l'environnement de test. Il peut être modifié dans la configuration du service Web LabVIEW/RIP. Si un port différent est utilisé, remplacez http://localhost:8001 dans le fichier Caddyfile par l'adresse correspondante du service Web RIP.
   6. Ajouter une règle de proxy inverse qui envoie les requêtes /RIP/SSE* vers l'adresse du service Web RIP, par exemple http://localhost:8001.
   7. Ajouter une règle de proxy inverse qui envoie les requêtes /RIP* à l'adresse du service Web RIP, par exemple http://localhost:8001. La configuration du fichier Caddy est illustrée à la Figure 6.
   8. Ouvrez l'invite de commandes sous Windows. Accédez au répertoire local de téléchargement ou d'installation de Caddy en saisissant la commande suivante :
      cd /d D:\caddy
      REMARQUE : Dans ce protocole, D:\caddy correspond au chemin local de téléchargement ou d'installation de Caddy utilisé dans l'environnement de test. Si Caddy est stocké dans un autre répertoire, remplacer D:\caddy par le chemin local correspondant.
   9. Lancez Caddy avec le fichier Caddy spécifié en entrant la commande suivante :
      caddy.exe run --config Caddyfile
   10. Vérifiez que Caddy démarre sans signaler d'erreur de configuration. Ouvrez http://localhost:8090/motor dans un navigateur Web et vérifiez que l'interface utilisateur Web du moteur est générée, comme illustré dans Figure 12.
       ​REMARQUE : Si la page web du moteur se charge mais que les valeurs de sortie ne se mettent pas à jour, vérifiez que le service web RIP est en cours d'exécution, que le VI du moteur est en cours d'exécution, que le port du service web RIP dans LabVIEW correspond à l'adresse du proxy inverse dans le Caddyfile, et que le chemin /RIP/SSE* est correctement transféré par proxy.
5. Vérifier les résultats de fonctionnement de l'expérience sur le moteur.
   1. Vérifiez que la page frontale génère automatiquement le Consigne, Kc, Ti, Td, Perturbation, et Réinitialiser contrôles d'entrée de contrôle.
   2. Vérifiez que la page frontale s'affiche correctement Position, Tension, Temps, et Vitesse angulaire mesurée variables de sortie
   3. Ajuster Consigne et observer si la position répond au changement de la position souhaitée.
   4. Ajuster Kc, Ti, et Td et observer si Tension, Position, et Vitesse angulaire mesurée changement
   5. Ajuster la perturbation et observer si la position, la tension de commande ou la vitesse angulaire mesurée est affecté par le perturbation entrée.
   6. Cliquez sur le contrôle Réinitialiser et observez si Position, Tension, Vitesse angulaire mesurée, et les états internes associés reviennent à leurs états initiaux selon la logique de réinitialisation.

Résultats

Après avoir terminé le flux de travail décrit ci-dessus, l'expérience sur le ventilateur et celle sur la commande de position PID d'un moteur à courant continu peuvent être accessibles via l'interface Web générée automatiquement. Un résultat concluant se manifeste par trois observations. Premièrement, la page Web génère automatiquement des commandes d'entrée et des champs d'affichage de sortie conformément aux métadonnées des variables renvoyées par le serveur RIP. Deuxièmement, lorsque l'utilisateur modifie une variable d'entrée sur la page Web, la valeur modifiée est écrite dans le VI d'arrière-plan LabVIEW via l'interface RIP. Troisièmement, les variables de sortie calculées par le VI d'arrière-plan sont renvoyées via RIP et actualisées en temps réel sur la page Web. Pour l'expérience sur le ventilateur, après avoir saisi http://localhost:8090/fan dans un navigateur, la page génère automatiquement des commandes d'entrée et des champs de sortie à partir des métadonnées RIP, comme illustré dans la Figure 7. Le côté entrée comprend Enable, PWM, Load, Tau, KMaxRPM et Disturbance, tandis que le côté sortie affiche SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA et PowerW. Pendant le fonctionnement normal, TimeS augmente continuellement, indiquant que le VI d'arrière-plan fengshan.vi s'exécute. Lorsque PWM augmente, SpeedRPM et SteadyRPM augmentent en conséquence. Lorsque Load augmente, la vitesse du ventilateur diminue, car la charge réduit la vitesse de fonctionnement en régime permanent. Lorsque Disturbance est ajustée, des changements correspondants peuvent être observés dans SpeedRPM, CurrentA et PowerW. Ces observations confirment que les entrées côté Web sont correctement transmises à l'arrière-plan LabVIEW et que les sorties calculées sont renvoyées à l'interface frontale via RIP.

Pour l'expérience de commande de position PID d'un moteur à courant continu, après avoir saisi http://localhost:8090/motor dans un navigateur, la page génère automatiquement les champs de commande et de sortie correspondants à partir des métadonnées RIP, comme illustré dans Figure 12. Les variables d'entrée comprennent Consigne, Kc, Ti, Td, Perturbation, et Réinitialiser contrôle, et les variables de sortie comprennent Position, Tension, Temps et Vélocité angulaire mesuréey. Lorsque Consigne est modifié, Position répond à la nouvelle valeur cible. Lorsque les paramètres PID Kc, Ti, et Td sont ajustés, la réponse en sortie, contrôle tension, et vitesse angulaire mesurée changer en conséquence, indiquant que les valeurs de paramètres saisies sur la page Web sont correctement écrites dans le modèle backend LabVIEW et participent au calcul de contrôle. Lorsque la commande de réinitialisation est activée, les variables du modèle reviennent à leur état initial conformément à la logique de réinitialisation.

Les états de défaillance et de communication côté navigateur sont illustrés dans Figure 13, Figure 14, Figure 15. Figure 13 présente un cas d'accès au navigateur ayant échoué, dans lequel Caddy n'est pas en cours d'exécution. Le navigateur tente d'accéder à http://localhost:8090/motor, mais affiche un message ERR_CONNECTION_REFUSED, indiquant que le service proxy local est indisponible ou n'écoute pas sur le port d'accès sélectionné. Figure 14 montre un échec de communication RIP POST après le chargement de la page. Dans ce cas, la console du navigateur signale une erreur 502 Bad Gateway pour la requête RIP POST, ce qui indique que le client a atteint l'adresse du proxy, mais que la requête ne peut pas être correctement transférée ou traitée par le service Web RIP en arrière-plan. En revanche, Figure 15 illustre un état de communication normal côté navigateur. Les outils de développement du navigateur montrent un chargement de page réussi, des requêtes RIP POST réussies et une requête SSE active avec expId=fan, indiquant que l'interface Web communique avec le service Web RIP via le proxy Caddy et reçoit des mises à jour en temps réel par le biais du canal SSE.

Ensemble, les résultats positifs concernant le ventilateur et le moteur ainsi que les résultats des diagnostics côté navigateur démontrent que le même flux de travail de génération automatique d'interface utilisateur basé sur les métadonnées peut être reproduit pour deux expériences LabVIEW différentes. Ces résultats fournissent également des critères observables permettant de distinguer une communication réussie des échecs représentatifs de déploiement, tandis que les procédures de dépannage correspondantes sont discutées dans la section Discussion.

Figure 1 : Structure générale du système expérimental. Le système comprend le VI backend LabVIEW, le serveur RIP, le proxy Caddy et l'interface Web générée automatiquement. Le VI LabVIEW fournit les variables du modèle, le serveur RIP lit les métadonnées du VI et les valeurs des variables, Caddy unifie le chemin d'accès et résout les problèmes d'accès inter-origines, et l'interface Web génère automatiquement les contrôles. Le nom et le logo de Caddy sont indiqués uniquement pour identifier le composant serveur/proxy Web Caddy utilisé dans le flux de travail. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 2 : Panneau avant du VI du ventilateur. Le panneau avant comprend des commandes d'entrée pour Enable, PWM, Load, Tau, KMaxRPM et Disturbance, ainsi que des indicateurs de sortie pour SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA et PowerW. Cette capture d'écran a été réalisée à partir du panneau avant de fengshan.vi dans LabVIEW 2026, dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 3 : Schéma fonctionnel du VI du ventilateur. Le modèle du ventilateur est implémenté à l'aide d'une boucle While, de registres à décalage, d'une logique Enable, d'un nœud de formule et d'indicateurs de sortie. Cette capture d'écran a été réalisée à partir du schéma fonctionnel du fichier fengshan.vi dans LabVIEW 2026, dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 4 : Page de configuration de fan.vi. L'expérience sur le ventilateur est enregistrée dans RIP Configuration avec le nom de l'expérience « fan », le chemin réel du VI, les informations de mots-clés, la description et la fréquence d'échantillonnage. Cette capture d'écran a été réalisée à partir de l'interface RIP Configuration utilisée avec LabVIEW 2026 et RIP WebService dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 5 : Paramètres de l'identifiant de l'expérience et logique de génération de l'interface utilisateur basée sur les métadonnées dans les fichiers frontaux XHTML. Les captures d'écran du code XHTML ont été réalisées à partir des fichiers Fan_Automatic_UI.xhtml et Motor_Automatic_UI.xhtml ouverts dans Visual Studio Code. Les pages ventilateur et moteur utilisent la même logique de lecture des métadonnées et de génération des contrôles ; seul l'identifiant de l'expérience est modifié pour correspondre au champ Nom correspondant dans la configuration RIP. Les captures d'écran du code XHTML ont été réalisées à partir des fichiers Fan_Automatic_UI.xhtml et Motor_Automatic_UI.xhtml ouverts dans Visual Studio Code dans l'environnement de développement local des auteurs. Les fichiers de code ont été préparés par les auteurs pour ce protocole. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 6 : Configuration du Caddyfile. Le Caddyfile définit le port d'accès proxy local, indique le répertoire racine du front-end, réécrit les routes /fan et /motor vers les fichiers XHTML correspondants, et achemine en proxy inverse les requêtes /RIP/SSE* et /RIP* vers le port du WebService LabVIEW/RIP. La capture d'écran de la configuration du Caddyfile a été réalisée à partir du fichier ouvert dans Visual Studio Code dans l'environnement de développement local des auteurs. Le Caddyfile a été préparé par les auteurs afin de configurer Caddy en tant que serveur Web local et proxy inverse. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 7 : Page Web UI de fan.vi. Cette capture d'écran de l'interface Web a été réalisée à partir de la page Web locale du ventilateur déployée par les auteurs, à l'aide de Mozilla Firefox. La page frontale génère automatiquement des commandes d'entrée et des affichages de sortie en fonction des métadonnées des variables renvoyées par le serveur RIP. Les commandes et champs de sortie affichés ont été générés à partir des métadonnées RIP présentes dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 8 : Panneau avant du VI du moteur. Le panneau avant comprend des commandes pour le Consigne, Kc, Ti, Td, Perturbation et la commande de Réinitialisation, ainsi que des indicateurs pour la Position, la Tension, le Temps et la Vitesse angulaire mesurée. Cette capture d'écran a été réalisée à partir du panneau avant de Motor.vi dans LabVIEW 2026, dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 9: Schéma du modèle de contrôle de position PID pour moteur à courant continu. Le schéma illustre le trajet du signal, depuis l'erreur de consigne, le contrôle PID, la limitation de tension, la superposition de perturbation, la dynamique électrique, la dynamique mécanique et la mise à jour de la position jusqu'à la rétroaction. Veuillez cliquer ici pour visualiser une version agrandie de cette figure.

Figure 10 : Schéma fonctionnel du VI du moteur. Le modèle du moteur est implémenté à l’aide d’une boucle While, de registres à décalage, d’un nœud de formule, d’une logique de temporisation et d’indicateurs de sortie. Cette capture d’écran a été réalisée à partir du schéma fonctionnel de Motor.vi dans LabVIEW 2026, dans l’environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n’est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 11 : Page de configuration de Motor.vi. L'expérience sur le moteur est enregistrée dans RIP Configuration avec le nom de l'expérience « Motor », le chemin réel du VI, les informations de mots-clés, la description et la fréquence d'échantillonnage. Cette capture d'écran a été réalisée à partir de l'interface RIP Configuration utilisée avec LabVIEW 2026 et RIP WebService dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 12 : Page Web UI de Motor.vi. La page frontale génère automatiquement des commandes d'entrée et des affichages de sortie pour l'expérience de contrôle de position PID du moteur à courant continu. Cette capture d'écran de l'interface Web a été réalisée à partir de la page Web du moteur déployée localement par les auteurs, à l'aide de Mozilla Firefox. Les commandes et champs de sortie affichés ont été générés à partir des métadonnées RIP dans l'environnement expérimental local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 13 : Échec d'accès au navigateur lorsque Caddy n'est pas en cours d'exécution. Lorsque Caddy n'est pas démarré, l'adresse locale proxy http://localhost:8090/motor est inaccessible et le navigateur affiche un message d'erreur ERR_CONNECTION_REFUSED. Ce symptôme d'échec indique que le service proxy local Caddy est indisponible ou n'écoute pas sur le port d'accès sélectionné. Cette capture d'écran du navigateur a été réalisée à l'aide de Mozilla Firefox dans l'environnement de test local des auteurs et illustre l'état d'accès échoué lorsque le proxy local Caddy n'était pas en cours d'exécution. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 14 : Échec de communication RIP POST après le chargement de la page. La console du navigateur affiche une erreur 502 Bad Gateway pour la requête RIP POST. Ce résultat indique que la page web a atteint l'adresse du proxy Caddy, mais que la requête ne peut pas être correctement transférée ou traitée par le service web backend RIP. Cette capture d'écran de la console du navigateur a été réalisée à l'aide des outils de développement Mozilla Firefox dans l'environnement de déploiement local des auteurs, et montre un échec de communication RIP POST avec l'erreur 502 Bad Gateway. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 15 : État des communications côté navigateur en fonctionnement normal. Les outils de développement du navigateur montrent un chargement réussi de la page, des requêtes POST RIP et une requête SSE active avec expId=fan. Ces requêtes indiquent que l'interface Web frontale communique avec le service Web RIP via le proxy Caddy et reçoit des mises à jour en temps réel par le biais du canal SSE. Cette capture d'écran des outils de développement du navigateur a été réalisée à l'aide de Mozilla Firefox dans l'environnement de déploiement local des auteurs et illustre une communication POST RIP et SSE normale. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 16 : Observation représentative unique au niveau de la console du navigateur et des ressources au niveau du processus pour l'expérience du ventilateur. La capture d'écran a été réalisée lors d'un test local de l'expérience du ventilateur. La console affiche le temps de requête/réponse des métadonnées, le nombre de variables de métadonnées, le temps de génération de l'interface utilisateur basée sur les métadonnées, le temps d'ouverture de la connexion SSE et les données SSE reçues. La vue du gestionnaire des tâches montre les valeurs de l'UC et de la mémoire au niveau du processus pour les processus du navigateur et de LabVIEW au moment de la capture. Ces valeurs correspondent à des observations descriptives issues de ce test individuel et ne constituent pas des mesures de performance répliquées ni une référence statistique. Cette capture d'écran a été effectuée à l'aide des outils de développement de Mozilla Firefox et du Gestionnaire des tâches de Windows dans l'environnement de test local des auteurs. Mozilla Firefox a été utilisé pour enregistrer la sortie de la console du navigateur, et le Gestionnaire des tâches de Windows a permis d'observer l'utilisation du processeur et de la mémoire par les processus du navigateur et de LabVIEW. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Figure 17 : Accès simultané à la même page Web basée sur RIP depuis un navigateur d'ordinateur de bureau et un navigateur mobile. La page de l'expérience du ventilateur est ouverte simultanément sur des appareils PC et mobiles, et les deux clients affichent les commandes et variables de sortie générées automatiquement. La page Web de bureau a été consultée à l'aide de Mozilla Firefox, et la page Web mobile a été consultée à l'aide d'un navigateur mobile dans le même environnement de réseau local. Les captures d'écran ont été réalisées dans l'environnement de test local des auteurs. Aucune donnée utilisateur tierce ni information confidentielle n'est incluse. Veuillez cliquer ici pour afficher une version agrandie de cette figure.

Nom de la variable	Type de données	Entrée/Sortie	Sens physique	Rôle dans le modèle			Plage/Réglage
Enable	Booléen	Entrée	Interrupteur de fonctionnement du ventilateur	Contrôle si le modèle reçoit l'entrée PWM. Lorsque True, u = PWM ; lorsque False, u = 0.			True / False
PWM	DBL	Entrée	Entrée de commande	Détermine l'intensité de commande de base du ventilateur et constitue l'entrée principale utilisée pour calculer la vitesse en régime permanent SteadyRPM.			0-1, pas de 0,01
Load	DBL	Entrée	Coefficient de charge	Décrit l'effet affaiblissant de la charge sur la vitesse en régime permanent. Lorsque Load augmente, la vitesse en régime permanent diminue.			0-1, pas de 0,01
Tau	DBL	Entrée	Constante de temps de réponse	Détermine la rapidité avec laquelle la vitesse du ventilateur atteint la vitesse en régime permanent à partir de l'état précédent.			0,1-5, pas de 0,1
KMaxRPM	DBL	Entrée	Vitesse maximale	Fixe la vitesse maximale autorisée par le modèle et est utilisée pour la limitation et la normalisation de la vitesse.			500-6000, pas de 100
Disturbance	DBL	Entrée	Entrée de perturbation	Représente l'effet d'une perturbation externe ou d'une fluctuation de charge sur la vitesse en régime permanent, le courant et la puissance.			0-1, pas de 0,1
SpeedRPM	DBL	Sortie	Vitesse réelle	Représente la vitesse de sortie actuelle du ventilateur et est mise à jour selon une dynamique inertielle du premier ordre.			Calculée par le modèle
SteadyRPM	DBL	Sortie	Vitesse en régime permanent	Représente la vitesse théorique en régime permanent sous les conditions d'entrée actuelles.			Calculée par le modèle
TimeS	DBL	Sortie	Durée de fonctionnement	Représente la durée continue de fonctionnement du modèle.			Calculée par le modèle
SpeedNorm	DBL	Sortie	Vitesse normalisée	Représente le rapport entre SpeedRPM et KMaxRPM.			0-1 ou calculée par le modèle
CurrentA	DBL	Sortie	Courant	Représente le courant estimé du modèle, qui varie en fonction de l'entrée de commande et de l'entrée de perturbation.			Calculé par le modèle
PowerW	DBL	Sortie	Puissance	Représente la puissance estimée du modèle, calculée à partir de la constante de tension et du courant.			Calculée par le modèle
Setpoint	DBL	Entrée	Position souhaitée	Fixe la position que le moteur doit atteindre et forme l'erreur e avec la position réelle Position.			-3 à 3, pas de 0,1
Kc	DBL	Entrée	Gain proportionnel	Ajuste l'intensité de la réponse du régulateur PID à l'erreur.			0-10, pas de 0,1
Ti	DBL	Entrée	Temps d'intégration	Ajuste l'action intégrale du régulateur PID et est utilisé pour réduire l'erreur en régime permanent.			0-10, pas de 0,1
Td	DBL	Entrée	Temps de dérivation	Ajuste l'action dérivée du régulateur PID et est utilisé pour limiter les variations trop rapides de l'erreur et améliorer la réponse dynamique.			0-5, pas de 0,1
Disturbance	DBL	Entrée	Entrée de perturbation	Représente une perturbation externe superposée à l'entrée du moteur, agissant sur le modèle du moteur conjointement avec la tension de commande.			0-10, pas de 0,1
Reset control	Booléen	Entrée	Commande de réinitialisation	Déclenche l'effacement de l'état du modèle afin que la position, la vitesse angulaire, le courant, l'erreur et le terme intégral reviennent à leurs états initiaux.			True / False
Position	DBL	Sortie	Position réelle	Représente la position angulaire actuelle du moteur et sert de variable de retour pour la commande PID.			Calculée par le modèle
Voltage	DBL	Sortie	Tension de commande	Représente la sortie du régulateur PID après limitation de tension et agit sur l'entrée du moteur.			Calculée par le modèle ; limitée à -24 à 24 V
Time	DBL	Sortie	Durée de fonctionnement	Représente la durée continue de fonctionnement du modèle du moteur.			Calculée par le modèle
Measured angular velocity	DBL	Sortie	Vitesse angulaire mesurée	Représente la vitesse angulaire actuelle du moteur et constitue la sortie d'état mécanique du moteur.			Calculée par le modèle

Tableau 1 : Variables d'entrée et de sortie utilisées dans les exemples de ventilateur et de moteur à courant continu. Ce tableau énumère chaque nom de variable, le type de données, le rôle entrée/sortie, la signification physique, la plage recommandée et la taille du pas.

Paramètre	Valeur	Signification physique	Rôle dans le modèle
R	1	Résistance de l'induit	Représente le terme de résistance dans le circuit de l'induit du moteur et détermine la chute de tension R × im dans l'équation du courant.
L	0,5	Inductance de l'induit	Représente l'inductance du circuit de l'induit et détermine la vitesse de variation du courant. Une valeur plus élevée de L produit une réponse en courant plus lente.
J	0,01	Moment d'inertie	Représente la résistance du rotor du moteur aux variations de l'accélération angulaire et détermine la rapidité avec laquelle la vitesse angulaire évolue.
b	0,1	Coefficient de frottement visqueux	Représente l'amortissement mécanique et décrit le couple d'amortissement qui s'oppose à l'augmentation de la vitesse angulaire en rotation.
Kt	0,01	Constante de couple	Représente le coefficient de proportionnalité qui convertit le courant de l'induit en couple électromagnétique.
Ke	0,01	Constante de force électromotrice induite	Représente le coefficient de proportionnalité selon lequel la vitesse angulaire génère la force électromotrice induite et décrit l'effet de rétroaction de la vitesse sur le courant.
Vmax	24	Tension de commande maximale	Représente la limite de la tension de sortie du contrôleur et maintient la tension dans la plage allant de -24 V à 24 V.
dt	0,001	Pas de simulation discret	Représente l'intervalle de temps pour chaque mise à jour d'état par boucle et est utilisé pour mettre à jour le courant, la vitesse angulaire, la position et le temps d'exécution.

Tableau 2 : Paramètres internes utilisés dans le modèle de commande de position PID du moteur à courant continu. Ce tableau énumère les paramètres électriques et mécaniques, leurs symboles, leurs valeurs numériques, leurs unités et leurs rôles dans le modèle.

Fichiers de codage supplémentaires : Fichiers complets de code source et de configuration permettant de reproduire les exemples du ventilateur et du moteur à courant continu. Les fichiers de codage supplémentaires comprennent le code du nœud formule LabVIEW, la configuration du serveur mandataire inverse Caddy, les fichiers XHTML d'interface frontale et les fichiers sources VI de LabVIEW utilisés dans ce protocole. Le document Code in LabVIEW Formula Node.docx contient le code du nœud formule pour les modèles de commande de position PID du ventilateur et du moteur à courant continu. Le fichier Caddyfile.txt contient la configuration locale du serveur Web et du serveur mandataire inverse. Les fichiers Fan_Automatic_UI.xhtml et Motor_Automatic_UI.xhtml contiennent la logique d'interface Web frontale basée sur les métadonnées. Les fichiers fengshan.vi et Motor.vi sont les fichiers VI LabVIEW de back-end pour les expériences avec le ventilateur et le moteur.Veuillez cliquer ici pour télécharger ce fichier.

Discussion

Une étape cruciale de ce protocole est la construction normalisée et l'enregistrement du VI backend LabVIEW. Les commandes et indicateurs du panneau avant doivent utiliser des noms de variables clairs et uniques, et leurs types de données doivent correspondre aux variables attendues par le calcul du modèle et par le processus de lecture/écriture du RIP. Dans les deux exemples utilisés dans ce protocole, des variables numériques scalaires sont définies comme des commandes ou indicateurs DBL, et les variables booléennes sont définies comme des commandes booléennes. Le diagramme bloc doit également assurer une mise à jour continue de l'état grâce à la boucle While, aux registres à décalage et au nœud de formule, afin que des variables telles que la vitesse du ventilateur, la position du moteur, la vitesse angulaire du moteur, la tension et le temps puissent être mises à jour pendant l'exécution. Une fois le VI construit, le nom de l'expérience dans la configuration du RIP doit correspondre exactement à l'identifiant d'expérience utilisé dans le fichier XHTML correspondant, et le chemin du VI doit pointer vers le fichier VI réellement enregistré. Ces paramètres sont importants car l'interface Web frontale ne code pas en dur les variables de chaque expérience. Elle dépend plutôt des métadonnées renvoyées par le serveur RIP pour identifier les variables accessibles en écriture, les variables accessibles en lecture, les types de données et les propriétés numériques^10,11.

Les principaux problèmes de dépannage sont liés à la cohérence entre l'identifiant d'expérience XHTML, la configuration de RIP, le service Web RIP et les paramètres du proxy Caddy. Si l'identifiant d'expérience dans le fichier XHTML ne correspond pas au nom de l'expérience dans la configuration de RIP, la page Web ne peut pas demander les métadonnées correctes et ne peut donc pas générer les contrôles et champs de sortie attendus. Si le chemin VI est incorrect ou si le service Web RIP n'est pas démarré, la page Web peut s'ouvrir mais ne peut pas communiquer avec le module LabVIEW. Si Caddy n'est pas en cours d'exécution, le navigateur ne peut pas accéder à l'adresse proxy locale sélectionnée et peut afficher un message d'erreur ERR_CONNECTION_REFUSED, comme illustré dans la Figure 13. Si Caddy est en cours d'exécution mais que la cible du proxy inverse ne correspond pas au port du service Web RIP, la page peut se charger tandis que les requêtes POST de RIP échouent avec une erreur 502 Bad Gateway, comme illustré dans la Figure 14. Si la route /RIP/SSE* ne fonctionne pas correctement, la page peut s'ouvrir et afficher les contrôles, mais les valeurs de sortie ne se mettent pas à jour en temps réel. En fonctionnement normal, les outils de développement du navigateur doivent indiquer un chargement réussi de la page, des requêtes POST de RIP et une requête SSE active avec l'identifiant d'expérience correct, comme illustré dans la Figure 15. Par conséquent, le dépannage doit commencer par vérifier l'identifiant d'expérience, le chemin VI, l'état du service Web RIP, l'état d'exécution de Caddy, les ports du proxy et la route SSE. Si la communication présente toujours un comportement anormal, redémarrer à la fois le service Web RIP et Caddy, effacer le cache du navigateur ou répéter le test dans un autre navigateur peut aider à distinguer un comportement propre au navigateur des problèmes de configuration de RIP ou de Caddy.

Le protocole actuel est reproductible dans les deux exemples car le même flux de travail de création, d'enregistrement, de déploiement et de vérification est appliqué à la fois à un modèle de régulation de vitesse d'un ventilateur et à un modèle de commande de position PID pour un moteur à courant continu. Afin de réduire la dépendance vis-à-vis de boîtes à outils spécialisées, les VIs de l'arrière-plan sont reconstruits à l'aide de structures LabVIEW de base, notamment des commandes et indicateurs du panneau avant, des boucles While, des registres à décalage, des nœuds de formule, ainsi que des variables numériques scalaires standard et des variables booléennes. Toutefois, la reproductibilité entre différentes versions de LabVIEW, installations Windows et environnements réseau locaux dépend toujours de paramètres de configuration tels que les chemins d'accès aux fichiers, les autorisations d'accès, les ports locaux, les commandes de démarrage des services et le comportement du navigateur. Ce flux de travail peut également être étendu à des expériences à distance liées au matériel, mais la méthode ne doit pas être interprétée comme une reconnaissance directe du matériel côté Web. L'interface Web frontale identifie les commandes et indicateurs du panneau avant LabVIEW grâce aux métadonnées RIP. Par conséquent, les capteurs, actionneurs, instruments ou dispositifs de régulation de processus doivent d'abord être connectés et traités dans le VI de l'arrière-plan LabVIEW via des pilotes matériels appropriés, des modules d'acquisition de données, des modules de commande d'instruments ou d'autres mécanismes d'adaptation matérielle. Une fois que les mesures matérielles et les commandes de contrôle sont mappées sur les indicateurs et commandes du panneau avant, l'interface Web frontale basée sur RIP peut reconnaître ces variables de la même manière qu'elle reconnaît les variables de simulation utilisées dans ce protocole. Des études antérieures sur des laboratoires à distance basés sur LabVIEW ont montré que LabVIEW peut être utilisé comme environnement d'arrière-plan pour des expériences de génie de la commande à distance, des expériences robotiques, des dispositifs de régulation de processus, l'acquisition de données de capteurs et l'interaction avec des dispositifs physiques^{9,12,17,18,19,20}.

Figure 16 présente un exemple représentatif unique d'implémentation enregistré lors d'une expérience avec un ventilateur local. Le code frontal a été instrumenté pour enregistrer le temps de requête/réponse des métadonnées, le nombre de variables de métadonnées, le temps de génération de l'interface utilisateur (IU) basée sur les métadonnées, le temps d'ouverture de la connexion SSE et les données SSE reçues. Dans cet exemple, la console du navigateur a indiqué un temps de requête/réponse des métadonnées de 68,00 ms, identifié 7 variables modifiables et 7 variables lisibles dans les métadonnées RIP, généré les éléments d'IU correspondants en 2,00 ms et ouvert la connexion SSE en 16,00 ms. Les entrées répétées de données SSE ont montré que des variables de sortie telles que SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA et PowerW étaient continuellement reçues depuis le module LabVIEW en arrière-plan. La vue du gestionnaire des tâches dans le même état de test local a montré environ 1,5 % d'utilisation du processeur et 391,7 Mo de mémoire pour le processus Firefox, tandis que le processus LabVIEW affichait 0 % d'utilisation du processeur et 9,2 Mo de mémoire au moment de l'enregistrement. Ces observations fournissent des preuves élémentaires que la récupération des métadonnées, la génération d'IU basée sur les métadonnées, la communication RIP/SSE et la surcharge processeur au niveau des processus peuvent être observées dans l'environnement de déploiement local. Toutefois, ces données visent à vérifier l'implémentation et non à constituer une évaluation complète des performances. Une évaluation systématique des performances dans différents navigateurs, avec des essais répétés, des charges plus importantes de variables, du matériel physique et plusieurs utilisateurs simultanés reste nécessaire dans les travaux futurs.

Cette méthode présente également des limites, notamment lorsqu'elle est étendue à des structures de données complexes, à des expériences matérielles ou à un fonctionnement multiutilisateur. Le flux de travail actuel convient surtout aux variables d'entrée/sortie numériques scalaires et booléennes. Il ne fournit pas automatiquement un support complet pour les tableaux complexes, les regroupements, les structures de données imbriquées, les relations entre graphiques ou les visualisations spécifiques à un domaine. Ces cas peuvent nécessiter des règles supplémentaires de mappage des métadonnées ou des composants d'interface écrites manuellement. L'interface utilisateur générée automatiquement peut créer des commandes et affichages de base à partir des métadonnées des variables, mais elle ne peut pas déduire complètement les relations physiques entre les variables, choisir la visualisation la plus appropriée ou concevoir des interactions de sécurité spécifiques à l'expérience. Lorsque le flux de travail est étendu à des équipements réels, des considérations supplémentaires s'imposent, notamment les pilotes matériels, l'étalonnage des dispositifs, les contraintes d'échantillonnage, les limites des actionneurs, la logique d'arrêt d'urgence, l'authentification et les mécanismes de contrôle d'écriture multiutilisateur. Le déploiement actuel peut également être accessible depuis plusieurs appareils clients via des navigateurs Web standards dans le même environnement de réseau local. Comme illustré dans Figure 17, la même page d'expérience du ventilateur a été ouverte simultanément sur un navigateur d'ordinateur de bureau et sur un navigateur mobile, et les deux clients affichaient les commandes générées automatiquement ainsi que les variables de sortie correspondantes. Cette observation indique une capacité de base d'accès simultané pour plusieurs clients afin de consulter et d'interagir avec la même page d'expérience. Toutefois, cela ne doit pas être interprété comme un cadre complet de contrôle multiutilisateur, car l'implémentation actuelle ne comprend pas d'authentification dédiée des utilisateurs, de verrouillage de contrôle, d'arbitrage d'écriture concurrente, de files d'attente d'écriture ou de mécanismes de résolution de conflits. Ces limitations sont conformes aux études antérieures sur les laboratoires distants, dans lesquelles les laboratoires distants complexes ou collaboratifs nécessitent généralement une conception d'interface spécifique à l'expérience, des mécanismes de synchronisation, des contraintes de sécurité et une logique de gestion des utilisateurs^{13,14,15,16,17}.

La valeur méthodologique de ce protocole ne réside pas dans l'introduction d'une nouvelle architecture RIP ou dans l'extension des types de données pris en charge par RIP. Au lieu de cela, sa valeur tient à la fourniture d'un parcours complet et reproductible pour mettre en œuvre un mécanisme établi de génération automatique d'interfaces utilisateur basé sur RIP sur différents systèmes LabVIEW. Par rapport à l'écriture d'une interface Web personnalisée pour chaque expérience, ce flux de travail réduit la mise en œuvre répétée de la disposition de base des contrôles, du couplage des variables et de la logique de communication en lecture/écriture lorsque les variables exposées par le VI backend sont compatibles^8,9,10,11. Ce protocole est donc utile pour l'enseignement de l'ingénierie, le développement de laboratoires à distance et le déploiement rapide d'expériences de simulation ou pédagogiques à faible risque nécessitant un ajustement des paramètres via navigateur et une surveillance en temps réel de l'état du système. Les travaux futurs devraient étendre ce flux de travail à des structures de données plus complexes, à des dispositifs expérimentaux physiques, à un contrôle d'accès multiutilisateurs formel et à une évaluation quantitative des performances, incluant le temps de génération de l'interface, la latence de communication, la stabilité de la synchronisation, la charge du serveur, la surcharge processeur et l'ergonomie du front-end.

Matériaux

Liste des matériaux utilisés dans cet article

Nom	Entreprise	Numéro de catalogue	Commentaires
Serveur proxy Caddy	Caddy	N/A	Proxy inverse utilisé pour servir l'interface Web et transférer les requêtes /RIP au service Web RIP
Fichier Caddy	Préparé par les auteurs	N/A	Définit les routes de fichiers statiques et les routes de proxy inverse pour la communication RIP
Fan_Automatic_UI.xhtml	Préparé par les auteurs	N/A	Interface Web frontale basée sur les métadonnées pour l'expérience du ventilateur
LabVIEW	National Instruments	2026	Logiciel utilisé pour créer et exécuter fengshan.vi et Motor.vi
Système d'exploitation Microsoft Windows	Microsoft	Win11	Système d'exploitation utilisé pour exécuter LabVIEW, le service Web RIP, Caddy et le navigateur.
Motor_Automatic_UI.xhtml	Préparé par les auteurs	N/A	Interface Web frontale basée sur les métadonnées pour l'expérience du moteur
Navigateur Mozilla Firefox pour ordinateur de bureau	Mozilla	2026	Navigateur pour ordinateur de bureau utilisé pour accéder à l'interface Web, aux outils de développement, aux observations temporelles et des ressources, ainsi qu'aux captures d'écran du réseau et de la console.
Service Web RIP	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Reçoit les requêtes POST RIP et fournit la couche de communication du service Web utilisée par l'interface frontale du navigateur.
Gestionnaire des tâches Windows	Microsoft	Intégré à Windows	Utilisé pour enregistrer les observations au niveau du processus concernant l'UC et la mémoire pour les processus du navigateur et de LabVIEW.