Мониторинг производственного оборудования: как с этим дела в России

image

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.

Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.

По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.

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

Почему нельзя обойтись без удалённого мониторинга?


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

  • В России поставщик и потребитель почти всегда достаточно далеко находятся друг от друга. Когда вы продали изделие в Сибирь, вы ничего, кроме того, что вам скажет поставщик, о нём не знаете. Ни как оно работает, ни в каких условиях эксплуатируется, ни, собственно, кто там кривыми руками какую кнопку нажал — этой информации объективно у вас нет, вы её можете знать только со слов потребителя. Это очень усложняет обслуживание.
  • Необоснованные обращения и претензии. То есть ваш заказчик, эксплуатирующий ваше изделие, в любой момент может позвонить, написать, пожаловаться и сказать, что ваша штука не работает, она плохая, она сломалась, приезжайте срочно и чините. Если вам повезло и это не просто «не залили расходник», то вы не зря отправили специалиста. Часто бывает так, что полезная работа занимала меньше часа, а всё остальное — подготовка командировки, перелёты, проживание, — всё это потребовало кучу времени инженера.
  • Бывают явно необоснованные претензии, и, чтобы это доказать, нужно отправить инженера, составить акт, обратиться в суд. В результате этого процесс затягивается, и ничего хорошего ни для заказчика, ни для вас это вообще не несёт.
  • Споры возникают из-за того, что, например, заказчик неправильно эксплуатировал изделие, заказчик по каким-то причинам имеет на вас зуб и не говорит о том, что ваше изделие работало неправильно, не в тех режимах, которые заявлены в ТЗ и в паспорте. При этом противопоставить ему вы ничего не можете или можете, но с трудом, если, например, ваше изделие как-то ведёт логирование и запись тех режимов. Поломки по вине заказчика — это происходит вообще сплошь и рядом. У меня был случай, когда дорогущий немецкий портальный станок сломался из-за наезда на столб. Оператор не делал привязку к нулю, и в результате там станок встал. Причём заказчик совершенно чётко сказал: «А мы тут ни при чём». Но логировалась информация, и можно было эти логи поднять и понять, на какой управляющей программе и в результате чего произошёл этот самый наезд. Это спасло очень большие расходы поставщика в связи с гарантийным ремонтом.
  • Упомянутые «серые» схемы — сговор с сервисником. Сервисник ездит к заказчику постоянно один и тот же. Ему говорят: «Слушай, Коль, давай знаешь как сделаем: ты напишешь, что у нас тут всё поломалось, компенсацию получим, или привезёшь для ремонта какой-то зип. Мы всё это тихой сапой реализуем, деньги поделим». Остаётся либо верить, либо как-то измысливать какие-то сложные пути проверки этих всех умозаключений, подтверждений, что не прибавляет ни времени, ни нервов, и ничего хорошего в этом не происходит. Если вы знакомы с тем, как автосервисы борются с мошенничествами по гарантии и сколько сложностей это накладывает на процессы, то примерно понимаете проблему.

Ну так все же устройства пишут лог, правда? В чём проблема?


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

Чтобы забрать лог, часто нужно подойти физически к оборудованию, открыть какой-то кожух, обнажить сервисный разъём, подключить к нему кабель и забрать файлы данных. Потом упорно грепать их несколько часов, чтобы получить картину ситуации. Увы, но так происходит почти везде (ну либо у меня однобокая точка зрения, поскольку мы работаем как раз с теми производствами, где мониторинг только налаживается).

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

В общем, в какой-то момент жареный петух всё же клюёт, и наступает время модификаций.

Сама по себе передача данных не очень страшна. На оборудовании обычно уже есть датчики (либо они довольно быстро ставятся), плюс уже пишутся логи и отмечаются сервисные события. Всё это нужно только начать отправлять. Общая практика — прямо в устройство от рентген-аппарата до автоматической сеялки вставляется какой-то модем, например, с embed-SIM, и отправляет телеметрию через сотовую сеть. Места, где сотового покрытия нет, как правило, находятся довольно далеко и в последние годы редки.

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

image

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

Рыночная ниша


На Западе путь решения такой ситуации сводится к трём вариантам: Siemens-экосистема (очень дорого, нужно для очень крупных узлов, как правило, типа турбин), самописные мандулы или кто-то из локальных интеграторов помогает. В итоге к приходу всего этого на российский рынок образовалась среда, где есть Siemens со своими кусками экосистемы, Amazon, Nokia и несколько локальных экосистем вроде разработок 1С.

