Русский
Русский
English
Статистика
Реклама

Мониторинг оборудования

Управление наружным освещением

24.03.2021 00:15:52 | Автор: admin

Однажды передо мной встала задача модернизации системы управления наружным освещением: художественная подсветка фасадов, рекламные вывески, уличные столбы, подсветка адресных табличек и т. п. Необходимость модернизации была вызвана тем, что работа осветительных установок требовала частого участия человека. Для того чтобы управление работало как положено, приходилось вручную корректировать время включения и отключения.

Модернизация предполагала максимальное использование существующей инженерной и IT инфраструктуры. Требовалось воздержаться от монтажа нового или замены старого оборудования, свести к минимуму перечень используемого ПО. Принципы, применяемые в системе управления, должны быть универсальными и пригодными для повторного использования. Должна быть обеспечена возможность легкого расширения системы. Осветительные установки, вводимые в эксплуатацию, могут быть смонтированы в разных районах города, в разных регионах или странах.

Разбираемся с инфраструктурой

На практике мне встречалось несколько подходов к управлению наружным освещением: регламентированное включение и отключение силами оперативного персонала, применение реле времени, сумеречных датчиков, фотореле и астрономических реле.

Использование астрономических реле является, наверное, одним из самых интересных решений. Их работа основана на определении времени восходов и закатов в определенном географическом положении. Во время заката освещение включается, во время восхода - отключается. Как правило, при настройке таких реле имеется возможность установки временных корректировок для ускорения или замедления действия реле. Внесение таких корректировок позволяет включить (отключить) освещение на несколько минут позже заката или раньше рассвета.

По похожей схеме работает и модернизируемая нами система. В роли астрономического реле выступает свободно программируемый логический контроллер (ПЛК). По линии RS485 ПЛК управляет проприетарными модулями ввода-вывода, которые установлены в разных зданиях. Управление и настройка системы осуществляется с использованием SCADA и OPC-сервера, установленного на одной из машин в сети Ethernet, к которой подключен ПЛК. Все используемое ПО является проприетарным.

Выявленные недостатки и их причины

В ходе эксплуатации осветительных установок стало понятно, что система управления требует постоянного внимания персонала. По большому счету все сводилось к тому, что становилось очевидно: подсветка зданий включается слишком поздно, а отключается слишком рано. Эта проблема решалась корректировкой коэффициентов в системе диспетчеризации. Путем ручного подбора коэффициентов удавалось достигнуть времени включения и отключения, соответствующего городскому графику. Коэффициенты оставались неизменными до следующей подобной ситуации. А повторялись такие ситуации довольно часто.

Было сделано предположение, что причина проблемы кроется в проекте, загруженном в ПЛК. Ознакомиться с исходниками проекта не представлялось возможным. Из текстового описания проекта стало понятно, что для определения времени включения/отключения освещения используется функциональный блок, доступный в проприетарной среде программирования. Используя триальную версию этой среды, удалось получить доступ к справке и более подробному описанию этого блока. Это внесло некоторую ясность: функциональный блок высчитывает время, когда угол (высота) Солнца над горизонтом для заданного географического положения станет равен 0. Коэффициенты корректируют этот угол. Например, при коэффициенте "-6" будет высчитано время, когда Солнце окажется ниже горизонта на 6. Но в ходе проведенных экспериментов сложилось мнение, что функциональный блок производит расчеты не совсем так, как это предполагается. Дальнейшие работы в этом направлении были прекращены ввиду отсутствия универсальности такой реализации.

Начинаем модернизацию

При рассмотрении существующих вариантов, я склонялся к варианту управления по расписанию. Не секрет, что существуют общедоступные графики отключения наружного освещения. Для Москвы и Санкт-Петербурга, например - МОССВЕТ и ЛЕНСВЕТ. Обладая этой информацией несложно написать скрипт, который следит за временем и по графику управляет освещением. Тем более, что в сети Ethernet, к которой подключен ПЛК, имеется Linux-машина.

Для того чтобы такой скрипт мог управлять удаленными модулями ввода-вывода, потребовалось заново создать проект для ПЛК. По-сути ПЛК стал выступать в роли шлюза, что предоставило нам возможность управлять освещением по открытому протоколу Modbus TCP.

Для работы с Modbus будем использовать утилиту modpoll. Скачаем и распакуем ее на нашей Linux машине:

$ wget https://www.modbusdriver.com/downloads/modpoll.tgz$ tar xzf modpoll.tgz$ sudo cp modpoll/linux_x86-64/modpoll /usr/local/bin/

Теперь управлять освещением будем следующим образом:

#Включить освещение$ modpoll -m tcp -r 2 -t 0 -a 1 -p 502 192.168.0.227 1 1 1 1 1 1 1 1 #Отключить освещение$ modpoll -m tcp -r 2 -t 0 -a 1 -p 502 192.168.0.227 0 0 0 0 0 0 0 0 

Дело осталось за малым - вызывать эти команды по заранее сформированному расписанию. Как было упомянуто выше, подобные графики доступны и мы можем ими воспользоваться. Но появилось желание найти более универсальный подход, поэтому давайте вспомним о таком явлении, как "сумерки".

Сумерки

