← Все статьи

Компрессорная станция без «ручного шаманства»: как данные предприятия превращаются в режим

18 октября 2026 6 мин чтения
Нагнетатель компрессорной станции на трубопроводе и график давления над ним

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

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

Из чего состоит стоимость режима

  • Топливный газ на привод газотурбинных агрегатов (на электроприводных агрегатах это электроэнергия).
  • Электроэнергия аппаратов воздушного охлаждения газа. Её доля заметно зависит от сезона.
  • Ресурс. Часы наработки в неблагоприятных режимах, пусковые циклы, термоциклирование.
  • Риск. Запас до границы помпажа и вероятность внепланового останова.

Самый экономичный режим не всегда самый безопасный. Поэтому задача ставится не как «минимум топлива», а как минимум затрат при заданной подаче и допустимом запасе по устойчивости.

Данные, которые уже есть, и что с ними не так

Почти всё необходимое на станции уже собирается.

  • Телеметрия агрегатов: давления и температуры на входе и выходе нагнетателя, обороты, расход топливного газа, вибрация, температуры подшипников. Это ряды с разной частотой опроса.
  • Газодинамические характеристики. Паспортные карты нагнетателей. Реальные характеристики со временем сдвигаются из-за загрязнения проточной части и износа.
  • Журналы: ТОиР (промывки, ремонты, замены), события диспетчера, акты по отказам.
  • Регламенты и инструкции диспетчера и персонала станции.

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

Сначала карта, потом расчёты

Мы начинаем со смыслового слоя: дерево «станция, цех, агрегат, нагнетатель, датчик». У каждого показателя карточка: единицы, тип значения (мгновенное или накопленное по счётчику), источник, формула для расчётных. Без карточки показатель в расчёт не попадает. Эта дисциплина знакома тем, кто видел работающую платформу на demo.alfarabi.ai: там по такому же принципу разобрана финансовая отчётность, и именно эта механика переносится на технологические данные.

Что считает код

Всё, что можно посчитать по физике, считается кодом, а не моделью.

  • Степень повышения давления ε = Pвых / Pвх и приведённые к стандартным условиям обороты и расход.
  • Положение рабочей точки относительно границы помпажа. Запас по помпажу в процентах: (Qраб − Qпомп) / Qраб × 100 при тех же приведённых оборотах.
  • Фактический КПД нагнетателя по замерам в сравнении с паспортным. Его динамика показывает, насколько проточная часть деградировала.
  • Удельный расход топливного газа с нормировкой на температуру воздуха и загрузку.
  • Баланс по участку: приход минус расход равен накоплению в трубе плюс небаланс. Растущий небаланс — повод проверить измерения или искать утечку.

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

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

Выбор режима: оптимизатор и исследователь

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

  1. Гипотезы. «Почему на этой неделе вырос удельный расход топливного газа: загрязнение проточной части, другой состав газа, иная загрузка, ошибка измерения?» Платформа строит план исследования, технолог его утверждает, затем каждая гипотеза проверяется на своих данных.
  2. Объяснение. Рекомендация приходит с обоснованием: рабочая точка агрегата ушла из зоны высокого КПД, при переходе на другую схему запас по помпажу сохраняется, вот расчёт.
  3. Сценарии «что если». Как изменится расход топлива и запас при росте подачи на столько-то или при выводе агрегата в ремонт.

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

Слабые сигналы: аномалии и прогноз отказов

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

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

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

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

Утечки и нештатные режимы

Классический подход — баланс по участку и анализ волн давления. Данные предприятия добавляют контекст: плановые переключения кранов, ремонтные работы, изменение схемы. Благодаря ему система не принимает запланированное действие за утечку и не пугает диспетчера зря.

Наставник диспетчера

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

Как выглядит пилот

  1. Один объект. Берём одну станцию или цех, а не всю сеть.
  2. Карта данных (2–4 недели). Описываем показатели, находим дыры и дрейфы, договариваемся о ключах между системами.
  3. Проверка на истории. Какие решения предложил бы советчик в прошлых периодах? Сравниваем с тем, что реально делала смена и к чему это привело.
  4. Режим совета на смене. Фиксируем рекомендации и решения диспетчера, разбираем расхождения.
  5. Показатели результата: удельный расход топливного газа (с нормировкой на условия), число срабатываний противопомпажной защиты, доля принятых рекомендаций, время реакции на аномалию.

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

Что из этого можно потрогать уже сейчас

Механика «дерево показателей, расчёты кодом, план гипотез с согласованием, проверка чисел» работает в платформе demo.alfarabi.ai. Сегодня она анализирует финансовые данные, а на технологические мы её переносим: это основной фокус нашей разработки. Если на вашей станции есть вопрос, на который хочется получить ответ из собственных данных, напишите на kd@tilekindustrial.com. Начнём с карты данных и первой гипотезы с оценкой эффекта.