Развитие в «1С:RCM Управление надежностью» инструментов для риск-ориентированного обслуживания оборудования

О развитии в системе «1С:RCM Управление надежностью» инструментов для риск-ориентированного обслуживания оборудования и активов предприятия — а именно, для создания оптимальной программы ТОиР и предсказания отказов оборудования с помощью модуля предиктивной аналитики — рассказывает Андрей Сериков, руководитель направления разработки «Деснол Софт».

«Интеллект» в программе

«1C:RCM Управление надежностью» — это система для формирования оптимальной по стоимости программы обслуживания, которая удовлетворяет требованиям надежности и учитывает данные предиктивной аналитики о возможных отказах оборудования.

В своем рассказе об 1С:ТОИР 2 КОРП я уже говорил, что цель компании «Деснол Софт» — улучшить культуру принятия эффективных управленческих решений в бизнесе. И показывал, как эта цель влияет на разработку наших продуктов. Еще затрагивал тему «умных» механизмов, которые прячут сложность процессов и данных за простым фасадом. Эти же темы помогут лучше понять пользу и назначение второго по важности решения в экосистеме решений для цифровизации ТОиР — «1С:RCM Управление надежностью».

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

Начнем с основного назначения системы.

Инструмент для RCM-анализа

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

Но почему именно он? Зачем потребовалась целая новая система для автоматизации какого-то там конкретного вида анализа?..

Предлагаю посмотреть на это с точки зрения «управленческих решений» в процессах.

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

  • планирование мероприятий (планово-предупредительные ремонты (ППР), регламентные мероприятия);
  • обеспечение этих мероприятий материалами и ресурсами (МТО и ресурсное планирование);
  • эффективное исполнение мероприятий (наряды на работы и акты о выполнении этапа работ);
  • реакции на неожиданные события (дефекты, предписания).

Этот процесс в целом понятен. Но! На предприятиях разное оборудование. А если и одинаковое, то разные условия эксплуатации. А если одинаковые сейчас, то могут измениться со временем. Возникает вопрос: как выстраивать эффективный процесс ТОиР и эффективно управлять им, реагируя на изменения ситуации?

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

Что у него будет на входе?

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

Что от него требуется на выходе?

  • оптимальная и обоснованная программа обслуживания, которая обеспечит нам требуемую надежность (т.е. это и есть описание того, каким должен быть эффективный процесс ТОиР для этого оборудования).

Какие инструменты можно использовать, чтобы работать с «будущим», ведь оно не определено?

  • Концепция рисков.
  • Рассматривать несколько вариантов с вероятностями.
  • Прогнозы и аппроксимации.

Такова наша ситуация, если мы хотим осознанно управлять нашими процессами ТОиР. Мы можем использовать что угодно, лишь бы это подходило нам в описанной нами «системе координат», в нашем «фреймворке» — использовало входы и давало, что нужно, на выходе.

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

  • «что может произойти?»
  • «какие причины могут это вызвать?»
  • «что можно сделать, чтобы этого не произошло?»
  • «что из этого мы выберем для обслуживания оборудования, чтобы его надежность была достаточной?»

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

В нашей версии получился процесс, состоящий из 4 этапов.

4 этапа процесса RCM-анализа и формирования оптимальной программы обслуживания оборудования

1. Подготовка данных для анализа

  • Формирование нормативно-справочной информации об объектах анализа.
  • Определение логических и функциональных моделей систем и подсистем.
  • Формирование структуры надежности.

Здесь решаются задачи загрузки данных из других систем — 1С:ТОИР 2 КОРП, 1С:ERP 2.5 и 2.4 или любой другой системы через универсальные загрузчики. Данные упорядочиваются, систематизируются и «обогащаются» экспертами.

2. Анализ отказов (FMEA/FMECA)

  • Определение списка объектов для проведения анализа.
  • Определение видов отказов и вероятности их возникновения.
  • Определение возможных последствий отказов и их тяжести.
  • Формирование матрицы оценки рисков.
  • Определение критичности отказов.
  • Определение параметров надежности.
  • Формирование отчетности.

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

  • рекомендации видов отказов из прошлых анализов, истории дефектов и прогнозов;
  • использование матрицы рисков для быстрой оценки последствий.
Отбор стратегий Отбор стратегий

Диаграмма решений по ГОСТ 27.606-2013 Диаграмма решений по ГОСТ 27.606-2013

Определение списка мероприятий Определение списка мероприятий

3. Формирование оптимальной программы ТОиР

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

Это второй по величине этап — мы также добавили сюда инструменты для помощи в принятии решений:

  • диаграммы решений;
  • просмотр влияния программы на матрице риска;
  • рабочее место для рационализации получившейся программы (удаления дубликатов мероприятий и определение оптимальной периодичности).
Анализ эффективности RCM мероприятий Анализ эффективности RCM-мероприятий