В сутках существуют периоды, называемые сумерки. Это время перед восходом Солнца и после заката, когда небо частично освещено рассеянным солнечным светом. Выделяют три вида сумерек: гражданские, навигационные и астрономические. Гражданские сумерки определяются как период, когда угол нахождения Солнца под горизонтом составляет от 050 до 6, навигационные сумерки от 6 до 12, а астрономические сумерки от 12 до 18.

Наибольший интерес для нас представляют навигационные сумерки. Именно в этот период освещение становится ближе к ночному, чем к вечернему, поэтому улицы городов нуждаются в искусственном освещении. Проще говоря, наружное освещение включается с началом навигационных сумерек (Солнце опускается ниже -6 ) и отключается с их окончанием (Солнце поднимается выше -6 ). Конечно стоит понимать, что в зависимости от погодных условий и в условиях городской застройки, включение может потребоваться раньше, чем Солнце опустится ниже -6 за горизонт.

Еще немного об астрономических реле.

Когда мы обсуждали работу астрономических реле, то упоминали временные корректировки, ускоряющие или замедляющие действие реле. Такой подход с задержкой времени имеет недостатки. Как мы выяснили, освещенность на улицах в основном определяется углом Солнца относительно горизонта. В одном и том же географическом положении скорость, с которой Солнце опускается за горизонт, изменяется в течении года. Или, иначе говоря, в зависимости от времени года изменяется продолжительность сумерек и навигационные сумерки могут наступать позже или раньше. Из-за этого временные задержки в астрономических реле требуют периодических изменений.

Если управлять освещением, опираясь именно на фактическое положение Солнца, то такая проблема отсутствует.

Подробный и крайне наглядный рассказ о движении Солнца был найден на Youtube - Как солнце ходит по небу / How the sun moves across the sky (by daybit).

Положение Солнца и наружное освещение

Итак, для решения нашей задачи мы будем синхронизировать работу наружного освещения с положением Солнца. При наступлении навигационных сумерек - включение освещения, в момент начала гражданских - отключение. Так как в нашем распоряжении имеется Linux машина и соответственно Perl, то для расчета положения Солнца воспользуемся им. Загрузим необходимый нам модуль:

$ sudo cpan install Astro::Coord::ECI

Создадим скрипт get_sun_elevation.pl, вычисляющий угол Солнца относительно горизонта.

#!/usr/bin/perl# Вычисление высоты Солнца над горизонтом в градусах в текущий момент# get_sun_elevation.pl 55.7558 37.6173 127# 55.7558 - широта в градусах# 37.6173 - долгота в градусах# 127 - высота над уровнем моря в метрахuse Astro::Coord::ECI::Sun;use Astro::Coord::ECI::Utils qw{:all};my ($lat, $lon, $elev) = (deg2rad($ARGV[0]), deg2rad($ARGV[1]), $ARGV[2]/1000);my $time = time ();my $loc = Astro::Coord::ECI->geodetic ($lat, $lon, $elev);my $sun = Astro::Coord::ECI::Sun->universal ($time);my ($azimuth, $elevation, $range) = $loc->azel ($sun);print rad2deg ($elevation), "\n";

Скрипт moscow_lights_ctrl.sh будет сравнивать заданное положение Солнца и его текущее положение в Москве. Если Солнце окажется ниже заданного угла, то отправим команду на включение, иначе - команду на отключение освещения:

#!/bin/sh[ -z "$1" ] && angle=-6 || angle=$1sun_angle=`./sun_pos.pl 55.751244 37.618423 124`if [ $(echo "$sun_angle >= $angle" |bc -l) -eq "0" ]; then  modpoll -m tcp -r 2 -t 0 -a 1 -p 502 192.168.0.227 1 1 1 1 1 1 1 1  exit 0fimodpoll -m tcp -r 2 -t 0 -a 1 -p 502 192.168.0.227 0 0 0 0 0 0 0 0

Опытным путем было определено, что на модернизируемом объекте потребность в наружном освещении возникает, когда Солнце опускается ниже -1.5. К слову, также было замечено, что городское освещение включается примерно в это же время.

С помощью cron будем выполнять moscow_lights_ctrl.sh каждую минуту:

# Если Солнце ниже 1.5 градусов - включение освещения, иначе - отключение* * * * * root /path/to/moscow_lights_ctrl.sh -1.5

Нам ничего не мешает создавать такие скрипты для любого географического положения. А когда возникнет необходимость расширения системы, мы сможем применить любое оборудование. Лично я склоняюсь к использованию модулей ввода-вывода, поддерживающих протокол Modbus TCP.

По большому счету все поставленные цели достигнуты. Модернизацию можно считать успешно завершенной.

ZABBIX

В ходе работ появились некоторые планы на ближайшее будущее, а именно настройка мониторинга работы оборудования. Возможности такого мониторинга сильно зависят от степени готовности самих инженерных систем. Например, мы можем следить за положением силового контактора и контролировать включение освещения. Или получать значение силы тока и тем самым определять, сколько ламп вышло из строя и т.д. К сожалению, на текущий момент к полноценному мониторингу модернизируемая система не готова. Тем не менее, для задела на будущее было решено использовать уже существующую на предприятии систему мониторинга - ZABBIX.

