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

Введение

MES (Manufacturing Execution System) — это цифровой диспетчер производства, который соединяет планирование с реальным производством. Если ERP говорит, что нужно сделать, то MES показывает, как именно это делать на заводе, собирая данные с оборудования и управляя процессами в режиме реального времени.

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

Описание проекта

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

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

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

В данном кейсе мы рассмотрим:

  • Архитектуру системы на базе микросервисов (Python, OpenCV, Redis, Linux)

  • Интеграцию с промышленным оборудованием (XRF-анализаторы, датчики, камеры)

  • Поэтапную реализацию: от видеоаналитики материалов до замкнутого контура автоматизации

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

  • Интеграцию компонентов и обеспечение бесперебойной передачи данных через Redis

  • Автоматизацию контроля множественных производственных процессов

  • Технические детали реализации каждого этапа производственного процесса

Этап 1. Видеоаналитика движущегося материала

схема работы видеоаналитики
схема работы видеоаналитики

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

Рядом с конвейерной лентой установлена камера (ВМ), задача которой — фиксировать изображение движущегося материала. Весь видеопоток поступает на виртуальную машину (VM-2), развёрнутую на базе Linux. Именно здесь запускается обработка: первым модулем в цепочке работает система видеоаналитики (ВА), реализованная на Python с использованием библиотеки OpenCV.

Техническая реализация видеоаналитики:

  • Python-скрипт анализирует геометрию насыпи и определяет высотный профиль материала

  • С учётом заданной плотности материала вычисляется масса проходящего сырья в килограммах

Интеграция с XRF-анализатором: Параллельно с видеоаналитикой система интегрируется с XRF-анализатором через консольное Windows-приложение. По нажатию клавиши "пробел" через заданное время например (10 секунд) делается скриншот экрана анализатора. OpenCV извлекает цифровые значения из изображения, после чего данные упаковываются в CSV-файлы и сохраняются в сетевую папку.

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

Этап 2. Передача данных через Redis и обработка в Connector

Схема работы передачи и хранении данных
Схема работы передачи и хранении данных

Дальше видеоаналитика передает результаты анализа одновременно в два направления: в Redis и в базу данных (DB). 

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

Автоматический мониторинг файлов: Отдельный модуль раз в минуту проверяет сетевую папку на появление новых CSV-файлов с данными анализа. При обнаружении новых файлов система автоматически их парсит и загружает данные на платформу для дальнейшей обработки.

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

Затем данные, временно хранящиеся в Redis, поступают в Connector — промежуточный модуль, отвечающий за передачу информации на платформу.

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

Таким образом, в базе данных формируются два типа данных:

  • первичные значения от видеоаналитики;

  • данные, подготовленные для передачи на платформу вычислений.

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

Этап 3. Замыкание контура автоматизации через Conundrum

схема передачи данных в conundrum
схема передачи данных в conundrum

После того как Connector передаёт эти данные на платформу (Conundrum), информация, полученная от видеоаналитики, сохраняется в (DB) для последующего использования при расчёте рекомендаций на следующий производственный цикл. 

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

Этап 4. Система мониторинга и визуализации данных

система мониторинга подачи воздуха
система мониторинга подачи воздуха

Мониторинг осуществляется через автоматизированное рабочее место (АРМ), которое представляет собой набор графиков и таблиц с показателями всех текущих процессов.

АРМ автоматически определяет: 

  • какой именно процесс происходит на том или ином оборудовании (с учётом фактических данных и рекомендаций),

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

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

  • данные видеоаналитики о начале и завершении загрузки в конвейер

  • данные о количестве воздуха, подаваемого в печь.

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

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

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

Таким образом, данные, зафиксированные камерой и обработанные видеоаналитикой, через цепочку Redis → Connector → систему управления превращаются в конкретное управляющее действие. Это замыкает цифровой контур автоматизации, в котором система не просто наблюдает за процессом, а активно им управляет.

Такая архитектура позволяет:

  • поддерживать стабильность технологических параметров,

  • оперативно реагировать на отклонения,

  • повысить качество продукции и энергоэффективность.

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

