Как устроена промышленная видеоаналитика на заводах СИБУРа

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

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

Ограничения промышленной среды

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

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

Архитектура пайплайнов и обработка кадров

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

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

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

Масштабирование и управление нагрузкой

Объединение сотен камер в единый сервис позволило внедрить динамическое управление частотой кадров (FPS). Для задач, где состояние меняется медленно — например, проверка уровня жидкости в колбе, которая может колебаться раз в час, — постоянный анализ 30 кадров в секунду избыточен. Система использует легкий детектор-наблюдатель, который проверяет изображение с низкой частотой.

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

Разделение компонентов и гибкая настройка

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

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