Cet article présente une implémentation possible d'un système automatisé de gestion des ressources matérielles (en utilisant des relais électromagnétiques comme exemple) en référence au temps absolu. Un tel système peut être très utile pour résoudre le problème des tests d'automatisation de divers équipements.
Par exemple, dans certains laboratoires d'essai, il est nécessaire d'automatiser la réinitialisation de l'alimentation des dispositifs étudiés / testés à des moments strictement définis en se référant à l'échelle absolue (par exemple, le lundi à 10h00 du matin). Cependant, la tâche est compliquée par le fait que la décision sur la possibilité d'effectuer une opération de gestion de l'alimentation est affectée par l'état actuel des autres ressources matérielles du périphérique à l'étude (par exemple, un ou un autre niveau sur la ligne GPIO de sortie).
Cette dernière circonstance complique quelque peu la solution et nous fait penser à l'utilisation d'un module matériel externe dans lequel il existe un support pour les ressources matérielles nécessaires pour résoudre un tel problème, à savoir: relais, horloges en temps réel, lignes d'entrée GPIO.
Les premières expériences que nous avons faites en utilisant la plate-forme Arduino. Cependant, quand il est devenu nécessaire de copier cette solution en grande quantité avec une qualité stable, ils ont commencé à chercher des solutions toutes faites. En conséquence, nous avons ajusté le système à l'aide d'un module matériel externe Laurent-5 avec la possibilité de surveiller le processus de contrôle via Ethernet.
Pour plus de détails, nous devions réinitialiser brièvement la puissance de l'appareil testé chaque jour strictement à 07h00 du matin. Cependant, une réinitialisation ne doit jamais être effectuée si l'appareil continue d'effectuer des opérations critiques. Dans ce cas, un niveau logique élevé (+3,3 V) est défini sur la ligne GPIO de sortie discrète de l'appareil.
Le module Laurent-5 a été connecté au dispositif de test comme suit. Le signal prêt pour l'appareil a été amené sur la ligne discrète d'entrée IO_1. Et l'alimentation de l'appareil a été transmise via des contacts normalement fermés du relais RELE_1. Si le relais est activé, l'alimentation de l'appareil testé est coupée.
Pour configurer le système, vous devez tout d'abord changer la direction du GPIO IO_1 du module Laurent-5 «en entrée». La façon la plus simple de configurer est via l'interface Web (l'adresse par défaut est 192.168.0.101). Nous allons à la section "Lignes générales IO1 - IO8" sur le panneau de commande principal.
Nous cliquons sur la «flèche» à la ligne IO_1 et changeons la direction de cette ligne GPIO à l'état «on» pour analyser l'état de la ligne «de préparation» de l'appareil testé.
Ensuite, nous créons des règles CAT logiques qui serviront à l'automatisation de l'analyse de la ligne de «préparation» et contrôleront le relais.
Nous allons dans la section CAT et cliquons sur le bouton "Créer un nouvel événement". Une fenêtre apparaîtra dans laquelle ID = 1 sera affecté à la nouvelle règle logique.
Choisissez le type d'événement RTC - la tâche sera terminée à l'heure spécifiée.
Dans les paramètres de l'événement, nous indiquons le temps de réponse - tous les jours à 07h00 du matin.
En réponse à l'occurrence de cet événement à l'aide de Ke-commandes, nous permettons le fonctionnement des événements CAT 2,3 et 4 que nous allons créer davantage. Des règles logiques supplémentaires sont nécessaires afin d'analyser la «disponibilité» du signal de l'appareil et d'éviter une réinitialisation de l'alimentation s'il n'est pas prêt pour cela.
Donnons un nom symbolique à cette règle logique pour plus de clarté.
Par conséquent, un nouvel événement avec ID = 1 apparaîtra dans la liste des règles logiques:
Ajoutez la règle logique suivante avec ID = 2 qui s'exécutera sur une minuterie avec une fréquence de 1 fois par seconde.
Nous indiquons une condition supplémentaire qui doit être satisfaite pour que la règle logique fonctionne, à savoir, nous spécifions la nécessité d'un niveau logique bas à IO_1, signalant ainsi que l'appareil est prêt pour une réinitialisation de l'alimentation.
Si toutes les conditions sont remplies, désactivez les événements 2,3 et 4. Nous réinitialisons le compteur de réponse pour l'événement 3 (voir ci-dessous) et activons le relais RELE_1 pendant 4 secondes, après quoi il reviendra automatiquement à son état d'origine (désactivé).
Cependant, que dois-je faire si l'appareil «se fige» et que l'alarme retentit tout le temps? Pour cela, nous utiliserons des événements avec ID = 3 et 4 dans lesquels nous implémentons un semblant de temporisateur de surveillance avec l'envoi d'un message d'alarme si, dans un délai spécifié, l'appareil n'a pas signalé sa disponibilité pour une réinitialisation matérielle.
Créons un événement avec ID = 3 selon le temporisateur habituel avec une fréquence de réponse toutes les 1 seconde. Cet événement ne fera rien, il suffit d'envoyer une commande $ KE vide. Cependant, à chaque opération, le compteur d'opérations de cet événement augmentera. En utilisant une règle logique avec ID = 4, nous surveillerons cette valeur et si elle dépasse un certain seuil (par exemple, 300 opérations, ce qui correspond à 5 minutes), nous arrêterons l'opération et incrémenterons la valeur de la variable de programme VAR_1 pour une analyse ultérieure du nombre d'opérations ayant échoué.
Au total, un ensemble de règles logiques se présente comme suit. Pour démarrer l'ensemble du système, il suffit d'activer le traitement des événements avec ID = 1.
Et puis il y aura ce qui suit: chaque jour à 07h00 du matin, une règle logique avec ID = 1 sera déclenchée. Dans ce cas, le traitement des événements avec les ID 2, 3 et 4 sera inclus en tant que réaction. Si l'appareil sous test est prêt à réinitialiser l'alimentation (niveau logique 0 à ligne de signal) - dans le cadre de la règle ID = 2, le traitement des événements 2-4 sera désactivé, le compteur de fonctionnement de la troisième règle est réinitialisé pour un cas aléatoire, et l'appareil est réinitialisé en activant brièvement le relais.
En parallèle, nous démarrons le compte à rebours avec une horloge une fois par seconde. En vérifiant la valeur du temporisateur de surveillance dans le cadre de la règle ID = 4, nous pouvons bloquer l'attente et signaler l'échec de toute l'opération ce jour-là en incrémentant la variable de programme VAR_1, dont la valeur peut ensuite être demandée via TCP / HTTP pour une analyse ultérieure.