Введение
Динамическое сжатие газа в центробежных компрессорах достигается увеличением политропного напора потока газа. Такой процесс описывается газодинамическими характеристиками компрессора, которые представлены на двухмерном графике кривой показывающей рабочие точки компрессора.
На режимах работы компрессора близких к расчетной точке (точка А), поток газа согласуется с формой элементов проточной части. При существенном отклонении режимов в потоке возникают различные вторичные течения, возникают сложные физические процессы.
Пересечение линии помпажа (точка В) сопровождается высокочастотными колебаниями, при этом происходит скачкообразное изменение расхода от максимального значения до отрицательного (реверсирование потока).
ПОМПАЖ – это нестационарный, автоколебательный режим работы компрессора с частотой колебаний давления и расхода порядка 0,5 – 2,0 Гц в зависимости от аккумулирующих характеристик сети.
Помпаж сопровождается быстрым ростом температуры газа, появлением сильных толчков и вибрации, что может привести к разрушению компрессора. Помпаж – недопустимое явление для компрессоров.
Как защититься от помпажа?
Современные системы управления компрессорными установками в своем арсенале имеют много различных алгоритмов для защиты компрессора от помпажных явлений. Математические модели описывающие процессы, протекающие при сжатии воздуха, заложенные в системы управления компрессорными установками позволяют осуществить управление исполнительными механизмами по кривой помпажа КУ (компрессорной установки), для уменьшения эксплуатационных затрат, без ущерба механической части КУ. В процессе эксплуатации механические характеристики КУ меняются не в лучшую сторону. Мат. Модель может быть адаптивна к новым характеристикам КУ, но она сложна в реализации. Поэтому на стадии пусковой наладке, настраивают мат. модель под конкретную КУ. Но само детектирование начала помпажных явлений или установившегося помпажа имеет место быть в независимости от применяемой системы управления КУ. Поэтому данный вид аварийной остановки КУ присутствует в любой САУ (системы автоматического управления) КУ. Для детектирования помпажных явлений используется много входных данных: изменение давления на выходе, температуры и т.д.
Детектор помпажа КУ
В данной статье я расскажу, как детектировать помпажное явление в КУ, применяя
Рассмотрим КУ К-250.
Центробежный, многоступенчатый компрессор, имеющий промежуточные отводы к газоохладителям.
В рабочем режиме, когда КУ вышел на номинальные характеристики, ток статора имеет практически номинальное значение, если двигатель подобран без запаса по мощности. Во время помпажных явлений, давление на выходе повышается до максимально возможного, для данного типа КУ, после чего происходит перетекание сжатого воздуха под воздействием давление из ступеней высшего порядка к низшим. В момент перетекания нагрузка на валу двигателя резко уменьшается, возникает механический удар. Этот момент необходимо детектировать на ранней стадии, чтобы предотвратить механические повреждения КУ. Почему возникают эти помпажные явления, останутся за рамками этой статьи.
Рассмотрим график тока статора в рабочем режиме.
Во время начавшегося помпажа, когда сжатый воздух перетекает из высшей ступени в низшую, происходит «подталкивание» электродвигателя, в этот момент происходит всплеск действующего значения тока, а затем в связи с уменьшением нагрузки происходит провал тока, затем набор рабочего тока, сжатие продолжается и цикл повторяется вновь, вплоть до исчезновения помпажа. График такого режима.
На данном графике колебания происходят с частой в 1 Герц. Такое поведение тока статора, прямое следствие начавшегося помпажа КУ. Как программно детектировать?
Программная реализация противопомпажной защиты
В рабочем режиме, ток меняется плавно и в небольших пределах. В момент начинающегося или уже случившегося помпажа, колебания имеют большую амплитуду и частоту. Значит обычным, цифровым ФНЧ, можно детектировать данную аварийную ситуацию.
К примеру, раз в 100 мс, будем вызывать функцию фильтра, формула которого выглядит следующим образом:
Где 0<А<1 коэффициент фильтра. Чем меньше А, тем слабее фильтр.
Посмотрим на график такого фильтра.
Теперь, если у нас начнется помпаж, то посмотрим, как себя поведет фильтр.
а графике видно, что ток пересекает фильтр несколько раз в режиме помпажа, но такой детектор будет иметь ложные срабатывания в рабочем режиме. Следовательно, необходимо отфильтрованный сигнал сместить вверх и вниз на значение, которое соответствует амплитуде помпажа. На пример на 5 А в ту и другую сторону.
Рабочий режим находится в диапазоне, что говорит о нормальном режиме работы, а помпаж уже пересекает наши границы, и можно смело детектировать помпаж на 7-8 пересечении и аварийно отключить КУ. Можно пойти еще дальше и на первом же пересечении попробовать остановить помпажное состояние, управляя исполнительными механизмами дроссельной заслонки и помпажного клапана.
На примере ПЛК Siemens S7-300 я опишу данную функцию.
В данном
Видео, демонстрирующее работу защиты от помпажа, смотри ниже.
Наряду с программными реализациями по глубокому дросселированию КУ по границе помпажа, необходимо иметь аварийную отработку уже начинающего или начавшегося помпажа в КУ.
Комментарии (43)
Helixa
04.01.2016 14:38-1В данном контексте, программный алгоритм — это программная реализация алгоритма.
amarao
04.01.2016 14:40+3Звучит как речекряк, честно. И остальное тоже травмирующе. «Приложенный файл» с расширением rar? В 2016 году? Srsly? Без ссылки на github или иной хостинг кода?
Helixa
04.01.2016 15:03Постарался учесть замечания. А на счет хостинга кода, то в данной статье это излишне.
stigory
05.01.2016 06:21+1Инженеры, программирующие в МЭК и github? Вы серьезно?
Это другая вселенная. В АСУП обмен архивами в rar — это нормально, а github — наоборот нет.amarao
05.01.2016 08:25+3Низкая культура software engineering, да. Уютное болотце, пока туда не придёт новый дерзкий бизнес, не посмотрит на протекающие мимо деньги с прищуром, и не заменит -цать старых инженеров парочкой хипстеров. Все будут стонать про новый ужас (а-ля докер), но так как своих практик нормальных не придумано, будут вынуждены жрать что дали, или сваливать с рынка по хронической неэффективности.
Roma80
05.01.2016 10:03+3Вас, видимо, действительно что то травмировало.
amarao
05.01.2016 10:36Плохие практики — да, травмировали. Версии кода в архивах на почту, редактирование кода прямо на сервере в продакшене, отсутствие малейших следов контролируемой среды исполнения (какие должны быть зависимости? Как сделать такой же сервер с нуля?).
Оно всё «работает, не трогай», пока не приходят новые и дерзкие, которые это дело вжик-вжик, и делаютправильнееэффективнее.stigory
05.01.2016 13:27+3Ох уж эти истории про дерзких и
дэффективных.
Это на рынке СКАД ещё как-то можно повыделываться и порулить местами как хочется. И то большинство далеко от стандарта OPC не отходят. А это автоматом тащит на себя одеяло винды, разной степени несвежести. Но альтернатива — жёсткий хард-кодинг драйверов под десятки систем и сотни приборов.
А что дерзкий будет делать с замкнутой на саму себя экосистемой железо-софт? Да ещё в условиях тяж. промышленности, госзаказа, дикого распилинга и откатинга с просранным дедлайном?
Эффективность показывать? Мужики засмеют.
Если сверху протолкнули ОВЕН, внедряют его. Если Сименс или Омрон, то нет времени эффективностью меняться. А бывает вообще неведому зверушку в ТЗ прописывают. И только МЭК- совместимость позволяет не заплакать кровавыми слезами.
И тут уж плевать на кривость и убогость среды разработки. Подсветка синтаксиса есть -уже хорошо. Компилит и заливает в прибор без бубна — и то радость.amarao
05.01.2016 17:04В условиях госзаказа — ничего не будет делать, всё хорошо. Просто настолько хорошо, что невозможно себе представить.
А вот в условиях открытого рынка может оказаться, что юные резкие дерзкие просто делают кратно дешевле. Или делают такое, что старички всегда говорили что нельзя и слишком много мороки.
Оно всегда происходит, все индустрии в какой-то момент надламываются и меняются. Или просто меняются.
Весь же вопрос в том, что пока тут сертификация, распил и госзаказ, можно плевать в потолок и набирать инженеров по 35круб в месяц. А как только реальные деньги и возможность подмять под себя конкурентный рынок — тут, внезапно, плевать в потолок больше некогда, и надо дело делать.
Разумеется, Россию в текущем варианте это не касается — я, скорее, про общечеловеческое. Не думаю, чтобы инженеры у Маска пользовались почтой с архивами с исходниками при работе над софтом для gigafactory…
deniskreshikhin
05.01.2016 17:29+4Да в 19 веке многие врачи тоже считали, что перед операцией мыть руки не стоит — дескать пациентов много, а времени мало.
Контроль версий исходников это такой же основополагающий принцип, как стерильность в операционной.
stigory
05.01.2016 17:41+1Ну, если мы обсуждаем только отсутствие сложившейся практики версионной разработки в средах программирования приборов АСУП, то это в основном болезнь самих сред разработки. Ну не реализуют компании разработчики этот функционал, хоть и существует большинство из них на рынке не один десяток лет. Беда в закрытой экосистеме. Нет свободы выбрать для разработки прикладного софта приглянувшийся пакет. Нельзя взять VisualStudio или NetBeans или на Eclipse пописать. Пиши там где позволили. Люди, имеющие опыт в программировании, конечно пытаются какую-то версионность организовать хотя бы на уровне бинарных файлов проектов. Но это все костыли.
А если вести речь о глобальном, то, как говорится, для революции необходимо, что бы верхи не могли, а низы не хотели жить по старому. Пока, на мой взгляд, точка бифуркации не достигнута. Хоть низы и ропщут, но верхи пока в силе.
stigory
05.01.2016 17:52+1Кстати по поводу инженеров ГигаФабрик.
Я уверен, что никто инженерные системы проектировать с нуля там не собирается. Зачем изобретать велосипеды и потерять время не успев выйти на рынок первыми. Будут ставить на инженерку готовые промышленные решения. Honeywell'а какого-нибудь или кто там для американцев актуальнее. А исполнительная часть потащит прицепом свою же автоматику. Автоматика потащит софт. И будут Инженеры Маска как миленькие писать так же как и по всему миру пишут. И никто особо кряхтеть не будет. Привыкли уже.amarao
05.01.2016 18:44+1До тех пор, пока их будет мало. А потом один из них придёт к Маску и скажет, что он может сэкономить компании сколько-то много денег, повысив эффективность работы дорогих инженеров, и нужно ему всего-то сколько-то спецов и сколько-то времени.
А потом все спохватятся и будет баззворд и кипеш среди отстающих.
То есть тут простой вопрос эффективности труда. Сопротивляться можно сколько угодно, но если одна практика даёт тот же результат за N часов работы, а другая за N/2, то рынок расставит всех по местам.
grossws
06.01.2016 01:54Часто там и нельзя иначе. Когда нет кода, а есть проприетарные бинарные форматы или дикий и незамутнённый xml, где перемешано расположение элементов fbd на экране и логические связи между ними, VCS вида
cp project project-bkp-`date +%F-%H%M`становится реальностью, к сожалению. И это в лучше случае; часто и этого нет.
leshabirukov
04.01.2016 15:22А возможно ли бороться с помпажом не отключая двигатель? Что будет, если менять напряжение на том же двигателе, разово или синхронно с паразитными колебаниями?
Helixa
04.01.2016 15:26+1Можно пойти еще дальше и на первом же пересечении попробовать остановить помпажное состояние, управляя исполнительными механизмами дроссельной заслонки и помпажного клапана.
Бороться с помпажом всегда есть возможность. Но когда программные реализации не успевают отработать начавшийся помпаж и он (компрессор) входит в устойчивые колебания, то со стороны механики щадящим будет отключение, чем вывод компрессора из этого не устойчивого состояния.
К тому же на таких компрессорах редко ставятся управляемые приводы. В основном это высоковольтные двигатели прямого включения в сеть.
jov
04.01.2016 15:34останов технологии, работу которой и обеспечивает компрессор, вас вообще не смущает?
Helixa
04.01.2016 15:38+1Нет, так как в промышленности, на этот случай всегда есть резерв. Второй компрессор, стоящий «под парами», как раз для таких аварийных отключениях основного. Время перехода составляет от нескольких минут до получаса, что на технологии практически никак не сказывается. К тому же ремонт компрессора, может стать дороже небольшого простоя технологии.
DanilinS
05.01.2016 11:10+7Я имел дело с такими компрессорами. Замечания:
1) На выходе компрессора обычно стоит ресивер. Который обеспечивает запас воздуха на 5-10 минут.
2) Всегда в горячем резерве стоят 1-2 резервных турбокомпрессоров. С возможностью немедленного пуска в течении 1-2 минут.
3) У нас стояло несколько поршневых компрессоров для аварийного режима работы. Если по каким-то причинам пуск резервных турбокомпрессоров оказался невозможен — отключение некритических потребителей воздуха + пуск поршневых. Поршневые нередко пускались на момент переключений турбокомпрессоров. Для подстраховки.
4) Турбокомпрессор обязательно имеет байпас. Который при снижении расхода просто приоткрывался. Ручками или регулятором. Загнать в помпаж — это очень постараться нужно. Но можно. А потом получить по ушам…
5) Бороться с помпажем не нужно! В принципе. Загнали в помпаж — отключаем и выводим в ремонт. А резервный стартуем. Без вариантов. Вскрываем и смотрим подшипники. И все остальное. Вам приходилось видеть как разорвало ротор такого турбокомпрессора? Как куски стали/чугуна летали по цеху? Я видел. Не понравилось…
6) Гнать нужно программистов из цеха. Неоднократно убеждался — будет только плохо. Нужен «инженер по автоматизации» с многолетним стажем. И повезет если программер только оборудование угробит, а не людей вокруг. Ибо производство имеет кучу не очевидных нюансов и особенностей, которые просто не принимаются во внимание.Helixa
05.01.2016 11:25+1Этак реальная картина на производстве. Я с ней полностью согласен, за исключением:
5) Бороться с помпажем не нужно! В принципе. Загнали в помпаж — отключаем и выводим в ремонт.
На счет бороться, то да смысла нет городить сложные системы, обеспечивающие безпомпажную эксплуатацию во всех режимах, но детектировать начавшийся помпаж необходимо автоматически, с малым временем реакции.Так как реакция машиниста на помпаж может достигать приличных временных отрезков.
RouR
04.01.2016 15:40+1Антипомпажный клапан с регулятором, при приближении к границе помпажа, подают часть потока с выхода на вход компрессора, КПД падает, но в качестве защиты подходит.
Helixa
04.01.2016 16:31Все остальные типы защит никто не отменял. Все они имеют место быть. Но из-за инертности механизма или его непредвиденной неисправности, такая защита не сработает.
frozzzen
04.01.2016 16:26+1Вы изобретаете велосипед, созданный более полувека назад. Существует метод вибродиагностики под названием анализ огибающей. Если на пальцах, то можно сделать так. Берете сигнал с катушки токового трансформатора приводного двигателя и выпрямляете диодным мостом. Выпрямленный сигнал режете ФНЧ 10 Гц и подаете на простейший спектроанализатор. Который либо «видит» колебания с частотой 1 Гц, либо не видит. Понимаю, что четыре диода, емкость и индуктивность это низкий стиль. Но, это работает.
Helixa
04.01.2016 16:35+1Понимаю, что аналоговая схемотехника тоже сможет справится с такой задачей, но в современных реалиях, когда АСУ основываются на ПЛК, и сигнал тока обязательный в ней параметр, то использование такого «велосипеда» как защиту компрессора от помпажа вполне обоснованное решение. А на счет стандартного сигнала с токового трансформатора, то мне кажется амплитуды для открытия 2-х диодов будет не достаточно.
frozzzen
04.01.2016 17:20+1Без синхронного детектора не обойтись? Знаю один секретный метод. Добавить витков в токовый трансформатор. И всё откроется.
Вы собирали в детстве простейший детекторный радиоприёмник?Helixa
04.01.2016 17:56Радио не собирал, я в детстве радиоэлектроникой увлекался только в рамках школьной программы. А добавить витков в готовое устройство, трансформатор тока, например 250/5 А и 10 кВольтовой изоляцией очень проблематично.
frozzzen
04.01.2016 18:59+1Напрасно не собирали. В детекторном радиоприемнике есть и выделение огибающей, и спектроанализатор:)
Следующий вопрос. Вы не пытались получить сигнал прямым измерением? Например, поставить в трубопроводы пару преобразователей давления в ток(solid state pressure transducer, не знаю, как это по-русски)? Как только начнет «хлопать», помпаж и услышите. Не?Helixa
04.01.2016 19:25И этот способ имеет место быть, но они капризные довольно. И иногда ложные срабатывания частят, например в осенне-весенний период. А в общем дублирование никогда не вредило общей концепции.
frozzzen
04.01.2016 22:13Если датчик давления «капризный», значит установлен неправильно. Или сигнальный кабель проложен альтернативно рекомендациям производителя. Вы ведь сигнальные кабеля вместе с силовыми на 10кВ одим пучком не прокладываете?
Helixa
04.01.2016 22:40-1Вы ведь сигнальные кабеля вместе с силовыми на 10кВ одим пучком не прокладываете?
Нет конечно. Но токовый трансформатор преобразует ток/ток, а датчик давления — давление/ток или напруга. В датчике давления используются различные элементы преобразования, отличные от простого и надежного так сказать трансформатора. Значит и слабых мест у них больше.frozzzen
05.01.2016 21:02Ага. Там в трубе много громких звуков на частотах от 500 до 5000 Гц. И датчик давления может от этих колебаний устать, натурально. Здесь нужно свежее решение! Цифровой фильтр или кусок поролона/войлока. Не?
Кстати, и токовый трансформатор преобразует «всё что слышит», вплоть до 10кГц. Вы это тоже «цифровым фильтром» режете?Helixa
05.01.2016 21:3610 кГц если они и есть, режет нормализатор (преобразователь) сигналов до аналогового входа ПЛК.
novoxudonoser
04.01.2016 17:13-2Эмм, а вы случаем ресурсом не ошиблись? (geektimes или другой специализированный ресурс подошёл бы лучше)
Helixa
04.01.2016 17:57+4Я смотрел на теги на geektimes. Так вот на Хабре эти теги более близки к теме топика. Ближе всего «промышленное программирование».
deniskreshikhin
04.01.2016 22:25+1Под «промышленным» имеется ввиду программирование с использованием стандартов промышленного производства — когда программный продукт разрабатывают большими организациями с отделами управления, проектирования, разработки, тестирования, контроля качества, приемки и поддержки.
Это несколько отличается от работы обычных ИТ-команд, где управляют, проектируют, разрабатывают и тестируют одни и те же люди.
Valle
05.01.2016 06:23+1А это в каких компаниях все такие отделы есть, если не секрет?
deniskreshikhin
05.01.2016 13:10В крупных компаниях которые разрабатывают ПО для корпоративных или государственных заказчиков.
Позиции из EPAM'а как пример:
www.epam-group.ru/careers/job-listings?sort=best_match&query=&department=all&country=all&city=allValle
05.01.2016 22:54+1Спасибо. Я про то, что если ограничиться таким определением промышленного программирования, то на хабре наверное скучно будет.
stigory
05.01.2016 06:31+5А я только за статьи, подобные этой. Не одним интернет-корпоративным-программированием мир держится. На самом деле вся железная часть Хабра и Гиктаймса заканчивается на Ардуино-и-прочие. А, как человек, связанный с автоматизацией систем отопления, я только поприветствую умные статьи о PLC, программируемых реле, CoDeSys, Symens STEP и др.
amarao
Пытаюсь понять что такое программный алгоритм. Это что-то типа software-defined algorithms? Когда алгоритм — это программа, по которой пишут программы? Мой мозг дымится, пытаясь себе представить абстрактный класс, инстансы наследников которого являются фабриками классов, чьи инстансы являются алгоритмами. Или, лучше, генераторами алгоритмов?