Все принципы работы остаются неизменными. Мы лишь перенесем всю описанную выше логику управления в ZABBIX.

Шаблон для ZABBIX

Создадим шаблон astro_outdoor_lighting для Zabbix со следующими макросами:

  • {$CIVIL_DEGREES} - Окончание и начало гражданских сумерек в градусах. Включение и отключение наружного освещения,

  • {$ELEV} - Высота над уровнем моря в метрах,

  • {$LAT} - Широта в градусах,

  • {$LON} - Долгота в градусах.

Элементы данных

Шаблон содержит только один элемент данных - elevation. Этот элемент следит за положением солнца в заданном географическом положении.

Чтобы получать текущее положение Солнца, элемент осуществляет внешнюю проверку через ранее созданный скрипт get_sun_elevation.pl.

/usr/lib/zabbix/externalscripts/get_sun_elevation.pl
#!/usr/bin/perl# Вычисление высоты Солнца над горизонтом в градусах в текущий момент# get_sun_elevation.pl 55.7558 37.6173 127# 55.7558 - широта в градусах# 37.6173 - долгота в градусах# 127 - высота над уровнем моря в метрахuse Astro::Coord::ECI::Sun;use Astro::Coord::ECI::Utils qw{:all};my ($lat, $lon, $elev) = (deg2rad($ARGV[0]), deg2rad($ARGV[1]), $ARGV[2]/1000);my $time = time ();my $loc = Astro::Coord::ECI->geodetic ($lat, $lon, $elev);my $sun = Astro::Coord::ECI::Sun->universal ($time);my ($azimuth, $elevation, $range) = $loc->azel ($sun);print rad2deg ($elevation), "\n";

Подробности настройки внешних проверок в ZABBIX смотрите в документации.

Триггеры

Единственный триггер civil_twilight_dawn срабатывает по окончании гражданских сумерек, т. е. в момент, когда возникает необходимость в работе наружного освещения.

Шаблон созданного макроса доступен на github.

Добавляем узел сети

После того как шаблон создан, нам необходимо создать узел сети для каждого географического положения, в котором находятся управляемые нами установки наружного освещения. Настройка узла сети заключается в задании актуальных координат и высоты Солнца.

Скрипты и действия ZABBIX

В разделе [Администрирование]->[Скрипты] создадим глобальные скрипты с говорящими названиями facade light off и facade light on.

Когда триггер civil_twilight_dawn переходит в состояние "Проблема", нам необходимо включить наружное освещение, т.е. выполнить скрипт facade light on. После восстановления триггера освещение необходимо отключить, для чего потребуется вызвать скрипт facade light off. Поэтому в разделе [Настройки]->[Действия] мы создадим действие facade light, реализующее необходимое нам поведение системы.

Подобным же образом добавляем скрипты и действия для каждого узла сети.

На этом настройку ZABBIX сервера для управления установками наружного освещения можно считать завершенной.

Заключение

После модернизации прошло несколько месяцев. За это время работа наружного освещения не вызывала каких-либо нареканий.

Как мне видится, даже в простейшем варианте (работа по cron) такой подход перекрывает потребности большинства подобных типовых задач в крупных коммерческих и административных зданиях. В плане экономической конкурентоспособности он тоже выглядит вполне достойно. Когда на объекте требуется более одного астрономического реле, реле времени и т. п., то их стоимость может быть вполне ощутимой. Кроме этого, чаще всего эти элементы управления разнесены по разным частям зданий и добиться их синхронной работы - не такая простая задача, как это может показаться.

Вариант с применением системы мониторинга может решать еще более интересные задачи. Кроме управления, он дает возможность контролировать работу оборудования и оповещать персонал при выявлении неисправностей. В качестве примера можно привести синхронное включение рекламных вывесок на фасаде торгового центра. А в случае неисправности какой-либо вывески оперативный персонал получит сообщение.

Конечно, все вышесказанное актуально при наличии какой-никакой IT инфраструктуры. Но, как правило, она имеется.

На этом все. Спасибо за внимание!

Подробнее..

Как я мониторил РИП-12 от Bolid

28.04.2021 02:24:00 | Автор: admin

Резервированные источники питания используются повсеместно. Они обеспечивают бесперебойным электропитанием приборы охранной и пожарной сигнализации, оборудование систем контроля доступа и другие системы. На нашем предприятии в качестве таких источников, как правило, используются приборы от ЗАО НВП Болид. У некоторых из них, как, например, у РИП-12-6/80M3-R-RS, имеется интерфейс RS485, что позволяет включать их в систему мониторинга.

Средства мониторинга

Мы используем Zabbix 5.2. Получать данные от РИП будем по протоколу Modbus RTU over TCP. Поддержка этого протокола реализована в Zabbix с помощью загружаемого модуля libzbxmodbus. Также в процессе мониторинга принимают участие преобразователь протокола C2000-ПП (вер. 1,32) в режиме Master и преобразователь последовательных интерфейсов (RS485 в Ethernet).

Объекты мониторинга

Для начала определимся, что конкретно мы сможем контролировать. Из документации к РИП-12-6/80M3-R-RS и С2000-ПП выяснилось, что рассчитывать мы можем на получение состояния семи зон (ШС) и числовых значений тока и напряжения. В ходе экспериментов мне удалось воспроизвести следующие состояния ШС:

