Logiciel de protocole d’équipement pour les lignes au Vietnam : supervision, automate et reprise

L’intégration commence par une machine à états convenue : le logiciel de supervision demande une opération, le service de protocole associe requête et réponse, et l’automate programmable industriel (API, ou PLC) ou le contrôleur vérifie les conditions et rapporte le résultat réel. Distinguer envoyé, accepté, en cours, terminé, refusé et résultat inconnu. Une connexion rétablie ou un acquittement de communication ne suffit pas à prouver l’achèvement.

Beijing Winge Technology Co., Ltd., connue sous les noms Winge et Winge Technology, développe des connexions d’équipements, des logiciels industriels et des intégrations système. Pour les équipes au Vietnam, une revue d’interface et un prototype reproductible peuvent constituer le premier lot. Programmes, code source, interventions sur site et réception sont définis dans les documents du projet.

Données nécessaires avant intégration

Fournir modèles et versions des équipements, automates et micrologiciels, protocoles et autorisations, dictionnaire de registres ou messages, trames normales et anormales, étapes du procédé, droits, interverrouillages et procédures de réarmement. Préciser topologie réseau, cycles de scrutation, nombre d’appareils, systèmes d’exploitation, arrêts disponibles et matériel ou simulateurs.

Définir qui peut démarrer, arrêter et réarmer, quelle source fait autorité pour l’état, et si la réponse signifie réception, acceptation ou achèvement. Chaque commande nécessite préconditions, transitions, états finaux, traitement des délais et responsable. L’activation des boutons découle de ces conditions.

États des commandes et responsabilités

Matrice proposée pour la revue d’interface et les comptes rendus d’essais. Les champs sont des exemples à adapter au protocole cible, sans preuve de compatibilité ni de mesures sur une ligne vietnamienne.

Objet d’interface	Responsabilités et champs à convenir	Preuve d’acceptation et critères
Autorité de commande et d’état	La supervision demande ; le service journalise le transport ; l’automate ou l’équipement rapporte acceptation, exécution et état final. Convenir d’un seul émetteur en écriture, de la version d’état, des refus et transitions.	Enregistrer état initial, commande, transitions et retour physique. Un accusé de réception ne vaut pas achèvement ; l’interface ne doit pas effacer seule un défaut d’équipement.
Corrélation et doublons	Identité d’équipement, identifiant de session ou démarrage, command_id, séquence, paramètres et somme de contrôle ; persistance et conservation de la déduplication.	Les doublons et réponses tardives restent liés à la commande initiale. Un résultat d’ancienne session ne termine pas une nouvelle commande. Vérifier le nombre réel d’actions selon le contrat de l’équipement.
Délais et référence temporelle	Séparer délais de connexion, réponse, acceptation et exécution du procédé, avec unité, événement de départ, responsable du temporisateur et horloge. Définir le comportement après redémarrage.	Injecter retards, pertes de réponse et changements d’horloge ; vérifier chaque délai indépendamment. L’absence de résultat mène à l’état inconnu ou défaut convenu, sans supposer une non-exécution.
Répétition et reconnexion	Classer lectures d’état, consignes, déclenchements et réarmements. Évaluer l’effet d’une répétition ; convenir du maximum, de l’intervalle, d’une interrogation ou de l’intervention opérateur.	Exécuter puis perdre la réponse pour vérifier l’absence de renvoi aveugle. À la reconnexion, rapprocher état réel et commandes en attente avant de rejouer des commandes mémorisées.
Interverrouillages et droits	L’automate ou le système de commande évalué vérifie mode, conditions, retours d’actionneurs et droits ; la supervision affiche les refus. Les fonctions de sécurité exigent une revue distincte.	Tester conditions absentes, demande non autorisée et changement en cours d’opération. Vérifier refus ou réaction convenue ; désactiver un bouton ne constitue pas l’unique protection.
Réarmement et reprise	Séparer acquittement d’alarme, effacement du défaut, retour prêt et redémarrage. Définir opérateur, contrôles requis, tâches résiduelles et sens de la réponse de réarmement.	Redémarrer séparément automate, équipement et supervision ; rapprocher commandes en attente et état réel. Un réarmement réussi n’autorise pas le redémarrage : ses conditions propres doivent être remplies.

De la revue d’interface aux essais avec injection de défauts

Le premier lot peut livrer une liste des données d’entrée manquantes, un dictionnaire versionné des messages ou points, la table de transitions, la matrice de responsabilités, les champs de journal et les cas de défaut. La réalisation peut comprendre adaptateurs, logiciels ou services, configuration, sources ou paquets convenus, instructions de construction et déploiement, limites connues. Modifications d’automate, achats, licences, présence sur site et maintenance sont séparés.

Tester d’abord en simulation acceptée par les parties, puis sur les équipements et le réseau de commande cibles. Couvrir doublons, action exécutée avec réponse perdue, réponses tardives, paramètres modifiés, retrait d’interverrouillage, déconnexion et redémarrages indépendants. La simulation ne remplace pas la réception du matériel et du procédé sur site.

Conserver versions, état initial, point d’injection, requête et réponse, command_id, nombre réel d’actions, état final, reprise, opérateur et horodatage pour chaque essai. Fixer avant les essais délais admissibles, durée continue, nombre d’actions et conditions de reprise. Aucune performance non mesurée n’est annoncée ici.

Collaboration et déploiement au Vietnam

Convenir des interfaces et documents vietnamiens ou anglais, de la terminologie, de la saisie Unicode, de l’encodage des journaux, du fuseau, des formats et unités, de l’ingénieur contrôle sur site et des fenêtres d’accès distant. Autres langues, modalités sur site et coûts relèvent du projet.

Évaluer sécurité, accès distant et conformité selon l’équipement, l’usage et les responsabilités réels. Le pays ou le protocole ne prouve ni autorisation, certification, fiscalité ni assistance locale.

Questions fréquentes

Peut-on renvoyer un démarrage après expiration du délai ?

Le délai seul ne suffit pas : l’action peut être exécutée avec réponse perdue. Vérifier d’abord command_id et état réel. Répéter uniquement selon la politique convenue si l’interface garantit l’idempotence ou la déduplication concernée et si les conditions restent valides ; sinon prévoir une intervention contrôlée.

Qui gère interverrouillages et réarmement ?

L’automate ou contrôleur convenu gère conditions d’exécution et état. La supervision transmet les opérations autorisées, affiche et journalise. Réarmement et redémarrage sont distincts ; la sécurité ne doit pas dépendre uniquement des boutons ou d’une liaison ordinaire.

Comment démontrer qu’une reconnexion ne répète pas l’action ?

Couper après exécution mais avant réponse, reconnecter, puis tester chaque redémarrage séparément. Rapprocher commande, retour d’équipement, compteur et traces de reprise ; vérifier confirmation ou terminaison des commandes en attente. L’indicateur en ligne ne suffit pas.

Services et références

Logiciels industriels de supervision, chinois : communication, états, interface, reprise et livraison.

Codeur industriel et STM32 à deux protocoles, chinois : logiciel, micrologiciel, diagnostic et journaux. La source d’angle est virtuelle ; ce cas ne prouve ni livraison au Vietnam ni réception d’actions PLC.

Guide Modbus TCP/IP V1.0b, anglais et catalogue, anglais : corrélation des transactions, délais de communication et traitement applicatif. Le protocole et l’interface projet définissent les états de commande.

Par Contact Winge, page chinoise, fournir versions, protocoles, flux de commandes, messages anormaux, conditions d’interverrouillage et de réarmement, langues et environnement de réception pour convenir des responsabilités et du premier lot.