сервера АСУ, у себя или в облаке? выбор вариантов

[shkiper]

предлагаю обсудить общие вопросы возникающие при принятии решения по организации вопросов про сервера, облака и т.п.

[AlexZhuk]

Давненько к нам Artem_ASU не заходил. Уже целый месяц. Наверное, это его темы.
Я тут как раз сейчас работаю с более приземленной тематикой, но связанной с облачным сервером OWEN Cloud. С его помощью можно настроить общение с любым устройством этой фирмы, имеющим RS-485, используя специальное устройство - шлюз. В фильме "Устройство управляющее многофункциональное ПР200" этот шлюз на первых кадрах мелькает, с антеннкой Wi-Fi.
Так вот, мое мнение...
Облачный сервер это хорошо. Но там, где есть устойчивый интернет. И работать он сможет только с теми величинами, по которым надо принимать мгновенные решения. Например, не дай Бог там PID-регулятор какой-нибудь запрограммировать. Данные приходят с опозданием. А если мы говорим о серьезных системах, то местами реакция на ситуацию должна быть мгновенной.
А в остальном - почему бы и нет, если вам надо управлять чем-то с мобильного телефона, то облако реальный выход.
Пы.Сы. озвучивается мнение дилетанта в данном вопросе.

[shkiper]

Давненько к нам Artem_ASU не заходил. Уже целый месяц. Наверное, это его темы.
Я тут как раз сейчас работаю с более приземленной тематикой, но связанной с облачным сервером OWEN Cloud. С его помощью можно настроить общение с любым устройством этой фирмы, имеющим RS-485, используя специальное устройство - шлюз. В фильме "Устройство управляющее многофункциональное ПР200" этот шлюз на первых кадрах мелькает, с антеннкой Wi-Fi.
Так вот, мое мнение...
Облачный сервер это хорошо. Но там, где есть устойчивый интернет. И работать он сможет только с теми величинами, по которым надо принимать мгновенные решения. Например, не дай Бог там PID-регулятор какой-нибудь запрограммировать. Данные приходят с опозданием. А если мы говорим о серьезных системах, то местами реакция на ситуацию должна быть мгновенной.
А в остальном - почему бы и нет, если вам надо управлять чем-то с мобильного телефона, то облако реальный выход.
Пы.Сы. озвучивается мнение дилетанта в данном вопросе.

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

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

2) практики, люди уже имеющие опыт работы с Owen и т.п., собирают щиты с ПЛК, умные дома, зачем нужны эти облака им тоже не совсем понятно, ну раз оно идет вместе с Owen, и есть бесплатный функционал, то можно попробовать

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

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

а вот касательно применения облаков в АСКУЭ и АСУТП, тут другие расклады
здесь надо принять решение, размещать мониторинг у себя или пользоваться облаком?
это надо сделать с точек зрения и тех. специалистов, и руководителя
а для руководителя это черный ящик (и с облаками, и без), и он например смотрит - "а как у всех"?
например бух. учет нынче все чаще пользуют в облаке, виртуальные АТС популярны
и предлагаемые здесь преимущества по сравнению с вариантом размещения серверов у себя аналогичные:
1) экономия на ресурсах - не надо покупать железо и разворачивать свою инфраструктуру
2) девиз всех модных экспертов - "все непрофильные активы в аутсорсинг!", всю работу по обеспечению функционала на себя берет облако, вам не нужны эти непонятные парни, которые чего-то там настраивают

недостатки тоже понятны:
1) это привязка к одному производителю, все датчики и прочее оборудование должны быть одной фирмы или совместимы
2) проблемы с тех. поддержкой, особенно если объект в регионе
3) скорость и возможность подключения новых узлов, если для этого надо платить, то сначала надо доказать директору, потом оплатить ...

а бывает, что надо собрать схему на "попробывать", и не ясно - будет ли у нее дальнейшее развитие
в общем тоже есть о чем подумать

представлю вариант компоновки для локального "облака", как я его вижу
нам понадобятся: железо, ПО и специалисты
сначала выберем железо
и сразу возникает вопрос, а как будет с надежностью и отказоустойчивостью в нашем самопальном "облаке", чем это будет обеспечиваться?
и я вам так скажу - это очень хороший вопрос!
вот его надо обязательно задавать на первых беседах про облака