ШС 0 Состояние прибора

149

Взлом корпуса прибора

Корпус РИП открыт

152

Восстановление корпуса прибора

Корпус РИП закрыт

250

Потеряна связь с прибором

Потеряна связь с прибором

ШС 1 Выходное напряжение

193

Подключение выходного напряжения

РИП подключил выходное напряжение при появлении напряжения в сети

192

Отключение выходного напряжения

РИП отключил выходное напряжение при отсутствии напряжения в сети и разряде батареи

199

Восстановление питания

Напряжение питания прибора пришло в норму

250

Потеряна связь с прибором

Потеряна связь с прибором

ШС 2 Ток нагрузки

194

Перегрузка источника питания

Выходной ток РИП более 7,5 А

195

Перегрузка источника питания устранена

Выходной ток РИП менее 7,5 А

250

Потеряна связь с прибором

Потеряна связь с прибором

ШС 3 и ШС 4 Напряжение на батарее 1 и 2 соответственно

200

Восстановление батареи

Напряжение батареи выше 10 В, заряд батареи возможен

202

Неисправность батареи

Напряжение на батарее ниже 7 В или не подключена

211

Батарея разряжена

Напряжение на батарее ниже 11 В при отсутствии сетевого напряжения

250

Потеряна связь с прибором

Потеряна связь с прибором

ШС 5 Степень заряда батарей

196

Неисправность зарядного устройства

ЗУ не обеспечивает напряжение и ток для заряда батареи в заданных пределах

197

Восстановление зарядного устройства

ЗУ обеспечивает напряжение и ток для заряда батареи в заданных пределах

250

Потеряна связь с прибором

Потеряна связь с прибором

ШС 6 Напряжение сети

1

Восстановление сети 220

Сетевое напряжение питания < 150 В или > 250 В

2

Авария сети 220 В

Сетевое напряжение питания в пределах 150250 В

250

Потеряна связь с прибором

Потеряна связь с прибором

Крайне вероятно, что мной была получена только часть из всех возможных состояний. Например, имеются догадки, что ШС 3 и 4 должны также иметь состояние [204] Необходимо обслуживание, а ШС 0 - состояние [203] Сброс прибора и другие. К сожалению, чтение документации ситуацию не прояснило. В связи с этим нам необходимо следить и реагировать на появление событий, которые мы не предусмотрели.

Конфигурирование устройств

Не будем долго останавливаться на процессе конфигурирования приборов, только коротко рассмотрим перечень необходимых действий. Настройка устройств Болид осуществляется при помощи утилиты UProg и имеет следующий порядок:

  1. Назначение сетевых адресов всем устройствам (РИП и С2000-ПП),

  2. Конфигурирование интерфейса интеграции С2000-ПП (Modbus RTU),

  3. Добавление ШС, описанных выше, в таблицу зон С2000-ПП. Крайне важно, чтобы, во-первых, были добавлены все ШС, а во-вторых, ШС должны следовать друг за другом в порядке возрастания.

UProg. Конфигурация С2000-ППUProg. Конфигурация С2000-ПП

При заполнении таблицы зон следует помнить следующее:

  • адрес прибора - сетевой адрес РИП, в нашем случае 126,

  • номер ШС - номер ШС от 0 до 6,

  • тип зоны - тип ШС, для ШС 0 назначаем тип зоны "3 - состояние прибора", для всех остальных - "8-РИП напряжение / ток".

Создаем шаблоны Zabbix

Напомню, что Zabbix с модулем libzbxmodbus выступает в роли Modbus-мастера. Из-за особенностей получения данных от C2000-ПП, о которых речь пойдет в процессе создания шаблонов, мы будем рассматривать два подхода к мониторингу.

  • мониторинг состояния ШС.

  • мониторинг как состояния, так и числовых параметров РИП.

Мониторинг состояния ШС

Итак, создадим шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. Шаблон имеет один элемент данных с именем Request и типом "Простая проверка". Ключом элемента является функция: modbus_read[{$MODBUS_PORT},{$MODBUS_SLAVE},{$STATUS_REG},3,7*uint16] . В параметрах функции используются значения макросов, которые позволяют составить корректный modbus запрос к C2000-ПП.

  • {MODBUS_PORT} - тип используемого протокола (enc - Modbus RTU over TCP), адрес и порт преобразователя последовательных интерфейсов.

  • {MODBUS_SLAVE} - Modbus UID С2000-ПП (настраивается в UProg на вкладке прибор).

  • {STATUS_REG} - адрес регистра в котором расположен ШС 0 интересующего нас РИПа. Получить данный адрес можно следующим образом: "Номер зоны в таблице зон С2000-ПП" + 40000 - 1. В нашем примере это: 450+40000-1 = 40449.

Основная задача элемента Request - запросить у С2000-ПП значение всех семи ШС контролируемого РИП и предоставить их в формате JSON. Результирующий JSON содержит объекты, ключами которых являются адресы регистров С2000-ПП, а значениями - содержимое этих регистров:

{  "40449":39115,  "40450":51195,  "40451":50171,  "40452":51963,  "40453":51451,  "40454":50683,  "40455":763}

