Назад в будущее: как мы разработали IT-решение для проблемы родом из 90-х — АСУ ТП: сообщество инженеров

Назад в будущее: как мы разработали IT-решение для проблемы родом из 90-х

Для нашей заводской ТЭЦ на ЕВРАЗ ЗСМК в Новокузнецке жизненно важно поступление из пруда воды определенной температуры. Она нужна для охлаждения конденсатора паровой турбины — одного из важнейших элементов данного агрегата. С помощью турбины осуществляется выработка электроэнергии. Для эффективной работы ТЭЦ одного водоема‑охладителя мало, нужен второй, но его нет: в дефицитные 90-е обустроить еще один пруд не было возможности. Как эту проблему помогает решать разработанная нами модель‑подсказчик, расскажу я, дата‑сайентист ЕВРАЗа Александр Варкентин.

Сейчас будет программа первого курса энергетического факультета о работе ТЭЦ. Хватит пары абзацев, чтобы любой мог понять основной принцип и потом при случае блеснуть знанием. Нам же это поможет объяснить проблему, чтобы перейти к решению.

Конденсатор паровой турбины

Как охладить пар

Паровой котел на ТЭЦ вырабатывает пар. Пар проходит через паровую турбину, расширяется и отдает энергию, приводя в движение вал генератора — так производится электроэнергия. На входе пар имеет высокое давление и температуру порядка 500 градусов по Цельсию, на выходе — уже гораздо ниже, около 30 градусов. Дальше пар попадает в конденсатор, где происходит конденсация — пар преобразуется в воду, при этом выделяется большое количество тепла, которое нужно отвести из конденсатора в пруд‑охладитель. А конденсат далее направляется обратно в паровой котел, из него снова вырабатывается пар и так по кругу. Это схема базовая, но, конечно, упрощенная.

На ТЭЦ, расположенной на ЕВРАЗ ЗСМК, две очереди: в первой — три паровых турбины, во второй — четыре. При строительстве первой очереди был выкопан пруд‑охладитель. А вот возведение второй очереди пришлось на конец 1980-х — начало 1990-х, эпоху безденежья, и возможность построить отдельный пруд для второй очереди отсутствовала.

Со временем стало понятно, что это проблема: объема одного пруда недостаточно для нормальной работы ТЭЦ. Почему? В летнюю жару — а такое случается в нашем крае — вода в пруде нагревается. Получается, что в конденсатор поступает вода, нагретая до 35 градусов, а пар температурой 30 градусов, — естественно, при таком условии он не может охлаждаться. Не вдаваясь в детали и формулы, просто скажу, что из‑за этого снижается объем вырабатываемой электроэнергии. Это потери — проблема, к решению которой подключили нас, разработчиков.

Модель для оптимизации

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

С математическими расчетами нам помог научный консультант — профессор Томского Политеха, доктор физико‑математических наук Борис Владимирович Борисов. Он предложил интересную модель в MATLAB. Я отвечал за IT‑разработку проекта и для нашего удобства реализовал ее в Python. Что было дальше? Для этой модели нужно огромное количество данных, а их нет, потому что нет датчиков, которые бы снимали нужные параметры.

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

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

Схема турбины

Двойник в трех ролях

По сути мы создали цифрового двойника. У разработанной модели три режима использования, которые отображаются на интерфейсе: факт, расчет, оптимизатор. Первый — это просмотр фактических параметров работы турбины, включая расчет тех самых недостающих данных, для которых отсутствуют измерительные приборы. Их много на разных этапах процесса: давление пара, расход пара, температура и расход воды, и др. Пользователь заходит в систему, выбирает турбину, которая его интересует, видит схему работы, смотрит параметры в реальном времени, включая расчетные. Есть цветовая индикация, которая отображает, корректно ли работают элементы турбины, адекватные ли данные поступают или нужно направить службу, чтобы она проверила, исправны ли измерительные приборы. Ключевое отличие от обычного АРМа оператора — расчет недостающих параметров, которые ранее оператор в реальном времени определял «по наитию» на основе своего опыта и квалификации. А учитывая общие текущие кадровые проблемы с рабочим персоналом в промышленности (квалифицированные операторы в большом дефиците), определение этих параметров — большая проблема.

В режиме расчета пользователю доступен калькулятор, с помощью которого он может изменить какой‑либо параметр и увидеть, как будет работать турбина. Допустим, если увеличить расход пара на входе в турбину, как поменяется генерация электроэнергии (понятное дело, она вырастет). Или, например, рассчитать, сколько пара мы сможем подать в турбину при текущем объеме охлаждающей воды. Это можно измерить опытным путем, но получится накладно — гонять оборудование из одного режима в другой. Да и зачем, когда можно сделать расчет на цифровом двойнике. Модель помогает вести планирование, например, генерации на летний сезон, если из‑за подъема температуры вода в пруде нагреется. Вообще можно моделировать разные ситуации, исходя из потребности.

Что дает режим оптимизатора? Мы всегда имеем какие‑то лимиты: по объему пара, по циркуляции воды. В первой случае — это может зависеть от парового котла, во втором — от насосов. Допустим, когда один из насосов на капремонте, сколько воды смогут направить в конденсатор? По заданным лимитам модель рассчитывает остальные параметры, то есть помогает выбрать оптимальный режим работы, чтобы в заданных условиях получить максимальную генерацию электроэнергии.

Проект в перспективе

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

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

Нам могут возразить, что проблему изначально можно было решить просто, закупив и установив на конденсаторы расходомеры воды. Стоимость одного расходомера на один конденсатор — порядка 3 млн рублей. С расчетом на все конденсаторы цена вопроса — 50 млн рублей. Мы разработали IT‑продукт, который помогает решать проблему гораздо дешевле. И сама разработка — бэкенд, фронтенд — без особых сложностей: мы использовали Python, фреймворк Falcon, гибкую модель данных Entity‑Attribute‑Value, брокер сообщений RabbitMQ.

Казалось бы, речь о технологическом решении, и все наши усилия направлены на разработку. А в процессе оказалось, что главная сложность проекта — в другом, в нахождении общего языка (и тут не о программировании) между заказчиком, персоналом ТЭЦ и разработчиками. Выстраивать коммуникацию, быть переговорщиком — одна из моих, не самых простых, ролей в этом проекте. IT‑специалисты не знают деталей технологических процессов, сотрудники ТЭЦ не понимают, для чего им модель, они ведь и сами справляются. Важно было донести, что подсказчик не замена им, а дополнительный инструмент. Открою небольшой секрет: мне помогло первое образование инженера‑теплотехника.

Источник: https://habr.com/ru/companies/evraz/articles/946356

🔗 Назад в будущее: как мы разработали IT-решение для проблемы родом из 90-х

Оставьте комментарий

Войти

Зарегистрироваться

Сбросить пароль

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

Прокрутить вверх