Энергетика — это просто. Топливо горит, кипятит пар, который крутит турбогенератор, вырабатывающий электрически ток. Чем меньше топлива на единицу электроэнергии, тем ниже себестоимость и эффективнее компания. В нашей компании 60-70% себестоимости электроэнергии — это топливо. Компания по объему генерации в России входит в топ-7, но по различным показателям эффективности делит первые места в отрасли.
Естественно, мы следим за трендами и взвешенно внедряем проекты, применяя доказавшие свою эффективность инструменты цифровизации. Об одном из таких проектов и расскажу: он прост и универсален, применить можно почти во всех сферах бизнеса, если в информационных системах остаются цифровые следы протекания бизнес-процессов. Спросите у своих айтишников.
Мы у своих спросили:
— А можно нам в существующей ERP-системе сделать модуль, который будет в формате старых добрых контрольных карт Шухарта визуализировать параметры горения топлива, забирая текущие и архивные данные из недр ERP или АСУТП?
— Конечно можно, пишите техническое задание чего хотите. А вам зачем? — идя на поводу у любопытства, спрашивают айтишники.
— У нас в ключевых показателях эффективности стоит экономия контролируемых затрат и повышение маржинальности на единицу произведенной продукции.
Хорошо, когда выходишь от айтишников и понятно что делать дальше.
Есть 10 ключевых технических параметров, влияющих на расход топлива. Параметры результирующие, то есть получаются за счет правильной комбинации сотен других, настраиваемых оператором параметров.
В существующей системе оператор стремится поддерживать 10 ключевых параметров в определенных границах, но если происходит выпад за эти границы, то сразу причину выпада никто не определяет, постфактум установить ее трудно, и статистика таких выпадов не ведется. Оператор лишь должен загнать ключевой параметр обратно в границы, играясь с десятками настраиваемых параметров, при этом стандартных четких инструкций как это сделать нет. Многое зависит от опыта.
На оперативных совещаниях и в отчетах фигурируют сильнодействующие неустранимые причины перерасхода топлива, намекающие на устаревшее, изношенное оборудование и техническое несовершенство средств измерения.
Существующая система мониторинга и анализа расхода топлива предполагает ежесуточный расчет и доклад на оперативных совещаниях. При этом анализом занимается отдельная служба, операторы, сидящие за пультами управления и непосредственно регулирующие технические параметры, в него не вовлечены.
Итак, текущее состояние системы:
- Ежесуточный анализ расхода топлива.
- Не анализируются причины отклонений параметров, только причины избыточного расхода топлива.
- Низкое качество причин избыточного расхода.
- Непосредственные исполнители не вовлечены в процесс анализа и совершенствования.
Целевое состояние системы:
- Ежечасный анализ расхода топлива.
- Анализ причин отклонений 3 из 10 ключевых параметров.
- Выявление корневых причин избыточного расхода для каждого случая.
- Вовлечение непосредственных исполнителей в процесс анализа.
Для достижения целевого состояния кросс-функциональной командой производственного блока, IT-управления и управления операционной эффективности было реализовано несколько мероприятий. Нужно сказать, что как такового проектного управления, когда оформляется паспорт, назначаются спонсоры, кураторы и прочая атрибутика мы не применяли. Просто рабочие встречи и внутреннее желание изменений, подогреваемое КПЭ.
Для начала необходимо было выбрать пилотные ключевые параметры, на совершенствование которых будут направлены усилия в первые шесть месяцев. Для этого пришлось поработать с Big Data — проанализировали выгрузку из АСУТП за 2018 и половину 2019 года, а это — 18 млн секундных значений, и определили какие из десяти ключевых параметров оказывают наибольшее влияние на значение расхода топлива. Выбрали первые три по значимости:
- Температура острого пара.
- Давление острого пара.
- Содержание кислорода в дымовых газах.
Затем на основании тех же данных с помощью методов статистического анализа определили и согласовали оптимальные диапазоны для трех выбранных параметров. Оптимальный диапазон — при котором отклик расхода топлива минимален. Естественно, границы этих диапазонов оказались уже или жестче заложенных в существующей нормативной документации. Никаких специальных программ или консультантов не было. Проверенный Excel со стандартным пакетом анализа.
Дальше дело было за айтишниками. Для удобства анализа и вовлечения персонала они таки по написанному управлением операционной эффективности техзаданию разработали встроенный в действующую ERP-систему цифровой модуль, который в ежечасном режиме получает данные из АСУТП о фактическом среднечасовом значении трех ключевых параметров. Ресурсы — один штатный программист и интегратор, осуществляющий поддержку ERP-системы в рамках действующего договора.
Сделали визуализацию в формате контрольных карт — наглядный инструмент для своевременного определения факта выхода значения параметра за контрольные границы. В этом же цифровом модуле предусмотрели для оператора возможность зафиксировать причину выпада, предварительно устранив ее на рабочем месте, а вышестоящее руководство должно спланировать и зафиксировать корневую причину и корректирующие действия.
Таким образом в ERP-системе происходит накопление исторических данных обо всех выпадах среднечасовых значений за установленные границы, обо всех причинах и корневых причинах, а также набор мероприятий, через реализацию которых компания добивается повышения топливной эффективности.
В итоге затраченные ресурсы:
- Две-три недели на анализ исторических данных
- Неделя на выбор параметров и согласование контрольных границ с производственным блоком
- Два месяца на разработку модуля в ERP-системе, вместе с написанием технического задания.
- Четыре человека с загрузкой 15-20% времени.
- Excel и стандартная поддержка от интегратора ERP-системы. Вы уже им платите за поддержку, если у вас есть ERP.
При успешной реализации проекта расчеты прогнозируют экономию до 2 000 кубометров топлива в час, что эквивалентно 18 млн рублей в год. И это только на одном энергоблоке и только на трех из десяти ключевых параметрах. Всего в компании блоков 26. А сколько их всего в России?
Безусловно, новизной проекта для нашей компании является ежечасный анализ ключевых параметров и цифровые контрольные карты для визуализации и управления параметрами.
Дальнейшие шаги — сужение границ допустимых диапазонов, подключение к мониторингу всех ключевых параметров и тиражирование проекта внутри компании. На перспективу — корректировка существующей нормативной документации по эффективности использования топлива, при наличии запроса и на уровне государства.
Непонятно, зачем Excel, если есть нормальный визуализатор с открытым исходным типа Grafana (ссылка удалена модератором)
Молодцы. То, что описано в статье и есть пример реализованного бережливого производства. Только, если планы действительно столь амбициозны, плотно пообщайтесь со своими IT-специалистами на соответствие их квалификации в решении заявленных задач. Возможно им понадобится сторонняя помощь. В статье мало информации для определения возможной архитектуры, но судя по описанию, реализовано решение очень неудобно.
Ребята молодцы!
(Отредактировано модератором)
«Предчувствия его не обманули»
Как я понял в статье речь идет о часовой экономии топлива, а разве энергоблок работает с постоянной нагрузкой, всегда выдает одинаковую электрическую мощность в сеть?
Полагаю, что вряд ли. Поэтому более корректно рассчитывать удельный расход топлива на единицу выработанной электроэнергии - кг/(кВт*час).
Возникает вопрос, а какое топливо? Настолько стабильны характеристики топлива?
Так там же в ERP и сделали бы вывод информации.
Зачем excel?
Дополнительно спрошу - это энергетический блок или ТЭЦ, паровая турбина конденсационная или с тепловым отбором?
Если с отбором, то тепловая нагрузка тоже влияет на расход топлива.
Режим работы блок стабильный или плавающий?
Если режимы нагрузки стоят стабильно какое-то время, то это вопрос как выставить параметры блока на режим.
А если режим плавающий, то блок постоянно требует регулирования и от качества регулирования зависит экономичность работы блока.
В последнем случае, однозначно скажу, хотите экономии ставьте нормальную систему регулирования и на турбину и на котел и общее управление блоком (котел + турбина).
Работу критически важного ПО можно увидеть на двух мониторах слева на картинке в начале статьи, а три оператора ТЭЦ уставились в монитор, где предположительно видна таблица Excel ))) - но эту картинку вряд ли предоставил автор ))) - скорее всего, редактор где-то надыбил ...
Судя по описанию в статье, анализ делается уже после происшедших событий ((( То, что написано в статье о постановке задачи ... и тут ручной Excel ещё встревает ... и всё это сразу становитсч полной ерундой. Но всё о чём рассказывается, делается на раз с помощью Оберон в реальном режиме времени - см. доклад - Масштабируемые Оберонтехнологии как средства обеспечения защищенного ПО критически важных систем Один из подзаголовков доклада - Оберон и борьба с избыточной сложностью.
а Grafana в основном написан на TypeScript, который потом конвертируется в JavaScript. Для критически важных систем это точно не решение, а в качестве примера авторы Grafana приводят интернет вещей и управление микроклиматом в офисе ))) . Известны и БЫЛИ попытки писать программы на JavaScript для космических спутников ...
или - Энергосистема Украины действительно подверглась атаке злоумышленников: выводы SANS, или Сеть 12-ти АЭС подверглась хакерским атакам в США
По первой ссылке, первое что проверяли эксперты - есть ли зараженные документы Microsoft Office. По последней ссылке - "Хакерам удалось взломать корпоративную сеть управляющей компании, осуществляющей деятельность в отношении АЭС".
Как можно управлять критически важными объектами таким образом???
То, что описано в статье или нечто аналогичное можно использовать, чтобы определить эффективность экономии ресурсов после внедрения Системы регулирования.
Если записать массив данных по работе объекта до внедрения Системы регулирования и после внедрения, то граммотно построенный сравнительный анализ это покажет.
Мы занимались чем-то подобным, когда нам в Контракт записали, что если наша Система не даст 7% экономии электроэнергии на привод нагнетателей, то будут штрафные санкции.
Пардон, но атаки никак не связаны с системой мониторинга, так как у нее нет возможности влиять на параметры системы, а только отображать их.
Конечно, для мониторинга критичных систем реального времени лучше аппаратные решения, но тем не менее - я не вижу проблем в использовании для мониторинга 10 параметров влияющих на маржинальность