Зависимые элементы данных

Элемент данных Request имеет 7 зависимых элементов. Основная задача этих элементов - распарсить JSON и получить состояние каждого ШС индивидуально. Вот эти элементы:

  • Status - состояние прибора (ШС 0),

  • Uout - выходное напряжение (ШС 1),

  • Iout - ток нагрузки (ШС 2),

  • Ubat1 - напряжение АКБ1 (ШС 3),

  • Ubat2 - напряжение АКБ2 (ШС 4),

  • Capacity - степень заряда АКБ (ШС 5),

  • Uin - напряжение сети (ШС 6).

Предобработка зависимых элементов данных

Чтобы получить состояние ШС 0 (Status), нам достаточно два шага предобработки. На первом шаге мы воспользуемся стандартным функционалом JSONPath, а затем разделим полученное значение на 256, тем самым получим код состояния.

К сожалению, мне не удалось использовать математические операции в параметрах JSONPath. Поэтому для оставшихся элементов данных пришлось использовать javascritpt-предобработку. Например, для элемента данных Iout (ШС 2) javascript-предобработка выглядит так:

function (value){    var reg = parseInt({$STATUS_REG})+2;    var data = JSON.parse(value);    return data[reg];}

Триггеры

После добавления триггеров создание шаблона можно считать завершенным. Перечень созданных триггеров:

  1. Взлом корпуса прибора,

  2. Перегрузка источника питания,

  3. Отключение выходного напряжения,

  4. Неисправность батареи АКБ1,

  5. Неисправность батареи АКБ2,

  6. АКБ1 разряжен,

  7. АКБ2 разряжен,

  8. Авария сети 220 В,

  9. Потеряна связь с прибором,

  10. Неизвестное состояние Status,

  11. Неизвестное состояние Iout,

  12. Неизвестное состояние Uout,

  13. Неизвестное состояние АКБ1,

  14. Неизвестное состояние АКБ2,

  15. Неизвестное состояние Capacity,

  16. Неизвестное состояние Uin,

  17. Превышено время отсутствия по MODBUS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS

Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS в картинкахШаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS в картинкахПример создания узла сетиПример создания узла сети

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS, Преобразование значений RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Мониторинг состояния и числовых параметров

Мониторинг числовых параметров имеет свои особенности. Все дело в том, что для получения числового значения нам необходимо сделать два modbus-запроса к С2000-ПП. Первый запрос устанавливает зону для запроса тока или напряжения, второй - непосредственное получение значения. В таком случае мы не имеем возможности использовать функционал libzbxmodbus, т.к. попросту не cможем гарантировать правильную очередность запросов.

Первое и самое простое, что приходит на ум, - это создать скрипт, который сделает получение числового параметра атомарной операцией и воспользоваться возможностями внешних проверок Zabbix. Но такой скрипт тоже не позволит использовать загружаемый модуль libzbxmodbus по причине невозможности организации монопольного доступа к разделяемому ресурсу, в нашем случае к преобразователю последовательных интерфейсов.

В связи с вышесказанным, для этих целей было решено отказаться от использования libzbxmodbus и написать скрипт, который сможет предоставлять и числовые параметры РИП и состояния его ШС.

Пишем shell скрипт для внешней проверки

Для того, чтобы синхронизировать доступ к преобразователю последовательных интерфейсов, воспользуемся утилитой flock. Работу с Modbus будем осуществлять при помощи modpoll. В /usr/lib/zabbix/externalscripts создадим скрипт rip_12_mod_56.sh

#!/bin/bash# rip_12_mod_56.sh# $1 - protocol://host:port# $2 - Modbus UID# $3 - Status register# $4 - Offset (0 - 6)# Example of requesting statuses:       ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000# Example value request:                ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000 3(($# < 3)) && { printf '%s\n' "You have given little data. Command exited with non-zero"; exit 1; }lockfile=$(echo "$1" | awk -F "://" '{print $2}')setzone(){        modpoll -m $1 -a $4 -r 46181 -0 -1 -c 1 -p $3 $2 $5> /dev/null 2>&1    (($? != 0)) && { printf '%s\n' "Command exited with non-zero"; exit 1; }    sleep 0.15}getvalue (){        value=$(modpoll -m $1 -a $4 -r 46328 -0 -1 -c 1 -t 4:hex -p $3 $2 |grep ]: |awk '{print $2}')        printf "%d" $value}getstatus (){        status=$(modpoll -m $1 -a $4 -r $5 -1 -c 7 -t 4:hex -p $3 $2 | grep ]: | awk -F "0x" 'BEGIN { printf"["} NR!=7{printf "\""$2"\","} NR==7 {printf "\""$2"\""} END { printf "]"}')    echo "{ \"status\": $status }"}(        flock -e 200        protocol=$(echo $1 | awk -F "://" '{print $1}');        host=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $1}')        port=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $2}')        register=$(($3+1))        if (($# >= 4)); then                zone=$(($register+$4-40000))                setzone $protocol $host $port $2 $zone                echo $(getvalue $protocol $host $port $2)                sleep 0.15                exit 0        fi        echo $(getstatus $protocol $host $port $2 $register)        sleep 0.15;) 200> /tmp/$lockfile

