Прогнозируемое обслуживание в первом мире: почему автоматизация обслуживания и дисциплина развертывания важных моделей

Система прогнозирующего технического обслуживания может выявлять усиление вибрации, необычные температурные режимы или сочетание сигналов, указывающих на вероятность отказа компонента. Это может показаться впечатляющим с технической точки зрения, но само по себе не сокращает время простоя.

Кто-то еще должен решить, насколько важен этот сигнал, насколько он срочный, какие действия следует предпринять и может ли оборудование безопасно продолжать работу в это время.

Самая сложная часть часто начинается после того, как модель уже сработала. Аналитический слой — это лишь одна часть системы.

Реальная оперативная ценность заключается в том, что происходит после обнаружения риска: как интерпретируется событие, кто его получает, как создается задача по техническому обслуживанию, что видит техник и используется ли полученная информация для принятия будущих решений.

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

Большинство дискуссий, посвященных предиктивному техническому обслуживанию, сосредоточены на точности модели, обнаружении аномалий, охвате датчиков и качестве исторических данных.

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

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

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

Таким образом, процесс технического обслуживания должен ответить на несколько вопросов, выходящих за рамки самой модели. Что именно произошло? Насколько это серьезно в контексте данного актива? Кто несет ответственность за реагирование? Что должно произойти дальше и как быстро?

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

Менее сложная модель, должным образом связанная с рабочими процессами сервисов, может оказаться более полезной на практике, чем более совершенная модель, результаты которой остаются изолированными от людей и систем, ответственных за их использование.

Контекст определяет, заслуживает ли оповещение каких-либо действий.

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

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

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

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

Рассмотрим два одинаковых насоса, демонстрирующих одинаковое увеличение вибрации. Один из них работает на производственной линии, где неожиданная остановка может остановить весь процесс.

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

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

Что еще более важно, они начинают терять доверие к самим оповещениям. Как только это происходит, к действительно важным предупреждениям можно относиться с тем же скептицизмом.

Не каждая аномалия должна перерасти в действие. Некоторые требуют немедленной реакции, за некоторыми следует наблюдать, а некоторые окажутся просто шумом. Различие между ними зависит от гораздо большего, чем просто оценка модели.

От прогнозирования к действию: недостающий уровень сервисов.

Когда событие становится достаточно серьезным, чтобы предпринять какие-либо действия, следующий вопрос становится более обыденным: куда оно может привести?

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

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

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

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

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

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

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

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

Различия обычно касаются непосредственно самого процесса эксплуатации. Одному производителю может потребоваться особый порядок обработки заявок для критически важных машин. Другой может направлять сервисные работы через существующую ERP-систему или систему выездного обслуживания.

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

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

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

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

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

Пороговые значения, логика оповещений, параметры встроенного программного обеспечения, конфигурации устройств и правила автоматизации — все это может влиять на поведение парка устройств и на частоту вызова сервисных бригад.

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

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

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

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

Внедрение может быть технически чистым, но при этом ухудшить ситуацию с техническим обслуживанием. Я бы следил за тем, действительно ли новая логика улучшит решения, принимаемые людьми в отношении оборудования.

Удалось ли выявлять значимые проблемы на более ранних этапах? Увеличилось ли количество ложных срабатываний? Начали ли технические специалисты получать больше работы, не обнаруживая больше неисправностей?

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

Рабочие процессы обслуживания должны соответствовать уже существующей операционной деятельности.

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

Как правило, целесообразнее интегрировать события, связанные с оборудованием, в инструменты и процедуры, которые люди уже используют.

Бригада технического обслуживания может работать в системе CMMS или на платформе выездного обслуживания, в то время как информация о клиентах и ​​договоры хранятся в системах CRM или ERP. В такой среде аномалия должна содержать достаточно контекста, чтобы стать частью существующего рабочего процесса.

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

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

Менеджера по обслуживанию волнуют серьезность проблемы, назначение задачи и соглашение об уровне обслуживания (SLA). Клиенту может потребоваться информация о запланированном техническом обслуживании, даже без доступа к внутренним диагностическим данным, лежащим в основе этого решения.

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

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

Правильная граница зависит от оборудования, последствий неверного решения и операционных процедур организации.

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

Никому не должно приходиться вручную восстанавливать событие с помощью нескольких разрозненных инструментов, прежде чем можно будет начать техническое обслуживание.

Такая повторяемость также меняет ассортимент продукции, которую могут продавать поставщики оборудования. Удаленный мониторинг, профилактическое техническое обслуживание или поддержка, ориентированная на бесперебойную работу, могут быть объединены в пакет услуг, предоставляемых постоянным клиентам и автопаркам.

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

Замыкание цикла после технического обслуживания

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

Подтвердилась ли предсказанная неисправность? Или же неисправности вообще не было? Действительно ли у оборудования была проблема, но по другой причине, нежели предполагала система? Это три совершенно разных результата, и они не должны сводиться к одному и тому же статусу «заявка закрыта».

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

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

Просто закрыть заявку недостаточно. Полезной записью должно быть то, что техник фактически обнаружил, какие работы были выполнены, какие компоненты были заменены, первопричина, если она известна, и исчезли ли впоследствии аномальные телеметрические данные.

Со временем эти записи показывают, где необходимо корректировать пороговые значения, где следует изменять процедуры технического обслуживания и когда обновление модели действительно оправдано. Они также позволяют легче определить, улучшает ли предиктивное техническое обслуживание результаты или просто создает дополнительную работу.

Без этой обратной связи система знает, что она предсказала, но не знает, привело ли это предсказание к правильному решению по техническому обслуживанию.

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

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

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

Полезный прогноз — это не просто точный прогноз. Он должен доходить до нужного человека или системы, вызывать соответствующую реакцию и оставлять достаточно доказательств, чтобы понять, действительно ли эта реакция сработала.
Источник