Система мониторинга работы оборудования

[Alex721]

Привет.
Предстоит реализовать следующую задачу.
Необходимо мониторить 30-50 единиц оборудования на два состояния (включено/отключено, в работе/не в работе)
Состояние в работе может меняться несколько раз в минуту.

Результатом мониторинга должны стать графики работы оборудования за сутки, месяц, год.
И подсчёт загрузки оборудования за сутки, месяц, год.

Помогите определиться с концепцией. Какими технологиями такое реализуется?
Пока думаю про два варианта:
1. В пользу простого ПЛК + Master Scada + MySql или другая БД.
Не знаю как скада работает с базами...

2. ПЛК+что-то, что сможет писать в БД. А оболочку сделать на PHP.

Вообщем, кто встречал подобные задачи - поделитесь опытом, как реализовывать?

[Jackson]

Привет.

Честно говоря, практически все тут постоянно сталкиваются с такими задачами и решают их успешно.
Как реализовать? Т.З. для начала составить. Без ТЗ результат - ХЗ.

Отправлено спустя 1 минуту 32 секунды:

А оболочку сделать на PHP.

Оригинально. Я бы даже сказал - инновационно.

[Никита]

Если есть большое желание пользовать продукцию инсата - поковыряйтесь с MasterOPC (до 32 тегов бесплатно). Там встроенный LUA и теоретически есть возможность писать в БД напрямую без всякой скады. На практике не пробовал.
ПЛК тоже не сильно нужен, если только для промежуточных архивов на случай обрыва связи или отказа ПК. А если эти данные не сильно критичны - достаточно просто модулей ввода.

[Serex]

Состояние в работе может меняться несколько раз в минуту.

Зависит от точности измерения. Продукты на базе OPC думаю дадут точность не выше секунды.
ПЛК в зависимости от модели - это точность порядка 1 мс.

[Alex721]

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

Если считать по максимуму, то одно устройство сможет генерировать до 86400 точек в сутки.
Допустим, ограничимся хранением логов на 3 месяца. Со 100 устройств это получится более 700 млн строк.

Никогда с такими данными не работал. Excel тоже такие объемы не потянет...

Возможно придется хранить суточные логи (как у Weintek), и потом вручную как-то компоновать.

Вообщем, пока присмотрюсь к возможностям Инсата.

[Jackson]

Никогда с такими данными не работал. Excel тоже такие объемы не потянет...

Excel - офисный продукт, а не промышленный.
Данные хранятся в БД. Настраиваете разбивку файлов БД чтобы не получалось гигантских файлов, и RAID соответствующего объёма, и всё будет ехать нормально.

У меня такое ощущение что Вы присматриваете подручные бесплатные средства для решения промышленной задачи. Тут подпилить, здесь прикрутить.... Забудьте. Промышленной задаче - промышленное решение.

Работа начинается с ТЗ.

[Alex721]

У меня такое ощущение что Вы присматриваете подручные бесплатные средства для решения промышленной задачи. Тут подпилить, здесь прикрутить.... Забудьте. Промышленной задаче - промышленное решение.

Работа начинается с ТЗ.

Речь не идет про бесплатные средства разработки.
Хочу услышать мнение профессионалов.

Из ответов понял, что идея с БД вполне себе годная.

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

[Jackson]

На счет ТЗ. В моей практике так складывается, что я, как разработчик, обычно сам же и пишу ТЗ.

Неважно кто его пишет. Важно чтобы оно было.

А хотелки заказчика я озвучил в стартовом сообщении

Эти хотелки ровно ни о чём не говорят.
Общую структуру уже озвучили неоднократно: сбор данных посредством модулей в/в и/или ПЛК. Складирование в БД. Отображение при помощи СКАДА.

Из ответов понял, что идея с БД вполне себе годная.

Других работающих "идей", вообще-то в АСУТП и нет.

[Jackson]

чтобы анализировать на предмет оптимизации загрузки оборудования.

