Чередование двух насосов и ввод резерва
Как построить чередование двух насосов: доступность агрегата, выбор ведущего, подтверждение пуска, ввод резерва и обработка общей причины отказа.
На мнемосхеме два одинаковых насоса, один работает, второй подписан резервным. Во время отказа автоматика переводит команду на второй агрегат, но он выведен в ремонт. Программа переключила номер ведущего и считает задачу выполненной, а подача так и не восстановилась.
Рабочий резерв определяется готовностью всего агрегата и способностью подтвердить результат пуска. Разберём обычное технологическое управление парой насосов, чередование и переход при неисправности. Резервирование контроллеров и проектирование защит оборудования здесь не рассматриваются.
Короткий ответ
Перед выбором ведущего сформируйте отдельный признак доступности каждого насоса. Чередование выполняйте по согласованному событию: новому циклу, наработке или другой принятой политике. Команда пуска должна сопровождаться ожиданием подтверждения и контролем технологического результата. При отказе сначала определите, разрешён ли пуск другого агрегата при этой причине. На HMI показывайте назначенного ведущего, фактически работающий насос и доступность резерва как разные состояния.
Чередование и резерв решают разные задачи
Чередование распределяет работу между пригодными агрегатами. Резерв подхватывает задачу при недоступности основного. Один и тот же насос может участвовать в обоих сценариях, но изменение очереди само по себе ещё не восстанавливает подачу.
Grundfos описывает для двухнасосных установок режимы duty/standby и duty/assist, а также варианты чередования по наработке или числу пусков. Эти понятия полезно явно перенести в техническое задание. Если заказчику нужен одновременный запуск второго насоса для увеличения расхода, схема «основной и резервный» не описывает весь требуемый алгоритм.
В режиме один рабочий плюс один резервный программа обычно выбирает один агрегат. В режиме совместной работы появляется дополнительное условие ввода и вывода второго. Смешение режимов приводит к трудным вопросам при наладке: второй включился из-за неисправности первого или потому, что одного стало недостаточно?
Готовность агрегата надо собирать явно
«Нет аварии» недостаточно. Насос может быть в местном режиме, отключён на обслуживание, не иметь разрешения от привода или быть недоступным из-за положения арматуры. Список условий зависит от схемы установки и должен опираться на реальные сигналы, а не на предположения оператора.
Полезно разделить техническую готовность и разрешение автоматического использования. Агрегат исправен, но выведен из ротации по заявке на обслуживание. Другой агрегат разрешён, однако его привод не подтвердил готовность. Для смены это разные причины, следовательно, им нужны разные сообщения.
На экране следует раскрывать, почему резерв недоступен. Один серый значок вынуждает инженера искать пять тегов в проекте. Короткая расшифровка «местное управление», «ремонтный вывод», «нет готовности привода» уменьшает время разбора и не требует превращать операторский экран в отладчик.
Когда менять ведущий насос
Самый простой вариант для периодической работы: на новом запросе выбирать доступный агрегат по очереди или меньшей наработке. Переключать уже работающую установку только ради выравнивания часов требуется не всегда. Каждая смена агрегата влияет на гидравлику, число пусков и ресурс арматуры.
Если процесс непрерывный, момент передачи нагрузки задают отдельно. Допустимы ли перекрытие работы, перерыв, плавный перевод или запуск второго с последующим остановом первого, определяется конструкцией системы. Универсальная последовательность «сначала выключить один, потом включить другой» для всех насосных узлов непригодна.
Наработку считают по подтверждённой работе, а не по команде. Иначе агрегат, который не запустился, получит часы полезного использования. Дополнительно сохраняют число пусков и неудачных запусков. Два насоса с одинаковыми часами могут иметь разную нагрузку по количеству включений.
Как подтвердить пуск
После команды автомат переходит в ожидание. Требуемое подтверждение может включать состояние привода, дискретный контакт работы и технологический признак. Их смысл различается: контактор включён, вал вращается и обеспечен расход не являются взаимозаменяемыми фактами.
Допустим, на условном стенде сигнал привода появляется за 0,3 с, а давление устанавливается за 2 с. Это учебные значения. Программа, которая ждёт давление только 0,5 с, будет объявлять исправный агрегат неисправным. Если же ждать десятки секунд при любой причине, можно надолго оставить потребителя без подачи. Интервалы выводят из измерений и требований узла.
Приёмка должна отличать отсутствие пуска от отсутствия технологического эффекта. Во втором случае причина может быть общей для обоих насосов. Например, недоступность источника жидкости не устраняется запуском второго агрегата. В проекте составляют таблицу причин, при которых резерв допустим, запрещён или требует решения оператора.
Переход при отказе
После зарегистрированного отказа программа фиксирует неисправный агрегат и проверяет альтернативу. Повторные переключения туда и обратно без изменения причины создают бесконечную ротацию команд. В алгоритме нужны предел попыток и явное состояние «автоматическое восстановление не удалось».
Если первый насос не подтвердил запуск, второй может получить команду только при выполненных условиях готовности и общей разрешающей логике. При этом нужно решить судьбу первого выхода и его возможного запоздалого подтверждения. Позднее появление сигнала «Работа» не должно незаметно превратить резервную схему в параллельную.
Возврат отремонтированного агрегата в доступные тоже не обязан вызывать немедленное переключение. Обычно полезно отделить устранение неисправности, подтверждение готовности и назначение нового ведущего. Это делает поведение после ремонта предсказуемым для смены.
Таблица состояний пары
| Состояние | Рабочая команда | Что показать оператору |
|---|---|---|
| Оба доступны, запроса нет | Оба остановлены | Кто выбран на следующий цикл |
| Один работает, другой доступен | По принятому режиму | Работа и готовый резерв |
| Ведущий не подтвердил пуск | Ожидание или ввод альтернативы | Причину и этап переключения |
| Оба недоступны | По проектному сценарию | Отсутствие автоматического резерва |
| Второй выведен в ремонт | Только разрешённый агрегат | Работа без резерва |
| Общий запрет установки | По проектной логике | Общую причину, а не две частные аварии |
Что испытать на FAT и объекте
Стендовый тест проверяет выбор и переходы, объектовый добавляет фактические времена и гидравлику. В сценарии включают отсутствие готовности, потерю подтверждения работы, общий запрет, вывод в местное управление и возвращение агрегата после ремонта.
Отдельный случай: оба запроса и оба подтверждения меняются в одном цикле. Приоритеты должны определяться логикой автомата, а не порядком записи переменных в разных POU. Проверяют также рестарт контроллера при работающем оборудовании: сохранённый номер ведущего не означает, что насос действительно продолжает работу.
Доказательством испытания служит последовательность событий с исходными сигналами, командами и решениями автомата. По одной финальной картинке «работает насос 2» нельзя установить, почему он выбран и что произошло с насосом 1.
Пример последовательности с неудачным пуском
В условной установке приходит запрос подачи. Оба насоса доступны, на следующий цикл назначен первый. Автомат выдаёт команду, сохраняет момент начала и переходит в ожидание. Если принятого подтверждения нет к контрольной границе, программа фиксирует неудачный пуск, а не считает насос работающим по наличию выхода.
Дальше проверяется причина. При частной недоступности первого и выполненных общих условиях может быть разрешена попытка второго. При общем запрете переход на другой агрегат не решает задачу и не должен автоматически обходить причину. Поэтому классификацию отказов полезно записать до разработки переходов.
После запуска второго агрегата проверяются его подтверждения. Первая попытка остаётся в журнале, а неисправный насос исключается из обычного выбора по описанному правилу. Если позднее от первого приходит сигнал работы, это новое событие требует реакции согласно проекту. Прежний контроль нельзя просто удалить из памяти вместе с изменением номера ведущего.
Если не удалось запустить и второй, система приходит в конечное диагностическое состояние. Две неудачные попытки должны быть видимы отдельно, вместе с общей потерей подачи. Бесконечно чередовать команды без изменения условий значит расходовать ресурс и создавать неясную последовательность вместо восстановления.
Счётчики, влияющие на ротацию
Наработка, число пусков и время последнего использования отражают разные стороны эксплуатации. Алгоритм, который выбирает меньшие часы, может постоянно назначать насос после ремонта, если его счётчик обнулили. Это может быть ожидаемым решением, а может противоречить политике распределения. Нужно определить, какие счётчики имеют пожизненный смысл и какие относятся к обслуживанию.
Часы по подтверждённой работе не стоит вычислять разностью календарных дат без обработки перерывов. Пропажа подтверждения, останов контроллера и перевод часов требуют собственного поведения. Для ротации обычно важна длительность известного рабочего состояния, а не время с момента последнего пуска независимо от результата.
Число пусков тоже имеет определение: команда, подтверждённый запуск или завершённая попытка. Эти показатели полезно разделить. Один привод может получить десять команд и запуститься один раз. Если сохранить только «пуски», эксплуатация не узнает, были ли это реальные циклы работы или повторные попытки при неисправности.
При изменении политики выбора старая история должна оставаться объяснимой. Запись о переходе с чередования по циклам на выбор по наработке помогает понять, почему распределение изменилось. Корректная программа обязана быть воспроизводимой по доступным исходным состояниям, а не зависеть от скрытого порядка выполнения блоков.
Ввод после обслуживания
Отремонтированный агрегат сначала возвращают в технически подтверждённое состояние. Затем отдельно снимают ремонтный вывод, если он предусмотрен. При этом программа не должна автоматически считать все прежние причины устранёнными только по одному контакту «Готов».
Проверка доступности включает те элементы узла, которые действительно входят в его контур управления: привод, разрешения, арматуру и достоверность сигналов по проекту. Необходимый объём работ задаётся документацией оборудования. Для программы важно получить осмысленный итог процедуры, а не набор случайно удобных битов.
Возврат в ротацию можно назначить на следующий допустимый цикл. Это позволяет продолжить текущую работу без ненужного переключения. Если процесс требует немедленной передачи нагрузки, для неё должен существовать отдельный сценарий с контролем результата, а не побочное действие снятия ремонтного признака.
В журнале обслуживания полезно сохранить пробный запуск и его исходные показатели. Такой опыт не обязан менять все общие счётчики одинаково: технологическая наработка и обслуживание могут учитываться раздельно. Главное, чтобы принятые определения сохранялись в отчётах и были понятны персоналу.
Что включить в описание алгоритма
Хорошее описание пары отвечает на несколько конкретных вопросов: как выбирается ведущий, какие причины исключают агрегат, когда допустима смена и что считается удачным восстановлением. Также описывают предел попыток, реакцию на общую неисправность и запуск контроллера при уже работающих механизмах.
Не менее полезен перечень исключений. Что произойдёт, если доступен только один насос? Если во время переключения исчез запрос потребителя? Если оператор изменил ведущего, пока автомат ждёт подтверждения? Такие случаи лучше решить текстом и диаграммой заранее, чем разбирать по месту после первой неожиданной ротации.
В приёмочном протоколе каждому исключению соответствует ожидаемый конечный результат. Тогда заказчик проверяет поведение установки, а не угадывает, правильно ли мигает условный знак резерва. Это делает программу обслуживаемой даже после смены разработчика.
Вопросы при работе
Достаточно ли менять насос раз в сутки? Это одна из политик, а не универсальный регламент. Выбор зависит от режима работы, допустимых переключений и документации установки. Для периодических задач иногда удобнее чередовать между завершёнными циклами.
Можно автоматически снять отказ после восстановления сигнала? Для отдельных предупреждений это допустимо по проекту. Но неудачный запуск и ремонтный вывод часто требуют подтверждения. Автоматический возврат в ротацию должен быть виден и согласован.
Зачем проверять резерв, если он почти не работает? Сам факт длительного простоя ничего не говорит о готовности. Контрольные пуски планируют с учётом оборудования и процесса; их результат записывают отдельно от обычной ротации. Такая проверка не должна неожиданно менять подачу потребителю.
Что полезно передавать следующей смене
При передаче смены важно знать фактически работающий агрегат, назначенного ведущего на следующий цикл и наличие готового резерва. Если один насос выведен в ремонт, это состояние не должно теряться среди давно квитированных сообщений. Установка может продолжать выполнять задачу и одновременно работать без предусмотренного запаса.
Отдельно показывают неудачные автоматические попытки и временные изменения политики ротации. Новая смена должна понимать, почему второй насос не используется и кто разрешил такой режим. Это предотвращает случайный возврат агрегата в автомат только ради выравнивания часов.
Для обслуживания полезны последнее подтверждённое испытание резерва и нерешённая причина его недоступности. Дата сама по себе недостаточна: проверка могла закончиться отказом. Сохраняют результат и относящийся к нему контекст.
Такая информация позволяет планировать действия по реальному состоянию пары. Два зелёных символа в момент просмотра не заменяют знания о предстоящем ремонте или незавершённом переключении. Операторская карточка должна помогать принять правильное следующее действие без поиска по исходному коду.