Este artículo analiza una posible implementación de un sistema automatizado para administrar recursos de hardware (usando relés electromagnéticos como ejemplo) con referencia al tiempo absoluto. Tal sistema puede ser muy útil para resolver el problema de la automatización de pruebas de varios equipos.
Por ejemplo, en algunos laboratorios de prueba es necesario automatizar el restablecimiento de la alimentación de los dispositivos estudiados / probados en puntos de tiempo estrictamente establecidos con referencia a la escala absoluta (por ejemplo, el lunes a las 10:00 de la mañana). Sin embargo, la tarea se complica por el hecho de que la decisión sobre la posibilidad de realizar una operación de administración de energía se ve afectada por el estado actual de otros recursos de hardware del dispositivo en estudio (por ejemplo, uno u otro nivel en la línea GPIO de salida).
La última circunstancia complica un poco la solución y nos hace pensar en usar algún módulo de hardware externo en el que haya soporte para los recursos de hardware necesarios para resolver dicho problema, a saber: relés, relojes en tiempo real, líneas GPIO de entrada.
Los primeros experimentos que hicimos con la plataforma Arduino. Sin embargo, cuando se hizo necesario copiar esta solución en grandes cantidades con calidad estable, comenzaron a buscar soluciones preparadas. Como resultado, ajustamos el sistema utilizando un módulo de hardware externo Laurent-5 con la capacidad de monitorear el proceso de control a través de Ethernet.
Para detalles, necesitamos restablecer brevemente la potencia del dispositivo probado todos los días estrictamente a las 07:00 de la mañana. Sin embargo, nunca se debe reiniciar si el dispositivo continúa realizando operaciones críticas. En este caso, se establece un nivel lógico alto (+3,3 V) en la línea GPIO de salida discreta del dispositivo.
El módulo Laurent-5 se conectó al dispositivo de prueba de la siguiente manera. La señal de dispositivo listo se llevó a la línea discreta de entrada IO_1. Y la potencia del dispositivo se envió a través de contactos normalmente cerrados del relé RELE_1. Si el relé está encendido, se corta la alimentación del dispositivo bajo prueba.
Para configurar el sistema, en primer lugar, debe cambiar la dirección del GPIO IO_1 del módulo Laurent-5 "en la entrada". La forma más fácil de configurar es a través de la interfaz web (la dirección predeterminada es 192.168.0.101). Vamos a la sección "Líneas generales IO1 - IO8" en el panel de control principal.
Hacemos clic en la "flecha" en la línea IO_1 y cambiamos la dirección de esta línea GPIO al estado "encendido" para analizar el estado de la línea de "preparación" del dispositivo bajo prueba.
A continuación, creamos reglas lógicas de CAT que servirán para la automatización del análisis de línea de "preparación" y controlarán el relé.
Entramos en la sección CAT y hacemos clic en el botón "Crear un nuevo evento". Aparecerá una ventana en la que ID = 1 se asignará a la nueva regla lógica.
Elija el tipo de evento RTC: la tarea se completará a la hora especificada.
En la configuración del evento, indicamos el tiempo de respuesta, todos los días a las 07:00 de la mañana.
En respuesta a la ocurrencia de este evento usando los comandos Ke, habilitamos la operación de los eventos CAT 2,3 y 4 que crearemos más. Se necesitan reglas lógicas adicionales para analizar la "preparación" de la señal del dispositivo y evitar el reinicio de la alimentación si no está listo para esto.
Pongamos un nombre simbólico a esta regla lógica para mayor claridad.
Como resultado, aparecerá un nuevo evento con ID = 1 en la lista de reglas lógicas:
Agregue la siguiente regla lógica con ID = 2 que se ejecutará en un temporizador con una frecuencia de 1 vez por segundo.
Indicamos una condición adicional que debe cumplirse para que la regla lógica funcione, a saber, especificamos la necesidad de un nivel lógico bajo en IO_1, lo que indica que el dispositivo está listo para un reinicio de energía.
Si se cumplen todas las condiciones, apague los eventos 2, 3 y 4. Restableceremos el contador de respuesta para el evento 3 (consulte a continuación) y activaremos el relé RELE_1 durante 4 segundos, después de lo cual volverá automáticamente a su estado original (apagado).
Sin embargo, ¿qué debo hacer si el dispositivo se "congela" y la alarma suena todo el tiempo? Para esto, utilizaremos eventos con ID = 3 y 4 en los que implementaremos una apariencia de temporizador de vigilancia con el envío de un mensaje de alarma si, dentro de un tiempo especificado, el dispositivo no ha indicado que está listo para un reinicio de hardware.
Creemos un evento con ID = 3 de acuerdo con el temporizador habitual con una frecuencia de respuesta de una vez cada 1 segundo. Este evento en realidad no hará nada, solo envíe un comando $ KE vacío. Sin embargo, con cada operación, el contador de operaciones de este evento aumentará. Usando una regla lógica con ID = 4, monitorearemos este valor y si excede un cierto umbral (por ejemplo, 300 operaciones, que corresponde a 5 minutos), detendremos la operación e incrementaremos el valor de la variable de programa VAR_1 para el análisis posterior del número de operaciones fallidas.
En total, un conjunto de reglas lógicas se verá de la siguiente manera. Para iniciar todo el sistema, es suficiente habilitar el procesamiento de eventos con ID = 1.
Y luego habrá lo siguiente: todos los días a las 07:00 de la mañana se activará una regla lógica con ID = 1. En este caso, se incluirá como reacción el procesamiento de eventos con las ID 2, 3 y 4. Si el dispositivo bajo prueba está listo para restablecer la alimentación (nivel lógico 0 a línea de señal): como parte de la regla ID = 2, el procesamiento de los eventos 2-4 se desactivará, el contador de operaciones para la tercera regla se reinicia para un caso aleatorio y el dispositivo se reinicia al encender brevemente el relé.
En paralelo, comenzamos el temporizador de guardia con un reloj una vez por segundo. Al verificar el valor del temporizador de vigilancia dentro del marco de la regla ID = 4, podemos bloquear la espera y señalar el fallo de toda la operación en ese día al incrementar la variable del programa VAR_1, cuyo valor puede solicitarse a través de TCP / HTTP para su posterior análisis.