4. Анализ эффективности мероприятий

  • Анализ эффективности RCM-мероприятий.
  • Передача сформированной программы ТОиР на исполнение в систему управления ремонтами и обслуживанием (это, напомню, EAM- или ERP-система).
  • Корректировка исполняемой программы ТОиР.

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

В целом следует рассматривать систему 1C:RCM как каркас, который структурирует данные в области ТОиР и содержит инструменты для «процесса управления процессами ТОиР» — управления надежностью. В нем уже есть один штатный метод — RCM-анализ. Его можно использовать как есть или адаптировать, расширять и даже добавлять что-то совсем новое, но в рамках имеющихся данных.

Инструмент для предиктивного анализа

Как я уже отметил, процесс управления надежностью в нашем понимании смотрит в будущее, и одним из входов этого процесса являются прогнозы и аппроксимации. В 1С:RCM встроен инструмент для организации предиктивного анализа своего оборудования.

Этот инструмент состоит из двух больших частей, или «слоев».

  • Подсистема «Предиктивная аналитика».
  • Механизм поиска аномалий в данных с датчиков, установленных на оборудовании и постоянно диагностирующих его состояние.

Подсистема «Предиктивная аналитика»

1-й слой. Подсистема «Предиктивная аналитика» внутри 1C:RCM сделана из расчета работы почти с любыми поставщиками предиктивной аналитики.

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

  • прогнозу наступающего отказа;
  • прогнозу остаточного срока компонентов или узлов;
  • прогнозу значений производственных показателей;
  • детектированию аномалий в состоянии оборудования.

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

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

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

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

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

  • шаблоны оборудования с датчиками;
  • паттерны отклонений (диагностики);
  • рабочее место для разбора аномалий.

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

Система также пытается быть «умной» и сама подбирает подходящие виды отказов по введенным паттернам отклонений (диагностикам).

Графики оценок аномалий по датчикам Графики оценок аномалий по датчикам

Контроль прогнозов Контроль прогнозов

Механизм детектирования аномалий

А теперь 2-й слой. Это одна реализация механизма, который может поставлять данные в нашу подсистему предиктивной аналитики. Он основан на разработанном нами сервисе обнаружения аномалий в работе оборудования, из которого 1С:RCM может получать данные. Мы предлагаем его нашим клиентам, если нет желания заниматься разворачиванием инструмента у себя.

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

Механизм написан на языке Python и использует открытые библиотеки машинного обучения. С помощью библиотеки функциональных подсистем, разработанной фирмой 1С (сокращенно БФП), мы включили наш инструмент в коробку 1С:RCM.

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

  1. Подключить по инструкции расширение с предиктивной аналитикой.

  2. Средствами библиотеки БФП установить Python и необходимое окружение.

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

  4. Организовать по инструкции поступление текущих данных.

  5. Сделать настройки на стороне 1С:RCM:

  • загрузить из сервиса данные об объекте мониторинга (состав и описание датчиков);
  • ввести известные диагностики отказов (если таких сведений нет, можно начинать работать с чистого листа и собирать базу диагностик в процессе работы);
  • настроить расписание по загрузке аномалий;
  • назначить исполнителей для проведения анализа аномалий.

Система диагностирования аномалий

Как именно система диагностирования аномалий в показаниях датчиков помогает «предсказывать» отказы?

Важны три момента:

  • «предсказание» на основе состояния;
  • обнаружение не абсолютных, а относительных отклонений;
  • обнаружение заранее неизвестных аномалий.

«Предсказание» на основе состояния

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

По такому же принципу работает и наш механизм: аномалия — «низкое давление в шине», диагностика — «если давление в шине ниже положенного, то с вероятностью 90% через 5 часов произойдет повреждение корда».

Обнаружение не абсолютных, а относительных отклонений

Важно, что детектирование аномалий не сводится к проверке выхода за допустимые границы. Это умеет проверять любая АСУ ТП, и в 1С:ТОИР 2 КОРП есть система сигнализации о таких отклонениях.

Система умеет находить ситуации, когда с виду допустимое значение выглядит «подозрительно»: например, показатель «открытие заслонки» принимает значения от 0 до 100% и вообще не может «выйти за границы». Тем не менее, был реальный пример, когда по показаниям этого датчика можно было предотвратить отказ, — заслонка открывалась всё больше и больше, хотя не должна была.

Обнаружение заранее неизвестных аномалий

Системе не надо объяснять, «куда смотреть». Она сама сопоставляет все значения со всеми. Это позволит не пропускать даже то, о чем не подумали заранее. По такой аномалии нельзя будет автоматически сказать, к какому виду отказа она приведет (если не будет соответствующего паттерна в системе), но она будет отправлена специалисту на разбор. И он сможет внести данные в систему или отметить, что это было несущественно.

Все вышеперечисленные моменты — это уже даже не просто «умный» механизм, которые скрывает сложность. Это уже почти «интеллект» — который думает и старается помочь.

Поделиться: