Отдел продаж: +7 495 174 55 50Тех поддержка: 8 800 555 25 11
Михаил Пирогов
Сегодня я руковожу НПП «Микропроцессорные технологии». Во многом мой взгляд на разработку оборудования сформировался в работе с энергосистемами промышленного предприятия. Например, приходилось разбираться, почему меняется давление, как ведёт себя электродвигатель, что означает сигнал датчика и какие действия после него должен выполнить человек. Ответы нужно было доводить до схемы, программы, наладки и понятной инструкции.
Примеры проектов 2005–2007 годов позволяют показывают разнообразность решаемых задач в то время. Они связаны с электроснабжением крупного завода по выпуску листового стекла: производства, компрессорной станцией, оборотным водоснабжением, очисткой воды, электроприводами и контролем движения механизмов.
У этих работ были разные масштабы. В одном случае требовалось объединить информацию от нескольких распределительных устройств, в другом — написать программу небольшого микроконтроллера и разработать электронные платы. Однако связь между ними вполне определённая: каждый проект начинался с конкретной производственной задачи и требовал понимания поведения оборудования.
В 2005 году я занимался системой автоматического контроля электроснабжения. Она давала персоналу возможность наблюдать параметры фидеров 6-10кВ: напряжение, частоту, токовые нагрузки, активную и реактивную мощности, коэффициент мощности, состояния высоковольтных ячеек. Для анализа были предусмотрены мнемосхемы, графики и отчёты.
С рабочего места РУ-ЦЕНТР можно было получать информацию о РУ-КВС и РУ-ДЭП через локальную сеть. При нарушении связи данные продолжали сохраняться на компьютерах удалённых распределительных устройств. Таким образом, мы учитывали вполне обычную для эксплуатации ситуацию: канал передачи может отказать, а наблюдение за оборудованием должно продолжаться на месте. Программное обеспечение верхнего уровня и его исходные коды разработал самостоятельно.
Мы с командой писали инструкции оперативному персоналу, что делать с показаниями. Например, при обнаружении расхождения фазных токов электродвигателя персоналу предлагалось проверить результат токовыми клещами. Если отклонение подтверждалось, следовало перейти на резерв и организовать профилактический ремонт. Эта последовательность связывала показания на экране с проверкой на объекте и конкретным решением.
Такой подход требовал внимания и к устройству интерфейса. Выход параметра за установленный диапазон выделялся цветом. Архивные графики позволяли рассматривать развитие отклонения во времени. Оперативный журнал сохранял сведения о действиях смены; отдельно предусматривались журналы обходов, дефектов, нарядов и заземлений. Персонал получал инструменты для повседневной работы и последующего разбора событий.
Уже тогда практическая разработка включала вопросы хранения данных: сколько их будет, как строить отчёты и что потребуется человеку, который обслуживает систему.
Это был опыт работы с полной последовательностью: получить показание, оценить его достоверность, сопоставить с допустимым режимом и определить дальнейшее действие. Качество каждого звена влияло на полезность всей системы.
Одним из самых интересных проектов того периода стала система мониторинга и автоматизированного управления компрессорной станцией 6кВ.
В 2006 году мы с командой разрабатывали проект, писали программы системы управления, организовывали связь с сервером данных и выполняли в пусконаладочные работы в режиме действующего предприятия. Примечателен тот факт, что мы это делали с Ивановым И. В. – блестящим инженером. Мы познакомились на вступительных экзаменах в политехнический университет, и с того момента, и по сей день дружим и работаем вместе.
Вернемся к технической задаче. Проблема предприятия была связана с распределением сжатого воздуха по предприятию. До создания системы было трудно установить, какой потребитель вызывает провал давления, как часто это происходит и как отражается на других цехах. До внедрения системы, недостаток информации компенсировали повышением производительности компрессорной станции и общего уровня давления – это приводило к повышенному расходу электроэнергии.
На станции было шесть компрессоров 6кВ с различной производительностью и разными ступенями регулирования. Состав работающих агрегатов менялся, отдельные ступени каждого компрессора могли быть недоступны – выведены в ремонт. Потребители тоже вели себя по-разному. При одном и том же давлении решение зависело от того, росло оно или снижалось, насколько быстро менялось и что происходило на остальных участках.
Мы организовали контроль давления в восьми точках, включая саму компрессорную. Значения обновлялись с интервалом десять секунд. Для каждого канала сохранялась история шести последовательных изменений, то есть система анализировала динамику за прошедшую минуту. В результате получалось 48 показателей изменения давления, которые требовалось свести к решению об изменении производительности.
Для оценки изменения давления использовался относительный индекс:
Индекс i обозначает точку контроля; числовое значение a выражает изменение в процентах. Положительный знак соответствует росту давления, отрицательный — падению. Давления в числителе и знаменателе берутся в одинаковых единицах. Делитель здесь — текущее давление: это особенность именно использованного выражения.
В этой работе я применил адаптивный алгоритм на основе небольшой модели нейронной сети разработанной самостоятельно – с автоматическим обучением во времени.
Алгоритм использовал взвешенную оценку изменений давления и нелинейную функцию для получения обобщённого показателя. Отдельно оценивалось приближение текущих давлений к границам допустимого диапазона. Весовые коэффициенты корректировались по заданным правилам, учитывавшим соотношение динамики на компрессорной и у потребителей.
Шесть сохранённых индексов каждого канала суммировались с его весом. Полученную величину преобразовывала функция гиперболического тангенса, а выходы восьми каналов усреднялись:
Здесь k — номер сохранённого отсчёта, W — вес значимости канала, D — общий показатель динамики, называемый в программе DIN_RESULT. Гиперболический тангенс ограничивает выход интервалом от −1 до +1; знак сохраняет направление изменения, а вес позволяет различать вклад участков. В формулах использованы единые обозначения для восьми каналов и шести отсчётов.
Второй показатель оценивал положение давлений относительно середины рабочего диапазона. В проекте использована следующая последовательность:
Pmin и Pmax — заданные границы давления, Pmid — их середина. Если давление ниже середины, его вклад Z положителен. В системе управления давление задаётся в кгс/см², а для числового масштаба аргумента принят коэффициент Kk = 4. Показатель B соответствует DELTA_P_MAX_DIN. Этот расчёт был определен без весов значимости W.
Адаптация меняла значимость потребителей небольшими шагами. Для выбора поправки динамику повторно оценивали при единичных весах; затем программа ИНТЕЛЛЕКТОР по правилам сопоставляла поведение давления потребителя и компрессорной. Один шаг изменения веса можно записать так:
Нулевое изменение означает отсутствие поправки. Потребители сжатого воздуха с выраженными локальными колебаниями при сравнительно неизменной величине давления в центральном коллекторе самой компрессорной станции могли получать меньший вес.
При общем падении давления вес участка с наиболее сильным отрицательным изменением повышался по отдельному правилу. Важна была возможность увидеть и проверить эти промежуточные расчёты в интерфейсе в режиме работы станции.
Смысл этой математической части состоял в том, чтобы при выборе управляющего действия учитывать поведение всей системы. По рассчитанным показателям программа рекомендовала увеличить или уменьшить производительность на доступную ступень (либо могла делать это в автоматическом режиме).
Комбинации доступной величины производительности определялись с учётом работающих компрессоров и разрешённых ступеней регулирования. Рекомендацию можно было видеть при отключённом автоматическом управлении; при включённом автоматическом режиме система выполняла предусмотренные переключения.
Алгоритм был достаточно обозримым: математическая модель с изменяемыми коэффициентами и правилами принятия решений. Для меня интерес заключался в возможности приспосабливать управление к изменяющимся условиям объекта и учитывать тенденцию изменения параметров до достижения нежелательного режима.
При этом математическая модель должна была работать вместе с эксплуатационной логикой. Ручные команды с пульта компрессора имели приоритет перед компьютерными. Неисправную ступень можно было исключить из управления. Предусматривалась аппаратная блокировка выходных реле. События регистрировались с отметками времени, а оператор не мог редактировать системные сообщения. Эти детали определяли, насколько управляемой и понятной оставалась установка в реальной работе.
Отдельные функции помогали разбирать причины провалов давления: находить характерные участки графика, оценивать их глубину и длительность, сравнивать события по цехам. Данные становились основанием для разговора с технологами и эксплуатацией о конкретных режимах потребления.
Следующий большой пласт работы был связан с насосной оборотного цикла и градирней.
Система объединяла уровни воды в башне и бассейнах, давление, температуры технологической и охлаждённой воды, токовые нагрузки и температуры оборудования. Под контролем находились три сетевых насоса, три шламовых насоса и четыре вентилятора; поступала информация и от связанных объектов. На одном экране оператор мог оценивать состояние нескольких частей оборотного водоснабжения.
Характерная задача касалась управления вентиляторами. Сначала алгоритм определял, сколько вентиляторов необходимо иметь в работе при текущей температуре воды. Затем выбирал конкретные доступные агрегаты с учётом разрешения на управление и их состояния. Для включения и отключения использовались разные температурные границы — гистерезис, позволяющий избежать переключений при небольших колебаниях около уставки.
Например, включение второго вентилятора требовалось при росте температуры примерно до 19 °C. При снижении температуры до 18,8 °C количество работающих вентиляторов сохранялось; возврат к одному в работе происходил после снижения ниже 18,6 °C. Для этой ступени разность порогов составляла:
Разные границы позволяли удерживать выбранный режим при небольшом обратном изменении температуры; выбор самого вентилятора выполнялся отдельно с учётом его технического состояния.
В выборе оборудования учитывалась и ежедневная обязательная «прокрутка» вентиляторов. Приоритет получали те, которые ещё не работали в течение суток; среди подходящих агрегатов использовался случайный выбор. Это предусматривалось для подсушки изоляции электродвигателей и предотвращению их преждевременного повреждения.
Так можно было совместить потребность в охлаждении с предусмотренным эксплуатационным прогревом. Если вентилятор находился на прогреве, это состояние учитывалось при управлении остальными агрегатами.
Здесь было интересно именно согласование режимов. Температура определяла потребность в охлаждении, техническое состояние ограничивало доступное оборудование, а эксплуатационные процедуры добавляли свои условия. Все эти обстоятельства требовалось выразить в понятной последовательности проверок, что и было реализовано в автоматическом режиме.
Полезным результатом проекта были экономия электроэнергии и автоматическая организация работы вентиляторов. Для меня этот проект показателен тем, как небольшие логические решения складываются в работу целой установки: проверка разрешения, учёт уже включённого агрегата, выбор границ переключения и согласование прогрева с охлаждением.
В проектах компрессорной и градирни отдельной задачей была организация программного обеспечения. Требовалось собирать сигналы, выполнять расчёты, выдавать команды, сохранять историю и предоставлять пользователю графики. Эти функции были разделены между несколькими программными модулями.
В системе компрессорной нижний уровень работал на контроллере с программой на ассемблере для Z80. Он обрабатывал дискретные входы и выходы. «Интеллектор» опрашивал контроллер и измерительные преобразователи, обрабатывал параметры и формировал управляющие решения. Отдельный SIP-server принимал данные и записывал их в базу MS SQL Server 2000. Навигатор вызывал программы графического анализа.
У названия SIP-server была своя рабочая история - «Сервер Иванова-Пирогова». Илья Иванов разрабатывал сервер данных и графический анализ, я — центральную управляющую математическую часть и её взаимодействие с сервером. Программу контроллера разрабатывал Александр Просвиркин (блестящий инженер, у которого мы учились основам разработки промышленной электроники). Такое разделение позволяло каждому заниматься своей частью общей системы.
Для градирни также был описан формат обмена между управляющей программой и сервером записи. Предусматривалось развитие пользовательских функций без изменения основного кода контроллера и «Интеллектора». Это создавало возможность поручать новые графики и отчёты другим программистам.
В инструкции по установке отдельно требовались проверка настроек, калибровка измерений и проверка логики вентиляторов. Сам факт установки программы ещё не завершал наладку: нужно было убедиться, что она правильно взаимодействует с конкретным оборудованием. Эта часть работы приучала думать о том, как систему будут запускать, обслуживать и дорабатывать после её внедрения.
Наряду с системами верхнего уровня мы занимались силовой электроникой. Мы разработали прототип устройства плавного пуска назвав его T-RSimplify. Разработали совместно с И. В. Ивановым. В нём использовались тиристоры и микроконтроллер PIC16F84A.
Комплект документации охватывал силовую схему, синхронизацию с питающим напряжением, цепи управления и питания, гальваническую развязку, расчёт трансформатора, печатную плату и спецификацию. Требовалось согласовать работу микроконтроллера с силовой частью и обеспечить управляемый разгон двигателя. Такая задача соединяла программирование с измеряемыми токами, напряжениями и конструкцией устройства.
Мы получили результат из практического эксперимента с двигателем вентилятора мощностью 30 кВт. При прямом пуске ток составлял 200 А, при плавном — 96 А, время разгона составляло около 30 секунд. Для этого опыта пик тока удалось уменьшить примерно вдвое.
Проведя эксперименты, мы получили вот такое отношение двух вариантов пуска:
Это означало уменьшение пика тока на 52 % в данном опыте.
Важен был и следующий вопрос: как улучшить управление после получения первого результата. Мы наметили развитие устройства с обратной связью по току и защитами по фазным токам. Это отражает то, как мы учились рабочему порядку разработки: проверить базовый принцип, увидеть его ограничения и определить, какую информацию нужно добавить в алгоритм.
Этот проект дал опыт проверки электронного устройства совместно с электромеханическим объектом.
В 2007 году мы с инженером лаборатории электротехнических разработок Ивановым И. В. работали над устройством контроля движения ленты элеватора. Задача возникала из особенностей самого механизма: при нарушении движения ленты или остановке ведомого вала электродвигатель мог продолжать вращаться – лента перетиралась и тонны сырья заваливали шахты элеваторов.
Чтобы обнаружить перетирание ленты элеватора шихты, требовался сигнал от ведомого звена привода.
Датчик на валу формировал импульсы, а контроллер семейства PIC16F84 анализировал длительности. В схему входили оптронный вход, светодиодная индикация, переключатель режимов и релейный выход в цепи управления пускателем. При обнаружении признаков нарушения движения устройство должно было выдать аварийный сигнал и отключить привод.
Особенно интересной была настройка датчика под работу конкретного механизма – каждый механизм индивидуален и универсальных уставок и настроек не существовало.
Перед вводом датчика в работу предусматривался режим «ЗАПИСЬ»: элеватор должен был поработать 15–20 минут под нагрузкой и без неё. Контроллер датчика автоматически определял характерные длительности уровней сигнала и формировал уставки с разумным запасом. Настройки сохранялись в энергонезависимой памяти EEPROM. После изменений привода или механики датчика процедуру следовало повторить.
Мы освоили программирование и написали программы на ассемблере. PIC контролировал минимальную и максимальную длительности обоих уровней сигнала меандра от ленты, а так же в программе PIC предусмотрели дополнительная проверка изменений входного сигнала для защиты от наводок.
Автоматический расчет уставок под конкретных механизм определялся так:
m и M — минимальная и максимальная длительности уровня, найденные при обучении датчика; L и U — соответствующие уставки. Индекс j различает низкий и высокий уровни. Длительности здесь выражены в отсчётах программного счётчика. Знаки приближённого равенства существенны: программа вычисляла процентную добавку целочисленно по битам числа.
Так выглядит допустимый диапазон для установившегося контроля. Здесь L и U — фактически рассчитанные целочисленные уставки. Величина n — текущая измеренная длительность в отсчётах программного цикла PIC.
Работа с таким контроллером требовала внимательно разбирать подробности: что происходит при пуске, как отличить полезный переход сигнала от помехи, как учитывать изменения нагрузки и когда выдавать аварию. Даже у небольшого прибора связь между механикой, электрической схемой и программой оказывалась тесной. Удобство настройки тоже становилось частью технического решения: наладчику требовалась понятная процедура, привязанная к реальному движению оборудования.
В оборотной воде механические взвеси ухудшали работу теплообменных систем. Разработанная и построенная, внедренная в производство установка включала отстаивание в баке, четыре песчаных фильтра и второй бак перед возвратом воды в цикл. У второго бака была дополнительная функция: задержать фильтрующий песок, если он пройдёт через элементы фильтра. В схеме предусматривалась возможность вывести отдельный фильтр на обслуживание, сохранив работу остальных.
Для такой установки требовалось описать порядок запуска, настройку уровней и сигнализации, промывку, проверку герметичности и действия персонала. В регламент входили и гидравлические процессы, и работа насосов, и контроль результата очистки.
Станция химической водоподготовки решала другой круг задач: забор и накопление воды, её умягчение и распределение потребителям. В ней предусматривались резервная подпитка и резервирование насосов. Автоматика подпитки на PIC16F84 использовала уровни воды и обратную связь от привода. Если в течение двух минут не поступало подтверждение полного открытия или закрытия привода, система выдавала звуковой сигнал тревоги.
В разработанных регламентах были описаны контроль жёсткости и pH, процедуры регенерации фильтров, обязанности оператора и обслуживание оборудования. Это расширяло круг ответственности разработчика. Нужно было определить, по каким признакам персонал поймёт, что технологический процесс идёт правильно, когда потребуется вмешательство и как проверить результат выполненной операции.
Подготовка таких регламентов заставляла последовательно проходить весь процесс с точки зрения человека у установки. Если действие трудно объяснить, стоит ещё раз проверить логику управления и понятность сигнализации. Документирование становилось способом проверить само техническое решение.
Среди самых первых проектов была задача по управлению конденсаторными установками. В настоящее время это решается установкой цифрового регулятора числа ступеней конденсаторной батареи. Но в то время мы не могли купить такие приборы по причине отсутствия финансирования и поэтому пришлось искать доступный способ решить задачу по восстановления работы систем компенсации реактивной мощности в автоматическом режиме.
Его исходная задача была вполне конкретной: часть установок не имела работоспособных блоков регулирования, и требовалось определить способ выбора ступеней компенсации для существующей системы электроснабжения – ориентируясь только на полный ток присоединения и не зная ничего о действующей величине коэффициента реактивной мощности….
Я проверял возможность использовать связь между током и реактивной мощностью для обследованной группы потребителей. В основе предположения лежала схожесть коэффициентов мощности и загрузки этих электроприёмников. Чтобы применить такой подход, нужно было изучить состав нагрузки каждого узла электроснабжения и сопоставить расчёт с измерениями. Я понимал долю двигателей, зная полный ток присоединения и фактический коэффициент загрузки каждого технологического электродвигателя – мог статистически рассчитать требуемую величину реактивной мощности для компенсации.
Для двигателя в расчёте выделялись реактивная мощность холостого хода и составляющая, зависящая от загрузки. Две зависимости можно было объединить в одну:
Q0 — реактивная мощность холостого хода, Qnom — реактивная мощность при номинальной загрузке, Qact — оценка для рассматриваемого режима; все три величины выражены в квар. Kload — безразмерный коэффициент загрузки.
Для подтверждения правильности формульных выводов мы сделали эксперимент на электродвигателях вакуум-насосной. Для насоса мощностью 90 кВт с его фактической технологической загрузкой мы определили расчётный коэффициент мощности 0,573 и экспериментально получили значение 0,58. Эти данные были частью проверки гипотезы на конкретном оборудовании.
В истории моего опыта этот проект занимает место первой исследовательской работы — попытки найти решение в условиях дефицита бюджета, проверить расчёт экспериментально и понять пределы применимости выбранного подхода. Практическая инженерия должна включать и такие этапы.
Оценивая материалы первых проектов, вижу, осознаю, что задачи решались командно. Илья Иванов и Александр Просвиркин. В монтаже и пусконаладке участвовали Станислав Добрыднев, Данил Лопаткин, Александр Афанасьев и Руслан Курапов. В разных проектах состав участников менялся, но совместная работа оставалась существенной частью результата.
Разделение обязанностей требовало согласовывать границы между частями системы. Программисту (им иногда был я) нужно было понимать, какой сигнал реально доступен от оборудования. Разработчику электроники — знать, какого поведения ожидает алгоритм. Наладчику — иметь схемы, настройки и возможность проверить выполнение команды. Через эти взаимодействия формировалось представление о разработке как о работе нескольких специалистов над одной производственной задачей. Это был потрясающий опыт, который определил принципы работы над всеми проектами в дальнейшем.
Сегодня, оценивая новую разработку, я обращаю внимание на вопросы, которые возникали ещё в тех проектах. И я осмысливаю не только бизнес-показатели, но и представляю себя на месте людей, кто будет использовать новые продукты-решения, включая все уровни организационного взаимодействия – делать это в комплексе очень важно.
Что именно измеряет прибор? Достаточно ли этой информации для решения? Как система ведёт себя при потере сигнала или изменении режима? Полезна ли информация и как ее практически использовать, а не просто оценивать очередной параметр. Понятно ли оператору, что произошло? Можно ли восстановить последовательность событий по записям и проверить вывод алгоритма?
У этих вопросов есть конкретные истоки. Контроль электроснабжения требовал связывать показания с действиями смены. Компрессорная станция — учитывать динамику нескольких потребителей. Градирня — согласовывать потребность в охлаждении с состоянием оборудования. Плавный пуск и датчик движения — проверять, как программа взаимодействует с физическим процессом. Регламенты водоподготовки — объяснять всю работу установки человеку, который будет её обслуживать.
Этот опыт помогает мне смотреть на изделие вместе с условиями его применения. У разработчика и эксплуатационного персонала разные повседневные задачи, но им необходимо одинаково понимать назначение устройства, его настройки и поведение при отклонениях. Я считаю такое взаимопонимание частью качества инженерной работы.
В заключении описания компрессорной станции 2006 года я написал: «Работа над данным проектом доставила огромное удовольствие». В этой фразе сохранилось отношение к самой работе: разобраться в процессе, найти подходящий способ управления и увидеть, как замысел превращается в действующую систему. Именно это отношение я хочу сохранять в работе и это мы транслируем сегодня при разработках новых продуктов в НПП «Микропроцессорные технологии».
Возврат к списку