Мы зашли на рынок как объединяющее звено, позволяющее собирать любые данные с любых устройств по любым (ладно, почти любым более-менее современным) протоколам, обрабатывать их вместе и показывать их человеку в любом требуемом виде: для этого у нас есть крутые SDK для всех сред разработки и визуальный конструктор пользовательских интерфейсов.

В итоге мы можем собрать все данные с устройства производителя, завести в хранилище на сервере и собрать там панель мониторинга с алертами.

Вот так это выглядит (здесь заказчик сделал ещё визуализацию предприятия, это несколько часов в интерфейсе):

image

image

image

image

И есть графики с оборудования:

image

image

Алерты выглядят так: на уровне станка, если превысили усилие на исполнительном органе или возникло столкновение, настраивается набор параметров, и система будет информировать отдел или ремонтные службы при выходе за них.

Ну и самое сложное — прогнозирование выхода из строя узлов по их состоянию для профилактики. Если понимать ресурс каждого из узлов, то можно сильно сократить расходы на тех контрактах, где идёт оплата за простой.

Резюме


Эта история звучала бы довольно просто: ну поняли, что нужно отправлять данные, мониторинг и анализ, ну выбрали вендора и внедрили. Ну и всё, все счастливы. Если речь идёт про самописные системы на своём же заводе, то, как это ни странно, системы быстро становятся недостоверными. Речь идёт о банальной потере логов, неточных данных, сбоях в сборе, хранении и получении. Через год-два после установки начинают удалять старые логи, что тоже не всегда хорошо заканчивается. Хотя там практика — с одного станка за год собирается 10 Гб. Решается это на пять лет покупкой ещё одного жёсткого диска за 10 тысяч рублей… В какой-то момент выясняется, что первично не само передающее оборудование, а система, которая позволяет получаемые данные анализировать. Важно удобство интерфейса. Это вообще беда всех промышленных систем: быстро разобраться в ситуации не всегда просто. Важно, сколько данных видно в системе, количество параметров с узла, способность системы оперировать большим объёмом и количеством данных. Настройка дашбордов, встроенная модель самого устройства, редактор сцен (чтобы рисовать схемы размещения на производствах).

Давайте приведу пару примеров, что это даёт на практике.

  1. Вот глобальная компания-производитель промышленного холодильного оборудования, используемого в основном в торговых сетях. 10 % дохода компании приносит оказание сервисных услуг по обслуживанию своей продукции. Нужно сократить себестоимость сервисных услуг и вообще дать возможность нормально увеличивать поставки, потому что, если продавать больше, то имеющаяся система сервисного обслуживания не справится. Подключились напрямую к платформе единого сервисного центра, модифицировали пару модулей для нужд именно этого заказчика, получили снижение командировочных расходов на 35 % за счёт того, что доступ к сервисной информации предоставляет возможность выявлять причины выхода из строя без выезда сервисного инженера. Анализ данных за длительные интервалы времени — прогнозировать техническое состояние и при необходимости быстро выполнять обслуживание «по состоянию». В качестве бонуса увеличилась скорость реакции на запрос: выездов стало меньше, инженеры стали успевать быстрее.
  2. Машиностроительная компания, производитель электрического транспорта, используемого во многих городах РФ и СНГ. Как и все, они хотят сократить расходы и при этом прогнозировать техсостояние троллейбусного и трамвайного парков города, чтобы вовремя уведомлять техперсонал. Подключили, создали алгоритмы сбора и передачи технических данных от подвижного состава в единый ситуационный центр (алгоритмы встраиваются непосредственно в систему управления приводами и работают с данными CAN-шины). Удалённый доступ к данным о техническом состоянии, включая доступ в реальном времени к изменяющимся параметрам (скорость, напряжение, передача рекуперированной энергии и др.) в режиме «осциллографа», дали доступ к удалённому обновлению прошивки. Результат — снижение командировочных расходов на 50 %: прямой доступ к сервисной информации предоставляет возможность выявлять причины выхода из строя без выезда сервисного инженера, а анализ данных за длительные интервалы времени — прогнозировать техническое состояние и при необходимости быстро выполнять обслуживание «по состоянию», включая объективный анализ нештатных ситуаций. Реализация контрактов расширенного жизненного цикла в полном соответствии с требованиями Заказчика и в установленные сроки. Соответствие требованиям Технического задания эксплуатанта, а также предоставление ему новых возможностей в части контроля характеристик потребительского сервиса (качество кондиционирования, разгон/торможение и т. п.).
  3. Третий пример — муниципалитет. Нужно экономить электричество и повышать безопасность граждан. Подключили единую платформу для контроля, управления и сбора данных о подключённом уличном освещении, удалённое управление всей инфраструктурой общественного освещения и обслуживание его с единой панели управления, обеспечивающее решение следующих задач. Фичи: затемнение или включение/выключение освещения дистанционно, индивидуально или в группе, автоматическое уведомление городских служб о сбоях в точках освещения для более эффективного планирования ТО, предоставление в реальном времени данных о потреблении энергии, предоставление мощных аналитических инструментов для мониторинга и улучшения системы уличного освещения на основе Big Data, предоставление данных о трафике, состоянии воздуха, интеграция с другими подсистемами «Умного города». Результаты — сокращение расхода электроэнергии на уличное освещение до 80 %, повышение безопасности для жителей за счёт использования интеллектуальных алгоритмов управления освещением (человек идёт по улице — включить ему свет, человек на переходе — включить ярче освещение, чтобы его было заметно издалека), обеспечение города дополнительными сервисами (зарядка электромобилей, предоставление рекламного контента, видеонаблюдение и пр.).

Собственно, что я хотел сказать: сегодня с готовой платформой (например, нашей) настроить мониторинг можно очень быстро и просто. Для этого не нужны изменения в оборудовании (либо минимальные, если датчиков и передачи данных до сих пор нет), для этого не нужны затраты на внедрение и отдельные специалисты. Надо просто изучить вопрос, потратить пару дней на то, чтобы понять, как это работает, и несколько недель на согласования, договор и обмен данными про протоколы. И после этого у вас будут точные данные со всех устройств. И всё это можно делать по всей стране при поддержке интегратора Техносерва, то есть мы гарантируем хороший уровень надёжности, нехарактерный для стартапа.

В следующем посте я покажу, как это выглядит со стороны поставщика, на примере одного внедрения.
Техносерв
Компания

Комментарии 28

  • НЛО прилетело и опубликовало эту надпись здесь
      0
      Вы только ПО для сбора телеметрии занимаетесь, которое установлено на оборудовании вендра, или поставляете ПО + «железо»?
        0
        Мы разрабатываем и поставляем ПО для сбора телеметрических данных с оборудования оборудованного plc, а также поставляем собственный блок winnum hardware для подключения к оборудованию, не имеющему plc.
          0

          Доброго дня. Уже больше 10 лет мы занимаемся практическим внедрением мониторинга инженерного оборудования на существующих объектах. Занимаем нишу от "ввода" до "передачи данных" (оборудование распределения электроэнергии, ИБП, ДГА, приточная и вытяжная вентиляция, кондиционирования и другое оборудование). ПО — адаптированный Zabbix в котором убрано лишнее и добавлена поддержка протоколов. В том числе предлагаем своё контрольное, измерительные и конверторы интересов, типа RS-485-Ethernet в

          0
          Мое мнение, что лучше использовать «самописные системы», и подбирать их объем заранее, чем лить служебную инфу на сторону. А зачем Вам хранить долгосрочный лог, не вижу смысла, максимум месяц (это полный лог). Там Вы все-равно ничего полезного не найдете. А вот наработку или счетчик пиковых нагрузок лучше выводить в БД. По ней и смотреть и прогнозировать.
          ИМХО в данной ситуации лог нужен только для того что бы найти виновника какой-либо ситуации, а тут как раз должны помочь алерты. Если не найти виновника в течении пары дней, то зачем вообще ставить подобный мониторинг?
          Почему хранение локально — не доверяю никому, кроме себя )))
          • НЛО прилетело и опубликовало эту надпись здесь
              +1
              А зачем Вам хранить долгосрочный лог, не вижу смысла, максимум месяц (это полный лог).

              Потому что годовой лог — это бесценная информация как минимум для двух вещей:
              Во-первых, аналитики по плавно изменяющимся параметрам, когда процент выработки падает на 0.01% в день, а колбасит его в тот же день на +-1%, и только сглаженный годовой график покажет вам хоть что-то похожее на реальные -3%.
              Во-вторых, для анализа отклонений: за год работы вы сможете увидеть все нормальные отклонения параметров и понять на основе их границы, когда параметры становятся ненормальными. Сделаете это на данных за месяц — в следующем месяце вас разбудят ночью по тревоге, потому что параметр вышел за уставки. Ничего страшного не произошло, режим штатный, просто в прошлом месяце, на которой вы ориентировались при создании уставок, колебания были меньше. И хорошо если просто вас разбудят ночью по тревоге, а не производство экстренно встанет на сутки с соответствующими счетами за простой.
              0
              А чем ваша система отличается от других таких же SCADA, коих тысячи, от действительно Siemens, до тех, которые работают на любом Айфоне с такой же визуализацией?
                +2
                Вы статью-то читали? Это не SCADA, это система мониторинга в режиме логгирования.
                  0
                  Т. е. у вас упрощенная SCADA, без режима управления, только мониторинг и логи.
                    0
                    Нет, это не «упрощенная скада», равно как и телефон — это не упрощенный компьютер, без клавиатуры. Это именно система с функциями ретроспективного анализа, ее задача не управлять в реальном времени, а наблюдать за текущими и историческими показаниями.
                    Ну и не у меня, я не имею отношения к компании.
                      0
                      Ну не знаю, как-то не очень понятно насчет ретроспективного анализа. А на картинках какие-то трубы с насосами, шкалы с графиками — ну SCADA же… Я вот себе на Айфон тоже трубы с вентилями нарисовал, расход холодной и горячей воды вывел — это у меня тоже система ретроспективного анализа получилась?
                        0
                        Вы ээээ… точно понимаете, что такое ретроспективный анализ и что там делает часть «ретро»?
                          0
                          Не точно, поэтому и интересуюсь. А если я посмотрю на Айфоне расход горячей воды за прошлый и позапрошлый месяц и сделаю вывод, что надо бы поменьше мыться — это будет ретроспективным анализом?
                            0
                            Ну, если сделаете инструмент, который будет хранить историю всех параметров с возможностью смотреть их значения в произвольное время, то да, что-то похожее будет.
                              0
                              Понятно. Это делать не надо, сервер исторических данных и так есть в каждой первой SCADA. Раньше это было обычно в виде программы для мощного физического компьютера, сейчас это может быть и облачное решение.
                                0
                                Видел я эти «сервера исторических данных». Заходишь в элемент управления и там табличка по часам. Формально — есть. Реально — пользоваться можно с трудом.
                                Если вы сталкивались с анализом телеметрии после нештатной ситуации, то там табличками обойтись нельзя: нужна возможность видеть всю систему в виде слепка на определенный момент времени, и возможность «проигрывать» телеметрию туда-сюда.
                                Для нормальной работы не хватает даже инструмента уровня grafana, которая умирает на 200+ графиках на одном экране.
                                  0

                                  Ну, может быть, мне не приходилось работать с 200+ графиками в каких-то сложных инструментах. Обычно хватало экспорта нужного периода из базы в Эксель, а уж в Экселе данные можно спокойно покрутить, повертеть, наложить графики и т. п.

                0
                Вот интереснее как Вы выбираете тип системы диагностики. То есть, как я вижу Вы применяете систему на нейросети, но у нее есть свои плюсы и минусы, интересен критерий оценки, почему лучше она, а не, например, метод графов…
                  0
                  Платформа хранит и анализирует данные за большой промежуток времени. Эти данные могут использоваться пользователями в приложениях на базе собственных диагностических алгоритмов, либо путем написания шаблонов на языке Java, которые динамически инкапсулируются в Winnum и могут циклично выполняться.
                    +1

                    Ну извините, но алгоритмы классифицируются, если подходить академически… Да реализацию их вы пишете сами, но они относятся к определенному классу) Потому и вопрос не про реализацию — там не суть важно какой язык программирования, а про выбор класса системы диагностики...

                  0
                  круговые шкалы и графики очень «красивые»
                  чем ваше упрощенное 3д лучше схемы с показателями?
                    0
                    Лучше, когда есть и «технологическая схема» с живыми показателями, и 3д отображение. Это по собственному опыту работы. 3Д нагляднее и позволяет быстрее донести ситуацию до широкого круга причастных — начиная от руководителей среднего звена и заканчивая сантехником из дежурной смены.
                    +1
                    Ваша система работает с эксплуатационной моделью здания / цифровым двойником полностью или основная цель — работа с технологией производства?
                      0
                      Платформа Winnum способна интегрироваться с ЭИМ объекта посредством общей среды данных или заменить ее в части систем мониторинга технического состояния оборудования, управления документацией и эксплуатации активов.
                      0
                      Где можно посмотреть демо-версию? Онлайн или скачать.
                        0
                        У нас нет демо-версии, к сожалению, но можно приобрести пилотную версию с полноценным функционалом. Пилотный проект устанавливается бесплатно. А покупка лицензии (продукта) оплачивается единожды.
                        0
                        Что значит «приобрести пилотную версию с полноценным функционалом»? Купить? Сколько стоит?
                        Что такое пилотный проект? Кто его делает?
                        Хотелось бы оценить (попробовать) возможности платформы. На сайте нет никакой информации по платформе. Я имею в виду не рекламную, а техническую информацию. Например, как подключить какое либо устройство (оборудование) по протоколу Modbus, OPC UA или MQTT, как настроить мнемосхему и т.п.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое