Исключить аварийные остановки на производстве и прогнозировать время, когда агрегаты нуждаются в ремонте, – команде ЕВРАЗа удалось достичь обе цели. Для этого на агломерационной фабрике внедрили автоматизированную систему, причем не отличающуюся особой сложностью. Как она работает, расскажу я, Python Backend разработчик компании Ольга Седова.
Для тех, кто не посвящен в горно-металлургическое производство, начну с короткого пояснения. Эксгаустер, конечно, не фантастическая тварь, но сходство есть: это большой агрегат, который помогает высасывать из сырья – агломерата – пыль, мелкие частицы, чтобы этот агломерат хорошо пропекся – так он станет более ценным топливом для доменных печей.
Что нам дано? Три агломашины, на каждой — по два эксгаустера. В устройстве эксгаустера есть ротор. У ротора возникают дефекты. Сколы и трещины на его лопатках создают дисбаланс в его работе. Износ ротора — самая частая причина, по которой работу эксгаустера приходилось останавливать. А это внеплановый ремонт, простои, словом, ощутимые экономические потери. Мониторинг агрегатов, конечно, велся, и попытки прогнозировать необходимость ремонта тоже были. Но в ручном режиме, в Excel. Этим процессам для большей точности и быстроты требовалась автоматизация.
Наша команда разработала систему, которая позволила полностью исключить внеплановые простои и вполовину сократить расходы на ремонт.
Каждой цели – свои данные
Эксгаустеры оборудованы датчиками, с которых снимаются показатели. На входе их было 854. Это данные о работе двигателя, собственно ротора, обеспечении маслом, положении различных задвижек и т.д. Все они информативны и важны для мониторинга состояния агрегатов. Однако для прогнозирования времени, когда требуется замена ротора, оказалось достаточным учитывать 36 из них. Вдобавок к этому данные собираются посекундно, а мы установили, что для достижения наших целей достаточно, чтобы система обрабатывала показатели поминутно.
Чтобы определить данные, значимые для прогнозирования, мы проанализировали различные факторы, которые могут влиять на состояние эксгаустеров: оборудование, персонал, среда, технологии, материалы, методы. Выяснилось, что наибольшее значение имеют вибрации. Любой дефект ротора — скол, трещина — создает дисбаланс в работе его лопаток, а подшипники, находящиеся в непосредственной близости к ротору, на это реагируют и сигнализируют нам, что есть неполадка. Вибрации на подшипниках различают горизонтальные, вертикальные, осевые. Рост этих вибраций линейный и довольно медленный, именно поэтому поминутный анализ данных оказался достаточен для точного прогноза износа ротора.
Для определения конкретной даты замены ротора мы также учитываем качественные показатели. Рост вибраций, возникновение ударов, достижение предупредительной уставки (то есть верхней границы параметра) — все это фиксируется и ведет к снижению прогноза до 7, 3 и даже 1 суток до требуемой замены ротора.
На этих данных строится работа двух ключевых компонентов нашей системы — прогнозной модели (Predictive Model) и подсказчика (Advisor). Модель прогнозирует дату выхода ротора из строя по 36 показателям датчиков — в горизонте 14 дней. Подсказчик анализирует все 854 показателя и формирует уведомления и рекомендации для персонала.
Фронтенд многоэкранный
Пользователь системы видит главный экран. На нем отображены все три агломашины с шестью эксгаустерами. По каждому указаны дата последней замены ротора и прогноз для следующей замены — в сутках, а также показатели состояния разных частей (узлов) агрегата, в том числе подшипников: вибрация, температура, уровень и давление масла. На экране предусмотрена цветовая индикация: достижение предупредительной уставки выделяется желтым, аварийной уставки — красным.
Вообще пользователю доступно множество экранов. Помимо главного, на отдельном экране можно посмотреть мнемосхему каждого эксгаустера и подробно ознакомиться с показаниями датчиков по месту их расположения. Тут тоже есть цветовая индикация: проблемные места подсвечиваются оранжевым, предупредительные и аварийные уставки — красным.
Подсказчик своевременно направляет уведомления о том, на что обратить внимание, и рекомендации — что следует делать. Проблемы ранжированы, есть сформированный список уведомлений и рекомендаций — в сумме их 30 типов. Например: «Повышенная температура масла перед охладителем», «Превышение тока ротора. Вызвать оперативный персонал». Актуальные уведомления на экране подсвечиваются красным, чтобы выделить их из потока сообщений. Все это помогает делать ремонты плановыми и избегать аварийных простоев.
Также есть возможность строить графики для визуального отображения показателей в динамике. Допустим, так можно сравнить работу узлов, если обнаруживается какая‑то закономерность, а корректировка позволит продлить срок службы ротора.
Бэкенд через события
Система включает три сети. В технологической сети собираются показатели с датчиков и хранятся на сервере ibaPDA. Бэкенд реализован в двух следующих: сети MES DMZ и корпоративной сети. В MES DMZ расположен продюсер, который подключается к ibaHD, забирает показатели и передает их в Kafka с помощью протокола потоковой передачи данных gRPC.
Уже из шины передачи данных Kafka в корпоративной сети консьюмер забирает показатели датчиков, кладет в базу данных, одновременно отправляет их в прогнозную модель (для расчета срока износа роторов) и в API для отображения на Фронтенде, чтобы на экране у пользователя были актуальные сведения о состоянии агрегатов. Вместе с этим через брокер сообщений RabbitMQ данные направляются в подсказчик, который анализирует их и по мере необходимости выдает уведомления, рекомендации.
В системе специально используются два брокера сообщений, которые отличаются по принципу хранения сообщений, топологии, модели проектирования и производительности.
Kafka нужен нам для внешнего взаимодействия. Это удобный инструмент для хранения большого массива данных и построения ETL процессов, так как возможно повторное прочтение сообщений разными группами консьюмеров. Только для получения исходных данных достаточно топологии Publish/Subscribe, которую использует Kafka, когда отправляет сообщения в соответствующие топики, которые далее потребляют пользователи в разных авторизованных группах. Плюс к этому Kafka реализует модель «тупой брокер/умный консьюмер»: этот инструмент не отслеживает сообщения, которые прочитал каждый пользователь, а запоминает только непрочитанные сообщения, сохраняя их в течение установленного времени, а консьюмеры должны самостоятельно следить за своей позицией в каждом журнале. Наконец, производительность Kafka – один миллион сообщений в секунду. То есть обработка и анализ данных ведутся в реальном времени.
RabbitMQ применяется для внутреннего взаимодействия: общения с прогнозной моделью и подсказчиком, оперативной доставки уведомлений на Фронтенд. Этот инструмент удаляет сообщения из очереди после их обработки и подтверждения, что удобно для передачи уведомлений на Фронтенд (RabbitMQ поддерживает протокол STOMP). Сообщение исчезает из топика по мере его прочитывания. По топологии: сообщения отправляются на обмен и только затем рассылаются в различные привязки очередей – такая сложная маршрутизация выгодна для построения событийной архитектуры. Модель проектирования у RabbitMQ иная – «умный брокер/тупой консьюмер»: брокер последовательно доставляет сообщения консьюмерам и отслеживает их статус. Пропускная способность – до 10 тысяч сообщений в секунду, и этого достаточно для процессов внутри.
RabbitMQ создает связку между компонентами системы. На этом инструменте построена событийная архитектура. Генерируют события ETL компонент (при поступлении новых данных), прогнозная модель (по итогу своей работы), подсказчик (формируя уведомления), а также сам пользователь (при совершении определенных действий). Решаются две ключевые задачи: доставка данных до подсказчика и до UI. Для подсказчика действуют три очереди: повторяющиеся события (как правило, это превышение уставок), одиночные (например, запуск и остановка агломашины) и системные (действия пользователя, например, замена ротора). Для UI очереди недекларируемые: они определяются числом активных пользователей системы в данный момент времени.
Чтобы оптимизировать учет событий, мы ввели счетчик, который фиксирует время первого появления события, количество повторов и время его окончания. Например, «повышенная температура масла перед охладителем» – при поминутной фиксации показателей таких уведомлений в системе будет довольно много.
Такой автоматизированный мониторинг пользовательской активности и работоспособности обеспечивает надежную работу системы.
Когда проще – лучше
О стеке разработки. В основе у нас Python. Брокеры Kafka и RabbitMQ — для взаимодействия с базой данных. SQLAlchemy и alembic — для миграции БД. pydantic — для валидации данных. В целом классический набор для разработки на Python.
Стоит отметить gevent — для работы с неблокирующим вводом/выводом. Выбрали его, а не asyncio, так как работать с ним сильно проще, это удобный инструмент. Он использует концепцию «зеленых потоков», с ним не нужны ключевые слова (async/await), можно запатчить любые драйвера, написанные на Python.
Также выделю библиотеку Kombu — она предоставляет высокоуровневый интерфейс для работы с AMQP, расширенным протоколом очереди сообщений, и дает нам абстракцию над брокерами. Мы пользуемся абстракцией не task (задача как таковая), а event. В нашей системе появляются event‑ы вместо асинхронной задачи. Такой подход оставляет больше свободы.
Для работы с http применяем быстрый, легкий в освоении микрофреймворк Falcon, который не дает свою инверсию контроля, ее мы можем выстроить самостоятельно. Вместе со всем этим мы используем свои внутренние библиотеки, которые в совокупности формируют собственный фреймворк.
В основе нашей разработки гексагональная архитектура, где отдельно выделяется слой приложения, отвечающий за логику, слой адаптеров, отвечающий за взаимодействие с внешними системами. Это вкратце.
Наша разработка не отличается особой сложностью, в ней не задействованы нейросети. Она как раз показывает, что в производстве и сравнительно простые решения могут давать необходимый экономический эффект. Создание системы прогнозного обслуживания эксгаустеров — так она называется — заняло у нас порядка восьми месяцев, даже меньший срок, чем планировалось. Этот опыт подтверждает, что не всегда нужно стремиться к сложности, можно и с помощью простого решения достичь целей при соблюдении нескольких условий. А именно:
— есть хорошо проработанное ТЗ;
— выстроен приоритет задач;
— налажена хорошая коммуникация в команде;
— есть необходимая инфраструктура (чтобы реализовать систему на уровне n+1, нужно реализовать систему уровня n);
— есть понимание, что главное не метод.
Процитирую здесь своего коллегу Андрея Зубкова: «Любой метод начинает работать, если его системно и последовательно применять».
