Émulation APCS : Contrôleurs Modbus RTU

Émulation logicielle des contrôleurs dans les systèmes SCADA pour tests

Le développement de logiciels pour les systèmes de supervision, de contrôle et d'acquisition de données (SCADA) exige un test rigoureux des interactions entre périphériques, capteurs et contrôleurs. Les panneaux physiques traditionnels avec interrupteurs et cellules de charge pouvaient simuler des scénarios basiques mais étaient limités par leur capacité de charge (jusqu'à 30 kg) et ne pouvaient pas reproduire fidèlement les processus parallèles. Le passage à l'émulation logicielle via Delphi a éliminé ces contraintes, permettant une simulation précise de la communication Modbus RTU et du comportement des modules d'entrée/sortie.

L'émulateur est conçu comme un configurateur d'appareils : les utilisateurs ajoutent des contrôleurs, attribuent des adresses RS-485 et définissent les mappages entrées/sorties. Il prend en charge toutes les versions d'équipements, y compris les boutons d'arrêt d'urgence pour simuler des pannes de communication.

Architecture de l'émulateur

La fenêtre principale affiche une liste des appareils avec des indicateurs d'état. Pour les contrôleurs de pesage, elle propose :

• Un curseur pour ajuster le poids sans limite physique.
• Un réglage manuel des paramètres et des changements d'état.
• Un commutateur mode manuel/automatique avec des incréments aléatoires de poids pour une dosification réaliste.

Les modules I/O permettent de basculer manuellement les entrées/sorties. En mode automatique, ils imitent la réelle dosage de matériaux (ciment, granulats, eau).

L'intégration avec l'application principale est minimale : la directive de compilation $IF Emulate=True redirige les appels depuis ComPort.Write vers Emulator.Send.

{$IF Emulate=True}
Emulator.Send(EmulData, FWaitingTime);
{$ELSE}
ComPort.Write(OutDIOM, 11, @InDIOM, 8);
ComPort.Wait(FWaitingTime);
{$IFEND}

Les modifications sont isolées au module de communication — les commandes Modbus RTU restent inchangées, et les réponses suivent strictement les spécifications.

Files d'attente de communication et de commandes

La communication suit un modèle "commande" avec plusieurs files d'attente pour assurer le parallélisme :

• Lecture continue de l'état des contrôleurs (même pendant les périodes d'inactivité).
• Lecture des entrées/sorties des modules I/O pour surveillance.
• Envoi de commandes (priorité maximale : démarrage de la dosification, activation du moteur).

Un flux continu gère les files. Les files de lecture se remplissent jusqu'à un seuil, tandis que les commandes opérateur à haute priorité sont insérées en tête. Les commandes sont générées dynamiquement selon l'état actuel et attendu des équipements.

Exemple : dans une centrale à béton, trois ou plusieurs opérations de dosification s'exécutent en parallèle (préparation, affectation de poids, démarrage). Dans une usine de ciment, des vérifications d'état séquentielles ont lieu avant chaque nouvelle commande.

Les indicateurs de file deviennent rouges en cas de perte de communication. Les délais sur 10 modules I/O (20 ms par requête) entraînent un cycle d'environ 400 ms plus le sondage du contrôleur, soit un temps de réponse total d'environ 1 seconde — pris en compte dans l'interface pour éviter les alertes d'erreur erronées.

Avantages de l'émulation logicielle

• Simulation complète des scénarios : pannes, blocages, dosifications parallèles — tout sans matériel physique.
• Sauvegarde et chargement de configurations adaptées à chaque usine spécifique.
• Extensibilité : ajouter de nouveaux appareils nécessite seulement de respecter les spécifications Modbus et du contrôleur.
• Mise en service accélérée : moins d'erreurs imprévues sur site.

L'émulateur fonctionne sur des applications héritées Windows XP/7, permettant des tests complexes sans interruption ni risque de dommage.

Points clés

• L'émulation préserve la précision de Modbus RTU, minimisant les modifications du code central.
• Le mode automatique inclut un dosage aléatoire pour des conditions de test réalistes.
• Plusieurs files de commandes permettent l'exécution parallèle sans blocage.
• Simplicité : facile à maîtriser après avoir compris le protocole et la documentation technique.
• Économies : pas besoin de panneaux physiques, développement et débogage plus rapides.

— Editorial Team