Подробности настройки внешних проверок в Zabbix уточняйте в документации.

Создаем RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Для получения информации о состоянии ШС шаблон содержит элемент данных Request с типом "Внешняя проверка". Ключом элемента является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}]. Как и в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS, задача элемента Request - сформировать JSON с состояниями всех ШС.

Возвращаемый JSON оптимизирован для использования функционала JSONPath. Для упрощения скрипта значения возвращаются в шестнадцатеричной форме:

{  "status": ["98CB","C7FB","C3FB","CAFB","C8FB","C5FB","02FB"]}

Состояния ШС. Снова зависимые элементы данных.

Как и в предыдущем шаблоне, элемент данных Request имеет 7 зависимых элементов. Задача этих элементов тоже неизменна - распарсить JSON и получить состояние каждого ШС.

Получаем числовые значения

Для получения числовых значений создадим 5 элементов данных с типом "Внешняя проверка".

  • Uout_value - значение выходного напряжения, В.

  • Iout_value - значение выходного тока, А.

  • Ubat1_value - значение напряжения на батарее 1, В.

  • Ubat2_value - значение напряжения на батарее 2, В.

  • Uin_value -значение напряжения сети, В.

Ключом этих элементов является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}, <НОМЕР ШС>].

Триггеры

Перечень триггеров не отличается от триггеров, созданных в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED в картинкахШаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED в картинкахПоследние значения RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDEDПоследние значения RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED, rip_12_mod_56.sh.

Вместо заключения

В своем мониторинге мы используем шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. По-большому счету причина такого решения одна - расширяемость системы. Использование загружаемого модуля позволяет включать в одну линию приборы разных типов и модификаций, организовать их мониторинг стандартными средствами. Кроме этого, большой потребности в получении числовых значений у нас пока не возникало.

Однако, несмотря на все вышесказанное, возможность получения числовых значений тоже может оказаться востребованной. В этом случае можно задуматься об использовании в триггерах функций прогнозирования.

Спасибо за внимание!

Подробнее..

Zabbix OPC DA

25.05.2021 00:13:35 | Автор: admin

В последних релизах Zabbix "из коробки" стал поддерживать некоторые популярные протоколы промышленного оборудования. Имея поддержку Modbus и MQTT, его использование с системами промышленной автоматизации стало чуточку проще. Но подобный подход к мониторингу такого рода оборудования не всегда возможен.

Как правило, на предприятиях используется большое количество устройств промышленной автоматики разных лет и от разных производителей, поддерживающих разные протоколы обмена. OPC серверы являются универсальным инструментом обмена данными с такими устройствами. Информация на тему интеграции Zabbix и OPC DA в сети практически отсутствует. Возможно, мой небольшой опыт в этом направлении окажется полезен.

Для чего нам Zabbix

В нашем сценарии использования Zabbix последний не является заменой имеющейся SCADA-системе. Параллельное развертывание системы мониторинга позволит иметь возможность гибкой настройки триггеров и своевременного получения оповещений о нештатных ситуациях на оборудовании. Также мы сможем создавать дополнительные информационные панели с графиками, которые смогут давать быстрое представление о ходе тех. процессов.

Взаимодействие с OPC серверами

Самой сложной задачей, которая стоит перед нами, является организация взаимодействия с OPC-серверами. В ходе поисков готового решения такого взаимодействия стало понятно, что подходящих нам вариантов не так много. Из того, что было найдено, наиболее пригодным к использованию оказался консольный клиент OpenOPC.

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

Проверим работу утилиты. Для начала выведем в консоль список доступных OPC серверов:

C:\Users\Администратор> opc.exe -qMerz.OPC_SAIA_S-BUS.1C:\Users\Администратор>

Теперь попробуем получить теги в удобном нам формате - csv:

C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP.Register.OAT,197,Good,05/24/21 07:16:15C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP5.Register.T_inlet ATP5.Register.T_outletATP.Register.OAT,198,Good,05/24/21 07:16:41ATP5.Register.T_inlet,627,Good,05/24/21 07:16:41ATP5.Register.T_outlet,654,Good,05/24/21 07:16:41C:\Users\Администратор>

Если что-то пошло не так

В ходе экспериментов с opc.exe выяснились некоторые моменты. Первое: каждый OPC клиент запускал новую копию OPC сервера, а их параллельная работа невозможна. Так как запустить используемый нами OPC сервер как службу не получилось, то через DCOM был настроен запуск OPC сервера от определенного пользователя. Все OPC клиенты - SCADA и агент Zabbix - были также настроены на запуск от этого пользователя. Второе: выявлены некоторые недостатки в работе самого OpenOPC. Например, клиент не вычитывает теги, в названии которых присутствуют символы, отличающиеся от латинских. С этим пока пришлось смириться и решать такие проблемы путем переименования тегов в OPC сервере.

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

  • Ноst name - уникальное имя хоста, совпадающее с именем узла сети на Zabbix сервере.

  • Zabbix server IP/DNS - IP-адреса Zabbix сервера.

  • Server or Proxy for active checks - IP-адрес Zabbix сервера для активных проверок.

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

  1. Увеличено время выполнения скрипта.

    ### Option: Timeout#Spend no more than Timeout seconds on processing.## Mandatory: no# Range: 1-30# Default:# Timeout=3Timeout=30
    
  2. Создан параметр для мониторинга.

    #User-defined parameter to monitor. There can be several user-defined parameters.#Format: UserParameter=<key>,<shell command>## Mandatory: no# Default:# UserParameter=UserParameter=opc[*],opc.exe -o csv -s $1 $2
    

