МЕТОД БЕЗОПАСНОЙ ДИАГНОСТИКИ ДИСКРЕТНОЙ АРМАТУРЫ В ПЛК ПО ОБРАТНЫМ СВЯЗЯМ И ВРЕМЕНИ ХОДА

A METHOD FOR SAFE DIAGNOSIS OF DISCRETE VALVES IN PLC SYSTEMS USING FEEDBACKS AND TRAVEL TIME

Berdikulova Dinora Farhodovna

Second-year postgraduate student, National University of Science and Technology MISIS, lead automation software engineer, Albacor IIR Limited Liability Company

Russia, Moscow

Аннотация

Рассматривается задача безопасной диагностики дискретной арматуры в программируемом логическом контроллере, когда команда перемещения и две конечные обратные связи должны быть интерпретированы совместно. Предложен метод, в котором для каждого клапана задаётся диагностический контракт: семантика команды, взаимная исключаемость сигналов открытого и закрытого положения, допустимое время хода, правила фиксации переходного состояния и реакция на неисправность. В отличие от логики, использующей только текущие значения обратных связей, метод различает нормальный переход, противоречивые сигналы, отсутствие подтверждения положения и превышение времени хода. На основе проектной модели функционального блока ПЛК сформирован эталонный набор из 28 сценариев, включающий штатные положения, переходы и инъекции отказов. Во всех сценариях вердикт модели совпал с ожидаемым, а 12 сценариев неисправностей не были ошибочно отнесены к нормальному состоянию. Результат предназначен для повторно используемых блоков управления клапанами и унифицированных диагностических экранов; натурные показатели надёжности и время реакции конкретного оборудования в работе не измеряются.

Abstract

The paper considers safe diagnosis of discrete valves in a programmable logic controller when a movement command and two end-position feedbacks must be interpreted together. A diagnostic contract is defined for each valve: command semantics, mutual exclusion of open and closed feedbacks, admissible travel time, transition-state rules, and the response to a fault. Unlike logic based only on current feedback values, the method distinguishes a normal transition, contradictory feedbacks, missing position confirmation, and travel-time violation. An oracle test set of 28 scenarios was formed from a PLC function-block model, including steady states, transitions, and fault injections. The model verdict matched the expected verdict in all cases, and 12 fault scenarios were not misclassified as normal. The result is intended for reusable valve-control blocks and standardized diagnostic screens; field reliability indicators and the response time of a particular equipment installation were outside the scope of the study.

Ключевые слова: дискретный клапан; ПЛК; обратная связь; время хода; безопасное состояние; функциональный блок; АСУ ТП; диагностика отказов; операторский интерфейс.

Keywords: discrete valve; programmable logic controller; position feedback; travel time; safe state; function block; industrial control system; fault diagnosis; operator interface.

Постановка задачи

Дискретная арматура является конечным исполнительным элементом технологического контура: её положение определяет направление потока, возможность выполнения операции и безопасность перехода к следующему шагу алгоритма. В типовой АСУ ТП команда клапану передаётся от ПЛК, а факт положения возвращается двумя дискретными сигналами: GSO — «клапан открыт» и GSC — «клапан закрыт». Такая структура кажется простой, однако её недостаточно интерпретировать набором независимых условных операторов. Сигналы могут быть одновременно активны из-за неисправности датчиков, одновременно отсутствовать во время движения, а команда может не привести к достижению конечного положения за допустимое время.

В инженерной практике эти ситуации часто сводятся к одному признаку «авария клапана». Это позволяет остановить последовательность, но не даёт оператору достаточной информации для поиска причины и затрудняет повторное использование блока на разных объектах. Подходы к обнаружению и диагностике отказов в технологических системах подробно рассмотрены в [1]. Дополнительный риск возникает при ошибочном признании состояния нормальным: например, если система не различает переходное состояние и потерю обратной связи, следующий шаг может быть разрешён до фактического завершения движения. Поэтому диагностическая функция должна проверять не только логическую согласованность сигналов, но и соответствие их временной модели.

