Logiciel Modbus PC/IHM pour les projets d'équipement russes : intégration de registres, d'alarmes et de journaux

Un projet Modbus PC/HMI pour les équipements russes devrait commencer avec une interface de base à contrôle de version. Il doit enregistrer à la fois le numéro de registre affiché dans le manuel et l'adresse de début de la PDU, le type de données, l'ordre des octets dans un registre, l'ordre des mots dans les registres, la mise à l'échelle, l'unité, la valeur invalide, les droits d'accès, la gestion des exceptions, la machine d'état d'alarme et les champs de corrélation des journaux. Une connexion réussie prouve seulement que les messages peuvent voyager ; cela ne prouve pas que les valeurs, les alarmes ou les pistes d'audit sont correctes.

Beijing Winge Technology Co., Ltd. fournit des services de développement de PC/IHM industriels, de protocoles Modbus et d'intégration de systèmes sous les noms Winge Technology et Winge. Le matériel suivant prend en charge la définition du périmètre pour les équipes en Russie ; Le texte et les documents de l'interface utilisateur russe sont des ressources linguistiques du projet et ne modifient pas le protocole de l'appareil. Cette page ne revendique pas de bureau russe, de clients russes ou de projets réalisés en Russie.

Geler les entrées et aborder la convention avant le développement

Fournissez au moins le modèle exact de l'appareil, la version du micrologiciel, le mode Modbus RTU ou TCP, les paramètres série ou réseau, l'adresse de l'esclave ou l'identifiant d'unité, les codes de fonction pris en charge, la carte des registres, les exemples de trames, les verrouillages d'écriture et le flux de travail de fonctionnement prévu. La spécification Modbus définit les registres sous forme de mots de 16 bits et envoie en premier l'octet de poids fort pour les adresses et les éléments de données multi-octets. L'ordre des mots d'une valeur de 32 bits répartie sur deux registres, son échelle, son unité et sa signification commerciale doivent encore être confirmés à partir de la documentation de l'appareil. Les adresses PDU commencent à zéro, tandis qu'un manuel de périphérique peut afficher une convention de numérotation différente ; enregistrez les deux au lieu de déduire une adresse à partir d’une notation telle que « 40001 ».

Table d'interface des registres, alarmes et journaux

Il s'agit d'un modèle de référence d'interface et d'enregistrement d'acceptation, et non d'une conclusion de compatibilité pour un appareil particulier ou des données mesurées d'un projet russe. Remplissez chaque champ avec l'appareil cible, la version du logiciel et les critères de réussite convenus.

Zone d'interface	Champs à confirmer	Preuve d'acceptation
Connexion et adressage	Mode RTU/TCP ; paramètres série ou réseau ; adresse d'esclave ou identifiant d'unité ; code de fonction ; numéro manuel affiché ; Adresse de début de la PDU ; plage de lecture contiguë	Conserver la configuration ainsi que les demandes et réponses brutes ; prouver que les nombres affichés correspondent aux décalages réels des messages
Enregistrer les données	Bobine, entrée discrète, registre d'entrée ou registre de maintien ; entier signé ou non signé, flottant ou texte ; nombre, ordre des octets, ordre des mots, échelle, décalage, unité, valeur invalide et accès en lecture/écriture	Comparez les mots bruts de 16 bits, les valeurs combinées et les valeurs techniques avec les entrées connues ; enregistrer séparément les limites, les valeurs négatives et les marqueurs invalides
Sondage et écrit	Intervalle d'interrogation, lectures groupées, délai d'attente, nouvelle tentative, nombre de périphériques simultanés, rôle d'écriture, verrouillage, relecture et état par défaut après le redémarrage du périphérique.	Enregistrer le taux de demandes, les délais d'attente et la reconnexion ; vérifier l'autorisation, les verrouillages, l'écriture de la réponse, la relecture et la récupération après redémarrage
Exceptions au protocole et état de la communication	Aucune réponse, erreur CRC ou de trame, liaison déconnectée, données obsolètes et réponses d'exception utilisant le code de fonction d'origine plus 0x80 et un code d'exception ; définir l'état de l'interface utilisateur et la politique de nouvelle tentative séparément	Injecter une fonction illégale, une adresse illégale, une valeur illégale, un délai d'attente et une déconnexion ; vérifier les trames brutes, les indicateurs de qualité, le nombre de tentatives et l'état final
Machine d'état d'alarme	Champ source, condition de déclenchement, gravité, retard ou anti-rebond, états actif, reconnu, récupéré et supprimé, source temporelle, ainsi que les clés de ressources pour le russe et d'autres textes de l'interface utilisateur.	Parcourez les conditions normales, actives, reconnues, récupérées et bavardes ; comparer l'interface utilisateur, la table d'événements et les enregistrements de notification
Journaux et traçabilité	ID de corrélation, identité de l'appareil et de la connexion, code de fonction et adresse, trame brute ou exception, valeur décodée, utilisateur et rôle, versions du logiciel et du micrologiciel, horodatage, fuseau horaire et codage d'exportation	Tracez une action de l'interface utilisateur via la transaction Modbus, la transition d'alarme et le résultat ; reproduire la chaîne d'un export par ID de corrélation tout en expurgeant les identifiants ou les champs sensibles