сначала нам нужен сервер, он должен быть надежный и отказоустойчивый
отказоустойчивость, в компьютерной всей теме обеспечивается методами дублирования узких мест
т.е. логикой организации системы, само железо конечно тоже добавляет (говорят - 5% примерно, и если наши сервера будут новые за 1 млн. руб. и более каждый - это тоже очень хорошо )
например два блока питания в сервере или поставили второй жесткий диск, объединили два диска в "зеркало" и у нас уже дисковая система надежна - выход одного диска из строя не влечет потерю данных
но сервер собранный таким образом получится очень дорогим и все равно будет не надежен, поэтому просто возьмем хороший комп (или недорогой сервер) и продублируем его вторым таким же (как что там будет конкретно дублироваться разберем позже), обеспечим сервера современными твердотельными дисками
и подключим к нашей системе мониторинга и сервера тоже
целых два сервера, надо их подпереть бесперебойником, самый разумный вариант купить ИБП типа "онлайн" (с двойным преобразованием), он позволит в случае потери электропитания, обеспечить работу от бытового бензо-генератора, практически неограниченное время (мощности онлайн ИБП 3000 ВА с режимом "конвертера", т.е. поддержание частоты 50 Гц на выходе, достаточно для обеспечения работы пары серверов и 5 компьютеров )
для возможности подключения к ИБП нескольких компьютеров по сети и мониторинга его состояния поставим в него сетевой модуль и так же подключим к мониторингу
этого в плане железа, вполне достаточно

теперь про ПО, нам понадобится:
1) Операционная система для серверов
2) сервер мониторинга
3) схема архивации

один важный момент, установка рабочего сервера (сервера мониторинга в нашем случае) непосредственно на железный сервер это "шарман и моветон", так уже не делается
гораздо разумней использовать виртуальные сервера, т.е. сервер как бы есть, но физически он представляет файл на жестком диске
в таком виде он гораздо мобильней (его можно легко архивировать или перенести на другой компьютер), он не привязан к конкретному железу,  ни к ОС железного хоста, ни к конфигурации программ на нем, т.е. этот момент тоже влияет на надежность
например, мы настраиваем сервер мониторинга и сохраняем его копию на втором сервере
и в случае чего, вуаля - наш бронепоезд стоит на запасном пути
а с данными как, копия сервера, устареет уже к тому времени?
вот мы плавно подошли  к вопросу архивации
вообще это замечательный проверочный вопрос, на тот случай если вас агитируют перейти на какое-нибудь облако
узнать кот с вами говорит, человек который реально что-то понимает или просто менеджер?
задать вопрос:
- а как у вас происходить обеспечение отказоустойчивости данных и в частности - архивация, при условии, что сервис (доступ к данным) должен функционировать круглосуточно, в режиме 24/7?

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

ну а если у вас, сервер месте с данными занимает немного места, и раз в неделю его можно и остановить на 5 минут, то можно и совсем просто, без изысков - автоматизировать процесс создания архива всего сервера сразу, вместе с данными  и запускать архивацию по расписанию

ну вот и все, осталось выбрать вариант ОС для серверов и ПО сервера мониторинга
это может быть платный проприетарный вариант, так и бесплатное свободное ПО
выбор за вами

ах да, надо еще парней найти, которые все это настроят
продолжу, чуть позже

и как подключать все наши датчики и ПЛК к нашему серверу тоже придумаем, это в принципе самый простой вопрос

[shkiper]

выбираем ПО, оно бывает двух видов:
1) Платное
2) Бесплатное

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

[shkiper]

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

причем что-бы рассчитать мощность на новом месте, надо сначала ее подсчитать на старом, т.к. там "исторически сложившаяся" ситуация - три ввода, никакого мониторинга (хотя попытка была, на одном шкафу в ВРУ, на боковине несколько шт Меркуриев-230, руководитель рассказал, что была попытка на их основе сделать учет, но "не взлетело")
нагрузка круглосуточная и в течении суток цикличная, для заявки на новом месте нужна была пиковая мощность за сутки
я к тому времени выбирал между Овен и Wiren Board, предложил как-раз проверить оборудование - купить небольшой комплект от WB: ПЛК, счетчик и накладные ТТ
и проверить его на подсчете суточного потребления на каждом из вводов
купили, проверили, в общем понравилось
сразу заработало, для простых задач в наличии простые начальные настройки через веб-интерфейс, подключение через wi-fi
очень понравился счетчик и накладные ТТ
сам ПЛК показался слабоват для промышленного применения, а его веб интерфейс однозначно не пригоден для этого
я в начале писал, что в это направление приходят разные люди, так вот, что касается категории "компьютерных людей", то они падки именно на WB
потому что это открытое ПО, Линукс, возможность устанавливать на ПЛК любое ПО
в общем поставил я на данном бренде свой "одобрямс"

и сделал вывод, что перед большим проектом собрать схему и испытать ее - самому посмотреть и руководству показать, очень полезно

в общем с приборами учетом определился
общую схему системы решил делать по схеме: датчик (счетчик) - ПЛК - сервер мониторинга

в качестве сервера  мониторинга который будет собирать информацию со всех ПЛК (их получилось не один) и отображать пользователям в нужном виде - Zabbix
это бесплатная, популярная система
учитывать решили всю нагрузку:
- по вводам (их по плану на новом месте тоже 3 шт)
- нагрузку распределения - по каждому РЩ, на которые идет кабель из ВРУ
- нагрузку по производству - некоторое оборудование по которому надо отслеживать режим работы (в комплексе с мониторингом других параметров)