Работа основана на проектной структуре универсального блока дискретной арматуры для ПЛК. В состав интерфейса входят Open_Cmd, GSO, GSC, сигнал аварии, признак ручного режима и команда сброса. Выходы блока включают команду управления, код состояния, признаки неисправности обратной связи и превышения времени хода. Для трёхходового клапана дополнительно задаётся безопасное положение, выбираемое проектом. В статье сохраняется разделение функций: диагностический блок формирует достоверный вердикт и безопасную реакцию, а конкретная логика технологического маршрута определяет, когда перемещение разрешено.

Цель и критерии метода

Цель исследования — разработать и проверить метод детерминированной диагностики дискретной арматуры, который может быть реализован как повторно используемый функциональный блок в среде программирования ПЛК. Метод должен обеспечивать четыре свойства: корректную классификацию устойчивых положений, безопасную обработку переходов, разделение причин отказа и воспроизводимость результата при одинаковом наборе входных данных. В качестве критерия корректности используется совпадение вердикта блока с эталонным вердиктом сценария; в качестве критерия безопасности — отсутствие нормального вердикта при противоречивых сигналах или истёкшем времени перемещения. Такой набор проверяемых свойств согласуется с требованиями к качеству программных систем [2].

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

Контракт фиксирует не только имена переменных, но и правила, по которым их значения превращаются в состояние объекта. Минимальная конфигурация представлена в табл. 1. Параметр τ_move задаётся для конкретной арматуры с учётом привода и технологического участка; универсальное значение для всех клапанов не вводится.

Таблица 1.

Состав диагностического контракта дискретного клапана

Для текущего цикла k контракт представляется кортежем:

K(k) = (Open_Cmd(k), GSO(k), GSC(k), t(k), τ_move, Reset(k), Safe_Position).

Здесь t(k) — время, прошедшее с момента обнаружения перехода или изменения команды. Входы GSO и GSC описывают физический результат движения, поэтому одна только команда не является подтверждением положения. Ввод временной компоненты позволяет отличить допустимое отсутствие конечной обратной связи во время движения от ситуации, в которой привод не выполнил команду в установленный срок.

Состояния и правила классификации

В блоке используются четыре внешних кода: 0 — промежуточное положение или движение, 1 — закрыто, 2 — открыто, 4 — авария. Код 0 намеренно не трактуется как неисправность: он нужен для технологических алгоритмов, которые должны ожидать завершения движения. Код 4 формируется при нарушении контракта и блокирует штатную команду до выполнения предусмотренной проектом безопасной реакции.

C_fb(k) = GSO(k) ∧ GSC(k).

Если C_fb(k) = 1, обратные связи противоречивы и вердикт немедленно переводится в код 4 независимо от команды. Если обе обратные связи равны нулю, состояние считается переходным только до истечения τ_move. При t(k) > τ_move формируется Fault_Time. Если активна только GSO, вердикт равен 2; если активна только GSC, вердикт равен 1. Смена команды, не подтверждённая соответствующей обратной связью, запускает или поддерживает контроль времени хода.

Таблица 2.

Правила перехода от сигналов к коду состояния

Как показано на рис. 1, проверка согласованности и временная проверка выполняются до формирования вердикта функционального блока. Благодаря этому HMI получает не только цвет состояния, но и причину, которая может быть выведена в журнал аварий: Fault_FB, Fault_Time или Fault_Command. Такая декомпозиция полезна при наладке, поскольку оператор и инженер видят различие между отказом датчика положения и механическим неисполнением команды.

Алгоритм функционального блока

Алгоритм реализуется циклически и не зависит от конкретного маршрута технологического процесса. На первом шаге фиксируется изменение команды и обнуляется локальный таймер перехода. На втором шаге проверяется взаимная исключаемость GSO и GSC. На третьем шаге определяется устойчивое положение либо переходное состояние. На четвёртом шаге проверяется тайм-аут. При активной аварии команда на привод снимается; для трёхходового клапана дополнительно выдаётся проектное безопасное положение.

В приведённой последовательности Fault_Time вычисляется отдельной частью блока как признак истечения таймера при отсутствии подтверждения конечного положения. Сброс не должен маскировать активную причину: Reset разрешает очистить зафиксированный код только после возврата входов в согласованное состояние и завершения диагностического цикла. Это исключает ситуацию, при которой оператор квитирует сообщение, а команда снова разрешается при сохранённом отказе.

Для дискретной арматуры с одной командой Open_Cmd безопасная логика должна учитывать направление перехода. При TRUE ожидается GSO, при FALSE — GSC. Если оба сигнала отсутствуют, объект остаётся в состоянии 0 до истечения таймера. Если фактическая конфигурация использует две взаимоисключающие команды, контракт расширяется полем Command_Conflict; общая схема диагностики при этом сохраняется.

Анализ отказов и интеграция с HMI

Для прикладной разработки важно разделять код состояния и код причины. Состояние используется визуальным объектом и последовательным алгоритмом, а причина — журналом аварий, сервисным экраном и диагностикой при наладке. Табл. 3 показывает минимальный набор отказов, который должен покрываться единым блоком.

Таблица 3.

Отказы, распознаваемые контрактом клапана

На HMI рекомендуется отображать состояние крупным цветовым индикатором, а причину неисправности — текстом и кодом в едином формате для всех объектов. Для состояния 0 оператор должен видеть признак движения или ожидания подтверждения, а не аварийный цвет. Для состояния 4 команда «Пуск» или команда изменения направления не должна выглядеть доступной, пока блокировка не снята по заданному алгоритму. Требования к структуре операторского интерфейса соответствуют ANSI/ISA-101.01 – 2015 [3], а правила управления тревогами — ANSI/ISA-18.2 – 2016 [4].

Модельная проверка

Проверка выполнена на модели функционального блока и не заменяет приёмочные испытания на объекте. Эталонные вердикты задавались независимо от условных операторов реализации: для каждого сценария фиксировались команда, обратные связи, время перехода и ожидаемый код. Такой подход снижает риск подтвердить корректность блока самим же кодом, который проверяется. Набор включает 28 сценариев: штатные положения, переходы, противоречивые сигналы, тайм-ауты и восстановление после отказа.

Таблица 4.

Состав и результат контрольной проверки

A = N_match / N_total = 28 / 28 = 1,00.

В результате A = 1,00: все 28 вердиктов модели совпали с эталоном. Внутри выборки было 12 сценариев отказа и 16 сценариев штатной работы; ни один отказ не получил код 1 или 2. Это не означает доказанную вероятность безотказной работы оборудования, а подтверждает логическую полноту выбранных ветвей на заданном наборе условий. Для анализа полноты диагностического покрытия удобно использовать показатель:

C_fault = N_{fault detected} / N_fault = 12 / 12 = 1,00.

В модели также проверено свойство безопасной реакции: при Fault_FB или Fault_Time штатная команда на привод снимается до выполнения Reset и устранения причины. Временная граница обнаружения тайм-аута в реальном ПЛК определяется периодом цикла и точностью системного таймера; аналитически она ограничена величиной τ_move + T_cycle. Фактическое значение T_cycle в статье не измеряется.

Обсуждение применимости

Преимущество метода состоит в том, что он переводит диагностику из набора локальных проверок в явно заданный контракт объекта. Это упрощает тиражирование блока на клапаны с разным временем хода, унифицирует коды HMI и позволяет заранее согласовать безопасную реакцию с технологическим алгоритмом. Подходы к диагностике исполнительных механизмов и моделированию отказов рассмотрены в [5]. По сравнению с логикой, которая определяет состояние только по GSO и GSC, предложенная схема добавляет временное ограничение и делает переходное состояние самостоятельным кодом. Тем самым исключается преждевременное разрешение следующей операции при незавершённом движении.

Ограничения исследования связаны с уровнем верификации. Рассмотрена модель дискретных сигналов и логика функционального блока; не проводились измерения реального времени хода, дребезга контактов, отказов кабельных линий, качества питания, пневматической или электрической части привода. Не задано универсальное безопасное положение, поскольку оно зависит от технологического риска конкретного клапана. Перед вводом в эксплуатацию необходимы стендовые испытания с генерацией обеих обратных связей, проверкой таймера, аварийным снятием команды и подтверждением поведения HMI.

Практическая последовательность приёмки должна включать: проверку всех комбинаций GSO/GSC; изменение команды на границах состояния; ввод задержки больше τ_move; имитацию одновременной активности концевиков; проверку Reset при активной и устранённой неисправности; контроль записи причин в журнале. Такой сценарный подход соответствует принципам верификации программируемых систем управления [6, 7] и рекомендациям по защите систем операционных технологий [8].

Заключение

Разработан метод безопасной диагностики дискретной арматуры в ПЛК по двум конечным обратным связям и времени хода. Метод основан на диагностическом контракте, который фиксирует семантику команды, допустимые сочетания сигналов, временное ограничение и безопасную реакцию. Сформирована классификация из четырёх кодов: промежуточное состояние, закрыто, открыто и авария.

Модельная проверка на 28 эталонных сценариях дала полное совпадение ожидаемых и фактических вердиктов; 12 сценариев неисправностей не были ошибочно классифицированы как нормальные. Полученный результат создаёт основу для повторно используемого функционального блока ПЛК, унифицированного лицевого элемента HMI и единых правил журналирования. Следующий этап прикладной разработки — стендовая проверка на контроллере с имитацией задержек, дребезга, обрыва обратной связи и аварийного снятия команды.

Вклад автора

Постановка задачи, разработка диагностического контракта, формирование алгоритма, подготовка эталонных сценариев, анализ результатов и подготовка рукописи выполнены Бердикуловой Д.Ф.

Список литературы

1. Venkatasubramanian V., Rengaswamy R., Yin K., Kavuri S.N. A review of process fault detection and diagnosis: Part I: Quantitative model-based methods // Computers & Chemical Engineering. – 2003. – Т. 27, № 3. – P. 293⁠–⁠311. – DOI: 10.1016/S0098-1354(02)00160-6.

2. ISO/IEC 25010:2023. Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Product quality model. Geneva: International Organization for Standardization [Электронный ресурс]. – URL: https://www.iso.org/standard/78176.html (accessed: 16.09.2026).

3. ANSI/ISA-101.01 Human Machine Interfaces for Process Automation Systems. Research Triangle Park: International Society of Automation [Электронный ресурс]. – 2015. – URL: https://www.isa.org/products/isa-101-01-2015-human-machine-interfaces-for (accessed: 16.09.2026).

4. ANSI/ISA-18.2 Management of Alarm Systems for the Process Industries. Research Triangle Park: International Society of Automation [Электронный ресурс]. – 2016. – URL: https://www.isa.org/products/ansi-isa-18-2-2016-management-of-alarm-systems-for (accessed: 16.09.2026).

5. Isermann R. Fault-Diagnosis Applications: Model-Based Condition Monitoring: Actuators, Drives, Machinery, Plants, Sensors, and Fault-Tolerant Systems. Berlin; Heidelberg: Springer. – 2011. – 372 P. – DOI: 10.1007/978-3-642-12767-0.

6. IE:2013. Programmable controllers – Part 3: Programming languages. Geneva: International Electrotechnical Commission [Электронный ресурс]. – P. 61131⁠–⁠3. – URL: https://webstore.iec.ch/en/publication/4552 (accessed: 16.09.2026).

7. IE:2010. Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements. Geneva: International Electrotechnical Commission [Электронный ресурс]. – P. 61508⁠–⁠1. – URL: https://webstore.iec.ch/en/publication/5515 (accessed: 16.09.2026).

8. Stouffer K., Pease M., Tang C. et al. Guide to Operational Technology (OT) Security. NIST Special Publication 800⁠–⁠82 Revision 3. – Gaithersburg: National Institute of Standards and Technology, 2023. – DOI: 10.6028/NIST.SP.800-82r3.