Комментарии 24
В АСУТП можно реализовать, грубо говоря, 50% описанной диагностики сигналов с датчиков. И систему оповещения персонала.
В чем интеллект?
НЛО прилетело и опубликовало эту надпись здесь
По поводу ИИ — есть разные типы диагностических моделей применяемых в АСУ. Одна из них является моделью на нейросетях. В любом случае можно собрать оптимальную модель синтезированную из нескольких. Наличие или отсутствие нейросетки не является каким-то критическим — можно достаточно достоверно настроить эту же экспертную систему диагностики. Ну а мониторинг в реальном времени, это и есть часть системы диагностики.
Совершенно верно, что в целом проверки на нормативы (уставки) можно осуществлять на базе АСУТП. Но в рамках данной активности цель была построить аналитическую платформу для сбора, обработки, аналитики данных не для конкретного кейса, а для реализации большого количества кейсов, направленных на повышение эффективности производственного процесса. Конечно в рамках развития платформы в т.ч. кейса по диагностики датчиков возможно внедрения алгоритмов ИИ в т.ч. на базе нейросетей.
Также хороший вопрос зачем строить отдельное озеро данных, если можно внедрить алгоритмы в системы АСУТП? Аналитика предполагает с большими объемами «исторической» информации, как и для построения аналитической отчетности, так и для разработки математических моделей. Вот здесь начинается «самое» интересное – как показывает практика в производственной системе данные хранятся где-то за последние 3 месяца, что конечно крайне мало для обучения мат. моделей, да и в целом для возможностей аналитики работы оборудования. Также такие запросы дают большую нагрузку на систему – выполняются крайне «долго», возможно в целом негативное влияние на работу пользователей системы. В целом это справедливо для всех транзакционных систем, основная цель которых обеспечить оперативное управление производством.
Подводя итоги, когда есть цель внедрять аналитические инструменты, строить мат. модели на производственных данных (данные с датчиков и MES систем), объединять производственные данные с бизнес данными (в ERP системе – например, планы по производству, KPI и др.) для построения аналитической отчетности и тех мат. моделей и Вы хотите построить не 1 отчет и не 1 конкретную модель, а как минимум планируете сделать несколько десятков отчетов и моделей и хотите, чтоб это работало в режиме near real time то тогда к вам придет на помощь технологии бигдата и озера данных, которые специально созданы для решения таких задач, а возможность их горизонтального масштабирования позволит расширять скоуп решаемых задач (количество предметных областей для аналитики и соответственно количество и сложность используемых мат. моделей).
Также хороший вопрос зачем строить отдельное озеро данных, если можно внедрить алгоритмы в системы АСУТП? Аналитика предполагает с большими объемами «исторической» информации, как и для построения аналитической отчетности, так и для разработки математических моделей. Вот здесь начинается «самое» интересное – как показывает практика в производственной системе данные хранятся где-то за последние 3 месяца, что конечно крайне мало для обучения мат. моделей, да и в целом для возможностей аналитики работы оборудования. Также такие запросы дают большую нагрузку на систему – выполняются крайне «долго», возможно в целом негативное влияние на работу пользователей системы. В целом это справедливо для всех транзакционных систем, основная цель которых обеспечить оперативное управление производством.
Подводя итоги, когда есть цель внедрять аналитические инструменты, строить мат. модели на производственных данных (данные с датчиков и MES систем), объединять производственные данные с бизнес данными (в ERP системе – например, планы по производству, KPI и др.) для построения аналитической отчетности и тех мат. моделей и Вы хотите построить не 1 отчет и не 1 конкретную модель, а как минимум планируете сделать несколько десятков отчетов и моделей и хотите, чтоб это работало в режиме near real time то тогда к вам придет на помощь технологии бигдата и озера данных, которые специально созданы для решения таких задач, а возможность их горизонтального масштабирования позволит расширять скоуп решаемых задач (количество предметных областей для аналитики и соответственно количество и сложность используемых мат. моделей).
На фото же не атмосферы, правда?:)
Какое «железо» используется для сбора, передачи и обработки данных?
Угу, озёра для саентистов, бигдата, а столы и кабинет у диспетчеров лет 20 не ремонтировались и не менялись, кто-то себе коврик из куска линолеума вырезал.
Кружка на рабочем месте… им там видимо вобще на всё пофиг)))
Кружка на рабочем месте… им там видимо вобще на всё пофиг)))
Да как же «не ремонтировались», когда на полу отчётливо видны три плитки другого цвета, а к спинке стула примонтирована другая спинка?
на этой картинке эталонная диспетчерская, столы и у нас такие — дольше живут, чем деревяхи )
А хотелось бы, чтобы оборудование ставило целью не прожить подольше, а помочь работникам прожить подольше…
На этом фото всё ужасно — стол мало того, что железный, так ещё и очевидно на неудобной высоте.
Мелкие вразнобой установленные самые дешевые мониторы с плохими матрицами и без регулировок по высоте
То же с клавомышами — какие нашли
Отсутствие какого-либо приемлемого микроклимата в помещении, что иллюстрируется вентилятором и ужасным напольным кондиционером на заднем плане
Можно и продолжать, но зачем?
На этом фото всё ужасно — стол мало того, что железный, так ещё и очевидно на неудобной высоте.
Мелкие вразнобой установленные самые дешевые мониторы с плохими матрицами и без регулировок по высоте
То же с клавомышами — какие нашли
Отсутствие какого-либо приемлемого микроклимата в помещении, что иллюстрируется вентилятором и ужасным напольным кондиционером на заднем плане
Можно и продолжать, но зачем?
Если в помещении перепад температур, то дольше живут ламинированные столы или с гранитным покрытием, у нас например shop.hlr.ua/laboratornaya-mebel/laboratornye-stoly
Какая СУБД импользуется для хранения телеметрии, собранной с датчиков? Смотрели в сторону VictoriaMetrics? Она позволяет очень эффективно хранить и обрабатывать большие объемы телеметрии (десятки и сотни триллионов показаний с сотен миллионов датчиков).
Следующий шаг после построения модели производства или техпроцесса это выкидывание «лишних» и дорогих датчиков. Не, ну модель же есть, зависимости от параметров есть. Не надо нам два датчика давления на входе и выходе, достаточно иметь датчик на входе и матмодель трубы, которая вам давление на выходе пересчитает. Это реальная история. Мы через это проходили уже.
2 TB / год + требования по near realtime — точно ли стоит такое добро тащить в хадуп?
Навскидку кажется, что MPP-базы подошли бы лучше (Vertica / ClickHouse).
Ну и при определенной фантазии и в одну классическую реляционную БД можно уложиться, кажется.
Или это всё цифры по какому-то одному производству / тех.процессу и планируется их масштабирование на порядки?
Навскидку кажется, что MPP-базы подошли бы лучше (Vertica / ClickHouse).
Ну и при определенной фантазии и в одну классическую реляционную БД можно уложиться, кажется.
Или это всё цифры по какому-то одному производству / тех.процессу и планируется их масштабирование на порядки?
2TB это только для прототипа с 1 производственной площадки из 1 источника данных, это не целевая история (площадок и источников данных кратно больше). Хадуп был выбран в качестве платформы для масштабирования в будущем. А текущий кейс именно как пилотный.
Цель (с точки зрения техники) была сделать именно потоковую обработку данных, которая может горизонтально масштабироваться, а не использовать обработку в Batch режиме.
И мы такую обработку сделали на kafka + Spark streaming. В kafka именно попадает новое значение показателя с датчика.
Также в такой реализации есть возможность масштабировать функционально сами расчеты, так например в процессе реализации аналогичных потоковых кейсов у нас есть возможность настраивать расчетные показатели в виде формул, которые не требуют переписывания самого модуля расчетов.
По вертике — решение не из дешевых с точки зрения лицензирования, КликХауз мы на него активно сейчас смотрим и пилотируем, возможно будем применять для определенных кейсов.
Цель (с точки зрения техники) была сделать именно потоковую обработку данных, которая может горизонтально масштабироваться, а не использовать обработку в Batch режиме.
И мы такую обработку сделали на kafka + Spark streaming. В kafka именно попадает новое значение показателя с датчика.
Также в такой реализации есть возможность масштабировать функционально сами расчеты, так например в процессе реализации аналогичных потоковых кейсов у нас есть возможность настраивать расчетные показатели в виде формул, которые не требуют переписывания самого модуля расчетов.
По вертике — решение не из дешевых с точки зрения лицензирования, КликХауз мы на него активно сейчас смотрим и пилотируем, возможно будем применять для определенных кейсов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы искали неработающие датчики на «УРАЛХИМЕ» (первый проект Data Lake)