В данной статье рассмотрен возможный вариант реализации автоматизированной системы управления аппаратными ресурсами (на примере электромагнитных реле) с привязкой к абсолютному времени. Подобная система может оказаться очень полезной при решении задачи автоматизации тестирования различной аппаратуры.
Например, в некоторой тестовой лаборатории есть необходимость автоматизировать сброс питания исследуемых / тестируемых устройств в строго установленные моменты времени с привязкой к абсолютной шкале (например, в понедельник в 10:00 утра). Однако, задача усложняется тем что на принятие решения о возможности выполнения операции управления питанием влияет текущее состояние других аппаратных ресурсов исследуемого устройства (например, тот или иной уровень на выходной GPIO линии).
Последнее обстоятельство несколько усложняет решение и заставляет задуматься о применении некоторого внешнего аппаратного модуля в котором есть поддержка необходимых аппартных ресурсов для решения такой задачи, а именно: реле, часы реального времени, входные GPIO линии.
Первые опыты мы сделали с использованием платформы Arduino. Однако когда возникла необходимость копировать данное решение в больших количествах со стабильным качеством стали смотреть в сторону готовых решений. В итоге наладили систему с использованием внешнего аппаратного модуля Laurent-5 с возможностью мониторинга процесса управления по Ethernet.
Для конкретики, нам нужно было кратковременно сбрасывать питание тестируемого устройства каждый день строго в 07:00 утра. Однако, сброс ни в коем случае проводить нельзя если устройство продолжает выполнять критические операции. В этом случае, на выходной дискретной GPIO линии устройтсва выставляется высокий логический уровень (+3.3 В).
Модуль Laurent-5 соединили с испытуемым устройством следующим образом. Сигнал готовности устройства завели на входную дискретную линию IO_1. А питание устройства пробросили через нормально замкнутые контакты реле RELE_1. Если реле включить — прекратиться подача питания на тестируемое устройство.
Для настройки системы в первую очередь нужно изменить направление для GPIO IO_1 модуля Laurent-5 «на вход». Настройку проще всего делать через Web интерфейс (адрес по умолчанию 192.168.0.101). Заходим в раздел «Линии общего назначения IO1 — IO8» на главной панели управления.
Нажимаем на «стрелочку» у линии IO_1 и меняем направление этой GPIO линии в состояние «на вход» для анализа состояния линии «готовность» тестируемого устройства.
Далее создадим логичесие правила CAT которые будут обслуживать автоматику анализа линии «готовность» и управлять реле.
Заходим в раздел CAT и нажимаем на кнопку «Создать новое событие». Появится вот такое окно в котором новому логическому правилу будет назначен ID = 1.
Выберем тип события RTC — выполнение задачи в указанное время.
В настройках события укажем время срабатывания — каждый день в 07:00 утра.
В качестве реакции при возникновении этого события с помощью Ke-команд включим работу CAT событий 2,3 и 4 которые создадим далее. Дополнительные логические правила нужны для того что бы анализировать сигнал «готовность» устройства и избежать сброса питания если оно к этому не готово.
Дадим символическое имя этому логическому правилу для наглядности.
В итоге в списке логических правил появится новое событие с ID = 1:
Добавим следующе логическое правило с ID = 2 которое будет выполнять по таймеру с частотой 1 раз в секунду.
Укажем дополнительное условие которое должно быть удовлетворено для того чтобы логическое правило сработало, а именно задаим необходимость наличия низкого логичсекого утровня на IO_1 сигнализирующего тем самым о готовности устройства к сбросу питания.
Если все условия будут выполнены — то тогда выключим события 2,3 и 4. Сбросим счетчик срабатываний для события 3 (см. далее) и включим реле RELE_1 на 4 секунды после чего оно самостоятельно вернется в исходное (выключенное) состояние.
Однако что делать если устройство «зависло» и сигнал тревоги все время взведен? Для того и будем использовать события с ID = 3 и 4 в которых реализуем подобие строжевого таймера с отправкой тревожного сообщния если в течение заданного времени устройство так и не просигнализировало о своей готовности к аппаратному сбросу.
Создадим событие с ID = 3 по обычному таймру с частотой срабатывания раз в 1 сек. Это событие по факту не будет ни чего делать, просто посылать пустую команду $KE. Однако при каждом срабатывании будет увеличиваться счетчик срабатываний этого события. С помощью логического правила с ID = 4 мы будем мониторить эту величину и если она превысит некоторый порог (например, 300 срабатываний что соответствует 5 минутам) — делать останов работы и инкрементирует значение программной переменной VAR_1 для последующего анализа числа проваленных операций.
Итого всеб набор логических правил будет выглядеть следующим образом. Для старта всей системы достаточно включить обработку события с ID = 1.
А далее будет следующее: каждый день в 07:00 утра будет срабатывать логическое правило с ID = 1. При этом в качестве реакции будет включена обработка событий с ID 2, 3 и 4. Если тестируемое устройство готово к сбросу питания (логический уровень 0 на сигнальной линии) — в рамках работы правила ID = 2 будет выключена обработка событий 2-4, сброшен на вяский случай счетчик срабатываний для 3-го правила и произведен ресет питания устройства путем кратковременного включения реле.
В паралель, запускаем строжевой таймер отсчитывающий с тактом раз в секунду. Путем проверки значения строжевого таймера в рамках правила ID = 4 мы можем аварийно прекратить ожидание и просигнализировать о провале всей операции в этот день путем инкрементирования программной переменной VAR_1 значение котрой можно потом запросить по TCP / HTTP для последующего анализа.
Например, в некоторой тестовой лаборатории есть необходимость автоматизировать сброс питания исследуемых / тестируемых устройств в строго установленные моменты времени с привязкой к абсолютной шкале (например, в понедельник в 10:00 утра). Однако, задача усложняется тем что на принятие решения о возможности выполнения операции управления питанием влияет текущее состояние других аппаратных ресурсов исследуемого устройства (например, тот или иной уровень на выходной GPIO линии).
Последнее обстоятельство несколько усложняет решение и заставляет задуматься о применении некоторого внешнего аппаратного модуля в котором есть поддержка необходимых аппартных ресурсов для решения такой задачи, а именно: реле, часы реального времени, входные GPIO линии.
Первые опыты мы сделали с использованием платформы Arduino. Однако когда возникла необходимость копировать данное решение в больших количествах со стабильным качеством стали смотреть в сторону готовых решений. В итоге наладили систему с использованием внешнего аппаратного модуля Laurent-5 с возможностью мониторинга процесса управления по Ethernet.
Для конкретики, нам нужно было кратковременно сбрасывать питание тестируемого устройства каждый день строго в 07:00 утра. Однако, сброс ни в коем случае проводить нельзя если устройство продолжает выполнять критические операции. В этом случае, на выходной дискретной GPIO линии устройтсва выставляется высокий логический уровень (+3.3 В).
Модуль Laurent-5 соединили с испытуемым устройством следующим образом. Сигнал готовности устройства завели на входную дискретную линию IO_1. А питание устройства пробросили через нормально замкнутые контакты реле RELE_1. Если реле включить — прекратиться подача питания на тестируемое устройство.
Для настройки системы в первую очередь нужно изменить направление для GPIO IO_1 модуля Laurent-5 «на вход». Настройку проще всего делать через Web интерфейс (адрес по умолчанию 192.168.0.101). Заходим в раздел «Линии общего назначения IO1 — IO8» на главной панели управления.
Нажимаем на «стрелочку» у линии IO_1 и меняем направление этой GPIO линии в состояние «на вход» для анализа состояния линии «готовность» тестируемого устройства.
Далее создадим логичесие правила CAT которые будут обслуживать автоматику анализа линии «готовность» и управлять реле.
Заходим в раздел CAT и нажимаем на кнопку «Создать новое событие». Появится вот такое окно в котором новому логическому правилу будет назначен ID = 1.
Выберем тип события RTC — выполнение задачи в указанное время.
В настройках события укажем время срабатывания — каждый день в 07:00 утра.
В качестве реакции при возникновении этого события с помощью Ke-команд включим работу CAT событий 2,3 и 4 которые создадим далее. Дополнительные логические правила нужны для того что бы анализировать сигнал «готовность» устройства и избежать сброса питания если оно к этому не готово.
Дадим символическое имя этому логическому правилу для наглядности.
В итоге в списке логических правил появится новое событие с ID = 1:
Добавим следующе логическое правило с ID = 2 которое будет выполнять по таймеру с частотой 1 раз в секунду.
Укажем дополнительное условие которое должно быть удовлетворено для того чтобы логическое правило сработало, а именно задаим необходимость наличия низкого логичсекого утровня на IO_1 сигнализирующего тем самым о готовности устройства к сбросу питания.
Если все условия будут выполнены — то тогда выключим события 2,3 и 4. Сбросим счетчик срабатываний для события 3 (см. далее) и включим реле RELE_1 на 4 секунды после чего оно самостоятельно вернется в исходное (выключенное) состояние.
Однако что делать если устройство «зависло» и сигнал тревоги все время взведен? Для того и будем использовать события с ID = 3 и 4 в которых реализуем подобие строжевого таймера с отправкой тревожного сообщния если в течение заданного времени устройство так и не просигнализировало о своей готовности к аппаратному сбросу.
Создадим событие с ID = 3 по обычному таймру с частотой срабатывания раз в 1 сек. Это событие по факту не будет ни чего делать, просто посылать пустую команду $KE. Однако при каждом срабатывании будет увеличиваться счетчик срабатываний этого события. С помощью логического правила с ID = 4 мы будем мониторить эту величину и если она превысит некоторый порог (например, 300 срабатываний что соответствует 5 минутам) — делать останов работы и инкрементирует значение программной переменной VAR_1 для последующего анализа числа проваленных операций.
Итого всеб набор логических правил будет выглядеть следующим образом. Для старта всей системы достаточно включить обработку события с ID = 1.
А далее будет следующее: каждый день в 07:00 утра будет срабатывать логическое правило с ID = 1. При этом в качестве реакции будет включена обработка событий с ID 2, 3 и 4. Если тестируемое устройство готово к сбросу питания (логический уровень 0 на сигнальной линии) — в рамках работы правила ID = 2 будет выключена обработка событий 2-4, сброшен на вяский случай счетчик срабатываний для 3-го правила и произведен ресет питания устройства путем кратковременного включения реле.
В паралель, запускаем строжевой таймер отсчитывающий с тактом раз в секунду. Путем проверки значения строжевого таймера в рамках правила ID = 4 мы можем аварийно прекратить ожидание и просигнализировать о провале всей операции в этот день путем инкрементирования программной переменной VAR_1 значение котрой можно потом запросить по TCP / HTTP для последующего анализа.