т.е. счетчиков много (3-х фазные 4-х канальные счетчики от WB как раз в тему) и они разнесены в пространстве
одного ПЛК недостаточно, взял сразу два
нагрузка на них оказалась сразу приличная - по 3-4 4-х канальных счетчика на каждый (в стандартном шаблоне один 4-х канальный счетчик передает 340 параметров на ПЛК, а еще к ним же кроме счетчиков  подключаются и другие датчики), предположение что ПЛК слабоваты подтвердилось практикой
шаблон поставил попроще (Basic), там 180 параметров на счетчик
в общем, в случае с WB, 4 4-х канальных счетчика это предел для контроллера (это в сумме 16 3-х фазных линий), больше уже совсем тяжко ему будет

кроме мониторинга энерго-потребления, поставил модули вводов на ПЛК, и подключил к ним сигнальные контакты почти всех автоматов в ВРУ и многих в РЩ, а также гергоны на:
- входную дверь в ВРУ
- двери шкафов в ВРУ
- двери некоторых РЩ

герконы на дверях, это вообще очень полезная вещь, как оказалось

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

[shkiper]

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

потому-что есть проблема, особенно в системах ориентированных на "умный дом" или на подключение оборудования в котельной - большой нагрузки они не любят
когда ПЛК обрабатывает 20 параметров это одно, когда несколько тысяч это другое
обработка происходит в основном по протоколу Modbus, по интерфейсу RS-485

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

при при опросе датчиков есть два варианта:
1) простой
2) правильный

в общем все как обычно

представьте вам нужно просто опросить датчик, мы обращаемся к ПЛК или к датчику, сначала передаем данные для установки подключения, потом запрос чего надо, потом та сторона ищет (если это ПЛК), потом передает этот кусок данных
если параметров немного, то это нормально, если их много, то становится грустно
вы начинаете искать решение, и т.к. вы не одиноки в этой ситуации, то на профильном форуме вам подскажут, что есть специальное ПО (библиотеки и т.п.), для того что-бы опрашивать датчики быстрее, т.е. за раз скачивать информацию большим куском по нескольким датчикам и разбирать ее на нужные куски при получении, в общем нырнуть с головой туда, куда не собирался и специально для этого покупал "готовое решение"
начнете возмущаться, а вам в ответ - "не мы такие, жисть такая", "без труда, не выловишь рыбку из пруда" и т.п.
вы начнете:
1) увеличивать скорость шины, а это сразу надо увеличивать ее на счетчиках и датчиках (т.е. например при замене, нельзя будет просто достать датчик или счетчик из коробки и послать монтажника, надо будет устройство сначала подключить, настроить)
2) настраивать тайм-ауты опроса везде где можно, а что значит таймаут в 20 секунд при опросе показаний тока или 20 секунд задержки на опрос состояние геркона?

начальник спросит: "почему система не среагировала когда дверь открыли?"
или не увидите скачок нагрузки
ваши оправдания приведут лишь к значительным репутационным потерям
начальник скажет: "купили систему за такие бабки, а она не работает как надо"

я на эти грабли наступил, решение было, но я его просто не тянул, сделал все по "простому", отложил на "потом"
хотя в моем случае проблема была наполовину решена на стороне ПЛК

суть проблемы - при больших объемах данных, эти данные получают не опросами по маленьким кусочкам, а потоком
если вы пытаетесь заместить поток кучей маленьких запросов, то вы огорчитесь результатом
например, вы смотрите IP TV, ваш телевизор не запрашивает каждый кадр у сервера, авторизуясь и устанавливая соединение каждый раз, сервер просто выдает видеопоток и ему по барабану принят он или нет и сколько там вообще клиентов - поток один широковещательный, вашему телевизору надо просто подписаться на него один раз в начале

и такие-же механизмы есть и для работы с датчиками
называется MQTT - очередь сообщений, суть в том что на ПЛК все принимаемые показания с датчиков сразу кидаются в поток и выставляются на IP порт (как фильм или сайт)
можно MQTT опрашивать и командой по отдельным параметрам, но это то сразу тормоза описанные выше
и я уж начал было огорчаться, когда понял, что нужно достаточно глубоко погружаться в программирование чтоб разобраться в этих делах
как вдруг пришла помощь "свыше", Zabbix объявил о поддержке MQTT в очередной версии, это решило проблему сразу, т.е. не нужно утомлять ПЛК миллионом запросов, не надо выставлять таймауты
при том что ПЛК прилично загружены и скорость по шине 9600, все данные теперь приходят сразу
пошла в рост нагрузка - сразу график пошел вверх, выбило автомат или открыли дверь - сразу отразилось в системе
пришлось переписывать все шаблоны на уже работающей системе
и появилось проблема куда девать все эти данные?
потому что столько много (по многим параметрам несколько раз в секунду прилетает) и не надо, приходится отсекать лишнее, но это уже решаемо