Релейная защита и автоматика > Системы автоматизации технологических процессов (АСУТП)
сервера АСУ, у себя или в облаке? выбор вариантов
shkiper:
предлагаю обсудить общие вопросы возникающие при принятии решения по организации вопросов про сервера, облака и т.п.
AlexZhuk:
Давненько к нам Artem_ASU не заходил. Уже целый месяц. Наверное, это его темы.
Я тут как раз сейчас работаю с более приземленной тематикой, но связанной с облачным сервером OWEN Cloud. С его помощью можно настроить общение с любым устройством этой фирмы, имеющим RS-485, используя специальное устройство - шлюз. В фильме "Устройство управляющее многофункциональное ПР200" этот шлюз на первых кадрах мелькает, с антеннкой Wi-Fi.
Так вот, мое мнение...
Облачный сервер это хорошо. Но там, где есть устойчивый интернет. И работать он сможет только с теми величинами, по которым надо принимать мгновенные решения. Например, не дай Бог там PID-регулятор какой-нибудь запрограммировать. Данные приходят с опозданием. А если мы говорим о серьезных системах, то местами реакция на ситуацию должна быть мгновенной.
А в остальном - почему бы и нет, если вам надо управлять чем-то с мобильного телефона, то облако реальный выход.
Пы.Сы. озвучивается мнение дилетанта в данном вопросе.
shkiper:
--- Цитата: AlexZhuk от 25 Март 2021, 22:11:25 ---Давненько к нам 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 скажу, поддержка у них на высоте, помогали не раз
Навигация
Перейти к полной версии