Узел сети и элементы данных на сервере Zabbix

На Zabbix сервере создадим узел сети. Имя узла сети должно совпадать с Ноst name, указанном при установке агента, интерфейс - IP-адрес агента.

Далее к созданному узлу сети добавим элемент данных c типом Zabbix агент (активный). Ключом должна являться конструкция типа: opc[<ИМЯ OPC СЕРВЕРА>, <ЗАПРАШИВАЕМЕ ТЕГИ ЧЕРЕЗ ПРОБЕЛ>].

Значениями элемента данных будут строки, разделенные запятыми:

ATP2.Register.OAT,273,Good,05/24/21 15:21:33ATP2.Register.GVS.T_inlet_W,501,Good,05/24/21 15:21:33ATP2.Register.GVS.T_outlet_W,445,Good,05/24/21 15:21:33ATP2.Register.T_outlet_w_com,404,Good,05/24/21 15:21:33ATP2.Register.RAD.T_outlet_W,256,Good,05/24/21 15:21:33ATP2.Register.P_in_W_com,39,Good,05/24/21 15:21:33ATP2.Register.P_out_W_com,36,Good,05/24/21 15:21:33ATP2.Register.RAD.P_outlet_W,43,Good,05/24/21 15:21:33ATP2.Register.FIRE.P_gidrant,68,Good,05/24/21 15:21:33

Зависимые элементы данных

Создадим зависимые элементы данных для того, чтобы распарсить CVS, полученный в самом элементе.

В предобработке используем JavaScript, который получит необходимую нам строку в CVS, проверит качество тега и вернет результат.

function (value){    var nr_line = 4;    var lines = value.split('\n');    var fields = lines[nr_line].split(',');    if(typeof fields[2] != "undefined" &&  fields[2] == "Good"){    return (typeof fields[1] != "undefined") ? fields[1] : null;    }    return null;}

Пример визуализации полученных данных:

Заключение

Теперь, когда данные от оборудования находятся в Zabbix, можно приступить к дальнейшей организации мониторинга: создание и обработка разнообразных триггеров, генерация графиков, отчетов и т. д.

Подробнее..

Вебинар Контроль качества технологии и технологической дисциплины

21.09.2020 16:09:27 | Автор: admin
image

Рады объявить о серии вебинаров посвященных контролю качества технологии и технологической дисциплины. Приглашаем всех желающих присоединиться к обсуждению во вторник, 6 октября в 11:00 по московскому времени.

Мониторинг металлообрабатывающего оборудования повышает эффективность его использования, сокращает время реагирования на незапланированные отключения или на условия, приводящие к выходу оборудования из строя, уменьшает простои и выявляет узкие места в производстве. Дополнительно, что еще более важно, мониторинг помогает качественнее проводить технологическую подготовку производства и данная серия вебинаров посвящена именно этому.

Данная серия вебинаров будет состоять из следующих блоков:


Вводная часть: IIoT для мониторинга
Как и чем Промышленный Интернет Вещей помогает технологам
Примеры реального использования IIoT-решения на отечественных предприятиях
Онлайн-подключение к действующему заводу
Q&A с лучшими в своем классе экспертами

Мероприятие ориентировано на руководителей предприятий, специалистов, отвечающих за подготовку производства, разработчиков УП, ИТ-директоров, директоров по цифровизации и развитию.

Вебинар для вас, если вы хотите:


Выпускать больше/качественнее благодаря современному подходу к подготовке производства
Увидеть места, где уместно пересмотреть и оптимизировать технологию
Сбалансировать выпуск за счет выравнивания производственных циклов
Узнать, как и где можно сократить время переналадок и смены инструмента
Получить автоматическую фотографию рабочего дня и актуализировать на ее основе нормы времени

Присоединяйтесь к нам, чтобы узнать о последних разработках в области Промышленного Интернета Вещей, онлайн мониторинга производства и практических способах повышения его эффективности.

Регистрация:

https://winnum.timepad.ru/event/1435934/
Подробнее..

Цифровой завод интерактивный цифровой двойник

12.10.2020 20:04:57 | Автор: admin

Цифровые двойники одна из популярнейших тем на сегодняшний день. Их часто рассматривают как панацею, призванную спасти производство и вывести его на качественно новый уровень. В данной статье мы расскажем о нашем опыте быстрого старта цифровизации производства, дающий ощутимые результаты в промышленном производстве.

Одна из наших ключевых целей при цифровизации производства обеспечить максимальную наглядность больших объемов данных с целью повышения оперативности принятия управленческих решений и увеличения мотивации у персонала. Идея цифрового двойника состоит в том, чтобы создать максимально точную цифровую версию физического объекта для дальнейшего анализа и диагностики, например, состояния оборудования и предотвращения его потенциальных поломок.

Тема цифрового двойника не новая, но с каждым годом она становится все популярнее благодаря новым решениям на рынке Интернета Вещей, которые выводят традиционное производство на новый конкурентоспособный уровень.