На первом этапе достигнуто:

  • Успешная интеграция всех компонентов микросервисной архитектуры

  • Стабильная работа системы видеоаналитики и обработки данных в режиме реального времени

  • Отладка замкнутого контура управления от измерения до исполнительных команд

  • Подтверждение технической осуществимости концепции заказчика

Результаты

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

Комментарии (8)


  1. Coder007
    19.07.2025 03:01

    А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".

    Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!


    1. joseph-cansas
      19.07.2025 03:01

      Про конвейерные весы я тоже подумал. Часть автоматизации описана очень плохо. Типовых схем нет. Я также не понял, что за датчик подаваемого воздуха и почему 3-4 секунды занимает процесс измерения. В хорошем КИПиА за это отвечает расходомер и измеряет он намного быстрее, чем 3-4 секунды. КИПиА часть и АСУТП часть очень мало раскрыты, а то, что есть вызывает много вопросов.


  1. pistoletov
    19.07.2025 03:01

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


    1. joseph-cansas
      19.07.2025 03:01

      Мне нравится открытость Вашего ума, желание понять логику и мотивы.

      Моё же мнение следующее. если это опасное или вредное производство (из текста это не понятно, но по смыслу должно быть хотя бы вредным), то у регуляторов могут быть какие-то свои требования (в Казахстане есть). И при наличии этих требований часто реализовать по-другому, кроме как ПЛК, SCADA, ПАЗ попросту нельзя. Большинство металлургических производств как минимум вредные. Если это вредное производство, + если у РФ есть к таким производствам требования то, вероятно, эта "автоматизация" не проходит по требованиям.

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


      1. pistoletov
        19.07.2025 03:01

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


  1. Ailuropoda_M
    19.07.2025 03:01

    А где заявленная в заголовке автоматизация производства? Вижу только один процесс и то - то что с ним сделали сложно назвать автоматизацией.


  1. AprilNvkz
    19.07.2025 03:01

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

    Конвейерные весы+ расходомер должны были решить проблему многократно дешевле и сильно точнее и надёжнее.

    Может, действительно, все сложнее. Но я говорю только на основе прочитанного.


  1. joseph-cansas
    19.07.2025 03:01

    У статьи есть ряд серьёзных проблем. Мы мало что знаем о самом процессе. Я понимаю, что раскрытие информации может быть запрещено заказчиком. Однако никто не может запретить дать хотя бы какую-то обобщенную информацию, не позволяющую идентифицировать заказчика. Хотя бы какой-то минимум, это пирометаллургия или гидрометаллургия. (дальше понятно, что это пирометаллургия, но это должно быть написано). Во введении нет части КИПиА, нет ничего про базы данных, например.

    мало что рассказано о "старых средствах" КИПиА и АСУТП. даже хотя бы в общем (я помню про возможный NDA).

    мало что знаем про ТЗ. Возможно, ТЗ дурканутое (типа засекать время в курилке, если люди сидят больше 10 минут включить распылители воды).

    АСУ ТП должны работать в реальном времени. Тема никак не раскрыта.

    "Python" - это не про надёжность, у него точно другая сфера применения, где ему почти нет конкурентов.

    Интеграция с XRF-анализатором: Параллельно с видеоаналитикой система интегрируется с XRF-анализатором через консольное Windows-приложение. По нажатию клавиши "пробел" через заданное время например (10 секунд) делается скриншот экрана анализатора. OpenCV извлекает цифровые значения из изображения, после чего данные упаковываются в CSV-файлы и сохраняются в сетевую папку.

    Я не знаю как это комментировать... Читать из скриншота...

    Автоматический мониторинг файлов: Отдельный модуль раз в минуту проверяет сетевую папку на появление новых CSV-файлов с данными анализа. При обнаружении новых файлов система автоматически их парсит и загружает данные на платформу для дальнейшей обработки.

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

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

    обычно это делается по-другому, состояние кнопок, переключателей, и/или контакторов через ПЛК.

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

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

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

    это не автоматизация. так не должно быть, всё должно быть на автомате.

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