Permissive, interlock, trip и first-out: не один «запрет», а четыре механизма

Сначала проектный глоссарий

Термины различаются между отраслями и предприятиями, поэтому проект должен закрепить собственные определения и связать каждую причину с control narrative или cause-and-effect.

Типовая модель: permissive не принимает пуск; running interlock прекращает или удерживает действие; trip выполняет защитный переход; first-out помогает расследовать каскад.

Permissive: готовность до команды

Разрешения могут быть постоянными, стартовыми и режимно-зависимыми. Оператору нужен перечень «не готов», а не общий непрозрачный бит.

Если условие исчезает после старта, реакция определяется отдельным running interlock или trip. Автоматически переносить логику стартового разрешения на работающий объект опасно.

• режим применимости;
• задержка и фильтрация;
• реакция на плохое качество;
• видимость причины в HMI;
• условие автоматического восстановления.

Interlock: команда и продолжающееся действие

Полезно разделять command inhibit, running interlock и sequencing interlock. Для каждого задаются действие, latch, reset, режимы, bad quality и допустимость bypass.

Process interlock не становится safety-функцией только потому, что останавливает механизм. Safety-related контур требует отдельного жизненного цикла и компетенций.

Trip: действие, safe state и reset

Цепочка проектируется полностью: причина, подтверждение или voting, trip demand, действия механизмов и подтверждение безопасного состояния. Alarm — только средство уведомления и не равен trip.

Квитирование сообщения не сбрасывает trip. Reset снимает разрешённую фиксацию, но не должен самопроизвольно запускать оборудование. Bypass имеет владельца, срок, индикацию и журнал.

First-out и предел точности

First-out хранит первый допустимый фронт после готовности группы, время, режим, команду и ключевые значения. Полный bitmap активных причин сохраняется отдельно.

Если несколько сигналов появились в одном цикле PLC, физический порядок может быть неразличим. Priority encoder даёт детерминированный выбор, но не доказывает причинность. Для точной SOE нужны согласованное время и подходящая инфраструктура.

PLC-контракт и HMI

Интерфейс оборудования может публиковать Ready, PermissiveOK, StartInhibit, Interlocked, Tripped, ActiveCauseBitmap, FirstOutCause, ResetRequired и BypassActive. Порядок: входы и quality → условия → разрешения → защитные действия → фиксация причин → диагностика.

SCADA различает «не готов», «команда заблокирована», «остановлен interlock», «tripped» и «первая причина». Status, event и alarm остаются разными сущностями.

Матрица проверки

Проверяются каждая причина, несколько одновременных причин, дребезг, bad quality, потеря связи, переходы режимов, restart, reset при активной причине, bypass и восстановление. Каждый тест содержит исходное состояние, воздействие, ожидаемое действие и доказательство.

Матрица условий и действий: пример насосного агрегата

Одну и ту же технологическую переменную нельзя автоматически использовать одинаково во всех состояниях. Условно низкое давление на всасывании до пуска может запрещать старт, а его появление во время работы — вызывать предупреждение, controlled stop или защитный переход. Выбор реакции зависит от процесса, конструкции агрегата, анализа риска и утверждённого cause-and-effect.

Практичная матрица содержит состояние объекта, причину, задержку, качество данных, действие, способ фиксации, условие reset и сообщение оператору. Она позволяет увидеть, что общий бит Fault скрывает несколько разных контрактов поведения.

• до пуска: условие не выполнено → StartPermissive = false → показать причину неготовности;
• во время работы: условие нарушено → выполнить утверждённую реакцию → зарегистрировать событие;
• нет подтверждения после команды → дождаться заданного времени → сформировать отдельную диагностику;
• качество сигнала потеряно → применить согласованную quality-policy, не подменяя неизвестность значением false;
• сработала safety-функция → обработать её в предусмотренном safety-контуре и передать статус в основную систему.

Фронт сигнала, дребезг и предел одного цикла PLC

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

До фиксации события нужно определить, где учитываются диагностика канала, фильтрация, задержка и признак применимости режима. Иначе короткий импульс, дребезг или Bad quality могут занять first-out раньше значимой технологической причины. Для более точной sequence-of-events требуются согласованные часы, достаточная временная разрешающая способность и подходящие устройства сбора событий.

• код причины и её человекочитаемое описание;
• время обнаружения и источник timestamp;
• режим и состояние объекта в момент события;
• команда, активная перед событием;
• bitmap всех причин, обнаруженных в том же диагностическом окне.

Reset, acknowledgement и restart — разные переходы

Удобно рассматривать защитную остановку как последовательность состояний: причина активна, действие выполнено, trip зафиксирован, причина исчезла, reset разрешён, объект снова готов. Квитирование alarm меняет состояние уведомления, но не подтверждает устранение причины и не обязано менять состояние trip.

После перезапуска PLC отдельно определяется судьба latched-причины, first-out и разрешения на повторный старт. Сохранять всё или очищать всё одинаково рискованно: решение зависит от требуемой диагностической истории, поведения оборудования и утверждённой startup-процедуры. Команда Reset обычно обрабатывается как отдельное авторизованное действие и не должна скрыто превращаться в Start.

• CauseActive — исходная причина всё ещё присутствует;
• TripLatched — защитное действие остаётся зафиксированным;
• ResetPermitted — выполнены согласованные условия восстановления;
• Ready — объект может принять новую команду, но ещё не запущен;
• StartRequested — новая команда зарегистрирована отдельно от reset.

Bad quality и потеря связи как самостоятельные причины

Сетевой Boolean со значением false и Boolean без достоверных данных — разные состояния. Если таймаут, stale-данные или Bad quality автоматически преобразовать в false, PLC может показать несуществующую готовность либо скрыть реальное состояние механизма. Поэтому для каждого удалённого условия задаётся отдельная политика качества.

Такая политика отвечает на вопросы: допускается ли пуск при неизвестном значении, требуется ли останов работающего объекта, сохраняется ли последнее значение, через какое время состояние считается недостоверным и что увидит оператор. Конкретная реакция выбирается по последствиям отказа; универсальное правило «при потере связи всегда trip» столь же неверно, как «продолжать по последнему значению».

• ProcessTrue / ProcessFalse — подтверждённое технологическое состояние;
• DataUnknown — значение нельзя считать актуальным;
• CommunicationLost — обнаружена конкретная проблема канала;
• FallbackActive — система перешла к заранее согласованному поведению;
• RecoveryPending — связь появилась, но условия возврата ещё не подтверждены.

Сквозная трассировка причины от схемы до FAT

Строке cause-and-effect полезно присвоить стабильный ID и сохранить его в спецификации логики, диагностическом интерфейсе, alarm list и тестовом сценарии. Тогда формулировка «низкое давление» не распадается на разные обозначения в PLC, SCADA и протоколе FAT.

Для каждой строки проверяются применимость по режимам, задержка, действие, latch, reset, приоритет отображения, текст для оператора и требуемое evidence. Если решение меняется, impact analysis показывает затронутые блоки, экраны и тесты. Это не заменяет независимую проверку safety-функций, но заметно снижает риск несогласованных правок обычной управляющей логики.

• Cause ID → источник и технологический смысл;
• Logic ID → условие, режим и действие PLC;
• HMI/Alarm ID → отображение и ожидаемое действие оператора;
• Test ID → воздействие, ожидаемый результат и evidence;
• Revision ID → версия, в которой связь была проверена.