Цифровой двойник в нашем понимании трехмерный компьютерный прообраз какого-либо объекта реального мира, имеющий обратную связь от него. В качестве такого объекта может выступать, например, все промышленное предприятие с его производственными линиями, конкретный экземпляр изделия или отдельный технологический процесс. Концепцию цифрового двойника можно разделить на три части:

  • Физический объект;

  • Виртуальный объект;

  • Связь между двумя этими объектами.

Чем точнее цифровой двойник описывается в компьютерной среде, тем больше он соответствует своему реальному прототипу. При этом объем данных зачастую приводит к сложности восприятия информации и возможности ее использования только узким кругом потребителей, поэтому наглядность информации один из ключевых приоритетов для нас. Идеальный цифровой двойник может воспроизвести те же параметры, что и его физический аналог, что дает инженерам и другим пользователям возможность протестировать и смоделировать определенные условия, не причиняя реального ущерба физическому объекту.

Использование цифровых двойников может значительно улучшить существующие процессы работы производства и открыть новые возможности для бизнеса. В совокупности это приводит к сокращению эксплуатационных расходов и реальному увеличению чистой прибыли.

Интерактивный цифровой двойник базируется, в первую очередь, на информации, полученной в автоматизированном режиме от производственного оборудования и/или из информационных систем и статических источников данных (файлы и пр).

Для этого имеется набор программных коннекторов, поддерживающих все основные промышленные и проприетарные протоколы, а также механизмы для подключения к базам данных и ИТ системам. Автоматизация сбора данных это гарантия объективности информации и независимости от человеческого фактора.

Коннекторы передают информацию в специальное хранилище, расположенное обычно в локальной сети предприятия и построенное на технологиях NoSQL. Хранилище способно хранить любую информацию в неограниченных объемах для последующего формирования отчетов, создания BI системы, визуализации хода производственных процессов на интерактивном цифровом двойнике, диагностики оборудования, рассылки уведомлений при выходе процесса за установленные рамки и т.д. Ключевым преимуществом такого решения относительно классических СУБД является кратное ускорение обработки данных (обработка миллиардов записей в секунду) и значительно более экономное использование дискового пространства.

Это позволяет постоянно отслеживать такую важную информацию, как данные о состоянии оборудования и данные о потреблении энергии от производственных систем. В свою очередь, это дает возможность выполнять предиктивный анализ и профилактическое обслуживание для предотвращения простоев и оптимизации энергопотребления. Также полученные данные являются основной для разработки новых бизнес-моделей.

Использование интерактивного цифрового двойника, работающего на основе Big Data, начинается с его создания и обучения. При создании используются 3D модели, созданные в любых САПР, или геометрия, созданная непосредственно на платформе в 3D Editor. Степень детализации трехмерной сцены определяется автоматизируемыми процессами, при этом создается целый трехмерный мир с широким набором инструментов по работе со светом, текстурами, пользовательскими камерами, механизмом взаимодействия с объектами и т.п. Объекты, размещенные на 3D сцене, в свою очередь, связываются с сигналами и данными, хранимыми в хранилище и для каждого из них описываются сценарии поведения в зависимости от значений сигналов, включая изменение цвета, положения объекта или его компонентов, появление информационных сообщений и т.д.

В результате интерактивный цифровой двойник становится посредником между физическим изделием и важной информацией о нем. Он реализует полноценную обратную связь для производственного оборудования или продукции предприятия, находящихся на этапе эксплуатации, на основе передачи данных из физического в виртуальный мир. В дальнейшем интерактивный цифровой двойник выносится на цеховые и уличные ТВ для контроля достижения заданных показателей и используется на рабочих местах для визуализации технологических процессов и сравнения с результатами имитационного моделирования, выполненного в соответствующем программном обеспечении. Кроме этого, одним из распространенных способов использования цифровых двойников в нашей практике является их применение в диспетчерских и мониторинговых центрах для контроля производственных и вспомогательных процессов на экраны выносится информация по всем производственным переделам, логистике, инженерному оборудованию (кондиционирование и т.п.), микроклимату, техническому состоянию оборудования и др.

Как показывает опыт, предприятия при создании и использовании 3D цифровых двойников преследуют две основных цели:

  • Оперативность принятия управленческих решений;

  • Вовлеченность персонала и повышение мотивации.

Указанные цели достигаются, в первую очередь за счет простоты и наглядности представления информации, не требующих специальных навыков для понимания происходящего. Одним из наиболее ярких примеров в нашей практике стало увеличение загрузки производства (и, соответственно, выпуска продукции) на 5% в течение недели после начала использования интерактивного цифрового двойника при отсутствии каких-либо дополнительных организационных или технических мероприятий только за счет того, что информация о ходе производственного процесса стала максимально прозрачной и понятной для всех групп пользователей.

Сроки ввода в эксплуатацию интерактивных цифровых двойников занимают, в среднем, по нашему опыту, от 3 до 5 недель на цех, состоящий из 70-100 единиц разнообразного оборудования. Таким образом, технологии цифрового двойника дают возможность быстрого старта цифровизации производства с получением конкретных результатов в кратчайшие сроки.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru