- PVSM.RU - https://www.pvsm.ru -
Привет! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.
Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.
По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.
Установка мониторинга требует модификации железа устройством передачи данных, самой передачи, какого-то озера данных для их накопления, разбора протоколов и среды обработки с возможностью всё посмотреть и сопоставить. Ну и с этим всем есть нюансы.
Банально дорого. Командировка для одного инженера — минимум 50 тысяч рублей (самолёт, гостиница, проживание, суточные). Плюс не всегда получается разорваться, и один и тот же человек может быть нужен в разных городах.
Проблема в том, что если поставщики более-менее понимают, что лог нужно постоянно писать куда-то (или поняли за последние несколько десятков лет), то дальше культура не пошла. Лог часто нужен для разбора случаев с дорогостоящим ремонтом — была ли это ошибка оператора или реальная поломка оборудования.
Чтобы забрать лог, часто нужно подойти физически к оборудованию, открыть какой-то кожух, обнажить сервисный разъём, подключить к нему кабель и забрать файлы данных. Потом упорно грепать их несколько часов, чтобы получить картину ситуации. Увы, но так происходит почти везде (ну либо у меня однобокая точка зрения, поскольку мы работаем как раз с теми производствами, где мониторинг только налаживается).
Наши основные клиенты — производители оборудования. Как правило, они начинают задумываться о том, что стоит как-то заняться мониторингом, либо после какого-то крупного инцидента, либо просто глядя на счета за командировки за год. Но чаще всё же речь идёт о крупном сбое с потерей денег или репутации. Прогрессивные руководители, которые задумываются о том, чтобы «как бы чего не случилось», редки. Дело в том, что обычно руководителю достаётся старый «парк» сервисных контрактов, а ставить датчики на новое железо он смысла не видит, потому что понадобится это только через пару лет.
В общем, в какой-то момент жареный петух всё же клюёт, и наступает время модификаций.
Сама по себе передача данных не очень страшна. На оборудовании обычно уже есть датчики (либо они довольно быстро ставятся), плюс уже пишутся логи и отмечаются сервисные события. Всё это нужно только начать отправлять. Общая практика — прямо в устройство от рентген-аппарата до автоматической сеялки вставляется какой-то модем, например, с embed-SIM, и отправляет телеметрию через сотовую сеть. Места, где сотового покрытия нет, как правило, находятся довольно далеко и в последние годы редки.
А дальше начинается тот же самый вопрос, что и раньше. Да, логи теперь есть. Но их нужно куда-то складывать и как-то их читать. В общем случае нужна какая-то система визуализации и разбора инцидентов.
И тут на сцене появляемся мы. Точнее, часто мы появляемся раньше, поскольку руководители поставщиков смотрят, как сделано у коллег, и сразу едут к нам советоваться по поводу подбора железа для отправки телеметрии.
На Западе путь решения такой ситуации сводится к трём вариантам: Siemens-экосистема (очень дорого, нужно для очень крупных узлов, как правило, типа турбин), самописные мандулы или кто-то из локальных интеграторов помогает. В итоге к приходу всего этого на российский рынок образовалась среда, где есть Siemens со своими кусками экосистемы, Amazon, Nokia и несколько локальных экосистем вроде разработок 1С.
Мы зашли на рынок как объединяющее звено, позволяющее собирать любые данные с любых устройств по любым (ладно, почти любым более-менее современным) протоколам, обрабатывать их вместе и показывать их человеку в любом требуемом виде: для этого у нас есть крутые SDK для всех сред разработки и визуальный конструктор пользовательских интерфейсов.
В итоге мы можем собрать все данные с устройства производителя, завести в хранилище на сервере и собрать там панель мониторинга с алертами.
Вот так это выглядит (здесь заказчик сделал ещё визуализацию предприятия, это несколько часов в интерфейсе):
И есть графики с оборудования:
Алерты выглядят так: на уровне станка, если превысили усилие на исполнительном органе или возникло столкновение, настраивается набор параметров, и система будет информировать отдел или ремонтные службы при выходе за них.
Ну и самое сложное — прогнозирование выхода из строя узлов по их состоянию для профилактики. Если понимать ресурс каждого из узлов, то можно сильно сократить расходы на тех контрактах, где идёт оплата за простой.
Эта история звучала бы довольно просто: ну поняли, что нужно отправлять данные, мониторинг и анализ, ну выбрали вендора и внедрили. Ну и всё, все счастливы. Если речь идёт про самописные системы на своём же заводе, то, как это ни странно, системы быстро становятся недостоверными. Речь идёт о банальной потере логов, неточных данных, сбоях в сборе, хранении и получении. Через год-два после установки начинают удалять старые логи, что тоже не всегда хорошо заканчивается. Хотя там практика — с одного станка за год собирается 10 Гб. Решается это на пять лет покупкой ещё одного жёсткого диска за 10 тысяч рублей… В какой-то момент выясняется, что первично не само передающее оборудование, а система, которая позволяет получаемые данные анализировать. Важно удобство интерфейса. Это вообще беда всех промышленных систем: быстро разобраться в ситуации не всегда просто. Важно, сколько данных видно в системе, количество параметров с узла, способность системы оперировать большим объёмом и количеством данных. Настройка дашбордов, встроенная модель самого устройства, редактор сцен (чтобы рисовать схемы размещения на производствах).
Давайте приведу пару примеров, что это даёт на практике.
Собственно, что я хотел сказать: сегодня с готовой платформой (например, нашей) настроить мониторинг можно очень быстро и просто. Для этого не нужны изменения в оборудовании (либо минимальные, если датчиков и передачи данных до сих пор нет), для этого не нужны затраты на внедрение и отдельные специалисты. Надо просто изучить вопрос, потратить пару дней на то, чтобы понять, как это работает, и несколько недель на согласования, договор и обмен данными про протоколы. И после этого у вас будут точные данные со всех устройств. И всё это можно делать по всей стране при поддержке интегратора Техносерва, то есть мы гарантируем хороший уровень надёжности, нехарактерный для стартапа.
В следующем посте я покажу, как это выглядит со стороны поставщика, на примере одного внедрения.
Автор: Winnum
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-danny-h/355932
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/514842/?utm_source=habrahabr&utm_medium=rss&utm_campaign=514842
Нажмите здесь для печати.