Релейная защита и автоматика > Системы автоматизации технологических процессов (АСУТП)
сервера АСУ, у себя или в облаке? выбор вариантов
shkiper:
теперь про грабли, на которые наступал
вообще общий совет при выборе решения для подобных систем, когда датчиков, счетчиков устанавливается сразу много, то на этапе "на берегу" поищите на форумах поддержки бренда темы про "медленный опрос большого количества датчиков", "ускорение опроса" и т.п.
потому-что есть проблема, особенно в системах ориентированных на "умный дом" или на подключение оборудования в котельной - большой нагрузки они не любят
когда ПЛК обрабатывает 20 параметров это одно, когда несколько тысяч это другое
обработка происходит в основном по протоколу Modbus, по интерфейсу RS-485
вы скажете - как же так, этот протокол и интерфейс как раз и были созданы для опроса множества датчиков
и таки да будете правы, даже не очень мощный ПЛК способен принять огромное число параметров Modbus
так в чем же дело?
дело в том, что при больших объемах информации которую надо запросить, принять, обработать и передать, нужны принципиально другие механизмы, чем при малых
при при опросе датчиков есть два варианта:
1) простой
2) правильный
в общем все как обычно :)
представьте вам нужно просто опросить датчик, мы обращаемся к ПЛК или к датчику, сначала передаем данные для установки подключения, потом запрос чего надо, потом та сторона ищет (если это ПЛК), потом передает этот кусок данных
если параметров немного, то это нормально, если их много, то становится грустно
вы начинаете искать решение, и т.к. вы не одиноки в этой ситуации, то на профильном форуме вам подскажут, что есть специальное ПО (библиотеки и т.п.), для того что-бы опрашивать датчики быстрее, т.е. за раз скачивать информацию большим куском по нескольким датчикам и разбирать ее на нужные куски при получении, в общем нырнуть с головой туда, куда не собирался и специально для этого покупал "готовое решение"
начнете возмущаться, а вам в ответ - "не мы такие, жисть такая", "без труда, не выловишь рыбку из пруда" и т.п.
вы начнете:
1) увеличивать скорость шины, а это сразу надо увеличивать ее на счетчиках и датчиках (т.е. например при замене, нельзя будет просто достать датчик или счетчик из коробки и послать монтажника, надо будет устройство сначала подключить, настроить)
2) настраивать тайм-ауты опроса везде где можно, а что значит таймаут в 20 секунд при опросе показаний тока или 20 секунд задержки на опрос состояние геркона?
начальник спросит: "почему система не среагировала когда дверь открыли?"
или не увидите скачок нагрузки
ваши оправдания приведут лишь к значительным репутационным потерям
начальник скажет: "купили систему за такие бабки, а она не работает как надо"
я на эти грабли наступил, решение было, но я его просто не тянул, сделал все по "простому", отложил на "потом"
хотя в моем случае проблема была наполовину решена на стороне ПЛК
суть проблемы - при больших объемах данных, эти данные получают не опросами по маленьким кусочкам, а потоком
если вы пытаетесь заместить поток кучей маленьких запросов, то вы огорчитесь результатом
например, вы смотрите IP TV, ваш телевизор не запрашивает каждый кадр у сервера, авторизуясь и устанавливая соединение каждый раз, сервер просто выдает видеопоток и ему по барабану принят он или нет и сколько там вообще клиентов - поток один широковещательный, вашему телевизору надо просто подписаться на него один раз в начале
и такие-же механизмы есть и для работы с датчиками
называется MQTT - очередь сообщений, суть в том что на ПЛК все принимаемые показания с датчиков сразу кидаются в поток и выставляются на IP порт (как фильм или сайт)
можно MQTT опрашивать и командой по отдельным параметрам, но это то сразу тормоза описанные выше
и я уж начал было огорчаться, когда понял, что нужно достаточно глубоко погружаться в программирование чтоб разобраться в этих делах
как вдруг пришла помощь "свыше", Zabbix объявил о поддержке MQTT в очередной версии, это решило проблему сразу, т.е. не нужно утомлять ПЛК миллионом запросов, не надо выставлять таймауты
при том что ПЛК прилично загружены и скорость по шине 9600, все данные теперь приходят сразу
пошла в рост нагрузка - сразу график пошел вверх, выбило автомат или открыли дверь - сразу отразилось в системе
пришлось переписывать все шаблоны на уже работающей системе
и появилось проблема куда девать все эти данные?
потому что столько много (по многим параметрам несколько раз в секунду прилетает) и не надо, приходится отсекать лишнее, но это уже решаемо
Навигация
Перейти к полной версии