ГОСТ Р 72216-2025. Национальный стандарт Российской Федерации. Цифровая промышленность. Унифицированная архитектура OPC. Часть 9. Аварийные сигналы и условия

(утв. и введен в действие Приказом Росстандарта от 27.10.2025 № 1280-ст)

от 27 октября 2025 г. № 1280-ст

ГОСТ Р 72216-2025

35.100.05

30 января 2026 года

Предисловие

1 РАЗРАБОТАН Ассоциацией «Цифровые инновации в машиностроении» (АЦИМ) и Федеральным государственным бюджетным учреждением «Российский институт стандартизации» (ФГБУ «Институт стандартизации»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 306 «Измерения, управление и автоматизация в промышленных процессах»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 октября 2025 г. № 1280-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта МЭК 62541-9:2020 «Унифицированная архитектура OPC. Часть 9. Аварийные сигналы и условия» (IEC 62541-9:2020 «OPC unified architecture — Part 9: Alarms and Conditions», NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

Система стандартов в цифровой промышленности имеет важное значение для управления процессами цифровой трансформации и создания умных (интеллектуальных) производств, основанных на интеграции и интероперабельности различных автоматизированных систем управления, технологического оборудования, промышленных роботов, средств оснащения, контроллеров и датчиков.

В настоящем стандарте определены информационная модель, связанная с описанием аварийных сигналов и условий в открытой платформе взаимодействия OPC, а также основные понятия в этой области.

Настоящий стандарт является девятой частью серии стандартов «Цифровая промышленность. Унифицированная архитектура OPC».

1 Область применения

Настоящий стандарт определяет аварийные сигналы и условия в соответствии с унифицированной архитектурой (UA) открытой платформы взаимодействия (OPC). В стандарте приведены термины и определения, относящиеся к аварийным сигналам и условиям, выполняемым серверами и устройствами путем реализации программного кода.

Настоящий стандарт необходимо использовать совместно с другими стандартами серии «Цифровая промышленность. Унифицированная архитектура OPC».

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р МЭК 62682 Системы аварийной сигнализации для обрабатывающей промышленности

ГОСТ Р 71808 Цифровая промышленность. Унифицированная архитектура OPC. Часть 3. Модель адресного пространства

ГОСТ Р 71809 Цифровая промышленность. Унифицированная архитектура OPC. Часть 4. Сервисы

ГОСТ Р 71810 Цифровая промышленность. Унифицированная архитектура OPC. Часть 5. Информационная модель

ГОСТ Р 72214 Цифровая промышленность. Унифицированная архитектура OPC. Часть 7. Профили

ГОСТ Р 72215 Цифровая промышленность. Унифицированная архитектура OPC. Часть 8. Доступ к данным

ГОСТ Р 72218 Цифровая промышленность. Унифицированная архитектура OPC. Часть 11. Доступ к хронологическим данным

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 признание (acknowledge): Действие оператора, указывающее на распознавание сигнала тревоги.

3.2 активное состояние (active): Состояние для сигнала тревоги, которое указывает на то, что ситуация, которую представляет сигнал тревоги, в настоящее время существует.

3.3 адаптивная сигнализация (adaptive alarm): Аварийный сигнал, для которого заданное значение или предельные значения изменяются с помощью алгоритма.

Примечание - Аварийные сигналы, которые автоматически настраиваются с помощью алгоритмов. Эти алгоритмы могут определять условия на предприятии и изменять заданные значения или предельные значения, чтобы предотвратить возникновение аварийных сигналов. Во многих случаях эти изменения происходят без участия оператора.

3.4 аварийное состояние (alarm flood): Состояние, при котором частота срабатывания сигнализации превышает возможности оператора эффективно ими управлять.

Примечание — OPC UA не определяет условия, которые можно было бы считать аварийным состоянием, эти условия определены в ГОСТ Р МЭК 62682.

3.5 группа подавления аварийных сигналов (alarm suppression group): Группа аварийных сигналов, которая используется для подавления других аварийных сигналов.

Примечание - Это тип группы аварийных сигналов, который используется для подавления других аварийных сигналов. Если активен какой-либо аварийный сигнал в группе, то активна и группа подавления аварийных сигналов. Если все сигналы тревоги в группе подавления сигналов тревоги неактивны, то группа подавления сигналов тревоги неактивна.

3.6 класс состояния (condition class): Группировка условий, указывающая в какой области или для какой цели используется определенное условие.

Примечание - В данной спецификации определены некоторые классы условий верхнего уровня. Поставщики или организации могут создавать более конкретные классы или определять другие классы верхнего уровня.

3.7 ветвь условий (condition branch): Конкретное состояние условия.

Примечание - Сервер может поддерживать ветви условий как для текущего состояния, так и для предыдущих состояний.

3.8 источник условия (condition source): Элемент, на котором основано конкретное условие или с которым оно связано.

Примечание - Обычно это переменная, представляющая тег процесса или объект, представляющий устройство или подсистему.

3.9 подтверждение (confirm): Действие оператора, информирующее сервер о том, что были предприняты корректирующие действия для устранения причины срабатывания сигнализации.

3.10 отключение (shutdown): Действие, настраивающее систему таким образом, чтобы сигнал тревоги не подавался, даже если присутствует базовое состояние тревоги.

3.11 сигнализация защелкивания (latching alarm): Сигнал тревоги, который остается в аварийном состоянии после того, как состояние процесса нормализовалось, и требует сброса оператором, прежде чем сигнал тревоги вернется в нормальное состояние.

Примечание - Сигналы тревоги с фиксацией, как правило, являются сигналами несоответствия, когда действие не выполняется в течение определенного времени. Как только происходит действие, сигнал тревоги остается активным до тех пор, пока он не будет сброшен.

3.12 оператор (operator): Специальный пользователь, которому поручено отслеживать и контролировать часть процесса.

3.13 обновление (refresh): Действие по обновлению подписки на события, которая предоставляет все аварийные сигналы, которые считаются сохраненными.

3.14 удержание (retain): Сигнал тревоги в состоянии, которое представляет интерес для клиента, желающего синхронизировать свое состояние условий с состоянием сервера.

3.15 стеллаж (shelving): Устройство, позволяющее оператору временно отключить отображение сигнала тревоги, если он причиняет оператору неудобства.

3.16 подавление (suppress): Действие по определению того, не должен ли возникать сигнал тревоги.

Примечание - Сигнал тревоги подавляется, когда применяются логические критерии, определяющие, что сигнал тревоги не должен возникать, даже если присутствует базовое состояние тревоги (например, превышена установка сигнала тревоги).

4 Концептуальные положения

4.1 Общие положения

Настоящий стандарт определяет информационную модель для условий, диалоговых окон и аварийных сигналов, включая возможности подтверждения. Он основан на базовой обработке событий, которая определена в ГОСТ Р 71808, ГОСТ Р 71809 и ГОСТ Р 71810. Эта информационная модель также может быть расширена для удовлетворения дополнительных потребностей конкретных областей. Подробная информация о том, какие аспекты информационной модели поддерживаются, определяется с помощью профилей, которые приведены в ГОСТ Р 72214. Некоторые системы могут предоставлять доступ к историческим событиям и условиям с помощью стандартной структуры доступа к хронологическим данным в соответствии с ГОСТ Р 72218.

4.2 Условия

Условия используются для представления состояния системы или одного из ее компонентов, например:

• температура, превышающая установленный предел;
• устройство, нуждающееся в техническом обслуживании;
• пакетный процесс, требующий от пользователя подтверждения какого-либо шага процесса перед продолжением.

Каждый экземпляр условия относится к определенному типу условий. Тип условия и производные типы являются подтипами базового типа события согласно ГОСТ Р 71808 и ГОСТ Р 71810. Поставщики определяют дополнительные типы условий, основанные на общих базовых типах, определенных в этой части. Типы условий, поддерживаемые сервером, отображаются в адресном пространстве сервера.

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

Условия представляют собой состояние системы или одного из ее компонентов. В некоторых случаях также должны сохраняться предыдущие состояния, которые все еще требуют внимания. Для выполнения этого требования и для различения текущего и предыдущих состояний вводятся ветви условий. Каждая ветвь условия имеет идентификатор, который отличает ее от других ветвей того же экземпляра. Ветвь условия, которая представляет текущее состояние условия (магистраль), имеет нулевой идентификатор. Серверы могут генерировать отдельные уведомления о событиях для каждой ветви. Когда состояние, представленное ветвью условия, не требует дальнейшего внимания, в уведомлении об окончательном событии для этой ветви свойству удержания будет присвоено значение «Ложь». Сохранение предыдущих состояний и следовательно поддержка нескольких ветвей необязательны для серверов.

Базовая модель состояния показана на рисунке 1. Она расширяется за счет различных подтипов состояния, определенных в этом стандарте, и может быть дополнительно расширена поставщиками. Основные состояния — отключенное состояние и включенное состояние. Отключенное состояние предназначено для того, чтобы разрешить отключение условий на сервере или под сервером (в устройстве или какой-либо базовой системе). Включенное состояние обычно расширяется за счет добавления подсостояний.

Рисунок 1 — Модель базового состояния

Переход в отключенное состояние приводит к возникновению условного события, однако никаких последующих действий не происходит.

Уведомления о событиях генерируются до тех пор, пока условие не вернется во включенное состояние. Когда условие переходит во включенное состояние, этот переход и все последующие переходы приводят к тому, что сервер генерирует события условия.

Если сервер поддерживает аудит, необходимо выполнить действие, связанное с аудитом. Сервер будет генерировать события аудита для включения и отключения операций (либо с помощью вызова метода, либо с помощью каких-либо средств, зависящих от сервера/поставщика), а не генерировать уведомление о событии аудита для каждого включенного или отключенного экземпляра условия.

4.3 Подтверждаемые условия

Подтверждаемые условия являются подтипами базового типа условий. Подтверждаемые условия предоставляют состояния, указывающие, должно ли условие быть подтверждено.

Незавершенное состояние и подтвержденное состояние расширяют разрешенное состояние, определенное условием. Модель состояния показана на рисунке 2. Включенное состояние расширяется путем добавления заблокированного состояния и (необязательно) подтвержденного состояния.

Рисунок 2 — Модель состояния подтверждаемых условий

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

В настоящем стандарте описаны две модели состояния подтверждения. Любая из этих моделей состояния может быть расширена для поддержки более сложных ситуаций подтверждения.

Базовая модель состояния подтверждения показана на рисунке 3. Эта модель определяет состояние подтверждения. Конкретные изменения состояния, которые приводят к изменению состояния, зависят от реализации сервера. Например, в типичных моделях сигнализации изменение ограничивается переходом в активное состояние или переходами в пределах активного состояния. Однако более сложные модели могут также допускать изменение заблокированного состояния при переходе в неактивное состояние.

Рисунок 3 — Подтверждающая модель состояния

Более сложная модель состояния показана на рисунке 4. Эта модель обычно используется для проведения различия между подтверждением наличия состояния и выполнением каких-либо действий по устранению этого состояния. Например, оператор, получивший уведомление о высокой температуре двигателя, вызывает метод подтверждения, чтобы сообщить серверу о том, что была обнаружена высокая температура. Затем оператор выполняет некоторые действия, например снижает нагрузку на двигатель, чтобы снизить температуру. Далее оператор вызывает метод подтверждения, чтобы сообщить серверу о том, что были предприняты корректирующие действия.

Рисунок 4 — Подтвержденная модель состояния подтверждения

4.4 Предыдущие состояния условий

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

Несколько ветвей условий также можно использовать для других случаев использования, когда снимки предыдущих состояний условия требуют дополнительных действий.

4.5 Синхронизация состояний условий

Когда клиент подписывается на события, уведомление о переходах начинается во время подписки. Текущее состояние не сообщается. Это означает, что клиенты не получают информацию о текущих активных сигналах тревоги до тех пор, пока не произойдет новое изменение состояния.

Клиенты могут получать текущее состояние всех экземпляров условий, которые находятся в интересующем состоянии, запрашивая обновление для подписки. Обновление не является общей возможностью воспроизведения, поскольку сервер не ведет журнал событий.

Клиенты запрашивают обновление, вызывая метод обновления условий. Сервер отвечает событием начала обновления. За этим событием следуют сохраненные условия. Сервер также может отправлять уведомления о новых событиях, чередуя их с уведомлениями о событиях, связанных с обновлением. После того, как сервер завершит обновление, будет выдано сообщение об обновлении конечного события, отмечающее завершение обновления. Клиенты должны проверять наличие нескольких уведомлений о событиях для ветви условия, чтобы избежать перезаписи нового состояния, переданного вместе с более старым состоянием из процесса обновления. Если ветвь условия существует, то должно быть сообщено о текущем состоянии.

Клиент, который хочет отображать текущее состояние аварийных сигналов и условий (известное как «отображение текущего аварийного сигнала»), будет использовать следующую логику для обработки уведомлений о событиях обновления. Клиент помечает все сохраненные условия как подозрительные при получении события типа обновления стартового мероприятия. Клиент добавляет все новые события, полученные во время обновления, не помечая их как подозрительные. Клиент также снимает флаг «Подозрительный» с любых сохраненных условий, которые возвращаются в рамках обновления. Когда клиент получает обновление конечного события, он удаляет все оставшиеся подозрительные события, поскольку они больше не применяются.

В отношении обновления условий следует обратить внимание на следующее:

1. согласно 4.4 некоторые системы требуют, чтобы предыдущие состояния условия сохранялись в течение некоторого времени. Некоторые серверы, в частности, если им требуется подтверждение предыдущих состояний, будут поддерживать отдельные ветви условий для предыдущих состояний, которые все еще требуют внимания;

2. при некоторых обстоятельствах сервер может быть не в состоянии обеспечить полную синхронизацию клиента с текущим состоянием экземпляров условий. Например, если базовая система, представленная сервером, сброшена или связь прервана на некоторый период времени, серверу может потребоваться повторная синхронизация с базовой системой. В таких случаях сервер должен отправить событие типа «требуется обновление», чтобы сообщить клиенту, что может потребоваться обновление. Клиент, получающий это специальное событие, должен инициировать обновление условий;

3. для того, чтобы клиент всегда был в курсе событий, три специальных типа событий (тип события окончания обновления, тип события начала обновления и тип события обязательного обновления) игнорируют фильтрацию содержимого событий, связанную с подпиской, и всегда доставляются клиенту;

4. условие обновления применяется к подписке. Если в одну и ту же подписку включено несколько уведомлений о событиях, обновляются все уведомления о событиях.

4.6 Ответственность, качество и комментарии

Комментарии, ответственность и качество являются важными элементами условий, и любое их изменение приведет к появлению уведомлений о событиях.

Ответственность состояния унаследована от базовой модели событий, определенной в ГОСТ Р 71810. Она указывает на срочность состояния и также обычно называется «приоритетом», особенно в отношении аварийных сигналов в классе условий процесса.

Комментарий — это сгенерированная пользователем строка, которая должна быть связана с определенным состоянием условия.

Качество относится к значению данных, на которых основано это условие. Поскольку условие обычно основано на одной или нескольких переменных, оно наследует качество этих переменных. Например, если значение процесса «Неопределенное», условие «Аварийный уровень» также вызывает сомнения. Если в данном условии представлено более одной переменной или если условие взято из выделенной системы и прямое сопоставление с переменной недоступно, приложение само определяет, какое качество отображается как часть условия.

4.7 Диалоговые окна

Диалоговые окна — это типы условий, используемые сервером для запроса пользовательского ввода. Обычно они используются, когда сервер переходит в какое-либо состояние, требующее вмешательства клиента. Например, сервер, контролирующий работу бумагоделательной машины, указывает, что рулон бумаги намотан и готов к проверке. Сервер активирует диалоговое окно, указывающее пользователю на необходимость проверки. Как только проверка будет выполнена, пользователь в ответ сообщит серверу о принятой или непринятой проверке, что позволит продолжить процесс.

4.8 Аварийные сигналы

Аварийные сигналы — это разновидности подтверждаемых состояний, которые добавляют к условию понятия активного состояния и других состояний, таких как отложенное состояние и подавленное состояние. Модель состояния показана на рисунке 5.

Рисунок 5 — Модель автомата состояний тревоги

Сигнал тревоги в активном состоянии указывает на то, что ситуация, которую представляет данное условие, существует в данный момент. Когда сигнал тревоги находится в неактивном состоянии, он представляет ситуацию, которая вернулась в нормальное состояние.

Некоторые подтипы сигналов тревоги содержат подсостояния активного состояния. Например, сигнал тревоги, представляющий температуру, может указывать как на состояние высокого уровня, так и на критически высокое состояние.

Состояние «Отложено» может быть установлено оператором с помощью методов OPC UA. Подавленное состояние устанавливается сервером внутри системы по причинам, зависящим от системы. Системы охранной сигнализации обычно реализуют функции подавления, выхода из строя и откладывания в «долгий ящик», чтобы помочь операторам избежать перегрузки во время «штормов тревоги», ограничивая количество сигналов тревоги, которые оператор видит на текущем дисплее сигнализации. Это достигается путем установки флажка «Подавлено» или «Отложено» для зависимых от второго порядка аварийных сигналов и/или менее серьезных аварийных сигналов, что позволяет оператору сосредоточиться на наиболее важных проблемах.

Состояния «Отложено», «Не работает» и «Подавлено» отличаются от состояния «Отключено» тем, что аварийные сигналы по-прежнему полностью функционируют и могут быть включены в уведомления о подписке для клиента.

Аварийные сигналы следуют типичной временной шкале, которая показана на рисунке 6. С ними связаны определенное время задержки и ряд состояний, которые они могут занимать.

Рисунок 6 — Типичный пример временной шкалы тревоги

4.9 Множественные активные состояния

В некоторых случаях желательно дополнительно определить активное состояние аварийного сигнала, предоставив автомат подсистемы для активного состояния. Например, сигнал тревоги с несколькими уровнями состояния, когда он находится в активном состоянии, может быть в одной из следующих областей: низкий уровень, высокий уровень или очень высокий уровень. Модель состояния показана на рисунке 7.

Рисунок 7 — Пример нескольких активных состояний

В модели аварийной сигнализации с несколькими состояниями разрешены переходы между активными подсостояниями, не приводящими к выходу из активного состояния.

Для учета различных вариантов использования поддерживаются как взаимоисключающие, так и неисключающие модели.

Исключительный уровень означает, что сигнал тревоги может подаваться только в одном подсостоянии одновременно.

Однако некоторые системы сигнализации допускают параллельное существование нескольких подсостояний (неисключительный уровень).

4.10 Экземпляры условий в адресной области

Поскольку условия всегда имеют состояние «Включено» или «Отключено» и множество подсостояний, имеет смысл размещать экземпляры условий в адресной области. Если сервер предоставляет экземпляры условий, они обычно отображаются в адресной области как компоненты объектов, которые владеют ими.

Доступность экземпляров позволяет клиентам иметь доступ к данным и отслеживать текущее состояние, подписываясь на значения атрибутов переменных узлов. Значения узлов не всегда соответствуют значениям, которые отображаются в событиях.

Хотя отображение экземпляров условия в адресной области не всегда возможно, это позволяет осуществлять прямое взаимодействие (чтение, запись и вызов метода) с конкретным экземпляром условия.

5 Модель

5.1 Общие положения

Модель аварийных сигналов и условий расширяет базовую модель событий OPC UA, определяя различные типы событий на основе базовых типов событий. Все типы событий, определенные в настоящем стандарте, могут быть дополнительно расширены для формирования аварийных сигналов и условий, специфичных для домена или сервера.

Экземпляры типов аварийных сигналов и состояний могут быть дополнительно представлены в адресном пространстве, чтобы обеспечить прямой доступ к состоянию аварийного сигнала или состояния.

На рисунке 8 описана иерархия типов условий. Подтипы предельного типа аварийной сигнализации и дискретного типа аварийной сигнализации не показаны.

Рисунок 8 — Иерархия типов условий

5.2 Конечные автоматы с двумя состояниями

Большинство состояний, определенных в настоящем стандарте, просты, т.е. они либо истинны, либо ложны. Тип переменной с двумя состояниями введен специально для этого варианта использования. Более сложные состояния моделируются с использованием типа конечного автомата, определенного в ГОСТ Р 71810.

Тип переменной с двумя состояниями является производным от типа переменной состояния, определенного в ГОСТ Р 71810 и указано в таблице 1.

Таблица 1

Определение типа переменной с двумя состояниями

Атрибут	Значение
Имя просмотра	Тип переменной с двумя состояниями
Тип данных	Локализованный текст
Ранг значения	-1 (-1 = Скалярная величина)
Аннотация	Ложь
Рекомендации	Класс узла	Имя просмотра	Тип данных	Определение типа	Правило моделирования
Подтип типа переменной состояния определен в ГОСТ Р 71810. Ссылка на этот подтип не указана в определении типа переменной состояния
Обладает свойством	Переменная	Идентификатор	Логический	Тип свойства	Обязательно
Обладает свойством	Переменная	Время перехода	Согласованное всемирное время	Тип свойства	Необязательно
Обладает свойством	Переменная	Действительное время перехода	Согласованное всемирное время	Тип свойства	Необязательно
Обладает свойством	Переменная	Истинное состояние	Локализованный текст	Тип свойства	Необязательно
Обладает свойством	Переменная	Ложное состояние	Локализованный текст	Тип свойства	Необязательно
Имеет истинное подсостояние	Конечный автомат или два типа переменной состояния	<Идентификатор состояния>	Определено в 5.4		Необязательно
Имеет ложное подсостояние	Конечный автомат или два типа переменной состояния	<Идентификатор состояния>	Определено в 5.4		Необязательно

Значение экземпляра типа переменной с двумя состояниями содержит текущее состояние в виде удобочитаемого имени.

Идентификатор наследуется от типа переменной состояния и переопределяется для отображения требуемого типа данных (логическое значение). Значение должно быть текущим состоянием, т.е. либо истинно, либо ложно.

Время перехода определяет, когда было введено текущее состояние. Эффективное время перехода определяет, когда было введено текущее состояние или одно из его подсостояний.

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

Другие необязательные свойства типа переменной состояния не имеют определенного значения для типа переменной с двумя состояниями.

Истинное и ложное состояния содержат локализованную строку для значения типа переменной с двумя состояниями, когда его свойство идентификатора имеет значение «Истина» или «Ложь» соответственно. Поскольку эти два свойства предоставляют метаданные для типа, серверы могут не разрешить выбирать эти свойства в фильтре событий для отслеживаемого объекта. Клиенты могут использовать службу чтения для получения информации из определенного типа условий.

5.3 Условная переменная

Различные информационные элементы условия не считаются состояниями. Однако изменение их значения считается важным и должно вызывать уведомление о событии. Эти информационные элементы называются переменными условия.

Переменные условия представлены типом переменной условия и определены в таблице 2.

Таблица 2

Определение типа переменной условия

Атрибут	Значение
Имя просмотра	Тип переменной условия
Тип данных	Базовый тип данных
Ранг значения	-2 (-2 = Любой)
Аннотация	Ложь
Рекомендации	Класс узла	Имя просмотра	Тип данных	Определение типа	Правило моделирования
Подтип типа базовой переменной данных определен в ГОСТ Р 71810
Обладает свойством	Переменная	Исходная временная метка	Согласованное всемирное время	Тип свойства	Обязательно

5.4 Ссылочные типы

В данном разделе определяются ссылочные типы, которые необходимы помимо тех, которые уже указаны в ГОСТ Р 71808 и ГОСТ Р 71810. Это включает в себя расширение автоматов состояний типа переменной с двумя состояниями и добавление группировки сигналов тревоги.

Ссылки на тип переменной с двумя состояниями будут существовать только тогда, когда доступны подсостояния.

5.5 Модель условий

5.5.1 Общие положения

Модель условий расширяет модель событий, определяя тип условий. Тип условий вводит понятие состояний, отличающее его от базовой модели событий. В отличие от базового типа событий условия не являются временными. Тип условия дополнительно расширен до диалогового и подтверждаемого типов условий, каждый из которых имеет свои собственные подтипы.

5.5.2 Тип условия

Тип условия определяет все общие характеристики условия. Все остальные типы условий являются производными от него. Тип условия определен в таблице 3.

Таблица 3

Определение типа условия

Атрибут	Значение
Имя просмотра	Тип условия
Аннотация	Истина
Рекомендации	Класс узла	Имя просмотра	Тип данных	Определение типа	Правило моделирования
Подтип типа базовой переменной данных определен в ГОСТ Р 71810
Имеет подтип	Тип объекта	Тип условия диалога	Определено в 5.6
Имеет подтип	Тип объекта	Тип признанного условия	Определено в 5.7
-	-	-	-	-	-
Имеет свойство	Переменная	Идентификатор класса условий	Идентификатор узла	Тип свойства	Обязательно
Имеет свойство	Переменная	Имя класса условий	Локализованный текст	Тип свойства	Обязательно
Имеет свойство	Переменная	Идентификатор подкласса условий	Идентификатор узла	Тип свойства	Необязательно
Имеет свойство	Переменная	Имя подкласса условий	Локализованный текст	Тип свойства	Необязательно
Имеет свойство	Переменная	Название условия	Строка	Тип свойства	Обязательно
Имеет свойство	Переменная	Идентификатор ветви	Идентификатор узла	Тип свойства	Обязательно
Имеет свойство	Переменная	Удержание	Логический	Тип свойства	Обязательно
Имеет свойство	Переменная	Включенное состояние	Локализованный текст	Тип переменной с двумя состояниями	Обязательно
Имеет составную часть	Переменная	Качество	Код состояния	Изменяемый тип условия	Обязательно
Имеет составную часть	Переменная	Последняя степень тяжести	[0 : 65535]	Изменяемый тип условия	Обязательно
Имеет составную часть	Переменная	Комментарий	Локализованный текст	Изменяемый тип условия	Обязательно
Имеет свойство	Переменная	Идентификатор пользователя-клиента	Строка	Тип свойства	Обязательно
-	-	-	-	-	-
Имеет составную часть	Метод	Отключение	Определено в 5.5.4		Обязательно
Имеет составную часть	Метод	Включение	Определено в 5.5.5		Обязательно
Имеет составную часть	Метод	Добавление комментария	Определено в 5.5.6		Обязательно
Имеет составную часть	Метод	Обновление условия	Определено в 5.5.7		Отсутствует
Имеет составную часть	Метод	Обновление условия 2	Определено в 5.5.8		Отсутствует

Тип условия наследует все свойства базового типа события. Их семантика определена в ГОСТ Р 71810. Свойство исходного узла идентифицирует источник условия. Если источник условия не является узлом в адресной области, идентификатору узла присваивается нулевое значение. Свойство исходного узла — это узел, с которым связано условие, оно может быть таким же, как и входной узел для сигнала тревоги, но может быть и отдельным узлом.

Идентификатор класса условия указывает, в каком домене используется это условие. Это идентификатор узла соответствующего подтипа базового класса условий. При использовании этого свойства для фильтрации клиенты должны указывать все индивидуальные подтипы идентификаторов узлов базового класса условия. Тип базового класса условия используется в качестве класса всякий раз, когда условие не может быть присвоено более конкретному классу.

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

Имя условия определяет экземпляр условия, из которого возникло событие. Его можно использовать вместе с именем источника в пользовательском окне для распознания различных экземпляров условия. Если у источника условия есть только один экземпляр условия, а у сервера нет имени экземпляра, сервер должен указать имя для просмотра типа условия.

Нулевой идентификатор ветви используется для всех уведомлений о событиях, относящихся к текущему состоянию экземпляра условия. Если идентификатор ветви не равен нулю, он идентифицирует предыдущее состояние этого экземпляра условия, которое все еще требует внимания оператора. Если текущее условие ветви преобразуется в предыдущее условие ветви, серверу необходимо присвоить ненулевой идентификатор ветви. Начальное событие для ветви будет сгенерировано со значениями условия ветви и нового идентификатора ветви. Ветвь условия может обновляться много раз, прежде чем она станет ненужной. Когда ветвь условия больше не требует ввода данных оператором, для конечного события сохранения будет установлено значение «Ложь». Бит сохранения текущего события равен «Истина», пока для любых условий ветви требуется ввод данных оператором.

Включенное состояние условия влияет на генерацию уведомлений о событиях и приводит к следующему специфическому поведению:

• когда экземпляр условия переходит в отключенное состояние, сервер устанавливает свойство сохранения этого условия в значение «Ложь», чтобы указать клиенту, что экземпляр условия в настоящее время не представляет интереса для клиентов;
• когда экземпляр условия переходит во включенное состояние, условие должно быть оценено и все его свойства должны быть обновлены, чтобы отразить текущие значения;
• сервер может продолжить проверку экземпляра условия, пока он отключен, однако, уведомления о событиях не будут генерироваться, пока экземпляр условия отключен;
• для любого условия, существующего в адресной области, атрибуты и следующие переменные будут продолжать иметь допустимые значения даже в отключенном состоянии: идентификатор события, тип события, исходный узел, имя источника, время и включенное состояние.

При изменении следующих компонентов должно быть вызвано уведомление о событии типа условия:

• качество;
• ответственность;
• комментарий.

Качество показывает состояние значений процесса или других ресурсов, на которых основан данный экземпляр условия. Значения качества могут быть любыми из кодов состояния OPC, определенных в ГОСТ Р 72215 и ГОСТ Р 71809. Эти коды состояния аналогичны описанию качества данных в различных спецификациях полевой шины, но несколько более универсальны. Сервер несет ответственность за сопоставление внутренней информации о состоянии с этими кодами.

Идентификатор пользователя клиента связан с полем «Комментарий» и содержит идентификатор пользователя, который добавил последний комментарий. Логика получения идентификатора пользователя определена в ГОСТ Р 71810.

Идентификатор узла экземпляра условия используется как идентификатор условия. Он явно не моделируется как компонент типа условия. Однако может быть запрошен с помощью простого атрибутивного операнда (см. таблицу 4) в поле выбора пункта фильтра событий.

Простой атрибутивный операнд

Имя	Тип	Описание
Простой атрибутивный операнд	-	-
Идентификатор типа	Идентификатор узла	Идентификатор узла типа условия
Путь к просмотру	Полное имя	-
Идентификатор атрибута	Целочисленный идентификатор	Идентификатор для узла идентификатора атрибута

5.5.3 Экземпляры условий и ветвей

Условия — это объекты, состояние которых меняется с течением времени. Каждый экземпляр условия имеет идентификатор условия в качестве идентификатора, который однозначно идентифицирует его на сервере.

Экземпляром условия может быть объект, который отображается в адресном пространстве сервера. В этом случае идентификатор условия является идентификатором узла для объекта.

Состояние экземпляра условия в любой момент времени — это установленные значения для переменных, которые принадлежат экземпляру условия. При изменении одного или нескольких значений переменной сервер генерирует событие с уникальным идентификатором события.

Если клиент вызовет обновление, сервер сообщит о текущем состоянии экземпляра условия, повторно отправив последнее событие.

Ветвь условия — это копия состояния экземпляра условия, которая может изменяться независимо от текущего состояния экземпляра условия. Каждая ветвь имеет идентификатор, который является уникальным среди всех активных ветвей для экземпляра условия. Ветви обычно не видны в адресном пространстве.

5.5.4 Метод отключения

Метод отключения используется для перевода экземпляра условия в состояние отключения. Обычно службе вызова передается идентификатор узла экземпляра объекта в качестве идентификатора объекта. Однако некоторые серверы не предоставляют экземпляры условия в адресной области. Следовательно, все серверы должны разрешать клиентам вызывать метод отключения, указывая идентификатор условия в качестве идентификатора объекта.

5.5.5 Метод включения

Метод включения используется для перевода экземпляра условия во включенное состояние. Обычно службе вызова передается идентификатор узла экземпляра объекта в качестве его идентификатора. Однако некоторые серверы не предоставляют экземпляры условия в адресном пространстве. Следовательно, все серверы должны разрешать клиентам вызывать метод включения, указывая условия в качестве идентификатора объекта.

5.5.6 Метод добавления комментария

Метод добавления комментария используется для применения комментария к определенному состоянию экземпляра условия. Обычно идентификатор узла экземпляра объект передается в службу вызова в качестве идентификатора объекта. Все серверы должны разрешать клиентам вызывать метод добавления комментария, указывая условия в качестве идентификатора объекта.

5.5.7 Метод обновления условия

Обновление условия позволяет клиенту запросить обновление всех экземпляров условия, которые в данный момент находятся в интересующем состоянии (у которых установлен флаг «Сохранение»). Клиент обычно вызывает этот метод при первом подключении к серверу и в любых ситуациях, таких как сбои связи или когда требуется повторная синхронизация с сервером. Этот метод доступен только для типа условия или его подтипов.

5.5.8 Метод обновления условия 2

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

5.6 Модель диалога

5.6.1 Общие положения

Модель диалога является расширением модели условий, используемой сервером для запроса пользовательского ввода. Она обеспечивает функциональность, аналогичную стандартным диалогам сообщений, используемым в большинстве операционных систем. Модель можно легко настроить, предоставив параметры ответа, специфичные для сервера, в наборе параметров ответа и добавив дополнительные функциональные возможности к производным типам условий.

5.6.2 Тип диалогового условия

Тип диалогового условия используется для представления условий в виде диалогов. Это показано на рисунке 9.

5.7 Модель подтверждаемых условий

5.7.1 Общие положения

Модель подтверждаемых условий расширяет модель условий. В модель условий добавляются состояния для подтверждения и перепроверки.

Подтверждаемые условия представлены типом подтверждаемого условия, который является подтипом типа условия.

5.7.2 Тип подтверждаемого условия

Тип подтверждаемого условия расширяет тип условия, определяя характеристики подтверждения. Это абстрактный тип. Тип подтверждаемого условия показан на рисунке 10.

Рисунок 10 — Обзор типов подтверждаемых состояний

Подтверждаемый тип условия наследует все свойства типа условия.

5.8 Модель аварийных сигналов

5.8.1 Общие положения

На рисунке 11 представлен тип аварийного состояния, его подтипы и место в иерархии типов событий.

Рисунок 11 — Иерархическая модель типов аварийных состояний

5.8.2 Тип состояния аварийных сигналов

Тип аварийного состояния наследует все свойства типа подтверждаемого состояния. Следующие состояния являются субстратами истинного включенного состояния.

5.8.3 Тип группы аварийных сигналов

Тип группы аварийных сигналов предоставляет простой способ группировки аварийных сигналов. Эта группировка может использоваться для подавления аварийных сигналов или для идентификации связанных аварийных сигналов. Фактическое использование типа группы аварийных сигналов указано там, где он используется.

Экземпляру группы аварийных сигналов следует присвоить имя и описание, которые описывают назначение группы оповещений.

Экземпляр группы аварийных сигналов содержит список экземпляров условия аварийных сигналов или подтипа условия аварийных сигналов. В экземпляре типа группы аварийных сигналов должен присутствовать хотя бы один сигнал тревоги.

5.8.4 Способ сброса

Метод перезагрузки используется для сброса заблокированного экземпляра аварийного сигнала. Он доступен только для экземпляра условия аварийного сигнала, который предоставляет фиксированное состояние. Обычно идентификатор узла экземпляра объект передается в службу вызова как идентификатор объекта. Однако некоторые серверы не предоставляют экземпляры условия в адресной области. Поэтому серверы должны разрешать клиентам вызывать метод сброса, указывая идентификатор условия в качестве идентификатора объекта.

5.8.5 Метод отключения звука

Метод отключения звука используется для отключения определенного экземпляра аварийного сигнала. Он доступен только для экземпляра условия аварийного сигнала, который также предоставляет значение состояния тишины. Обычно идентификатор узла экземпляра объекта передается службе вызова как идентификатор объекта. Однако некоторые серверы не предоставляют экземпляры условия в адресной области. Поэтому серверы должны разрешать клиентам вызывать метод отключения, указывая идентификатор условия в качестве идентификатора объекта.

5.8.6 Метод подавления

Метод подавления используется для подавления конкретного экземпляра аварийного сигнала. Он доступен только для экземпляра условия аварийного сигнала, который также предоставляет подавленное состояние. Этот метод может быть использован для изменения подавленного состояния аварийного сигнала и перезаписи любого подавления, вызванного соответствующей группой поддержки тревоги.

5.8.7 Метод отмены подавления

Метод отмены подавления используется для снятия подавленного состояния с конкретного экземпляра аварийного сигнала. Он доступен только для экземпляра типа аварийного состояния, который также отображает подавленное состояние. Этот метод может быть использован для перезаписи любой причины подавления соответствующей группой подавления аварийных сигналов.

5.8.8 Метод вывода из эксплуатации

Метод вывода из эксплуатации используется для подавления конкретного экземпляра аварийного сигнала. Он доступен только для экземпляра типа аварийного состояния, который также предоставляет состояние выхода из строя. Серверы должны позволять клиентам вызывать состояние выхода из обслуживания, указывая условие в качестве идентификатора объекта.

5.8.9 Метод ввода в эксплуатацию

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

5.8.10 Тип предельного аварийного сигнала

Аварийные сигналы могут быть смоделированы с несколькими исключительными подсостояниями и назначенными ограничениями, или они могут быть смоделированы с неисключительными ограничениями, которые могут использоваться для группировки нескольких состояний вместе.

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

5.8.11 Аварийные сигналы о скорости изменения

Аварийный сигнал о скорости изменения обычно используется для сообщения о необычном изменении или отсутствии изменений в измеряемой величине, связанных со скоростью, с которой это значение изменилось. Сигнал тревоги о скорости изменения включается, когда скорость, с которой изменяется значение, превышает или опускается ниже определенного предела.

Скорость изменения измеряется в единицах времени, таких как секунды или минуты, и в некоторых единицах измерения, таких как проценты или метры.

5.8.12 Дискретные сигналы тревоги

5.8.12.1 Тип дискретной сигнализации используется для классификации типов аварийных состояний, при которых входные данные для аварийного сигнала могут принимать только определенное количество возможных значений (например, истина/ложь, выполняется/остановлен/завершается).

5.8.12.2 Тип аварийной сигнализации, отличающийся от нормы, является специализацией типа дискретной сигнализации, предназначенной для представления дискретного состояния, которое считается ненормальным. Этот подтип обычно используется для обозначения того, что дискретное значение находится в аварийном состоянии, и оно активно до тех пор, пока присутствует ненормальное значение.

5.8.12.3 Тип сигнала тревоги при выключении системы используется сервером для указания на то, что базовая система, предоставляющая информацию о тревоге, испытывает проблемы со связью.

5.8.12.4 Тип аварийной сигнализации отключения — это специализация типа выключения сигнала тревоги, предназначенная для отображения состояния отключения оборудования. Аварийная сигнализация включается, когда на контролируемом оборудовании возникает какая-либо ненормальная неисправность, например отключение двигателя из-за перегрузки.

5.8.12.5 Тип диагностического сигнала тревоги прибора является специализацией типа выключения сигнала тревоги, предназначенной для отображения неисправности в полевом устройстве. Сигнал тревоги включается, когда на контролируемом устройстве возникает неисправность, например отказ датчика.

5.8.12.6 Тип системного диагностического сигнала тревоги является специализацией типа выключения сигнала тревоги, он предназначен для отображения неисправности в системе или подсистеме. Сигнал тревоги включается, когда в контролируемой системе возникает неисправность.

5.8.12.7 Тип сигнала тревоги об истечении срока действия сертификата генерируется сервером, когда срок действия сертификата сервера находится в пределах допустимого срока действия. Этот сигнал тревоги автоматически возвращается в нормальное состояние при обновлении сертификата.

5.9 Классы условий

Условия используются в конкретных прикладных областях, таких как обслуживание, система или процесс. Иерархия классов условий используется для определения доменов и ортогональна иерархии типов условий. OPC UA определяет базовый тип объекта для всех классов условий и набор общих классов, используемых во многих отраслях.

Классы условий не являются представлениями объектов в базовой системе и следовательно существуют только как узлы типа в адресном пространстве.

5.10 События аудита

Ниже приведены подтипы типа события метода обновления аудита, которые будут генерироваться в соответствии с методами, определенными в этом стандарте. Они показаны на рисунке 12.

Рисунок 12 — Иерархия событий аудита

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

Типы событий условия аудита наследуют все свойства типа события метода обновления аудита, определенного в ГОСТ Р 71810. Если подтип не переопределяет определение, унаследованные свойства условия будут использоваться так, как они определены.

5.11 События, связанные с обновлением условий

Ниже приведены подтипы системных событий, которые будут генерироваться в ответ на вызов метода обновления. Они проиллюстрированы на рисунке 13.

5.12 Ссылочный тип, имеющий условие

Ссылочный тип, имеющий условие, является конкретным ссылочным типом и может использоваться напрямую. Это подтип неиерархических ссылок.

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

Ссылки на имеющиеся условия могут использоваться в определении типа объекта или переменной. В этом случае исходным узлом этого ссылочного типа должен быть узел типа объекта или переменной, или один из их узлов объявления экземпляра. Применяются следующие правила для создания экземпляров:

• все ссылки на имеющиеся условия, используемые в типе, должны существовать в экземплярах этих типов;
• если целевой узел в определении типа является условием, то в экземпляре будет указана ссылка на тот же целевой узел.

Ссылки на имеющиеся условия могут использоваться исключительно в пространстве экземпляров, если они недоступны в определениях типов. В этом случае исходным узлом этого ссылочного типа должен быть объект, переменная или узел метода.

5.13 Коды состояния аварийных сигналов и условий эксплуатации

В таблице 5 приведены коды состояния, определенные для аварийных сигналов и условий эксплуатации.

Таблица 5

Коды результатов аварийных сигналов и состояний

Идентификатор кода	Описание
Неисправное состояние включено	Адресованное условие включено
Неисправное состояние отключено	Адресованное условие отключено
Неисправное состояние отложено	Сигнал тревоги находится в отложенном состоянии
Ветвь с неисправным состоянием признана	Идентификатор события не относится к состоянию, которое требует подтверждения
Ветвь с неисправным состоянием подтверждена	Идентификатор события не указывает на состояние, требующее подтверждения
Неисправное состояние, не отложено	Сигнал тревоги не находится в запрошенном отложенном состоянии
Неисправный диалог, не активен	Экземпляр типа состояния диалогового окна не находится в активном состоянии
Неверный ответ на неисправный диалог	Выбранный параметр не является допустимым индексом в наборе параметров ответа
Идентификатор ошибочного события неизвестен	Указанный идентификатор события неизвестен серверу
Выполняется обновление сбоя	Операция обновления условия уже выполняется
Время задержки недоступно	Указанное время хранения выходит за пределы диапазона, разрешенного сервером для хранения

6 Организация адресного пространства

6.1 Общие положения

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

6.2 Уведомление о событиях и иерархия источников

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

6.3 Добавление условий в иерархию

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

Клиенты могут находить условия, сначала просматривая источники условий, следуя ссылкам на источник (включая подтипы), а затем просматривая ссылки на условия из всех целевых узлов обнаруженных ссылок.

6.4 Условия в объявлениях экземпляров

Ссылки, имеющие условие и источник условия, используются для указания того, какие ссылки и условия доступны для экземпляра типа объекта. Использование ссылки на источник условия в контексте объявлений экземпляров и узлов определения типа не влияет на генерацию событий.

6.5 Условия в типе переменной

Использование условия в типе переменной является особым случаем использования, поскольку переменные (и типы переменных) могут не содержать условий в качестве компонентов.

7 Состояние системы и аварийные сигналы

7.1 Общие положения

На состояние аварийных сигналов влияет состояние технологического процесса, оборудования, системы или установки. Например, когда резервуар выводится из эксплуатации, сигнализаторы уровня, связанные с этим резервуаром, больше не будут использоваться до тех пор, пока резервуар не будет возвращен в эксплуатацию. В разделе 7 описаны ссылочные типы, которые могут использоваться конечным автоматом для указания определенного воздействия на аварийные сигналы, вызванные переходом конечного автомата.

7.2 Эффект отключения

Является конкретным ссылочным типом и может использоваться напрямую. Это подтип эффекта. Семантика этого ссылочного типа заключается в том, чтобы указать на переход к сигналу тревоги, который будет отключен.

Исходный узел этого ссылочного типа должен быть объектом переходного типа или одного из его подтипов. Целевой узел может быть типа объекта или тревоги.

7.3 Эффект включения

Является конкретным ссылочным типом и может использоваться напрямую. Это подтип эффекта. Семантика этого ссылочного типа заключается в указании на переход к аварийному сигналу, который будет включен. Если ссылка относится к объекту, то включаются все сигналы тревоги в иерархии уведомителя ниже этого объекта.

Исходный узел этого ссылочного типа должен быть объектом переходного типа объекта или одного из его подтипов. Целевой узел может принадлежать к любому классу узлов.

7.4 Эффект подавляющего действия

Является конкретным ссылочным типом и может использоваться напрямую. Это подтип эффекта. Семантика этого ссылочного типа заключается в указании на переход к сигналу тревоги, который будет подавлен. Если ссылка относится к объекту, то все сигналы тревоги в иерархии уведомителей о событиях ниже этого объекта подавляются.

7.5 Эффект неподавляющего действия

Является конкретным ссылочным типом и может использоваться напрямую. Это подтип эффекта.

Исходный узел этого ссылочного типа должен быть объектом переходного типа или одного из его подтипов. Целевой узел может принадлежать к любому классу узлов.

8 Показатели тревоги

Цель хорошо спроектированной системы сигнализации состоит в том, чтобы оператор был осведомлен о проблемах как критических, так и некритических, но не был перегружен сигналами тревоги/оповещениями или другими сообщениями. При проектировании системы охранной сигнализации определяются критерии частоты срабатываний и общей эффективности системы на различных уровнях (станция оператора, производственная зона, система в целом и т.д.). Оценка эффективности системы охранной сигнализации в соответствии с этими критериями проектирования требует сбора показателей аварийной сигнализации. Эти показатели содержат сводную информацию о частоте срабатываний и другую информацию, связанную с сигнализацией.

Структура показателей тревоги может быть реализована на нескольких уровнях, позволяя серверу собирать показатели по мере необходимости. Например, объект этого типа может быть добавлен к серверному объекту, предоставляющему сводную информацию о производительности сигнализации для всего сервера. Экземпляр также может быть предоставлен для объекта, который содержит иерархию уведомителя.

УДК 004.03:006.354	ОКС 25.040.40 35.100.05
Ключевые слова: унифицированная архитектура OPC, аварийные сигналы, условия, организация адресного пространства, модель

---