Этот вопрос надо продумать отдельно. кто будет анализировать и как. На том же самом АРМе строить отчёты и тренды, или данные отдавать на сторону (на другой офисный компьютер). Ибо АРМ не должен находиться в общей сети предприятия, физически связи быть не должно, иначе это потянет за собой уйму проблем эксплуатации, не говоря о пром.безопасности. Об этом тут много писали.

Т.е. если данные надо уносить на офисный комп.начальнику - должен быть продуман механизм транспорта: либо экспорт прямо с АРМа на какой-то носитель (флешки на АРМе - зло), либо передача по какому-либо защищённому каналу через сетевые экраны (это дорого), либо ещё как-то (интернет на АРМе - мегазло). Это повлияет на выбор формата БД, СКАДА и на весь АРМ и/или сервер БД.

Отправлено спустя 2 часа 14 минут 6 секунд:
Поэтому нужно ТЗ. В котором будут оговорены и продуманы все подобные нюансы, указан подробный перечень оборудования с интерфейсами, требуемым объемом данных, периодом опроса, физическим расположением, требованиями к самому АРМу, к объему хранения данных, к способу представления и много чего ещё. Вот тогда можно будет что-то сказать наверняка, выбрать оборудование, прикинуть работы (трудозатраты ведь тоже денег стоят). А пока - общие принципы.

[Serex]

Почти все СКАДА системы работают с базами данных, на этом работают тренды и архив алармов. Элементарно положить данные в базу точно могут. Но не у каждой СКАДЫ есть удобные инструменты для работы с базой. А если аналитику по базе данных, то это точно за пределы любой СКАДА выходит.
Так что СКАДА - это как промежуточный буферный архив на короткий промежуток времени, а дальше какой-то софт, который вытаскивает из базы данных СКАДЫ данные, аналитически обрабатывает и складывает в результирующую базу, которую уже можно и начальнику на компе показать. Также решения на базе данных хорошо по сети передаются, в отличие от каких-нибудь OPC DA.

[bdeas]

Если Вы - не оборонка и не под санкциями, мы можем предложить Вам недорогое комплексное решение для малых и средних предприятий. Немецкая компания, на Российском рынке не давно. В Европе более 1000 внедрений. Если интересно - можем предоставить описание решения. Внедрение осуществляется либо нами непосредственно, либо нашим российским партером-интегратором IT-Consult

[Alex721]

Bdeas, в личку скиньте предложение.

[pike]

Результатом мониторинга должны стать графики работы оборудования за сутки, месяц, год.
И подсчёт загрузки оборудования за сутки, месяц, год.
Помогите определиться с концепцией. Какими технологиями такое реализуется?
Пока думаю про два варианта:
1. В пользу простого ПЛК + Master Scada + MySql или другая БД.
Не знаю как скада работает с базами...
2. ПЛК+что-то, что сможет писать в БД. А оболочку сделать на PHP.
Вообщем, кто встречал подобные задачи - поделитесь опытом, как реализовывать?

Задачу можно решить на панельном контроллере ESA EW100AB\AC https://www.cospa.ru/catalog/panelnye-kontrollery/ с удаленными или вх\вых.
С базами данных дружит на прямую, выгружать в базу можно как отдельные переменные так и целиком журнал событий и аварий, даталоги и другое.
По журналу событий и аварий есть объект статистики который за заданный период покажет сколько раз происходило событие и сколько оно было активно.
Учитывая озвученные объемы активный буфер (фактически загрузка ОЗУ) лучше рассчитывать на 4-8 часов и с такой же периодичностью забирать в базу.

[Alex721]

Я присматриваюсь к решению этой задачи на контроллере от Weintek, серия Cloud (не реклама, если что).
В последнем обновлении у них появился инструмент Диаграммы Ганнта.
Это как раз то, что я собирался выводить на экран.

Есть конечно и недостаток - VNC у них поддерживает только 3 одновременных подключения.

[pike]

Это не контроллер, а так называемый web-hmi (если о cmt идет речь). помочь в обработке такого кол-ва данных она вам не поможет.