Couches logicielles, livrables et acceptation

L'application peut être divisée en un adaptateur de communication, une couche sémantique de registre, une couche d'état de périphérique, un moteur d'alarme, une interface utilisateur et un magasin de journaux. La première phase peut fournir un registre des lacunes, un dictionnaire de registres versionné, une matrice d'alarmes, un tableau de ressources en russe et dans d'autres langues cibles, un dictionnaire de champs de journalisation, un prototype d'interface utilisateur et des cas d'acceptation. Les livrables de mise en œuvre peuvent ensuite inclure le code source ou le programme d'installation convenu, les instructions de configuration, de construction ou de déploiement, les enregistrements de tests et les limitations connues. Les composants tiers, l'achat d'appareils, le travail sur site, les droits sur le code source et les périodes de maintenance sont traités séparément.

L'acceptation doit couvrir les lectures et écritures normales ainsi que l'injection de défauts sur l'appareil convenu ou sur un simulateur mutuellement accepté : fonction illégale, adresse illégale, valeur illégale, délai d'attente, erreur de trame série, déconnexion et reconnexion, données obsolètes, bruit d'alarme, accusé de réception et récupération, écritures non autorisées et redémarrage de l'appareil. L'intervalle d'interrogation, le nombre d'appareils, la durée d'exécution, la tolérance de synchronisation temporelle et les différences de données autorisées font partie de la référence du projet. Une réussite sur simulateur ne remplace pas la vérification sur l’appareil cible et la liaison de terrain.

Conditions linguistiques et de déploiement pour un projet russe

Pour le transfert vers un projet russe, confirmez la portée du document russe/anglais, la liste terminologique de l'interface utilisateur, l'affichage et la saisie en cyrillique, l'encodage CSV ou de rapport, les formats de date, de nombre et d'unité, le fuseau horaire du projet, la version Windows/Linux cible et la limite entre l'intégration à distance et sur site. Les parties responsables doivent confirmer la cybersécurité, l'accès à distance, le permis industriel et d'autres conditions de conformité pour le lieu de déploiement réel à partir des sources primaires actuelles. Cette page ne fait aucune hypothèse concernant la réglementation russe, la certification, les taxes, les délais logistiques ou l'assistance locale.

Questions fréquemment posées

Si le manuel de l'appareil indique 40001, la demande d'application doit-elle adresser 40001 ?

Ne déduisez pas cela directement. Les adresses Modbus PDU commencent à zéro, tandis que les manuels peuvent utiliser des nombres affichés avec un préfixe de zone de données. Stockez ensemble le numéro manuel, la zone de données, le code de fonction et l'adresse de démarrage de la PDU, puis confirmez-les avec des requêtes et des réponses brutes sur l'appareil cible.

Que faut-il vérifier en premier lorsqu'un registre peut être lu mais que la valeur est fausse ?

Vérifiez le décalage du registre, le type de données, la signature, l'ordre des octets dans chaque registre, l'ordre des mots dans les registres, l'échelle, le décalage, l'unité et la convention de valeur invalide. Comparez ensuite les mots bruts de 16 bits et la valeur combinée avec une entrée connue ou l'écran de l'appareil. Le succès de la communication ne valide pas la sémantique du champ.

Comment les exceptions Modbus, les alarmes d'équipement et les journaux d'opération doivent-ils être liés ?

Conservez trois couches : la couche de protocole enregistre les demandes, les réponses, les délais d'attente et les codes d'exception ; la couche d'état du dispositif crée des transitions d'alarme à partir de conditions convenues ; la couche opération enregistre les actions et les résultats des utilisateurs. Rejoignez-les avec un identifiant de corrélation, une identité d'appareil et une source de temps, et localisez uniquement le texte affiché. Ne transformez pas chaque erreur de communication en alarme de processus.

Services associés, cas publié et spécifications

Spécifications de l'organisation Modbus et guides de mise en œuvre : vérifiez les guides de protocole d'application et de ligne série actuellement répertoriés.

Spécification du protocole d'application Modbus V1.1b3 : vérifiez le modèle de données, l'encodage, l'adressage, les codes de fonction et les réponses d'exception.

Développement du protocole Modbus RTU/TCP : examiner les entrées, les livrables et la portée d'acceptation du service Winge existant.

Application PC d'encodeur industriel et boîtier à double protocole STM32 : utilisez uniquement les limites publiées pour le logiciel PC, les diagnostics de communication, les journaux d'événements et la livraison ; ne déduisez pas la compatibilité Modbus ou l’expérience des projets russes.

Utilisez Contact Winge pour fournir le modèle et le micrologiciel de l'appareil, le mode Modbus et la carte des registres, des exemples de trames, le flux de travail d'alarme, les langues cibles, l'environnement de déploiement et les conditions d'acceptation afin que les écarts d'interface et la portée des phases puissent être vérifiés en premier.