ГОСТ Р 54418.25.4-2014
(МЭК 61400-25-4:2008)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Возобновляемая энергетика. Ветроэнергетика
УСТАНОВКИ ВЕТРОЭНЕРГЕТИЧЕСКИЕ
Часть 25-4
КОММУНИКАЦИИ ДЛЯ ТЕКУЩЕГО КОНТРОЛЯ И УПРАВЛЕНИЯ ВЕТРОВЫМИ ЭЛЕКТРОСТАНЦИЯМИ
Отображение совокупности параметров в процессах передачи информации
Renewable power engineering. Wind power engineering. Wind turbines. Part 25-4. Communications for monitoring and control of wind power plants. Mapping to communication profile
ОКС 27.180
Дата введения 2016-07-01
Предисловие
1 ПОДГОТОВЛЕН Открытым акционерным обществом "Научно-исследовательский институт энергетических сооружений" (ОАО "НИИЭС") на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4.
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 330 "Процессы, оборудование и энергетические системы на основе возобновляемых источников энергии"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2014 г. N 1689-ст
4 Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 61400-25-4:2008* "Турбины ветровые. Часть 25-4. Коммуникации для мониторинга и контроля ветровых станций. Маршрутизация к коммуникационному профилю" (IEC 61400-25-4:2008 "Wind turbines - Part 25-4: Communications for monitoring and control of wind power plants - Mapping to communication profile"). Внесение технических отклонений направлено на учет особенностей объекта и аспекта стандартизации, характерных для Российской Федерации.
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .
Сведения о соответствии ссылочных национальных и межгосударственных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, представлены в приложении ДА.
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Серия стандартов ГОСТ Р 54418.25 устанавливает требования к информационной связи между компонентами ветроэнергетических станций, такими как ветротурбины и объекты системы управления и сбора данных (SCADA). Внутренние информационные связи между компонентами ветроэнергетических станций в серии стандартов ГОСТ Р 54418.25 не рассматриваются.
Серия стандартов ГОСТ Р 54418.25 предназначена для коммуникационной среды, поддерживаемой моделью клиент-сервер. Определены три области, сформированные отдельно, для обеспечения реализации масштабной модели:
1) информационные модели ветровой электростанции;
2) модели информационного обмена;
3) отображение моделей на стандартный профиль коммуникации.
Информационная модель ветровой электростанции и информационно-обменная модель рассматриваются вместе и представляют собой интерфейс между клиентом и сервером. В этой связке серверы информационной модели ВЭС служат для интерпретации доступных данных ветровой электростанции. Информационная модель ВЭС используется клиентским сервером для предложения унифицированной, компонентно-ориентированной точки зрения на ветровой электростанции. Информационно-обменная модель отражает все активные обмены сервера. Группа стандартов ГОСТ Р 54418.25 обеспечивает унификацию разнородных интерфейсов клиента и серверов разных производителей и поставщиков.
Концептуальная коммуникационная модель серии стандартов ГОСТ Р 54418. 25 представлена на рисунке 1.
Рисунок 1 - Концептуальная коммуникационная модель серии стандартов ГОСТ Р 54418.25
В соответствии с рисунком 1 серия стандартов ГОСТ Р 54418.25 характеризует сервер по следующим аспектам:
- информация, предоставленная компонентом ветроэнергетической станции, например, скорость вращения ротора ветроколеса или выработка электроэнергии за определенный промежуток времени, обрабатывается и становится общедоступной;
- средства обмена обработанными данными, определяемые в настоящем стандарте;
- отображение обработанных данных в коммуникационном профиле, предусматривающем набор протоколов для их дальнейшей передачи.
Серия стандартов ГОСТ Р 54418.25 описывает моделирование данных, обмен данными и их отображение в специальных коммуникационных протоколах.
В настоящем стандарте отсутствуют требования к тому, как и где выполняют коммуникационный интерфейс, интерфейс для прикладных программ, а также рекомендации по их исполнению. Цель настоящего стандарта состоит в том, чтобы информация, связанная с отдельным компонентом ветроэнергетической станции (таким, как ветротурбина), была доступна для соответствующего логического устройства.
1 Область применения
Настоящий стандарт определяет особые отображения стеков протоколов, кодирующих сообщения, необходимые для информационного обмена между клиентом и удаленным сервером, для:
- доступа к данным и их вывода;
- управления устройства;
- отчеты и ведение журнала событий;
- сервисов публикаций и подписок;
- самоописания устройств (словарь данных устройства);
- распределения данных по типам и открытия типов данных.
Отображения, указанные в настоящем стандарте, включают в себя отображения:
- SOAP - основных веб-Сервисов;
- OPG/XML-DA;
- в [1]* MMS;
- в ГОСТ Р МЭК 60870-5-104;
- в DNP3.
Все отображения являются опциональными, но по крайней мере одно отображение должно быть выбрано в соответствии с настоящим стандартом.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р МЭК 870-5-5-96 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 5. Основные прикладные функции
ГОСТ Р ИСО/МЭК 8824-93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)
ГОСТ Р ИСО/МЭК 8825-1-2003 Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования
ГОСТ Р ИСО 8326-95 Системы обработки информации. Взаимосвязь открытых систем. Определение базовых услуг сеансового уровня в режиме с установлением соединения
ГОСТ Р МЭК 60870-5-101-2006 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 101. Обобщающий стандарт по основным функциям телемеханики
ГОСТ Р МЭК 60870-5-104-2004 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей
ГОСТ Р МЭК 61850-6-2009 Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях
ГОСТ Р МЭК 61850-7-1-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 1. Принципы и модели
ГОСТ Р МЭК 61850-7-2-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI)
ГОСТ Р МЭК 61850-7-3-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 3. Классы общих данных
ГОСТ Р 54418.25.2-2014 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-2. Коммуникации для текущего контроля и управления ветровыми электростанциями. Информационные модели
ГОСТ Р 54418.25.3-2014 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-3. Коммуникации для текущего контроля и управления ветровыми электростанциями. Процессы передачи информации при отслеживании состояния и управления ветроэлектрическими установками
ГОСТ Р 54418.25.5-2013 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 аналоговая информация ВЭС (wind power plant analogue information): Непрерывная информация о реальном состоянии или поведении системы или компонентов системы.
Примечание - Измеренное значение, обрабатываемое значение, трехфазное значение, заданное значение, параметр.
3.2 ветровая электростанция (wind power plant); ВЭС: Электростанция, состоящая из двух и более ветроэлектрических установок, предназначенная для преобразования энергии ветра в электрическую энергию и передачи ее потребителю.
3.3 ветроколесо ветроэнергетической установки (wind turbiune): Устройство для преобразования ветровой энергии в механическую энергию вращения ветроколеса.
3.4 внешняя система управления (actor): Система, принимающая участие в мониторинге, контроле состояния и режима работы ВЭС, но не принимающая непосредственного участия в управлении оборудованием ВЭС, в частности в управлении и сборе данных (SCADA).
Примечание - Существуют другие обозначения: центральная система управления, системы мониторинга и контроля, система дистанционного управления.
3.5 временные данные (timing data): Длительность конкретного состояния коммуникационной системы.
3.6 диагностика коммуникационной системы (diagnostics): Управленческая функция, которую используют для настройки и обеспечения самоконтроля и выявления причин сбоев в коммуникационной системе.
3.7 диспетчерский контроль и сбор данных (SCADA): Система, основанная на процессоре, который получает информацию от интеллектуальных электронных устройств (IED), определяет требования к контролю и посылает команды IED.
3.8 извлечение данных (data retrieval): Операционная функция, используемая для сбора данных о ВЭС.
3.9 измеренные данные (measured data): Выборка значений количественных оценок процесса и связанных с ним атрибутов, таких, как метка времени и качества.
3.10 интеллектуальное электронное устройство (IED): Любое устройство, включающее один или несколько процессоров, с функцией получения данных от внешнего отправителя или отправки данных на внешний приемник.
Пример - Контроллер ВЭУ может иметь соединения с другими контроллерами ВЭС как в качестве клиента, так и в качестве сервера, или одновременно в качестве одного и другого.
3.11 информационная модель (information model): Модель представления информационных функций и устройств, в которых реализованы функции коммуникации.
Примечание - Эта модель становится видимой и доступной с помощью представления в соответствии с условиями группы стандартов ГОСТ Р 54418.25. Модель описывает абстрактный способ коммуникационно-ориентированного представления вещественной функции или устройства.
3.12 информационный обмен (information exchange): Коммуникационный процесс между двумя системами (компонентами ВЭС и внешней системой управления) для передачи и получения соответствующей информации, требующий определенных коммуникационных функций, состоящих из одной или нескольких служб.
3.13 информация (information): Содержание сигналов, которыми обмениваются участники коммуникационной среды.
Примечание - Основным элементом информации являются необработанные данные от компонента ВЭС, которые должны быть переработаны в соответствии с требованиями группы стандартов ГОСТ Р 54418.25. Категории информации: источник информации (аналоговая, дискретная и др. информация), извлеченная информация (статистическая и накопленная информация).
3.14 команда (command): Контролируемая информация о состоянии системы (разблокирован/заблокирован, активный/неактивный).
3.15 компонент ВЭС (wind power plant component): Техническая система, используемая в работе ВЭС, такая как система управления ВЭУ, метеорологическая или электрическая система.
3.16 коммуникационная функция (communication function): Функция информационного обмена с ВЭС, используемая разработчиком для настройки и контроля информационного обмена.
3.17 логическое устройство (logical device): Объекты, которые представляют собой набор типовых функций ВЭС.
3.18 метеорологическая система (meteorological system): Компонент ВЭС, отвечающий за мониторинг условий окружающей среды, например скорость и направление ветра, давление, температура и т.д. Система представляет данные для различных целей, например определения соотношения метеорологических данных и выхода электрической энергии отдельных ВЭУ для оценки использования энергии ветра.
3.19 мониторинг (monitoring): Эксплуатационная функция локального или удаленного наблюдения системы или процесса для выявления изменений, которые могут возникнуть с течением времени. Этот термин может также использоваться для наблюдения за изменением значений данных или группы значений данных.
3.20 необязательный к исполнению (optional): Контент, который может быть дополнительно представлен в соответствии с серией стандартов ГОСТ Р 54418.25.
3.21 обработанные данные (processed data): Измеренные величины, обработанные с использованием соответствующих их атрибутам методов расчета.
3.22 обязательный к исполнению (mandatory): Контент, который должен быть представлен в соответствии с серией стандартов ГОСТ Р 54418.25.
3.23 отчет (report): Актуальная информация, посланная для обязательной отчетности. Отчет может содержать все виды информации, определенные в ГОСТ Р 54418.25.2.
3.24 отчетность (reporting): Оперативная функция по передаче отчетных данных с сервера клиенту, инициированная процессом сервера.
3.25 параметр (parameter): Контролируемая информация, предназначенная для получения состояния или исправления поведения системы.
3.26 переходный регистрационный журнал (transient log): Событие, синхронизирующее хронологический список большого объема информации для короткого периода времени (события, фиксированные в докладе).
3.27 подсчет значения (counting value): Общее количество событий определенного типа.
3.28 профиль (profile): Формат отображения данных, используемый конкретным протоколом для передачи данных, команд и т.д.
3.29 регистрационный журнал (log): Сборник информации о режиме и эксплуатационном состоянии ВЭС. Хронологический список источников информации за определенный период времени.
3.30 регистрация (logging): Оперативная функция записи последовательных данных (часто в хронологическом порядке) о режиме и состоянии ВЭС и ее компонентов, событиях с участием ВЭС и ее компонентов.
3.31 сигнализация (alarm): Система предоставления персоналу информации о состоянии ВЭС. За безопасностью ветроэнергетической установки следит система управления ветроэнергетической установки (ВЭУ).
3.32 синхронизация времени (time synchronization): Координация появлений состояния коммуникационной системы для управления в соответствии со временем возникновения состояния. Этот процесс может быть предварительным мероприятием установки состояния синхронизации параллельно со временем, или может быть наблюдаемым совпадением различных состояний системы.
3.33 система управления ВЭС (wind power plant management system): Компонент ВЭС, который обеспечивает выбор, ведение и документирование режима работы ВЭС, адаптацию всей системы ВЭС к статическим и динамическим условиям работы и требованиям взаимодействия ВЭУ с электроэнергетической системой.
Примечание - Система управления ВЭС может включать в себя др. функции (например, функции контроля шума и звукоизоляции, предупреждение об обледенении, громоотвод), которые не моделируются в группе стандартов ГОСТ Р 54418.
3.34 событие (event): Переходное состояние статуса, сигнала, команды.
3.35 статистическая информация (statistical information): Результат применения статистического алгоритма обработки для набора данных в целях получения вероятностных оценок процесса.
3.36 статус (status): Параметр состояния компонента или системы (st1/st2/..stn).
3.37 стек протокола (protocol stack): Программная реализация набора протоколов компьютерных сетей.
Примечание - Термины "стек протокола" и "набор протоколов" часто используются как синонимы. Строго говоря, набор является определением протоколов, а стек - это их программная реализация.
3.38 три фазы данных (three phase data): Измеренное значение в трехфазной электрической цепи с соответствующими атрибутами данных (метка времени, качество и расчет).
3.39 управление (control): Оперативная функция, используемая для ввода и изменения параметров режима, вмешательства, контроля, параметризации и оптимизации режима и состояния ВЭС.
3.40 управление доступом (user/access management): Функция управления, используемая для настройки, изменения, удаления пользователей (административно), назначение прав доступа (административно) и контроля доступа.
Примечание - Функция управления может не включать в себя услуги связи.
3.41 управленческая функция (management function): Функция управления обменом информацией на определенном уровне системы коммуникации. Функции управления обменом информацией - это управление вида доступа пользователям, синхронизация времени, диагностика и настройка.
3.42 характерные значения (characteristic values): Свойства аналоговой информации (мин., макс., среднее, отклонение и т.д.).
3.43 эксплуатационная функция (operational function): Функция получения информации и передачи команд для нормальной повседневной эксплуатации ВЭС. Ее типы: мониторинг, ведение регистрационного журнала, отчетность, поиск данных, контроль.
3.44 электрическая система ВЭС (electrical system): Компонент ВЭС, отвечающий за сбор и передачу энергии, произведенной ВЭУ.
4 Сокращения
В настоящем стандарте использованы следующие сокращения:
ACSI - абстрактный интерфейс коммуникационных сервисов (определен, например, в ГОСТ Р МЭК 61850-7-2);
ASDU - Сервис Приложений Модулей Данных;
CASDU - Общий Адрес;
CDC - общий класс данных;
CI - Встречный Опрос;
СОТ - Причина передачи;
DAComp - компонент атрибута данных;
DC - класс данных;
DNP3 - протокол передачи данных, версия 3;
DA - атрибут данных;
GI - Общий Опрос;
HTTP - протокол передачи гипертекста;
O&M - эксплуатация;
OSI - взаимосвязь открытых систем;
ICMP - интернет протокол управления сообщениями;
IED - интеллектуальное электронное устройство;
IEM - информационно-обменная модель;
IM - информационная модель;
IP - межсетевой интернет протокол;
IOA - Информационный Адрес Объекта;
LCB - регистрационно-контрольный блок;
LD - логическое устройство;
LN - логический узел;
LOG - журнал (регистрации);
LPHD - логический узел физического устройства;
MMS - Обработка Спецификации Запросов (см. [23]);
PI - Изображение процесса;
QDS - Качественный Дескриптор;
QOI - Спецификатор Опроса;
RCB - отчетно-контрольный блок;
RFC - запрос комментариев;
SCADA - система диспетчерского контроля и сбора данных;
SCSM - отображение конкретного коммуникационного сервиса;
SOAP - протокол простого объекта доступа;
SSL - уровень защиты сокета;
S/E - Выбрать/Выполниться;
SCL - Язык Конфигурации подстанции;
SCL - система конфигурации языка (определена в ГОСТ Р МЭК 61850-6);
TTL - время существования;
TCP - протокол контроля передачи;
TI - Тип Идентификации;
UDP - протокол контроля датаграмм;
UUID - универсальный уникальный идентификатор;
URL - универсальный локатор ресурса;
WPP - ветровая электростанция (ВЭС);
WSDL - язык описания Веб-Сервисов;
WT - ветровая турбина (ветроколесо);
XML - расширяемый язык разметки;
XPATH - XML язык пути.
5 Основной обзор
5.1 Общие положения
Отображение информационной модели, определенной в ГОСТ Р 54418.25.2, и информационно-обменной модели, определенной в ГОСТ Р 54418.25.3, рассмотрены в настоящем стандарте со специальными отображениями, данными в соответствии с приложениями А-Д:
а) информационно-обменная модель ВЭС отображена в набор веб-сервисов, которые обеспечивают отображение для информационно-обменных сервисов в соответствии с ГОСТ Р 54418.25.3;
б) информационно-обменная модель ВЭС отображена в ОРС XML-DA стеков протоколов, которые обеспечивают отображение для информационно-обменных сервисов в соответствии с ГОСТ Р 54418.25.3;
в) информационно-обменная модель ВЭС отображена в стандарте [1] MMS стеков протоколов, которые обеспечивают отображение для информационно-обменных сервисов в соответствии с ГОСТ Р 54418.25.3;
г) информационно-обменная модель ВЭС отображена в ГОСТ Р МЭК 60870-5-104 стеков протоколов, которые обеспечивают отображение для информационно-обменных сервисов в соответствии с ГОСТ Р 54418.25.3;
д) информационно-обменная модель ВЭС отображена в DNP3 стеков протоколов, которые обеспечивают отображение для информационно-обменных сервисов в соответствии с ГОСТ Р 54418.25.3.
В подразделе 5.2 описаны отношения между информационной моделью, информационно-обменными сервисами и отображением в стеки протоколов.
В подразделе 5.3 описаны отношения между информационно-обменными сервисами, определенными в ГОСТ Р 54418.25.3, и возможностями отображения в стеках протоколов.
В приложении Е приведено описание требуемого времени выполнения синхронизации в целях соответствия настоящему стандарту.
В приложении Ж приведено вспомогательное руководство для понимания стандартов серии ГОСТ Р 54418.25, а также пример реальной системы в эксплуатации.
5.2 Отображение стеков протоколов
В настоящем стандарте поддерживаются многомерные отображения, например более чем одно уникальное отображение указано в качестве нормы. По крайней мере одно отображение должно быть выбрано для соответствия настоящему стандарту. Концепция строения многомерного отображения приведена на рисунке 2.
Рисунок 2 - Коммуникационные профили
5.3 Сервисы ГОСТ Р 54418.25.3, отображенные в стеках протоколов
В таблице 1 сделан обзор информационно-обменных сервисов, описанных в ГОСТ Р 54418.25.3, и степень выполнения, обеспечиваемая указанными отображениями в стеках протоколов. Для каждого отображения приведена колонка, которая указывает на совместимость с требуемыми сервисами. Графа М/О показывает, каким образом сервис определен в ГОСТ Р 54418.25.3: как обязательный или дополнительный. Знак "Y" в столбце означает "YES", т.е. сервис поддерживается, в то время как "N" означает, что сервис не поддерживается, и "Р" означает частичную поддержку, т.е. сервис, определенный в ГОСТ Р 54418.25.3, поддерживается не полностью.
Таблица 1 - Обзор отображений сервисов ГОСТ Р 54418.25.3
Обзор возможностей отображения | ||||||
Сервисы ГОСТ Р 54418.25.3 | М/О | Web- | OPC XML-DA | Стандарт [1] (MMS) | ГОСТ Р МЭК 60870-5-104 | DNP3 |
Associate | М | Y | Y | Y | Y | Y |
Release | О | Y | Y | Y | Y | N |
Abort | О | Y | Y | Y | N | N |
GetServerDirectory | О | Y | Y | Y | N | Y |
GetLogicalDeviceDirectory | О | Y | Y | Y | N | Y |
GetLogicalNodeDirectory | О | Y | Y | Y | N | N |
GetDataValues | М | Y | Y | Y | Y | Y |
SetDataValues | М | Y | Y | Y | Y | Y |
GetDataDirectory | О | Y | Y | Y | N | N |
GetDataDefinition | О | Y | Y | Y | N | N |
GetDataSetValues | М | Y | P | Y | N | Y |
SetDataSetValues | О | Y | N | Y | N | Y |
CreateDataSet | О | Y | N | Y | N | N |
DeleteDataSet | О | Y | N | Y | N | N |
GetDataSetDirectory | О | Y | N | Y | N | N |
Report | О | Y | Y | Y | Y | N |
GetBRCBValues | О | Y | N | Y | N | N |
SetBRCBValues | О | Y | N | Y | N | N |
GetURCBValues | О | Y | N | Y | N | N |
SetURCBValues | О | Y | N | Y | N | N |
AddSubscription | О | Y | Y | Y | N | N |
RemoveSubscription | О | Y | Y | Y | N | N |
GetLCВValues | О | Y | N | Y | N | N |
SetLCBValues | О | Y | N | Y | N | N |
GetLogStatusValues | О | Y | N | Y | N | N |
QueryLogByTime | О | Y | N | Y | N | N |
QueryLogAfter | О | Y | N | Y | N | N |
Select | О | Y | Y | Y | Y | Y |
SelectWithValue | О | Y | Y | Y | Y | Y |
Cancel | О | Y | Y | Y | Y | N |
Operate | М | Y | Y | Y | Y | Y |
CommandTermination | О | Y | Y | Y | Y | Y |
TimeActivatedOperate | О | Y | Y | Y | N | N |
УРОВНИ ПОДДЕРЖКИ РАССМОТРЕНЫ В ДАЛЬНЕЙШЕМ В Б.5.7.3.5 |
Приложение А
(обязательное)
Отображение сервисов специальной коммуникации - Структура и отображение в Веб-Сервисы
А.1. Основные положения
А.1.1 Введение в структуру и отображение в Веб-Сервисы
Настоящее приложение описывает решения, включая структуры и отображение ГОСТ Р 54418.25.2 и ГОСТ Р 54418.25.3, Информационной Модели и сервисов Информационно-Обменных Классов и Моделей в сетевые объекты и Веб-Сервисы. Приложение описывает полное коммуникационное решение, определяемое WSDL файлом, предназначенным для осуществления коммуникации с ВЭС.
Настоящее приложение включает в себя следующие разделы:
- А.1 - представляет общее введение в задачу отображения в Веб-Сервисы;
- А.2 - представляет список нормативных ссылок для отображения в Веб-Сервисы;
- А.3 - представляет список условных сокращений, используемых в приложении А;
- А.4 - представляет отображение Информационной Модели в Веб-Сервисы;
- А.5 - представляет отображение Информационно-Обменной Модели в Веб-Сервисы;
- А.6 - представляет детали стека протоколов;
- А.7 - представляет WSDL спецификацию отображения в Веб-Сервисы. Стиль привязки, выбранный в WSDL спецификации, - это документальное/буквенное оформление.
А.1.2 Контекст структуры и отображения в Веб-Сервисы
В контексте структуры и отображения в Веб-Сервисы находится обмен информационными процессами, требуемыми для оперативных задач, основанных на отношениях клиент-сервер.
Информационная модель и информационно-обменная модель составляют спецификацию интерфейса между клиентом и сервером. Информационная модель поставляет базу понятий для открытых данных ВЭС и используется сервером для предложения связанному с ним клиенту внешней формы и компонентно-базированного видения данных ВЭС.
Объем информации, доставляемой сервером, может варьироваться в зависимости от ряда дополнительных данных, предлагаемых разными производителями.
Клиент может быть локальным, региональным или расположенным в центре управления масштабов страны, который осуществляет обмен информацией в целях мониторинга и управления ВЭС.
А.1.3 Структура отображения
Структура отображения состоит из следующих трех частей:
1) отображение информационной модели;
2) отображение классов данных;
3) отображение информационно-обменных сервисов.
Указанное отображение для настоящего приложения основано на использовании SOAP/XML для обмена компонентами информационных моделей ВЭС в системе отношений клиент-сервер.
Информационная модель ВЭС, определенная в ГОСТ Р 54418.25.2, должна быть отображена иерархической структурой.
Структура отображения (концепция) показана на рисунке А.1. Информационная модель ВЭС из ГОСТ Р 54418.25.2 предполагается постоянной при отображении в Веб-Сервисы. Это в особенности значит, что:
- сервер осуществляет иерархическую информационную модель ВЭС из ГОСТ Р 54418.25.2 (IM), которая может быть выдана сервисам согласно ограничениям в таблице А.1;
- клиент осуществляет информационную модель ВЭС по существующей конфигурации;
- позиция клиента подтверждает иерархическую информационную модель ВЭС из ГОСТ Р 54418.25.2 через сервисы, которые доставляют отображения Веб-Сервисам для обмена информацией.
Рисунок А.1 - Структура отображения (концепция)
Таблица А.1 - Обзор отображения в Веб-Сервисы по ГОСТ Р 54418.25 IM и IEM
ГОСТ Р 54418.25.2 1М | ГОСТ Р 54418.25.3 IEM Сервисы | M/O | Включено в отобра- | Отображается сетевым объектам и веб-сервисам |
SERVER | Y | tServer | ||
GetServerDirectory | O | Y | GetServerDirectory | |
ASSOCIATION | ||||
Associate | M | Y | Associate | |
Release | O | Y | Release | |
Abort | O | Y | Abort | |
LOGICAL-DEVICE | Y | tLD | ||
GetLogicalDeviceDirectory | О | Y | GetLogicalDeviceDirectory | |
LOGICAL-NODE | Y | tLN | ||
GetLogicalNodeDirectory | О | Y | GetLogical NodeDirectory | |
DATA | Y | tData | ||
GetDataValues | M | Y | GetDataValues | |
SetDataValues | M | Y | SetDataValues | |
GetDataDirectory | О | Y | GetDataDirectory | |
GetDataDefinition | О | Y | GetDataDefinition | |
DATA-SET | Y | tDataSet | ||
GetDataSetValues | M | Y | GetDataSetValues | |
SetDataSetValues | O | Y | SetDataSetValues | |
CreateDataSet | O | Y | Create DataSet | |
DeleteDataSet | O | Y | DeleteDataSet | |
GetDataSetDirectory | O | Y | GetDataSetDirectory | |
REPORTING | ||||
AddSubscription | O | Y | AddSubscription | |
RemoveSubscription | O | Y | RemoveSubscription | |
Report | O | Y | ReportRequestlResponse | |
BRCB | tBRCB | |||
GetBRCBValues | O | Y | GetBRCBValues | |
SetBRCBValues | O | Y | SetBRCBValues | |
URCB | tURCB | |||
GetURCBValues | O | Y | GetURCBValues | |
SetURCBValues | O | Y | SetURCBValues | |
LOG | Y | tLOG | ||
GetLogStatusValues | O | Y | GetLogStatusValues | |
QueryLogByTime | O | Y | QueryLogByTime | |
QueryLogAfter | O | Y | QueryLogAfter | |
LCB | tLCB | |||
GetLCBValues | O | Y | GetLCBValues | |
SetLCBValues | O | Y | SetLCBValues | |
CONTROL | ||||
Select | O | Y | Select | |
SelectWithValue | O | Y | SelectWithValue | |
Cancel | O | Y | Cancel | |
Operate | M | Y | Operate | |
CommandTermination | О | Y | CommandTermination | |
TimeActivatedOperate | О | Y | TimeActivatedOperate | |
Примечание - Графа M/O в таблице А.1 показывает, каким образом сервис определен в ГОСТ Р 54418.25.3: как обязательный или как дополнительный. Знак "Y" в графе означает "YES", т.е. сервис поддерживается, в то время как "N" означает, что сервис не поддерживается. |
А.2 Специальные нормативные ссылки на Веб-Сервисы
Следующие нормативные ссылки являются необходимым приложением к настоящему стандарту. В случае, если дана датированная ссылка, то необходимо применять документ именно этого издания. Если дана недатированная ссылка, то возможно использование последней редакции документа с учетом всех внесенных в него изменений.
ГОСТ Р 54418.25 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25. Коммуникации для текущего контроля и управления ветровыми электростанциями.
ГОСТ Р МЭК 61850-6-2009 Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях
Кроме того, при работе с Веб-Сервисами необходимо использовать документы [1]-[21].
А.3 Сокращения
Сокращения приведены в разделе 4 настоящего стандарта.
А.4 Отображение информационной модели ГОСТ Р 54418.25 в Веб-Сервисы
А.4.1 Основное введение в приложение А
Главные характеристики классов отображения, определенных в ГОСТ Р 54418.25.2, приведены в таблице А.2.
Таблица А.2 - Отображение ГОСТ Р 54418.25 IM в Веб-Сервисы
ГОСТ Р 54418.25.2 IM Классы | Отображение сетевым объектам и Веб-Сервисам |
SERVER | tServer |
LOGICAL-DEVICE | tLD |
LOGICAL-NODE | tLN |
DATA classes | tDATA |
COMMON-DATA classes | tCDC |
DATA-ATTRIBUTE type | tDataAttribute |
DA-COMPONENT type | tDAType |
Отображение основных типов атрибутов данных сведены в таблицу А.3.
Таблица А.3 - Отображение ГОСТ Р 54418.25 IM основных типов атрибутов данных
ГОСТ Р 54418.25 name | Value Range/explanation | Отображение сетевым объектам и Веб-Сервисам |
BOOLEAN | True I False | according to tBasicType |
INT8 | -128 до +127 | according to tBasicType |
INT16 | -32768 до +32767 | according to tBasicType |
INT24 | -8388608 до 8388607 | according to tBasicType |
INT32 | -2**32 до (2**32)-1 | according to tBasicType |
INT128 | -2**127 до (2**127)-1 | according to tBasicType |
INT8U | от 0 до 225 | according to tBasicType |
INT16U | от 0 до 65535 | according to tBasicType |
INT24U | от 0 до 16777215 | according to tBasicType |
INT32U | от 0 до 4294967295 | according to tBasicType |
FLOAT32 | Единичная точность плавающей точки | according to tBasicType |
FLOAT64 | Двоичная точность плавающей точки | according to tBasicType |
ENUMERATED | Упорядоченный набор значений, определенных в виде целых чисел и текста | according to tBasicType |
CODED ENUM | Определенный набор значений ограничивается целыми числами с определенным числом бит | according to tBasicType |
OCTET STRING | Шестнадцатеричная двоичная | according to tBasicType |
VISIBLE STRING | Строка символов, декодируемая как строка Юникод | according to tBasicType |
UNICODE STRING | Строки Юникод с ненулевыми значениями, байтовые последовательности которых основаны на UTF-8 формате преобразования [2], символы которых декодируются в соответствии с байтами | according to tBasicType |
Информационная модель ВЭС, описанная в ГОСТ Р 54418.2, определяется классами Логических Узлов (LOGICAL NODE), Данные (DATA), Общие Данные (COMMON-DATA), типами Атрибуты Данных (DATA-ATTRIBUTE) и Компоненты Данных (DATA-COMPONENT).
Объекты информационной модели названы в соответствии с методикой, описанной в ГОСТ Р 54418.25.2 (разделы 5 и 6).
Первая часть имени объекта - это определяемое пользователем Логическое Устройство (LD) имя максимальной длины 64 символа, находящееся перед знаком слэш ("/"), используемым в качестве разделителя.
На рисунке А.2 приведено устройство части имени, следующего за знаком слэш, которое состоит из стандартных компонентов. В устройстве имени участвуют три набора таблиц:
- логический Узел (LN); определения даны в ГОСТ Р 54418.25.2 (раздел 6);
- класс Общие Данные (DATA); определения даны в ГОСТ Р 54418.25.2 (подраздел 7.3);
- атрибуты Общих Данных (DA); определения даны в ГОСТ Р 54418.25.2 (подраздел 7.2).
Рисунок А.2 - Структура имен, применяемых в серии стандартов ГОСТ Р 54418.25 (концепция)
В дополнение к указанным компонентам в ГОСТ Р 54418.25.2 (таблица 42), указаны наборы базовых типов. Финальный компонент имени является атрибутом данных, который не имеет базового типа данных.
Определения логических узлов (LN) содержат списки компонентов, которые также являются данными (DATA). Определения данных (DATA) содержат списки компонентов, которые могут быть как DA (известные как "Простые" CDC) или иные данные (известные как "Составные" CDC). Пример, когда одни данные (DATA) используются в качестве компонентов, входящих в другие данные (DATA) - это соединенные звездой электрические объекты (WYE), когда компоненты другого класса Значения Комплексных Мер (CMV), также являющиеся классом Данные (DATA).
Компоненты из DATA являются DA, которые могут быть или атрибутом, имеющим базовый тип данных (называемым "Simple" (простой) компонент, который благодаря этому становится завершающим компонентом имени) или другим DA (называемым "Composite" (составным) компонентом).
Конструкция имени начинается с ввода набора LN таблиц и нахождения LN Name (Имени Логического Узла), которое прилагается к имени сразу после разделителя слэш. LN Name может начинаться с дополнительного LN префикса, за которым следует имя стандартизованного класса LN, и заканчивается обязательной LN конкретным ID (например, вторая WGEN в LD означает WGEN2). Содержащийся в LN конкретный ID заканчивается знаком точка (".") как разделителем.
Найдя предназначенную LN таблицу, выбирается следующий, относящийся к делу компонент списка. Имя компонента приложено после точки-разделителя и заканчивается следующей точкой-разделителем. LN таблица указывает на класс DATA этого компонента. Затем выбирается подходящая таблица среди структуры DATA и следующий удовлетворяющий компонент списка структуры данных. Имя этого компонента находится после последнего разделителя-точки.
Если компонент DA является простейшим, то имя завершено. Во всех остальных случаях компонент может быть другими DATA или DA с определениями в DA таблицах. В любом из этих случаев предназначенная таблица вводится заново и выбирается следующий подходящий компонент из списка. Если этот компонент не является простейшим DA, то предназначенные таблицы вводятся заново, как и присвоенные имена и знаки-разделители, до тех пор пока простейший компонент не будет найден.
Эта схема будет использоваться для всех сервисов, которые содержат структуру и/или значения данных, полученных в каждом конкретном случае с помощью информационной модели ВЭС, производных от классов, упоминаемых в настоящем стандарте.
Структуры WSDL, показанные на рисунке А.2.1, облегчают понимание спецификации. Точные спецификации WSDL представлены в А.7, которые будут использоваться в соответствии с настоящим стандартом.
Рисунок А.2.1 - XML схема для информационной модели ВЭС
А.4.2 Класс Сервер (SERVER)
Класс Сервер следует отображать так, как описано в следующем тексте:
Все элементы следует определять, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.3).
А.4.3 Класс Логическое Устройство (LOGICAL-DEVICE)
Класс Логическое Устройство следует отображать так, как описано в следующем тексте:
Все элементы следует определять, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.4).
А.4.4 Класс Логический Узел (LOGICAL-NODE)
Класс Логический Узел следует отображать так, как описано в следующем тексте:
Все элементы следует определять, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.5).
А.4.5 Класс Данные (DATA)
Класс Данные следует отображать так, как описано в следующем тексте:
Составные CDC и Простые CDC являются особенностью класса данных для настоящего стандарта, все остальные элементы следует описывать так, как определено в ГОСТ Р 54418.25.3 (подраздел 9.6).
А.4.6 Класс Набор Данных (DATA-SET)
Класс Набор Данных DATA-SET следует отображать так, как описано в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.7).
А.4.7 Структура Атрибут Данных (DATA ATTRIBUTE)
Структура Атрибут Данных DATA ATTRIBUTE должна быть отображена так, как определено в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.6).
А.4.8 Класс Тип Атрибута Данных (DAType)
Класс Тип Атрибута Данных DAType должен быть отображен так, как определено в следующем тексте:
DAComp и PrimComp являются особенностью класса данных для настоящего стандарта, все остальные элементы следует описывать так, как определено в ГОСТ Р 54418.25.3 (подраздел 9.6).
А.4.9 Класс Контрольный Блок (REPORT-CONTROL-BLOCK)
Контрольный блок обеспечивает механизм самопроизвольного отчета о значениях данных по специальным критериям (например, при изменении значения, качества информации или просто периодически по времени). Поведение сервиса контрольных отчетов определяется значениями атрибутов соответствующих состояний контрольного блока (например, включение/отключение отчетов, использование последовательной нумерации). Контрольный блок отсылает текущее состояние данных, указывает значения наблюдаемых данных и отсылает отчеты самопроизвольно.
Буферизованный Контрольный Блок (BRCB) обеспечивает функциональность и гарантирует, что сервер посылает последовательности событий даже в случае, если коммуникация является временно нарушена. В случае с небуферизованным контрольным блоком (URCB) серверу не требуется помещать события в буфер в случае нарушения коммуникации.
Все атрибуты и поведение классов Контрольный Блок (BRCB и URCB), определенные в ГОСТ Р 54418.25.3 (подраздел 9.8), должны быть отображены следующим образом.
А.4.10 Класс Буферизованный Контрольный Блок (BRCB)
Класс Буферизованный Контрольный Блок BRCB должен быть отображен так, как описано в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.8).
А.4.11 Класс Небуферизованный Контрольный Блок (URCB)
Класс Небуферизованный Контрольный Блок URCB должен быть отображен так, как описано в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.8).
А.4.12 Класс Регистрационно-контрольный блок (LOG-CONTROL-BLOCK) (LCB)
Класс Регистрационно-контрольный блок должен быть отображен так, как описано в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.9).
А.4.13 Класс Журнал (LOG)
Класс Журнал LOG должен быть отображен так, как описано в следующем тексте:
Все элементы следует определять так, как описано и приведено в ГОСТ Р 54418.25.3 (подраздел 9.9).
А.5 Отображение Информационно-обменной модели в Веб-Сервисы
А.5.1 Основные положения
Сервисы обмена информацией ВЭС, указанные в ГОСТ Р 54418.25.3 IEM, должны быть отображены с помощью сервисов, определенных в этой главе.
Все имена сервисов и определения, данные в А.5, были взяты из ГОСТ Р МЭК 61850-7-2, кроме сервисов AddSubscription, определенных в А.5.7.2 и RemoveSubscription, определенных в А.5.7.3.
Все определения, данные в этой главе, использующие CODED ENUM (кодированные перечисления), начинаются с 1, кроме случаев, когда значения специально указаны в ГОСТ Р 54418.25.2.
А.5.2 Отображение класса сервисов Сервер (SERVER)
А.5.2.1 Основные положения
Класс сервисов Сервер должен быть отображен в Веб-Сервисы, как показано в таблице А.4.
Таблица А.4 - Отображение класса сервисов Сервер в Веб-Сервисы
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и Web сервисам |
SERVER (Сервер) | tServer | |
GetServerDirectory (Получить директорию сервера) | GetServerDirectory (Получить директорию сервера) | |
ASSOCIATION (Связь) | ||
Associate (Связать) | Associate (Связать) | |
Release (Реализация) | Release (Реализация) | |
Abort (Прервать) | Abort (Прервать) |
А.5.2.2 Получить директорию сервера (GetServerDirectory)
А.5.2.2.1 Основное положение
Клиенту следует использовать сервисы GetServerDirectory для вывода области имен обнаруженных Логических Устройств (LD) и таким образом доступных клиенту, обращающемуся к серверу.
А.5.2.2.2 Запрос "Получить директорию сервера" (GetServerDirectoryRequest)
Запрос сервиса "Получить директорию сервера" следует описывать следующим образом:
Имена тегов описаны в таблице А.5.
Таблица А.5 - Запрос "Получить директорию сервера"
Наименование | Описание |
GetServerDirectory Request | Сервис запрашивает у клиента список обнаруженных Логических устройств и, таким образом, доступных запрашивающему клиенту |
ObjClass | Отсылка к Логическому устройству или Файлу |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.2.2.3 Ответ "Получить директорию сервера" (GetServerDirectoryResponse)
Ответ сервиса "Получить директорию сервера" следует описывать следующим образом:
Имена тегов описаны в таблице А.6.
Таблица А.6 - Ответ "Получить директорию сервера"
Наименование | Описание |
GetServerDirectory Response | Сервер отвечает на запрос клиентом списка логических устройств, возглавляемых сервером |
LDRef | Объектная ссылка логического устройства. Этот элемент является уникальным именем пути к логическому устройству |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент будет представлен в ответном сообщении, то клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.2.3 Отображение сервисов связи (ASSOCIATION)
Процесс создания связи с сервером является мерой, принимаемой до начала обмена информацией. Клиент должен идентифицировать себя для сервера. Сервер должен подтвердить значения параметров для обеспечения связи до того, как сеанс связи между клиентом и сервером будет продолжен.
Клиент и сервер могут иметь многомерные связи, их количество ограничивается только практическим исполнением и в соответствии с рамками, очерченными в настоящем стандарте.
Последний шаг в сеансе коммуникации - это реализация связи. Он позволяет клиенту уведомить сервер о своем намерении реализовать связь таким образом, чтобы сервер был в состоянии перераспределить ресурсы, связанные с установлением связи.
Сервер должен поддерживать кратковременные связи для каждой установленной связи. Если краткий период времени превышен и к серверу не поступило никаких запросов от клиента, то сервер должен полагать, что сеанс коммуникации завершен, и реализовать все связанные ресурсы. Любой запрос сервисов, полученный с неправильным (неиспользуемым) идентификатором связи, означает ошибку сервиса и потерю соединения.
<s:enumeration value="connection-lost"/>
Со стороны клиента уведомление об ошибке сервиса "потеря соединения" подразумевает разрыв коммуникации, т.е. необходим новый запрос связи в целях смены сервиса со стороны сервера.
Если клиент зафиксировал ненормальную ситуацию, при которой игнорируются обменные действия между сервисами, или если сервер отказывается устанавливать связь, то клиент может прервать связь, используя сервис "AbortRequest".
Сервер не может отказаться выполнить этот сервис. Только ошибка сервиса, учтенная в AbortResponse. является потерей соединения, что означает, что сервер полагает связь реализованной.
А.5.2.4 Установить связь (Associate)
А.5.2.4.1 Запрос "Установить связь" (AssociateRequest)
Запрос сервиса "Установить связь" следует описывать следующим образом:
Имена тегов описаны в таблице А.7.
Таблица А.7 - Имена тегов
Наименование | Описание |
AssociateRequest | AssociateRequest должен быть первым посланным сообщением при организации соединения с сервером. Это позволит клиенту задать установки сеанса связи, а серверу - верифицировать эти установки и задать соответствующие значения. Если клиент пытается отправить какие-либо сообщения до AssociateRequest, то последует ответ SOAP "ошибка" с кодом ошибки: Client.MustAssociate, но без всяких ограничений на особенности формы строки ошибки. Если клиент уже подключен к серверу и отправляет AssociateRequest, то AssociateResponse будет содержать ServiceError |
UserName | Сервер использует UserName для идентификации клиента как зарегистрированного пользователя, и если это невозможно, сервер отправляет ошибку в AssociateResponse |
Password | Атрибут Password используется сервером для верификации запрашивающего клиента и разрешения связи с системой. Если верификация пароля не пройдена, сервер отправляет ошибку в AssociateResponse |
LocallD | Атрибут LocallD является дополнительным и может быть использован сервером для ответа на запрос клиента, например, предоставляя клиенту выбрать язык, на котором будет выведена запрашиваемая информация. Если LocallD не используется, то будут использованы установки, заложенные производителем по умолчанию. Если значение этого атрибута неприемлемо, то сервер ответит ошибкой. Доступный диапазон значений LocallD - это ввод из трех символов, значение которых рассмотрено в [2] |
MaxMessageSize | Максимальное количество байт памяти, которое клиент способен принять в одном ответном SOAP сообщении от сервера |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
Пример
Основа соответствующего SOAP сообщения для AssociateRequest:
LocallD указывает, что в сообщении будет применяться немецкий язык. MaxMessageSize указывает максимальное количество байт памяти, которое клиент способен принять в одном ответном SOAP сообщении от сервера.
А.5.2.4.2 Ответ "Установить связь" (AssociateResponse)
Ответ сервиса "Установить связь" следует описывать следующим образом:
Имена тегов описаны в таблице А.8.
Таблица А.8 - Ответ "Установить связь"
Наименование | Описание |
AssociateResponse | AssociateResponse является ответным сообщением сервера после получения AssociateRequest. Это сообщение будет содержать только дополнительную ошибку или дополнительный ClientRequestHandle. Клиент использует AssociateResponse для подтверждения успешного совершения AssociateRequest |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
MaxMessageSize | Максимальное количество байтов памяти в любом сообщении между клиентом и сервером. Максимальный размер сообщения должен быть меньше или равен MaxMessageSize, указанному в клиентском AssociateRequest |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например, присвоенных подписей и входов на сервер |
Пример
Основа соответствующего SOAP сообщения для AssociateResponse:
А.5.2.5 Реализация (Release)
А.5.2.5.1 Запрос "Реализация" (ReleaseRequest)
Запрос "Реализация" следует описывать следующим образом:
Имена тегов описаны в таблице А.9.
Таблица А.9 - Запрос "Реализация"
Наименование | Описание |
ReleaseRequest | ReleaseRequest является последним сообщением, отправленным при завершении сеанса связи. Это позволяет клиенту подготовить сервер к завершению сеанса. Если одна или более клиентских подписок действуют на сервере во время принятия ReleaseRequest, то идентификатор AssocID используется для идентификации владельца подписки |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.2.5.2 Ответ "Реализация" (ReleaseResponse)
Ответ "Реализация" следует описывать следующим образом:
Имена тегов описаны в таблице А.10.
Таблица А.10 - Ответ "Реализация"
Наименование | Описание |
ReleaseResponse | ReleaseResponse является ответным сообщением от сервера сразу после получения ReleaseRequest. Клиенту следует использовать ReleaseResponse для подтверждения, что ReleaseRequest успешно выполнен |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.2.6 Прервать (Abort)
А.5.2.6.1 Запрос "Прервать" (AbortRequest)
Запрос сервиса "Прервать" следует описывать следующим образом:
Имена тегов описаны в таблице А.11.
Таблица А.11 - Запрос "Прервать"
Наименование | Описание |
AbortRequest | Если клиент зафиксировал ненормальную ситуацию, при которой игнорируются обменные действия между сервисами, или если сервер отказывается устанавливать связь, то клиент может прервать связь, используя сервис "AbortRequest". Сервер не может отказаться выполнить этот сервис. Только ошибка сервиса, учтенная в AbortResponse, является потерей соединения, что означает, что сервер полагает связь реализованной |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.2.6.2 Ответ "Прервать" (AbortResponse)
Ответ сервиса "Прервать" следует описывать следующим образом:
Имена тегов описаны в таблице А.12.
Таблица А.12 - Ответ "Прервать"
Наименование | Описание |
AbortResponse | Любой запрос сервисов, полученный с неправильным (неиспользуемым) идентификатором связи, означает ошибку сервиса и потерю соединения. |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.3 Отображение класса сервисов Логическое Устройство (LOGICAL-DEVICE)
А.5.3.1 Основное положение
Класс сервисов Логическое Устройство LOGICAL-DEVICE должен быть отображен в Веб-Сервисы, как показано в таблице А.13.
Таблица А.13 - Отображение класса сервисов LOGICAL-DEVICE
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и Веб-Сервисам |
LOGICAL-DEVICE | tLD | |
GetLogicalDeviceDirectory | GetLogicalDeviceDirectory |
А.5.3.2 Получить директорию Логического Устройства (GetLogicalDeviceDirectory)
Клиенту следует использовать сервис GetLogicalDeviceDirectory для вывода области имен LD обнаруженных Логических Узлов, и, таким образом, доступных клиенту, запрашивающему Логическое Устройство.
А.5.3.2.2 Запрос "Получить директорию Логического Устройства" (GetLogicalDeviceDirectoryRequest)
Запрос сервиса "Получить директорию Логического Устройства" следует описывать следующим образом:
Имена тегов описаны в таблице А.14.
Таблица А.14 - Запрос "Получить директорию Логического Устройства"
Наименование | Описание |
GetLogicalDevice | Сервис запрашивает у клиента список обнаруженных Логических устройств и, таким образом, доступных запрашивающему клиенту |
LDRef | Объектная ссылка логического устройства. Этот элемент является уникальным именем пути к логическому устройству |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.3.2.3 Ответ "Получить директорию Логического Устройства" (GetLogicalDeviceDirectoryResponse)
Ответ сервиса "Получить директорию Логического Устройства" следует описывать следующим образом:
Имена тегов описаны в таблице А.15.
Таблица А.15 - Ответ "Получить директорию Логического Устройства"
Наименование | Описание |
GetServerDirectory | Сервер отвечает на запрос клиента путем вывода списка объектных ссылок, содержащихся в логических устройствах |
LNRef | Объектная ссылка логического узла. Этот элемент является уникальным именем пути к логическому устройству |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.4 Отображение класса сервисов Логический Узел (LOGICAL-NODE)
А.5.4.1 Общие положения
Класс сервисов LOGICAL-NODE должен быть отображен в Веб-Сервисы как показано в таблице А.16.
Таблица А.16 - Отображение класса сервисов LOGICAL-NODE
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и Веб-Сервисам |
LOGICAL-NODE | tLN | |
GetLogicalNodeDirectory | GetLogicalNodeDirectory |
А.5.4.2 Получить директорию Логического Узла (GetLogicalNodeDirectory)
А.5.4.2.1 Общие положения
Клиенту следует использовать сервис GetLogicalNodeDirectory для вывода области имен LN, обнаруженных Данных или Контрольных Блоков (например, RCB или LCB), и, таким образом, доступных клиенту, запрашивающему Логический Узел.
А.5.4.2.2 Запрос "Получить директорию Логического Узла" (GetLogicalNodeDirectoryRequest)
Запрос сервиса "Получить директорию Логического Узла" следует описывать следующим образом:
Имена тегов описаны в таблице А.17.
Таблица А.17 - Запрос "Получить директорию Логического Узла"
Наименование | Описание |
GetLogicalNodeDirectoryRequest | Сервис запрашивает у клиента список обнаруженных объектов запрашиваемого класса и таким образом доступных запрашивающему клиенту |
LNRef | Объектная ссылка логического узла. Этот элемент является уникальным именем пути к логическому узлу |
lEMcls | Нумерация ("DATA", "DATASET", "BRCB", "URCB", "LCB", "LOG") |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.4.2.3 Ответ "Получить директорию Логического Узла" (GetLogicalNodeDirectoryResponse)
Ответ сервиса "Получить директорию Логического Узла" следует описывать следующим образом:
Имена тегов описаны в таблице А.18.
Таблица А.18 - Ответ "Получить директорию Логического Узла"
Наименование | Описание |
GetLogicalNode DirectoryResponse | Сервер отвечает на запрос клиента путем вывода списка объектных ссылок, содержащихся в логических устройствах |
DATAname | Элемент, который однозначно идентифицирует данные в пределах логического узла |
DSname | Элемент, который однозначно идентифицирует Набор данных в пределах логического узла или в пределах связи клиент-сервер |
BRCBname | Элемент, который однозначно идентифицирует BRCB в пределах логического узла |
URCBname | Элемент, который однозначно идентифицирует URCB в пределах логического узла |
LCBname | Элемент, который однозначно идентифицирует LCB в пределах логического узла |
LOG name | Элемент, который однозначно идентифицирует LOG в пределах LLN0 логического узла. LOGname является именем Логического устройства |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5 Отображение класса сервисов Данные (DATA)
А.5.5.1 Основное положение
Набор данных должен быть отображен в списке объектов так, как определено в таблице А.19.
Таблица А.19 - Отображение ДАННЫХ (DATA)
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services | Отображение объектам и веб-сервисам |
Набор данных | tData | |
Получение значений данных (Get-DataValues) | Получение значений данных (GetDataValues) | |
Задать значения данных (SetDataValues) | Задать значения данных (SetDataValues) | |
Получение каталога данных (Get-DataDirectory) | Получение каталога данных (GetDataDirectory) | |
Получение структуры данных (Get-DataDefinition) | Получение структуры данных (GetDataDefinition) |
А.5.5.2 Получение значений данных (GetDataValues)
А.5.5.2.1 Запрос получения значений данных (GetDataValuesRequest)
Сервис "Запрос получения значений данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.20.
Таблица А.20 - Запрос получения значений данных
Наименование | Описание |
GetDataValues | Вывести значения Атрибутов Данных, на которые ссылаются обнаруженные Данные, и, таким образом, доступные клиенту ссылающимся на них Логическим Узлом |
Ref | Параметр Reference будет определять функционально ограниченные данные (FCD) или функционально ограниченный атрибут данных (FCDA). Reference являет собой FCD или FCDA |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. |
Подробнее о UUID - см. [21] | |
AssocID | AssocID для определения общего идентификатора - специального клиента. |
AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.2.2 Ответ получения значений данных
Сервис "Ответ получения значений данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.21.
Таблица А.21 - Ответ получения значений данных
Наименование | Описание |
GetDataValuesResponse | Ответ сервера клиенту, запрашивающему сервис GetDataValues со значениями всех отсылаемых видимых Атрибутов Данных (DataAttributes) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
DataAttrVal | Тип, привязывающий Значение из DataRef содержащемся в tDataAttributeValue типе |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.3 Задать значения данных (SetDataValues)
А.5.5.3.1 Запрос "Задать значения данных" (SetDataValuesRequest)
Сервис запроса "Задать значения данных" следует описывать следующим образом:
Имена тегов следует определять согласно таблице А.22
Таблица А.22 - Запрос "Задать значения данных"
Наименование | Описание |
SetDataValuesRequest | Клиенту следует использовать сервис SetDataValues для задания значений всех видимых Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
Ref | Параметр Reference будет определять функционально ограниченные данные (FCD) или функционально ограниченный атрибут данных (FCDA). Reference являет собой FCD или FCDA |
DataAttrVal | Тип, привязывающий Значение из DataRef, содержащееся в tDataAttributeValue типе |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.3.2 Ответ "Задать значения данных" (SetDataValuesResponse)
Сервис ответа "Задать значения данных" следует описывать следующим образом:
Имена тегов следует определять согласно таблице А.23.
Таблица А.23 - Ответ "Задать значения данных"
Наименование | Описание |
SetDataValuesResponse | Ответ сервера клиенту, запрашивающему сервис SetDataValues со значениями всех отсылаемых видимых Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
Result | Простая строка результата "Ok", обозначающая, что запрос "Задать значение" SetValue был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.4 Получить Каталог Данных (GetDataDirectory)
А.5.5.4.1 Основное положение
Клиенту следует использовать GetDataDirectory для вывода области имен всех обнаруженных Атрибутов Данных и, таким образом, доступных клиенту, обращающемуся к классу Данные (DATA).
А.5.5.4.2 Запрос получения каталога данных (GetDataDirectoryRequest)
Сервис "Запрос получения каталога данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.24
Таблица А.24 - Запрос получения каталога данных
Имя тега | Расшифровка |
GetDataDirectoryRequest | Клиенту следует использовать сервис GetDataDirectory для вывода полного списка структуры всех Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
DataRef | Значение DSReference (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. |
Подробнее о UUID - см. [21]. | |
AssocID | AssocID для определения общего идентификатора - специального клиента. |
AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.4.3 Ответ получения каталога данных (GetDataDirectoryResponse)
Ответ сервиса "Получения каталога данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.25.
Таблица А.25 - Ответ получения значений данных
Наименование | Описание |
GetDataDirectoryResponse | Ответ сервера клиенту, запрашивающему сервис GetDataDirectory со значениями всех отсылаемых видимых Аттрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
DataAttrName | Параметр DataAttrName содержит DataAttrName самого высокого уровня Атрибутов Данных DATA |
DATAname | Элемент, который однозначно идентифицирует данные в пределах логического узла |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.5.5 GetDataDefinition (Получение структуры данных)
А.5.5.5.1 Общие положения
Клиенту следует использовать сервис GetDataDefinition для вывода структуры всех подвергнутых изменению видимых DATA-ATTRIBUTES (СВОЙСТВ ДАННЫХ), и, таким образом, доступных обращающемуся к классу DATA (ДАННЫХ) клиенту.
А.5.5.5.2 GetDataDefinitionRequest (Запрос получения структуры данных)
Сервис GetDataDefinitionRequest будет определяться следующим:
Имена тегов будут определяться согласно таблице А.26
Таблица А.26 - GetDataDefinitionRequest
Наименование | Описание | ||
GetDataDefinitionRequest | Клиенту следует использовать сервис GetDataDefinition для вывода полного списка структуры всех Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) | ||
DataRef | Значение DataReference (Запрос Данных) должно содержать ObjectReference (ссылку на объект) DATA (ДАННЫХ). The ObjectReference (ссылка на объект) будет DataRef (запросом данных) | ||
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. | ||
AssocID | AssocID для определения общего идентификатора - специального клиента. |
А.5.5.5.3 GetDataDefinitionResponse (Ответ получения структуры данных)
Ответ GetDataDefinitionResponse (получения структуры данных) будет определяться следующим образом:
Имена тегов будут определяться согласно таблице А.27
Таблица А.27 - GetDataDefinitionResponse
Наименование | Описание |
GetDataDefinitionResponse | Клиенту следует использовать сервис GetDataDefinition для вывода полного списка структуры всех Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и, таким образом, доступных запрашивающему клиенту отсылаемым ЛОГИЧЕСКИМ УЗЛОМ (LOGICAL NODE) |
DataAtlrDef | Строчный тип, используемый в спецификации языка описания программных интерфейсов (Web-сервисов) (WSDL) |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента |
А.5.6 Сервисы отображения класса НАБОРА ДАННЫХ (DATA-SET)
А.5.6.1 Основание
Набор данных должен быть отображен в списке объектов, как определено в таблице А.28.
Таблица А.28 - Отображение НАБОРА ДАННЫХ (DATA SET)
ГОСТ Р 54418.2 IM Class (информационная модель) | ГОСТ Р 54418.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и веб-сервисам |
Набор данных | tDataSet | |
Получение значений набора данных (GetDataSetValues) | Получение значений набора данных (GetDataSetValues) | |
Задать значения набора данных (SetDataSetValues) | Задать значения набора данных (SetDataSetValues) | |
Создать набор данных (Create DataSet) | Создать набор данных (Create DataSet) | |
Удалить набор данных (DeleteDataSet) | Удалить набор данных (DeleteDataSet) | |
Получение каталога набора данных (GetDataSetDirectory) | Получение каталога набора данных (GetDataSetDirectory) |
А.5.6.2 Получение значений набора данных (GetDataSetValues)
А.5.6.2.1 Запрос получения значений набора данных (GetDataSetValuesRequest)
Сервис "Запрос получения значений набора данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.29
Таблица А.29 - Запрос получения значений набора данных
Имя тега | Расшифровка |
GetDataSetValues | Клиенту следует использовать сервис GetDataSetValues для вывода значений всех видимых Атрибутов Данных (DataAttributes) и, таким образом, доступных запрашивающему клиенту отсылаемым НАБОРОМ ДАННЫХ (DATA-SET) |
DSRef | Значение DSReference (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. |
Подробнее о UUID - см. [21]. | |
AssocID | AssocID для определения общего идентификатора - специального клиента. |
AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.2.2 Ответ получения значений набора данных
Сервис "Ответ получения значений набора данных" следует определять следующим образом:
Имена тегов следует определять согласно таблице А.30
Таблица А.30 - Ответ получения значений набора данных
Наименование | Описание |
GetDataSetValuesResponse | Ответ сервера клиенту, запрашивающему сервис GetDataSetValues со значениями всех отсылаемых видимых Атрибутов Данных (DataAttributes) и таким образом доступных запрашивающему клиенту отсылкой НАБОРА ДАННЫХ (DATA-SET) |
DataAttrVal | Тип, привязывающий Значение из DataRef, содержащемся в tDataAttributeValue типе |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.3 Задать значения набора данных (SetDataSetValues)
А.5.6.3.1 Запрос "Задать значения набора данных" (SetDataSetValuesRequest)
Сервис запроса "Задать значения набора данных" следует описывать следующим образом:
Имена тегов следует определять согласно таблице А.31
Таблица А.31 - Запрос "Задать значения набора данных"
Имя тега | Описание |
SetDataSetValuesRequest | Клиенту следует использовать сервис SetDataSetValues для задания значений всех видимых Атрибутов Данных (DataAttributes) соответствующих Данных (DATA), и таким образом доступных запрашивающему клиенту отсылаемым НАБОРОМ ДАННЫХ (DATA-SET) |
DSRef | Значение DSReference (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
DataAttrVal | Тип, привязывающий Значение из DataRef содержащееся в tDataAttributeValue типе |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.3.2 Ответ "Задать значения набора данных" (SetDataSetValuesResponse)
Сервис ответа "Задать значения набора данных" следует описывать следующим образом:
Имена тегов следует определять согласно таблице А.32.
Таблица А.32 - Ответ "Задать значения набора данных"
Имя тега | Описание |
SetDataSetValuesResponse | Ответ сервера клиенту, запрашивающему сервис SetDataSetValues со значениями всех отсылаемых видимых Атрибутов Данных (DataAttributes) соответствующих Данных (DATA) и таким образом доступных запрашивающему клиенту отсылкой НАБОРА ДАННЫХ (DATA-SET) |
Result | Простая строка результата "Ok", обозначающая, что запрос "Задать значение" Set-Value был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.4 Создание набора данных (CreateDataSet)
А.5.6.4.1 Запрос "Создать набор данных" (CreateDataSetRequest)
Сервис запроса "Создать набор данных" (CreateDataSetRequest) следует описывать следующим образом:
Имена тегов описаны в таблице А.33.
Таблица А.33 - Запрос "Создать набор данных"
Наименование | Описание |
CreateDataSetRequest | Клиенту следует использовать сервис CreateDataSet для запроса сервера создать НАБОР ДАННЫХ (DATA-SET) со списком видимых определенных членов с функциональными ограничениями или функционально ограниченным атрибутом данных (FCDA) и таким образом доступных запрашивающему клиенту |
DSRef | Значение DSRef (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
DSMemberRef | Атрибут DSMemberRef будет описывать функционально ограниченные данные (FCD) или функционально ограниченный атрибут данных (FCDA) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.4.2 Ответ "Создать набор данных" (CreateDataSetResponse)
Сервис ответа "Создать набор данных" (CreateDataSetResponse) следует описывать следующим образом:
Имена тегов описаны в таблице А.34.
Таблица А.34 - Ответ "Создать набор данных"
Наименование | Описание |
CreateDataSetResponse | Ответ сервера клиенту на запрос "Создать набор данных" CreateDataSet созданием НАБОРА ДАННЫХ (DATA-SET) со списком видимых определенных членов с функциональными ограничениями или функционально ограниченным атрибутом данных (FCDA) и таким образом доступных запрашивающему клиенту |
Result | Простая строка результата "Ok", обозначающая, что запрос "Задать значение" SetValue был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.5 Удалить набор данных (DeleteDataSet)
А.5.6.5.1 Запрос "Удалить набор данных"
Сервис запроса "Удалить набор данных" (DeleteDataSetRequest) следует описывать следующим образом:
Имена тегов описаны в таблице А.35.
Таблица А.35 - Запрос "Удалить набор данных"
Наименование | Описание |
DeleteDataSetRequest | Клиенту следует использовать DeleteDataSet для запроса сервера на удаление обнаруженного набора данных и таким образом доступного запрашивающему клиенту |
DSRef | Значение DSRef (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.5.2 Ответ "Удалить набор данных" (DeleteDataSetResponse)
Сервис ответа "Удалить набор данных" (DeleteDataSetResponse) следует описывать следующим образом:
Имена тегов описаны в таблице А.36
Таблица А.36 - Ответ "Удалить набор данных"
Наименование | Описание |
DeleteDataSetResponse | Ответ сервера клиенту, запрашивающему сервис DeleteDataSet, путем удаления НАБОРА ДАННЫХ (DATA-SET) и таким образом доступным запрашивающему клиенту |
Result | Простая строка результата "Ok", обозначающая, что запрос "Задать значение" SetValue был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.6 Получить директорию набора данных (GetDataSetDirectory)
А.5.6.6.1 Основное положение
Клиенту следует использовать сервис GetDataSetDirectory для вывода области имен со всеми подверженными действию данными (DATA) и таким образом доступные клиенту, обращающемуся к НАБОРУ ДАННЫХ (DATA SET).
А.5.6.6.2 Запрос "Получить директорию набора данных" (GetDataSetDirectoryRequest)
Запрос сервиса "Получить директорию набора данных" (GetDataSetDirectoryRequest) следует описывать следующим образом.
Имена тегов описаны в таблице А.37.
Таблица А.37 - Запрос "Получить директорию набора данных"
Наименование | Описание |
GetDataSetDirectoryRequest | Клиенту следует использовать сервис GetDataSetDirectoryRequest для вывода списка объектных ссылок для всех членов наборов данных, на который ссылается видимый набор данных (DATA SET) и таким образом доступный запрашивающему клиенту |
DSRef | Значение DSRef (Запрос Данных) должно быть уникальным именем пути к действующему НАБОРУ ДАННЫХ (DATA-SET) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.6.6.3 Ответ "Получить директорию набора данных" (GetDataSetDirectoryResponse)
Ответ сервиса "Получить директорию набора данных" (GetDataSetDirectoryResponse) следует описывать следующим образом.
Имена тегов определены в таблице А.38.
Таблица А.38 - Ответ "Получить директорию набора данных"
Наименование | Описание |
GetDataSetDirectoryResponse | Сервер отвечает клиенту, который запросил сервис GetDataSetDirectory, путем вывода списка объектных ссылок для всех членов наборов данных, на который ссылается видимый набор данных (DATA SET) и таким образом доступный запрашивающему клиенту |
DSMemberRef | Атрибут DSMemberRef будет описывать функционально ограниченные данные (FCD) или функционально ограниченный атрибут данных (FCDA) |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7 Отображение класса сервисов ОТЧЕТ-УПРАВЛЕНИЕ-БЛОКИРОВАНИЕ (RCB)
А.5.7.1 Основные положения
Класс сервисов RCB должен быть отображен веб-сервисам так, как определено в таблице А.40. В ГОСТ Р 54418.25.3 (раздел А.1 (приложение А)) предложен образец, как сервисы ОТЧЕТ (REPORT) предполагаемо функционируют на практике.
Таблица А.39 - Отображение сервисов отчет, управление, блокирование
ГОСТ Р 54418.2 IM Class (информационная модель) | ГОСТ Р 54418.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и Web-сервисам |
ОТЧЕТ-УПРАВЛЕНИЕ-БЛОКИРОВАНИЕ | ||
AddSubscription (Добавить Подписку) | AddSubscription (Добавить Подписку) | |
RemoveSubscription (Удалить подписку) | RemoveSubscription (Удалить подписку) | |
Report (Отчет) | ReportRequest/ReportResponse (Запрос/Ответ отчета) | |
BRCB (Буферизованный RCB) | tBRCB | |
GetBRCBValues (Получить BRCB значения) | GetBRCBValues (Получить BRCB значения) | |
SetBRCBValues (Указать BRCB значения) | SetBRCBValues (Указать BRCB значения) | |
URCB (Небуферизованный RCB) | tURCB | |
GetURCBValues (Получить URCB значения) | GetURCBValues (Получить URCB значения) | |
SetURCBValues (Указать URCB значения) | SetURCBValues (Указать URCB значения) |
Веб-Сервис методически принуждает сервер отвечать на запросы, посланные клиентами. Механизм отчета определен в информационном обмене указанных сервисов особым способом, на основании чего сервер, будучи запрошенным, заявляет сохраненные события в отчете клиенту.
Клиент запрашивает сервис "Добавить Подписку" (AddSubscription) или принудительно активирует отчетный атрибут RptEna для использования сервисов "Указать URCB значения" и "Указать BRCB значения". При отображении клиенту следует послать соответствующее сообщение. Помимо того, отображение Веб-Сервиса должно периодически посылать сообщение "Запрос Отчета" (ReportRequest) серверу в рамках временного окна между Минимальным Временем Запроса (MinRequestTime) и Максимальным Временем Запроса (MaxRequestTime).
Поведение клиента в отчетной концепции будет таким, в соответствии с рисунком А.3, которая очерчивает поведение клиента при запросе отчета с помощью установок Ответа и Запроса времени (Request- and ResponseTime).
Рисунок А.3 - Поведение клиента в отчетном сервисе (концепция)
Если "ОтветныйОтчет" (ReportResponse) не поступает до истечения Максимального Времени Ответа (MaxResponseTime), то клиент должен допустить, что сервер не активен.
Клиенту следует задержать следующий Запрос Отчета (ReportRequest) до тех пор, пока не истечет Минимальное Время Запроса (MinRequestTime).
Запрос сервиса клиенту следует осуществлять по истечении Минимального Времени Запроса (MinRequestTime) и не превышая Максимальное Время Запроса (MaxRequestTime). Минимальное Время Запроса определено сервером и сообщено клиенту в Ответе на запрос Отчета (ReportResponse). Это позволяет серверу сбалансировать загрузку в управляющем управляемом действии. Максимальное Время Ответа (MaxResponseTime) определяется клиентом. Оно позволяет клиенту сбалансировать загрузку содействия в управляемом действии.
Когда клиент желает прервать прием отчетов, ему следует отправить запрос сервисов Удаление Подписки (RemoveSubscription) или SetUBCBValues или SetBRCBValues с помощью принудительного переименования атрибута RptEna на "false". Отображено будет отправленное последнее сообщение Запрос Отчета, сопровождаемое сообщением, связанным с сервисами запрашиваемой информационно-обменной моделью (ЗапросУдаленияПодписки (RemoveSubscriptionRequest), SetURCBValuesRequest или SetBRCBValuesRequest).
Временные рамки определяются Минимальным - Максимально Запросом Времени и Минимального - Максимального Ответа Времени будет также относиться к прекращению процедуры запроса-ответа отчета.
Поведение сервера в процедуре отчета описывается следующим образом.
Когда приложения сервера получает запрос клиентом сервиса ЗапросОтчета, отображение сервера будет сохранять вместе с AssocID, пока сервер хочет отправить отчет. В результате принятия от клиента Запроса Отчета все сохраненные отчеты, которым присвоены запрошенные AssoscID, будут включены в ответ.
Рисунок 4 отображает как поведение сервера контролируется установками Ответ-Запрос Время.
Рисунок А.4 - Поведение сервера в сервисе отчетов (концепция)
Если "ЗапросОтчета" (ReportRequest) не поступает до истечения МаксимальногоВремениЗапроса (MaxRequesteTime), сервер должен допустить, что клиент не активен.
Серверу следует задержать следующий ОтветныйОтчет (ReportResponse) до тех пор, пока не истечет МинимальноеВремяОтвета (MinResponseTime).
Если данные, которые должны быть в отчете, представлены, когда МинимальноеВремяОтвета истекло, тогда ОтветныйОтчет должен быть отправлен немедленно.
Если данные, которые должны быть в отчете, не представлены, когда МинимальноеВремяОтвета истекло, тогда ОтветныйОтчет должен быть отправлен немедленно, данные для нового момента становятся доступными.
Если данные отчета не становятся доступными, пустой Отчетный Ответ (с отсутствием Форматов Отчета (ReportFormats)) будет отправлен до истечения Максимального Времени Ответа.
Временные рамки, определенные Минимальным-Максимальным Временем Ответа и Минимальным-Максимальным Временем Запроса, будут также относиться к прекращению процедуры запроса-ответа отчета.
В зависимости от отслеживания отчетной последовательности в случае неправильного срабатывания, потери соединения, переполнения буфера и т.д., последовательность, сгенерированная сервером, получена через SqNum в ФорматеОтчета (ReportForemat). Отображение клиента в получении SqNum способно отслеживать последовательность отчета и показывать случай, если любой отчет был утерян или дубликат отчета был получен. С помощью использования EntrylD клиент способен запросить особый отчет, потерянный в течение совместной работы. Более подробная детализация процесса, связанного с SqNum и восстановления потерянных отчетов, реализуется особым образом и не является объектом настоящего стандарта. SqNum будет уникальным для каждого случая совместной работы. Рисунок А.5 показывает вышеописанный механизм процессов, связанных с отчетами.
Рисунок А.5 - Механизм сервисов реализации отчетов (концепция)
Сервисы, участвующие в реализации отчетов, специфицированы в А.5.7.2-А.5.7.7.4.
А.5.7.2 Добавить Подписку (AddSubscription)
А.5.7.2.1 Запрос "Добавить Подписку" (AddSubscriptionRequest)
Запрос сервиса "Добавить Подписку" (AddSubscriptionRequest) следует оформлять следующим образом:
Имена тегов разъяснены в таблице А.40.
Таблица А.40 - Запрос "Добавить подписку"
Наименование | Описание |
AddSubscription Request | Запрос AddSubscriptionRequest должен следовать за ReportRequest во временных рамках от MinRequest до MaxRequestTime, определенных для сервиса Отчет (Report) |
RCBRef | Атрибут RCBRef - это уникальное имя пути к RCB |
RCBType | Тип RCB (RCBType) означает выбор типа, BRCB или URCB, используемого подпиской |
RptID | Атрибут RptID - это ориентированный на клиента идентификатор отчета BRCB, который является следствием создания отчета. Если значение идентификатора отчета BRCB равно НОЛЬ (NULL), то упоминание о BRCB будет сообщено как идентификатор отчета |
RptEna | Атрибут RptEna используется для контроля и индикации текущего состояния BRCB |
DatSet | Атрибут DatSet указывает ОбъектнуюСсылку (ObjectReference) на наблюдаемый НАБОР ДАННЫХ (DATA-SET) и какие значения членов НАБОРА ДАННЫХ (DATA-SET) (один, подмножество или все) будут сообщены в отчете |
Optflds | Атрибут OptFlds - это указанные клиентом дополнительно включенные в отчет поля, отправленные BRCB |
BufTm | Атрибут BufTm указывает временной интервал в миллисекундах для буферизации внутренних уведомлений вследствие изменения данных (dchg), изменения качеств (qchg), обновления данных (dupd) BRCB для включения в единичный отчет |
TrgOp | Атрибут TrgOps указывает условия пуска, которые наблюдаются этой BRCB. Определяются следующие значения: |
IntgPd | Если TrgOp включает установку указания сплошности, то атрибут IntgPd указывает период времени для образования отчета безошибочности (в миллисекундах). Отчет безошибочности сообщает значения всех членов связанного НАБОРА ДАННЫХ (DATA-SET). BufTm не имеет эффекта, когда эти изменения включаются в отчет |
DSMbrRef | Атрибут DSMbrRef определяет функционально связанные данные (FCD) или функционально связанные атрибуты (FCDA) данных (DATA) |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер. |
А.5.7.2.2 Ответ "Добавить Подписку" (AddSubscriptionResponse)
Ответ сервиса "Добавить Подписку" (AddSubscriptionResponse) следует оформлять следующим образом:
Имена тегов описаны в таблице А.41.
Таблица А.41 - Ответ "Добавить Подписку"
Имя Тега | Описание |
AddSubscription Response | Ответ AddSubscriptionResponse должен следовать за ReportResponse во временных рамках от MinResponse до MaxResponseTime, определенных для сервиса Отчет (Report) |
Result | Простая строка результата "Ok", обозначающая, что запрос "Задать значение" SetValue был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.3 Удалить Подписку (RemoveSubscription)
А.5.7.3.1 Запрос "Удалить Подписку" (RemoveSubscriptionRequest)
Запрос сервиса "Удалить Подписку" (RemoveSubscriptionRequest) следует оформлять следующим образом:
Имена тегов описаны в таблице А.42.
Таблица А.42 - Запрос "Удалить Подписку"
Наименование | Описание |
RemoveSubscription Request | Клиенту следует использовать сервис RemoveSubscriptionRequest для удаления оформленной подписки |
RCBRef | Атрибут RCBRef это уникальное имя пути к RCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.3.2 Ответ "Удалить Подписку" (RemoveSubscriptionResponse)
Ответ сервиса "Удалить Подписку" (RemoveSubscriptionResponse) следует оформлять следующим образом:
Имена тегов описаны в таблице А.43.
Таблица А.43 - Ответ "Удалить подписку"
Наименование | Описание |
RemoveSubscription Response | Сервер отвечает клиенту на запрос "Удалить Подписку", используя сервис удаления подписки |
Result | Простая строка результата "Ok", обозначающая, что запрос "Удалить подписку" (RemoveSubscription) был принят |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.3.3 Формат Отчета (ReportFormat)
Структура Формата Отчета (ReportFormat) строится следующим образом:
Имена тегов описаны в таблице А.44.
Таблица А.44 - Формат Отчета
Наименование | Описание |
tReportFormat | Сервис Формат Отчета (ReportFormat) указывает информацию, которая должна быть включена в отчет |
RptID | Атрибут RptID - это ориентированный на клиента идентификатор отчета BRCB, который является следствием создания отчета. Если значение идентификатора отчета BRCB равно НОЛЬ (NULL), то упоминание о BRCB будет сообщено как идентификатор отчета |
OptFlds | Атрибут OptFlds - это указанные клиентом дополнительно включенные в отчет поля, отправленные BRCB |
SqNum | Атрибут SqNum указывает последовательный номер каждого BRCB, у которого допуск отчета установлен на TRUE. Этот номер будет увеличиваться BRCB для каждого созданного и отправленного отчета. Увеличение будет происходить, как только BRCB сформировало отчет и получило запрос на его передачу. Первый отчет, следующий за установкой допуска отчета на TRUE, будет содержать последовательный номер 0. Последовательный номер будет меняться от 0 до его максимального значения. Последовательный номер будет включен в отчет, если дополнительные поля, включенные в отчет атрибутом (OptFlds) BRCB, включают последовательный номер (=TRUE); в противном случае он будет исключен |
SubSqNum | В случае длинных отчетов, которые не умещаются в одно сообщение, одиночный отчет будет разделен на частичные отчеты. Каждый сегмент единого отчета будет пронумерован одним и тем же последовательным номером и уникальным SubSqNm. BRCB будет содержать последовательные номера сегментов для каждого отчета. Этот номер будет увеличиваться BRCB для каждого созданного и отправленного суботчета. Увеличение будет происходить, как только BRCB сформировало суботчет и получило запрос на его передачу. Первый суботчет, следующий за установкой допуска отчета на TRUE, будет содержать последовательный номер 0. Последовательный номер будет меняться от 0 до его максимального значения. Последовательный номер будет включен в суботчет, если дополнительные поля, включенные в отчет атрибутом (OptFlds) BRCB, включают последовательный номер (=TRUE); в противном случае он будет исключен |
MoreSegFlw | Параметр БольшеЧастейСледует (MoreSegmentsFollow) показывает, что больше частей отчета с тем же последовательным номером будут следовать |
DatSet | Параметр DatSet выведен из соответствующего атрибута в BRCB |
BufOvfl | Параметр BufOvfl показывает клиенту, что записи в буфере могут быть потеряны. Определение возможности потери информации появляется, когда запросы клиента ресинхронизируются с несуществующей записью или к первой записи в очереди ожидания |
ConfRev | Атрибут ConfRev будет представлять итоговое количество случаев, когда конфигурация НАБОРА-ДАННЫХ (DATA-SET), на которую ссылается DatSet изменена |
TimeOfEntry | Атрибут ВремяЗаписи (TimeOfEntry) означает время, за которое уведомление о внутреннем событии было получено оператором отчетов. Это значение присваивается специальному EntrylD, который также присвоен во время получения внутреннего уведомления |
EntryID | Значение EntrylD, возращенное в ответ GetBRCBValues, определяется следующим: |
EntryData | Параметр EntryData содержит данные ссылки, значения и reasonCode (код причины) каждого члена НАБОРА ДAHHЫX (DATA-SET), включенного в отчет. Значение должно включать значение всех атрибутов данных члена НАБОРА ДАННЫХ (DATA-SET) |
А.5.7.4 Получение Значений BRCB (GetBRCBValues)
А.5.7.4.1 Запрос "Получение Значений BRCB" (GetBRCBValuesRequest)
Запрос сервиса "Получение Значений BRCB" следует вызывать следующим образом:
Имена тегов описаны в таблице А.45.
Таблица А.45 - "Получение Значений BRCB"
Наименование | Описание |
GetBRCBValues Request | Клиенту следует использовать сервис GetBRCBValues, чтобы получить значения атрибутов BRCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
BRCBRef | Значение BRCBRef должно быть уникальным именем пути к действующему BRCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.4.2 Ответ "Получение Значений BRCB" (GetBRCBValuesResponse)
Ответ сервиса "Получение Значений BRCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.46.
Таблица А.46 - Ответ "Получение Значений BRCB"
Наименование | Описание |
GetBRCBValues Response | Сервер отвечает клиенту на запрос сервиса GetBRCBValues путем выдачи значений атрибутов BRCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
RptID | Атрибут RptID - это ориентированный на клиента идентификатор отчета BRCB, который является следствием создания отчета. Если значение идентификатора отчета BRCB равно НОЛЬ (NULL), то упоминание о BRCB будет сообщено как идентификатор отчета |
RptEna | Атрибут RptEna служит для контроля и отображения текущего состояния BRCB |
DatSet | Атрибут DatSet указывает ОбъектнуюСсылку (ObjectReference) на наблюдаемый НАБОР ДАННЫХ (DATA-SET) и какие значения членов НАБОРА ДАННЫХ (DATA-SET) (один, подмножество или все) будут сообщены в отчете |
ConfRev | Атрибут ConfRev будет представлять итоговое количество случаев, когда конфигурация НАБОРА ДАННЫХ (DATA-SET), на которую ссылается DatSet, изменена |
OptFlds | Атрибут OptFlds - это указанные клиентом дополнительно включенные в отчет поля, отправленные BRCB |
BufTm | Атрибут BufTm указывает временной интервал в миллисекундах для буферизации внутренних уведомлений вследствие изменения данных (dchg), изменения качеств (qchg), обновления данных (dupd) BRCB для включения в единичный отчет |
SqNum | Атрибут SqNum указывает последовательный номер каждого BRCB, у которого допуск отчета установлен на TRUE. Этот номер будет увеличиваться BRCB для каждого созданного и отправленного отчета. Увеличение будет происходить, как только BRCB сформировало отчет и получило запрос на его передачу |
TrgOp | Атрибут TrgOps указывает условия пуска, которые наблюдаются этой BRCB. Определяются следующие значения: |
IntgPd | Если TrgOp включает установку указания сплошности, атрибут IntgPd указывает период времени для образования отчета безошибочности (в миллисекундах). Отчет безошибочности сообщает значения всех членов связанного НАБОРА ДАННЫХ (DATA-SET). BufTm не имеет эффекта, когда эти изменения включаются в отчет |
Gl | Атрибут GI указывает запрос на начало процесса основного запроса. После установки TRUE BRCB начинает процесс основного запроса. После опознания основного запроса этот атрибут автоматически с помощью BRCB устанавливается на FALSE |
PurgeBuf | Атрибут PurgeBuf указывает запрос на отмену буферизованных событий. После установки TRUE BRCB отменяет буферизованные события, все еще не отправленные клиенту. После отмены буферизованных событий этот атрибут автоматически с помощью BRCB устанавливается на FALSE |
EntryID | Значение EntrylD, возращенное в ответ GetBRCBValues, определяется следующим: |
TimeOfEntry | Атрибут ВремяЗаписи (TimeOfEntry) означает время, за которое уведомление о внутреннем событии было получено оператором отчетов. Это значение присваивается специальному EntrylD, который также присвоен во время получения внутреннего уведомления |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.5 Установить Значения BRCB (SetBRCBValues)
А.5.7.5.1 Запрос "Установить Значения BRCB" (SetBRCBValuesRequest)
Запрос сервиса "Установить Значения BRCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.47.
Таблица А.47 - Запрос "Установить Значения BRCB"
Наименование | Описание |
SetBRCBValues Request | Клиенту следует использовать сервис SetBRCBValues, чтобы задать значения атрибутов BRCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
BRCBRef | Значение BRCBRef должно быть уникальным именем пути к действующему BRCB |
RptID | Атрибут RptID - это ориентированный на клиента идентификатор отчета BRCB, который является следствием создания отчета. Если значение идентификатора отчета BRCB равно НУЛЬ (NULL), то упоминание о BRCB будет сообщено как идентификатор отчета |
RptEna | Атрибут RptEna служит для контроля и отображения текущего состояния BRCB |
DatSet | Атрибут DatSet указывает ОбъектнуюСсылку (ObjectReference) на наблюдаемый НАБОР ДАННЫХ (DATA-SET) и какие значения членов НАБОРА ДАННЫХ (DATA-SET) (один, подмножество или все) будут сообщены в отчете |
OptFlds | Атрибут OptFlds - это указанные клиентом дополнительно включенные в отчет поля, отправленные BRCB |
BufTm | Атрибут BufTm указывает временной интервал в миллисекундах для буферизации внутренних уведомлений вследствие изменения данных (dchg), изменения качеств (qchg), обновления данных (dupd) BRCB для включения в единичный отчет |
TrgOp | Атрибут TrgOps указывает условия пуска, которые наблюдаются этой BRCB. Определяются следующие значения: |
IntgPd | Если TrgOp включает установку указания сплошности, атрибут IntgPd указывает период времени для образования отчета безошибочности (в миллисекундах). Отчет безошибочности сообщает значения всех членов связанного НАБОРА ДАННЫХ (DATA-SET). BufTm не имеет эффекта, когда эти изменения включаются в отчет |
Gl | Атрибут GI указывает запрос на начало процесса основного запроса. После установки TRUE BRCB начинает процесс основного запроса. После опознания основного запроса этот атрибут автоматически с помощью BRCB устанавливается на FALSE |
PurgeBuf | Атрибут PurgeBuf указывает запрос на отмену буферизованных событий. После установки TRUE BRCB отменяет буферизованные события, все еще не отправленные клиенту. После отмены буферизованных событий этот атрибут автоматически с помощью BRCB устанавливается на FALSE |
EntryID | Значение EntrylD, возращенное в ответ GetBRCBValues, определяется следующим: |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.5.2 Ответ "Установить Значения BRCB" (SetBRCBValuesResponse)
Ответ сервиса "Установить Значения BRCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.48.
Таблица А.48 - Ответ "Установить Значения BRCB"
Наименование | Описание |
SetBRCBValues Response | Сервер отвечает клиенту на запрос сервиса SetBRCBValues путем установления значений атрибутов BRCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
Result | Простая строка результата "Ok", обозначающая, что запрос SetBRCBValues был принят |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.6 Получить значения URCB (GetURCBValues)
А.5.7.6.1 Запрос "Получить значения URCB" (GetURCBValuesRequest)
Запрос сервиса "Получить значения URCB" (GetURCBValuesRequest) следует описывать следующим образом:
Имена тегов описаны в таблице А.49.
Таблица А.49 - Получение значений URCB
Наименование | Описание |
GetURCBValues Request | Клиенту следует использовать сервис GetURCBValues, чтобы получить значения атрибутов URCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
URCBRef | Значение URCBRef должно быть уникальным именем пути к действующему URCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.4.2 Ответ "Получение значений URCB" (GetURCBValuesResponse)
Ответ сервиса "Получение значений URCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.50.
Таблица А.50 - Ответ "Получение значений URCB"
Наименование | Описание |
GetURCBValues Response | Сервер отвечает клиенту на запрос сервиса GetURCBValues путем выдачи значений атрибутов URCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
RptID | Атрибут RptID это ориентированный на клиента идентификатор отчета BRCB, который является следствием создания отчета. Если значение идентификатора отчета BRCB равно НУЛЬ (NULL), то упоминание о BRCB будет сообщено как идентификатор отчета |
RptEna | Атрибут RptEna служит для контроля и отображения текущего состояния BRCB |
Resv | Атрибут Resv (если установлен TRUE) будет показывать, что URCB в текущем времени зарезервирована для клиента, который установил значение TRUE. Остальные клиенты не допущены устанавливать любые атрибуты этой URCB |
DatSet | Атрибут DatSet указывает ОбъектнуюСсылку (ObjectReference) на наблюдаемый НАБОР ДАННЫХ (DATA-SET) и какие значения членов НАБОРА ДАННЫХ (DATA-SET) (один, подмножество или все) будут сообщены в отчете |
ConfRev | Атрибут ConfRev будет представлять итоговое количество случаев, когда конфигурация НАБОРА-ДАННЫХ (DATA-SET), на которую ссылается DatSet, изменена |
OptFlds | Атрибут OptFlds - это указанные клиентом дополнительно включенные в отчет поля, отправленные BRCB |
BufTm | Атрибут BufTm указывает временной интервал в миллисекундах для буферизации внутренних уведомлений вследствие изменения данных (dchg), изменения качеств (qchg), обновления данных (dupd) BRCB для включения в единичный отчет |
SqNum | Атрибут SqNum указывает последовательный номер каждого BRCB, у которого допуск отчета установлен на TRUE. Этот номер будет увеличиваться BRCB для каждого созданного и отправленного отчета. Увеличение будет происходить, как только BRCB сформировало отчет и получило запрос на его передачу |
TrgOp | Атрибут TrgOps указывает условия пуска, которые наблюдаются этой BRCB. Определяются следующие значения: |
IntgPd | Если TrgOp включает установку указания сплошности, атрибут IntgPd указывает период времени для образования отчета безошибочности (в миллисекундах). Отчет безошибочности сообщает значения всех членов связанного НАБОРА ДАННЫХ (DATA-SET). BufTm не имеет эффекта, когда эти изменения включаются в отчет |
Gl | Атрибут GI указывает запрос на начало процесса основного запроса. После установки TRUE, BRCB начинает процесс основного запроса. После опознания основного запроса этот атрибут автоматически с помощью URCB устанавливается на FALSE |
Result | Простая строка результата "Ok", обозначающая, что запрос GetURCBValues был принят |
PurgeBuf | Атрибут PurgeBuf указывает запрос на отмену буферизованных событий. После установки TRUE URCB отменяет буферизованные события, все еще не отправленные клиенту. После отмены буферизованных событий этот атрибут автоматически с помощью URCB устанавливается на FALSE |
EntryID | Значение EntrylD, возращенное в ответ GetURCBValues, определяется следующим: |
TimeOfEntry | Атрибут ВремяЗаписи (TimeOfEntry) означает время, за которое уведомление о внутреннем событии было получено оператором отчетов. Это значение присваивается специальному EntrylD, который также присвоен во время получения внутреннего уведомления |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.5 Установить значения URCB (SetURCBValues)
А.5.7.5.1 Запрос "Установить значения URCB" (SetURCBValuesRequest)
Запрос сервиса "Установить значения URCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.51.
Таблица А.51 - Запрос "Установить значения URCB"
Наименование | Описание |
SetURCBValues Request | Клиенту следует использовать сервис SetURCBValues, чтобы задать значения атрибутов URCB обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
URCBRef | Значение URCBRef должно быть уникальным именем пути к действующему URCB |
RptID | Атрибут RptID - это ориентированный на клиента идентификатор отчета URCB, который является следствием создания отчета. Если значение идентификатора отчета URCB равно НУЛЬ (NULL), то упоминание о URCB будет сообщено как идентификатор отчета |
RptEna | Атрибут RptEna (если установлен TRUE) показывает, что URCB в настоящий момент способен передавать значения НАБОРА ДАННЫХ (DATA-SET). Если установлено TRUE, URCB отслеживает посылаемое значение НАБОРА ДАННЫХ (DATA-SET) и создает отчеты. Если установлено FALSE, URCB перестает выпускать отчеты |
Resv | Атрибут Resv (если установлен TRUE) будет показывать, что URCB в текущем времени зарезервирована для клиента, который установил значение TRUE. Остальные клиенты не допущены устанавливать любые атрибуты этой URCB. Если атрибут Resc не установлен на TRUE, то установка TRUE для RptEna резервирует косвенно |
DatSet | Атрибут DatSet указывает ОбъектнуюСсылку (ObjectReference) на наблюдаемый НАБОР ДАННЫХ (DATA-SET) и какие значения членов НАБОРА ДАННЫХ (DATA-SET) (один, подмножество или все) будут сообщены в отчете |
OptFlds | Атрибут OptFlds это указанные клиентом дополнительно включенные в отчет поля, отправленные URCB |
BufTm | Атрибут BufTm указывает временной интервал в миллисекундах для буферизации внутренних уведомлений вследствие изменения данных (dchg), изменения качеств (qchg), обновления данных (dupd) URCB для включения в единичный отчет |
TrgOp | Атрибут TrgOps указывает условия пуска, которые наблюдаются этой URCB. Определяются следующие значения: |
IntgPd | Если TrgOp включает установку указания сплошности, атрибут IntgPd указывает период времени для образования отчета безошибочности (в миллисекундах). Отчет безошибочности сообщает значения всех членов связанного НАБОРА ДАННЫХ (DATA-SET). BufTm не имеет эффекта, когда эти изменения включаются в отчет |
Gl | Атрибут GI указывает запрос на начало процесса основного запроса. После установки TRUE URCB начинает процесс основного запроса. После опознания основного запроса этот атрибут автоматически с помощью URCB устанавливается на FALSE |
PurgeBuf | Атрибут PurgeBuf указывает запрос на отмену буферизованных событий. После установки TRUE URCB отменяет буферизованные события, все еще не отправленные клиенту. После отмены буферизованных событий этот атрибут автоматически с помощью URCB устанавливается на FALSE |
EntryID | Значение EntrylD, возращенное в ответ GetURCBValues, определяется следующим: |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.5.2 Ответ "Установить значения URCB" (SetURCBValuesResponse)
Ответ сервиса "Установить значения URCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.52.
Таблица А.52 - Ответ "Установить значения URCB"
Наименование | Описание |
SetURCBValues Response | Сервер отвечает клиенту на запрос сервиса SetURCBValues путем установления значений атрибутов URCB обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
Result | Простая строка результата "Ok", обозначающая, что запрос SetURCBValues был принят |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.7.3 Запрос Отчета (ReportRequest)
Сервис "Запрос Отчета" следует описывать следующим образом:
Имена тегов описаны в таблице А.53.
Таблица А.53 - Запрос Отчета (ReportRequest)
Наименование | Описание |
ReportRequest | Клиенту следует использовать сервис ReportRequest для получения отчета |
MaxResponseTime | МаксимальноеВремяОтвета (MaxResponseTime) определяется клиентом и сообщается серверу с целью позволить клиенту настраивать истечение срока ожидания в порядке управления. Когда MaxResponseTime истекает, клиенту следует считать сервер неактивным |
MinResponseTime | МинимальноеВремяОтвета (MinResponseTime) определяется клиентом и сообщается серверу в ReportRequest и показывает минимальное время, которое сервер должен выждать до ответа на ReportRequest. Это время используется клиентом для сбалансирования загрузки способа управления |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.7.7.4 Ответный Отчет (ReportResponse)
Сервис ответа на запрос отчета (ReportResponse) следует описывать следующим образом:
Теги описаны в таблице А.54.
Таблица А.54 - Ответный Отчет (ReportResponse)
Наименование | Описание |
ReportResponse | Сервер отвечтает на сервис запроса клиентом отчета (ReportRequest), отсылая запрашиваемый отчет |
ReportFormat | ReportFormat указывает информацию, которая должна быть включена в отчет |
MaxRequestTime | МаксимальноеВремяЗапроса (MaxRequestTime) определяется сервером и сообщается клиенту с целью позволить серверу настраивать истечение срока ожидания в порядке управления. Когда MaxRequestTime истекает, серверу следует считать клиента неактивным |
MinRequestTime | МинимальноеВремяЗапроса (MinRequestTime) определяется сервером и сообщается клиенту в ReportResponse и показывает минимальное время, которое клиент должен выждать между получением ответа от сервера (ReportResponse) и запроса следующего ReportRequest в той же самой ассоциации. Это время используется сервером для сбалансирования загрузки способа управления |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
moreFollows | Более сегментов отчета с одинаковым последовательным номером следуют |
А.5.8 Отображение класса сервисов ЗАПИСЬ В ЖУРНАЛ-КОНТРОЛЬ-БЛОКИРОВАНИЕ
(LCB - LOG-CONTROL-BLOCK)
А.5.8.1 Основное положение
Отображение в веб-сервисы класса сервисов ЗАПИСЬ В ЖУРНАЛ-КОНТРОЛЬ-БЛОКИРОВАНИЕ определяется согласно таблице А.55.
Таблица А.55 - Отображение сервисов ЗАПИСЬ В ЖУРНАЛ-КОНТРОЛЬ-БЛОКИРОВАНИЕ
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services | Отображение объектам и Web сервисам |
ЗАПИСЬ В ЖУРНАЛ-КОНТРОЛЬ-БЛОКИРОВАНИЕ (LOG-CONTROL-BLOCK) | tLCB | |
Получить значения LCB (GetLCB-Values) | Получить значения (LCB GetLCBValues) | |
Установить значения LCB (SetL-CBValues) | Установить значения LCB (SetLCBValues) |
А.5.8.2 Получить значения LCB
А.5.8.2.1 Запрос "Получить значения LCB" (GetLCBValuesRequest)
Запрос сервиса "Получить значения LCB" следует описывать следующим образом:
Теги описаны в таблице А.56.
Таблица А.56 - Запрос "Получить значения LCB"
Наименование | Описание |
GetLCBValues Request | Клиенту следует использовать сервис GetLCBValues для вывода значений атрибутов LCB, обнаруженных и таким образом доступных клиенту доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
LCBRef | Атрибут LCBRef является уникальным именем пути к LCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.8.2.2 Ответ "Получить значения LCB" (GetLCBValuesResponse)
Ответ сервиса "Получить значения LCB" следует описывать следующим образом:
Имена тегов описаны в таблице А.57.
Таблица А.57 - Ответ "Получить значения LCB"
Наименование | Описание |
GetLCBValuesResponse | Сервер отвечает клиенту на запрос сервиса GetLCBValues путем выдачи значений атрибутов LCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
LogEna | Параметр LogEnable содержит значение соответствующего атрибута LogEna ссылающегося LCB |
DatSet | Параметр DataSetReference содержит значение соответствующего атрибута DataSet ссылающегося LCB |
TrgOp | Параметр TriggerOptions содержит значение соответствующего атрибута TrgOps ссылающегося LCB |
IntgPd | Параметр IntegrityPeriod содержит значение соответствующего атрибута IntgPd ссылающегося LCB |
LogRef | Параметр LogReference содержит значение соответствующего атрибута LogRef ссылающегося LCB |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.8.3 Установить значения LCB (SetLCBValues)
А.5.8.3.1 Основное положение
Атрибуты и поведение системы LCB определены в ГОСТ Р 54418.25.3 (а также в ГОСТ Р МЭК 61850-7-2).
А.5.8.3.2 Запрос "Установить значения LCB" (SetLCBValuesRequest)
Запрос сервиса "Установить значения LCB" (SetLCBValuesRequest) следует описывать следующим образом:
Имена тегов определены в таблице А.58.
Таблица А.58 - Запрос "Установить значения LCB"
Наименование | Описание |
SetLCBValuesRequest | Клиенту следует использовать сервис SetLCBValues, чтобы задать значения атрибутов URCB обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
LCBRef | Параметр LCBReference содержит значение соответствующего атрибута LCBRef ссылающегося LCB |
LogEna | Параметр LogEnable содержит значение соответствующего атрибута LogEna ссылающегося LCB |
DatSet | Параметр DataSetReference содержит значение соответствующего атрибута DataSet ссылающегося LCB |
OptFlds | Параметр OptFlds указывает выбранные клиентом дополнительные поля, включенные в отчет этого BRCB |
IntgPd | Параметр IntegrityPeriod содержит значение соответствующего атрибута |
IntgPd ссылающегося LCB | |
LogRef | Параметр LogReference содержит значение соответствующего атрибута LogRef ссылающегося LCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.8.3.3 Ответ "Установить значения LCB" (SetLCBValuesResponse)
Ответ сервиса "Установить значения LCB" (SetLCBValuesResponse) следует описывать следующим образом:
Имена тегов определены в таблице А.59.
Таблица А.59 - Ответ "Установить значения LCB"
Наименование | Описание |
SetLCBValues Response | Сервер отвечает клиенту на запрос сервиса SetLCBValues путем установления значений атрибутов LCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
Result | Простая строка результата "Ok", обозначающая, что запрос SetLCBValues был принят |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9 Отображение класса сервисов "Журнал" (LOG)
А.5.9.1 Основное положение
Класс сервисов "Журнал" следует отображать Веб-сервисам согласно таблице А.60. В ГОСТ Р 54418.25.3 (раздел А.2 (приложение А)) предложен образец внедрения сервисов "Журнал" в функционирование на практике.
Таблица А.60 - Отображение класса сервисов "Журнал" (LOG)
ГОСТ Р 54418.25.2 IM Class (информационная модель) | ГОСТ Р 54418.25.3 IEM Services (сервисы информационно-обменной модели) | Отображение объектам и Web сервисам |
LOG | tLOG | |
Получить значения состояния журнала (GetLogStatusValues) | Получить значения состояния журнала (GetLogStatusValues) | |
Вывод журнала по времени (QueryLogByTime) | Вывод журнала по времени (QueryLogByTime) | |
Вывод журнала впоследствии (QueryLogAfter) | Вывод журнала впоследствии (QueryLogAfter) |
А.5.9.2 Получить значения состояния журнала (GetLogStatusValues)
А.5.9.2.1 Запрос "Получить значения состояния журнала" (GetLogStatusValuesRequest)
Запрос сервиса "Получить значения состояния журнала" следует описывать следующим образом:
Имена тегов описаны в таблице А.61.
Таблица А.61 - Запрос "Получить значения состояния журнала"
Наименование | Описание |
GetLogStatusValuesRequest | Клиенту следует использовать сервис GetLogStatusValues для вывода значений атрибутов LCB, обнаруженных и таким образом доступных клиенту доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
LogRef | Атрибут LogRef является уникальным именем пути к LCB |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9.2.2 Ответ "Получить значения состояния журнала" (GetLogStatusValuesResponse)
Ответ сервиса "Получить значения состояния журнала" следует описывать следующим образом:
Имена тегов описаны в таблице А.62.
Таблица А.62 - Ответ "Получить значения состояния журнала"
Наименование | Описание |
GetLogStatusValues Response | Сервер отвечает клиенту на запрос сервиса GetLogStatusValues путем выдачи значений атрибутов LCB, обнаруженных и таким образом доступных запрашивающему клиенту отсылаемым LOGICAL NODE (ЛОГИЧЕСКИМ УЗЛОМ) |
OldEntrTm | Атрибут OldEntrTm показывает время занесения последней записи в журнал. Примечание. Это то время, когда запись была занесена в журнал. Это время отличается от отметки времени самой записи, которая показывает, когда произошло событие, повлекшее за собой создание записи в журнале |
NewEntrTm | Атрибут NewEntrTm показывает время, когда новейшая запись занесена в журнал |
OldEntr | Атрибут OldEntr показывает EntrylD для старейшей записи, доступной в журнале |
NewEntr | Атрибут NewEntr показывает EntrylD для новейшей записи, доступной в журнале |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID. полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9.3 Запрос журнала по времени (QueryLogByTime)
А.5.9.3.1 Запрос сервиса "Вывод журнала по времени" (QueryLogByTimeRequest)
Запрос сервиса "Вывод журнала по времени" следует описывать следующим образом:
Имена тегов описаны в таблице А.63.
Таблица А.63 - Запрос сервиса "Вывод журнала по времени"
Наименование | Описание |
QueryLogByTime Request | Клиенту следует использовать сервис QueryLogByTime для вывода серии записей Журнала (LOG) из временных рамок (от НачальногоВремени (StartTime) до КонечногоВремени (StopTime)) |
Log Ref | Атрибут Log Ref является уникальным именем пути к LOG |
StartTime | Параметр StartTime содержит начальное время вывода записей Журнала. Первая выбранная журнальная запись должна быть первой записью с НачальнымВременем (StartTime), большим или равным StartTime. В случае когда StartTime не указано, первая журнальная запись, содержащаяся в журнале, будет первой записью выбранной для передачи |
StopTime | Параметр StopTime содержит конечное время вывода записей Журнала. Последняя выбранная журнальная запись должна быть последней записью с КонечнымВременем (StartTime), меньшим или равным StopTime. В случае когда StopTime не указано, последняя журнальная запись, содержащаяся в журнале, будет последней записью выбранной для передачи |
DataFilter | ФильтрДанных (DataFilter) указывает FCD или FCDA, значения которых необходимо вывести из журнала в ответе. Это фильтрующий механизм: сервер будет включать только те журнальные записи, которые удовлетворяют указанному DataFilter, ссылающемуся на интервал, запрашиваемый клиентом. Если DataFilter не запрошен, сервер будет выводить все записи журнала из запрошенного интервала |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21] |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9.3.2 Ответ сервиса "Вывод журнала по времени" (QueryLogByTimeResponse)
Ответ сервиса "Вывод журнала по времени" следует описывать следующим образом:
Имена тегов описаны в таблице А.64.
Таблица А.64 - Ответ сервиса "Запрос журнала по времени"
Наименование | Описание |
QueryLogByTime Response | Сервер отвечает клиенту на запрос сервиса QueryLogByTime, выводя записи Журнала (LOG), исходя из временных рамок (StartTime и StopTime) |
LogEntry | Параметр LogEntry будет обращаться к журнальной записи, соответствующей выбранному StartTime, после которой находятся все выбранные журнальные записи |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9.4 Вывод журнала впоследствии (QueryLogAfter)
А.5.9.4.1 Запрос "Вывод журнала впоследствии" (QueryLogAfterRequest)
Запрос сервиса "Вывод журнала впоследствии" следует описывать следующим образом:
Имена тегов описаны в таблице А.65.
Таблица А.65 - Запрос "Вывод журнала впоследствии"
Наименование | Описание |
QueryLogAfterRequest | Клиенту следует использовать сервис QueryLogAfter для вывода серии записей Журнала (LOG) с номерами после StartTime и EntrylD |
LogRef | Атрибут LogReference будет указывать ОбъектСсылку LogRef на LOG |
StartTime | Параметр RangeStartTime содержит время выбранной записи Журнала (или нескольких записей, если одному времени соответствует несколько записей) |
EntryID | Параметр EntrylD будет обращаться к журнальной записи, соответствующей выбранному StartTime, после которой находятся все выбранные журнальные записи |
DataFilter | ФильтрДанных (DataFilter) указывает FCD или FCDA, значения которых необходимо вывести из журнала в ответе. Это фильтрующий механизм: сервер будет включать только те журнальные записи, которые удовлетворяют указанному DataFilter, ссылающемуся на интервал, запрашиваемый клиентом. Если DataFilter не запрошен, сервер будет выводить все записи журнала из запрошенного интервала |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.9.4.2 Ответ "Вывод журнала впоследствии" (QueryLogAfterResponse)
Ответ сервиса "Вывод журнала впоследствии" следует описывать следующим образом:
Имена тегов описаны в таблице А.66.
Таблица А.66 - Ответ "Вывод журнала впоследствии"
Наименование | Описание |
QueryLogAfterResponse | Сервер отвечает клиенту на запрос сервиса QueryLogAfter, выводя записи Журнала (LOG) с номерами после StartTime и EntrylD |
LogEntry | Параметр LogEntry будет обращаться к журнальной записи, соответствующей выбранному StartTime, после которой находятся все выбранные журнальные записи |
ServiceError | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10 Отображение класса сервисов "Контроль" (CONTROL)
А.5.10.1 Основное положение
Модель контроля позволяет клиенту специальным путем изменять состояния внутренних и внешних процессов. Модель контроля может быть применена только к Данным, имеющим атрибут ctlModel. Такие данные будут упоминаться как "объекты контроля". Модель контроля состоит из:
- спецификация сервисов;
- указанное поведение с установленными машинами.
Модель контроля определяет следующие сервисы:
- Выбор;
- Выбор со значениями;
- Отмена;
- Управление;
- ОграничениеУправления;
- ВремяАктивированияУправления.
Атрибуты, поведение объектов контроля и объектов контроля установленных машин определено в ГОСТ Р 54418.25.3 (а также в ГОСТ Р МЭК 61850-7-2).
Сервисы класса Контроль следует отображать веб-сервисам согласно с таблицей А.67.
Таблица А.67 - Отображение класса сервисов "Контроль"
ГОСТ Р 54418.25.2 IM Class | ГОСТ Р 54418.25.3 IEM Services | Отображение объектам и веб-сервисам |
CONTROL | ||
Select (Выбор) | Select (Выбор) | |
SelectWithValue (ВыборСоЗначениями) | SelectWithValue (ВыборСоЗначениями) | |
Cancel (Отмена) | Cancel (Отмена) | |
Operate (Действие) | Operate (Действие) | |
CommandTermination (Завершение выполнения команды) | CommandTermination (Завершение выполнения команды) | |
TimeActivatedOperate (Время Активирования Управления) | TimeActivatedOperate (Время Активирования Управления) |
А.5.10.2 Выбор (Select)
А.5.10.2.1 Запрос "Выбор" (SelectRequest)
Запрос сервиса "Выбор" следует описывать следующим образом:
Имена тегов описаны в таблице А.68.
Таблица А.68 - Запрос "Выбор"
Наименование | Описание |
SelectRequest | Клиент отправляет запрос Select включающий возможный объект контроля, доступный клиенту в отсылаемом Логическом Узле (LOGICAL-NODE) |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.2.2 Ответ "Выбор" (SelectResponse)
Ответ сервиса "Выбор" следует описывать следующим образом:
Имена тегов описаны в таблице А.69.
Таблица А.69 - Ответ "Выбор"
Наименование | Описание |
SelectResponse | Сервер отвечает на запрос Select предполагаемого объекта контроля путем Выбора, если клиент выделяет полномочия доступа, подтверждает, что контролируемый объект не является в настоящий момент выбранным другим клиентом, и что устройство, представленное связанным с ним Логическим узлом, в рабочем состоянии и не помечено, как ограниченно рабочее. |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Service Error | Внутренняя ошибка. Сервер будет использовать элемент обозначения того, что запрос сервиса был неудачен. Когда такой элемент представлен в ответном сообщении, клиент должен принять, что запрос отказан сервером |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.3 ВыборСоЗначениями (SelectWithValue)
А.5.10.3.1 Запрос "ВыборСоЗначениями" (SelectWithValueRequest)
Запрос сервиса "ВыборСоЗначениями" следует описывать следующим образом:
Имена тегов описаны в таблице А.70.
Таблица А.70 - Запрос "ВыборСоЗначениями"
Наименование | Описание |
SelectWithValue-Request | Клиент отправляет запрос SelectWithValue, включающий возможный объект контроля, доступный клиенту в отсылаемом Логическом Узле (LOGICAL-NODE) |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
T | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
Check | Изменения из одного состояния в следующее состояние в процессе работы будут контролироваться параметром Проверка (Check). Условия проверки могут быть указаны параметром сервиса (например, синхронная проверка). Кроме условия проверки указанного параметром сервиса, объекты контроля могут подвергаться дополнительным проверкам |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.3.2 Ответ "ВыборСоЗначениями" (SelectWithValueResponse)
Ответ сервиса "ВыборСоЗначениями" следует описывать следующим образом:
Имена тегов описаны в таблице А.71.
Таблица А.71 - Ответ "Выбор Со Значениями"
Наименование | Описание |
SelectWithValueResponse | Сервер отвечает на запрос SelectWithValue предполагаемого объекта контроля путем Выбора, если клиент выделяет полномочия доступа, подтверждает, что контролируемый объект не является в настоящий момент выбранным другим клиентом, и что устройство, представленное связанным с ним Логическим узлом, в рабочем состоянии и не помечено, как ограниченно рабочее. |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
AddCause | Параметр ДобавочноеСледствие (AddCause) будет выяснять причину в случае отказа сервиса контроля. Диапазон значений следующий: |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.4 Отмена (Cancel)
А.5.10.4.1 Запрос "Отмена"
Запрос сервиса "Отмена" следует описывать следующим образом:
Имена тегов описаны в таблице А.72.
Таблица А.72 - Запрос "Отмена"
Наименование | Описание |
CancelRequest | Клиенту следует использовать сервис Отмена для отмены ранее требуемого сервиса управления Выбор |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
T | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.4.2 Ответ "Отмена"
Ответ сервиса "Отмена" следует описывать следующим образом:
Таблица А.73 - Ответ "Отмена"
Наименование | Описание |
CancelResponse | Сервер отвечает Отмена, когда произведена отмена выбора или отказано в параметре ДобавочногоСледствия |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
T | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
AddCause | Параметр ДобавочноеСледствие (AddCause) будет выяснять причину в случае отказа сервиса контроля. Диапазон значений следующий: |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.5 Действие (Operate)
А.5.10.5.1 Запрос "Действие" (OperateRequest)
Запрос сервиса "Действие" следует описывать следующим образом:
Имена тегов описаны в таблице А.74.
Таблица А.74 - Запрос "Действие"
Наименование | Описание |
OperateRequest | Клиенту следует вызывать сервис Operate, включающий ControlObjectRef, когда требуется сервис действия |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
Check | Изменения из одного состояния в следующее состояние в процессе работы будут контролироваться параметром Проверка (Check). Условия проверки могут быть указаны параметром сервиса (например, синхронная проверка). Кроме условия проверки указанного параметром сервиса, объекты контроля могут подвергаться дополнительным проверкам |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.5.2 Ответ "Действие" (OperateResponse)
Ответ сервиса "Действие" следует описывать следующим образом:
Имена тегов описаны в таблице А.75.
Таблица А.75 - Ответ "Действие"
Наименование | Описание |
OperateResponse | Сервер отвечает Operate, когда сервис завершил действие или отказано в параметре ДобавочногоСледствия |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы. |
AddCause | Параметр ДобавочноеСледствие (AddCause) будет выяснять причину в случае отказа сервиса контроля. Диапазон значений следующий: |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.6 Завершение выполнения команды (CommandTermination)
А.5.10.6.1 Запрос "Завершение выполнения команды" (CommandTerminationRequest)
Запрос сервиса "Завершение выполнения команды" следует оформлять следующим образом:
Имена тегов описаны в таблице А.76.
Таблица А.76 - Запрос "Завершение выполнения команды"
Наименование | Описание |
CommandTermination Request | Клиенту следует использовать сервис CommandTermination, включая ControlObjectRef, когда требуется прекращение предыдущей команды |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.6.2 Ответ "Завершение выполнения команды" (CommandTerminationResponse)
Ответ сервиса "Завершение выполнения команды" следует оформлять следующим образом:
Имена тегов описаны в таблице А.77.
Таблица А.77 - Ответ "Завершение выполнения команды"
Наименование | Описание |
CommandTermination Response | Сервер отвечает CommandTermination, когда сервис завершил действие или отказано в параметре ДобавочногоСледствия |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
AddCause | Параметр ДобавочноеСледствие (AddCause) будет выяснять причину в случае отказа сервиса контроля. Диапазон значений следующий: |
AddCause | - превышение лимита времени (time-limit-over); |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.7 Назначение Времени Активизации Действия (TimeActivatedOperate)
А.5.10.7.1 Запрос "Назначение Времени Активизации Действия" (TimeActivatedOperateRequest)
Запрос сервиса "Назначение Времени Активизации Действия" (TimeActivatedOperateRequest) следует описывать следующим образом:
Имена тегов описаны в таблице А.78.
Таблица А.78 - Запрос "Назначение Времени Активизации Действия"
Наименование | Описание |
TimeActivatedOperateRequest | Клиенту следует вызывать сервис Operate, включающий ControlObjectRef валидный для посылаемого Логического Узла (LOGICAL NODE) |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
Т | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
Check | Изменения из одного состояния в следующее состояние в процессе работы будут контролироваться параметром Проверка (Check). Условия проверки могут быть указаны параметром сервиса (например, синхронная проверка). Кроме условия проверки указанного параметром сервиса, объекты контроля могут подвергаться дополнительным проверкам |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.5.10.7.2 Ответ "Назначение Времени Активизации Действия" (TimeActivatedOperateResponse)
Ответ сервиса "Назначение Времени Активизации Действия" (TimeActivatedOperateResponse) описывать следующим образом:
Имена тегов описаны в таблице А.79.
Таблица А.79 - Ответ "Назначение Времени Активизации Действия"
Наименование | Описание |
TimeActivatedOperate Response | Сервер отвечает TimeActivatedOperate, когда сервис завершил действие или отказано в параметре ДобавочногоСледствия |
ControlObjectRef | Параметр ControlObjectRef содержит ОбъектнуюСсылку на контролируемые доступные Данные |
Value | По запросу клиента параметры Values должны содержать особые значения сервиса |
T | Параметр Т содержит время, в которое сервис был запрошен |
Test | Параметр Test показывает со значением TRUE, что значения в сообщении не будут использованы в целях работы |
AddCause | Параметр ДобавочноеСледствие (AddCause) будет выяснять причину в случае отказа сервиса контроля. Диапазон значений следующий: |
TimeOperRsp | Параметр TimeOperRsp будет указывать детали ответа сервиса TimeActivatedOperate. TimeOperRsp не принадлежит перечисленным типам и может иметь значения активированного таймера I выполненной команды |
UUID | Универсальный уникальный идентификатор (UUID) используется как уникальный сервис идентификации для отношений запрос/ответ. Подробнее о UUID - см. [21]. Сервер должен отразить значение UUID, полученное в сообщении запроса, и вернуть то же значение в ответном сообщении |
AssocID | AssocID для определения общего идентификатора - специального клиента. AssocID будет использоваться для идентификации, например присвоенных подписей и входов на сервер |
А.6 Детализация стека протоколов
Для соответствия с отображением следует использовать приведенную в таблице А.80 систему выбора стека протоколов.
Протоколы TCP следует принимать основным уровнем транспортного протокола и IP следует принимать основным уровнем сетевого протокола для отображение Веб-сервисам. Спецификации для уровня передачи данных и физического уровня являются отдельно осуществляемыми и в пределах объема группы стандартов ГОСТ Р 54418.25
Таблица А.80 - Выбор стека протоколов
Уровень модели связи открытых систем (OSI model) | Спецификация | М/О | ||
Название | Спецификация сервиса | Спецификация протокола | ||
Приложение | Web Services | [3] | М | |
SOAP | [8] | М | ||
HTTP ver 1.1 | [18], [19] | М | ||
SSL/TLS ver. 1.0 | [20] | O | ||
Представление | - | - | ||
Сеанс работы | - | - | ||
Передача | Transmission Contol Protocol (TCP) | [12] | М | |
Сеть | Internet Protocol IPver. 4 (ICMPv4) or IP ver.6(ICMPv6) | [10], [11] | М | |
An Ethernet Address Resolution Protocol (ARP) | [13] | М | ||
Broadcasting Internet Datagrams | [15] | М | ||
[16] | ||||
[14] | ||||
Host Extensions for I P Multicasting | [17] | М | ||
Уровень передачи данных | Осуществление специально и в пределах группы | - | - | |
Физический уровень | Осуществление специально и в пределах группы | - | - | |
А.7 Спецификация Языка Описания Веб-Сервисам (WSDL) для определения и отображения веб сервисам*
_______________________
* Текст документа соответствует оригиналу. - .
Спецификацию WSDL для отображения веб-сервисам следует оформлять, как приведено в следующем тексте. Для описания WSDL используется буквенный/переносный стиль.
Все URL ссылки в представленном WSDL файле имеют целью создание связей с областью имен, применяемой в сервисах.
Файл WSDL - это входной файл для кодирования созидательных инструментов для набора инструментов Веб-сервисов, которые создают код, который может быть использован программистом в сумме с библиотеками набора инструментов для осуществления различных сообщений.
Текст WSDL файла, представленный в этой главе, включает все структуры и отображения. Часть структуры, которая не передается через провод в связи клиент-сервер, отмечена комментариями в WSDL файле, предложенном ниже.
Приложение Б
(обязательное)
Определенная коммуникационная сервисная картография - Картография к OPC XML-DA
Б.1 Общая информация
Б.1.1 Ведение в отображение к OPC XML-DA
Настоящее приложение описывает отображение служб из ГОСТ Р 54418.25.3 к службам OPC XML-DA. Это отображение основано на следующих двух принципах:
- информационная модель, определенная в ГОСТ Р 54418.25.2, должна быть доступной к использованию службы OPC XML-DA;
- сервис OPC XML-DA должен следовать за правилами, определенными в OPC XML-DA 1.01 спецификации.
Данное приложение включает в себя следующие разделы:
- Б.1: предоставляет общее введение отображения OPC XML-DA;
- Б.2: предоставляет список нормативных ссылок для отображения к OPC XML-DA;
- Б.3: предоставляет список сокращенных терминов, использованных в приложении Б;
- Б.4: предоставляет отображение ГОСТ Р 54418.25.2 в информационной модели к OPC XML-DA;
- Б.5: предоставляет отображение ГОСТ Р 54418.25.3 информационных моделей обмена к OPC XML-DA;
- Б.6: предоставляет детали комплекта стека протокола.
Б.1.2 Область отображения к OPC XML-DA
Область отображения к сервису OPC XML-DA является обменом информацией процесса, запрошенной в эксплуатационных целях. Количество информации, предоставленной сервером, может измениться в зависимости от эксплуатационных потребностей. Исполнители могут быть местными, региональными или общенациональными узлами управления, которые получают информацию для мониторинга и контроля (управления) процесса.
Б.1.3 Строение отображения
Строение отображения состоит из двух частей:
1) отображение информационной модели;
2) отображение службы обмена информацией.
Информационная модель ВЭС, определенная в ГОСТ Р 54418.25.2, должна быть отображена в иерархической структуре.
Концептуальное отображение изображено на рисунке Б.1. Информационная модель ВЭС в ГОСТ Р 54418.25.2 предназначена для того, чтобы быть представленной в сервисе OPC XML-DA. Это означает:
- сервис реализует иерархическую информационную модель ВЭС ГОСТ Р 54418.25.2, которая может быть восстановлена службами согласно таблице Б.1;
- клиентская реализация информационной модели конфигураций ВЭС или возможность восстановить ее, используя службы самоописания;
- клиент приложения получает доступ к иерархической информационной модели ВЭС ГОСТ Р 54418.25.2 через сервисы, данные в OPC XML-DA, отображения изменения данных в информационной модели.
Рисунок Б.1 - Отображение (концептуальное) архитектуры
Службы обмена информацией ВЭС, определенные в ГОСТ Р 54418.25.3 IEM, должны быть отображены в сервисах согласно таблице Б.1. Графа М/О указывает, определено ли обслуживание в ГОСТ Р 54418.25.3 как принудительное или дополнительное. "Y" значит "Да", обслуживание поддержано, соответственно "N" значит "Нет", обслуживание не поддерживается.
Таблица Б.1 - Отображение IEM сервиса ГОСТ Р 54418.25.2 в OPC XML-DA сервисах
ГОСТ Р 54418.25.2 IM Classes | ГОСТ P 54418.25.2 IEM Services | M/O | Ото- | OPC XML-DA services |
ASSOCIATION | ||||
Associate | M | Y | - | |
Release | O | Y | - | |
Abort | O | N | - | |
SERVER | ||||
GetServerDirectory | O | Y | Browse | |
LOGICAL-DEVICE | ||||
GetLogicalDeviceDirectory | O | Y | Browse | |
LOGICAL-NODE | ||||
GetLogicalNodeDirectory | O | Y | Browse | |
DATA | ||||
GetDataValues | M | Y | Read | |
SetDataValues | M | Y | Write | |
GetDataDirectory | O | Y | Browse | |
GetDataDefinition | O | Y | Browse | |
DATA-SET | ||||
GetDataSetValues | M | P | (see Note) | |
SetDataSetValues | O | N | ||
CreateDataSet | O | N | ||
DeleteDataSet | O | N | ||
GetDataSetDirectory | O | N | ||
REPORTING | ||||
Report | O | Y | SubscriptionPolledRefresh | |
AddSubscription | O | Y | Subscribe | |
RemoveSubscription | O | Y | SubscriptionCancel | |
URCB | ||||
GetURCBValues | O | N | ||
SetURCBValues | O | N | ||
BRCB | ||||
GetBRCBValues | O | N | ||
SetBRCBValues | O | N | ||
LCB | ||||
GetLCBValues | O | N | ||
SetLCBValues | O | N | ||
LOG | ||||
GetLogStatusValues | O | N | ||
QueryLogByTime | O | N | ||
QueryLogAfter | O | N | ||
CONTROL | ||||
Select | O | Y | Write | |
SelectWithValue | O | Y | Write | |
Cancel | O | Y | Write | |
Operate | M | Y | Write | |
CommandTermination | O | Y | Read/Subscribe, SubscriptionPolledRefresh, SubscriptionCancel | |
TimeActivatedOperate | O | Y | Write, Read /Subscribe, SubscriptionPolledRefresh, SubscriptionCancel | |
Примечание - "P" средние величины, которые частично поддерживают сервис. Понятие DATA SET не существует на стороне сервера, но отображение включает в себя информативное описание того, как клиент мог использовать услуги DataSet IEM управлять DATA SET, используя OPC XML-DA сервисы. |
Б.2 Ссылки, определенные для OPC XML-DA отображения
OPC XML-DA Спецификация. Version1.01, 18 декабря 2004
Кроме того, необходимо использовать [8], [10]-[13], [18], [20].
Б.3 Сокращения
Сокращения приведены в разделе 4 настоящего стандарта.
Примечание - В настоящем приложении вместо термина ACSI применен термин IEM.
Б.4 Отображение Информационной Модели ГОСТ Р 54418.25 к OPC XML-DA
Б.4.1 Отображение классов Информационной Модели ГОСТ Р 54418.25.2 к OPC XML-DA
Соотношение между классами IM и понятиями, используемыми в OPC XML-DA, описано в таблице Б.2.
Таблица Б.2 - Отображение класса IM ГОСТ Р 54418.25.2 к OPC XML-DA
ГОСТ Р 54418.25.2 IM Класс | OPC XML-DA понятие | OPC XML-DA related сервис |
Server | Web Service | Browse |
Logical Device Logical Node Data | Branch | Browse |
DataAttribute (Composite) | ||
DataAttribute (Primitive) | Item | Browse Read Write Subscribe SubscriptionPolledRefresh SubscriptionCancel |
Примечание - Понятия Branch и Item - не доступные объекты. Они используются различными OPC XML-DA веб-методами. |
Б.4.2 Сервер
В серии стандартов ГОСТ Р 54418.25 сервер представлен OPC XML-DA веб-сервером.
OPC XML-DA веб-служба является каждой из веб-служб, несущих нагрузку в веб-сервере согласно правилам, определенным в OPC XML-DA спецификации. Каждой веб-службе присваивают коммуникационный адрес, ее сервисная точка доступа, через которую может быть изменен OPC XML-DA сервис. Формат адресного URL такой как:
- http://machineName/virtualDirectory/serviceName.asmx;
- https://machineName/virtualDirectory/serviceName.asmx.
Сервер IEM, покрываемый за счет веб-сервера, который содержит OPC XML-DA сервисы. Признаки класса сервера нанесены на отображение как данные в таблице Б.3.
Таблица Б.3 - Признаки класса Сервера
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарий |
ServiceAccessPoint [1..n] | URL OPC XML-DA веб-служба | |
LogicalDevice [1..n] | Child/Branch | |
TPAppAssociation [0..n] | - | HTTP-сессия |
Примечание - ГОСТ Р МЭК 61850-7-2 определяет Файлы и MCAppAssociations как атрибуты класса Сервера. Файлы и MCAppAssociations не являются частью информационной модели ГОСТ Р 54418.25.2. |
Б.4.3 Логическое устройство
Логические устройства отображены ветвями в иерархии ОРС. Для каждого логического устройства в иерархии ОРС должно быть отделение. Ответвление отделения должно иметь LDName логического устройства. Логические признаки класса устройства нанесены в отображение как данные в таблице Б.4.
Таблица Б.4 - Логические признаки Класса Устройства
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарий |
LDName | Name | |
LDRef | ItemName | |
LogicalNode [3..n] | Branch | По крайней мере LLN0, LPHD и еще один LN должны присутствовать |
Б.4.4 Логический Узел
Логические узлы должны быть отображены ветвями в иерархии ОРС. Для каждого логического узла в иерархии ОРС должно быть отделение. Ответвление отделения должно иметь LNName логического узла. У ItemName отделения должен быть формат: LDName/LNName.
Логические признаки класса узла отображены данными в таблице Б.5
Таблица Б.5 - Логические признаки Класса Узла
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии |
LNName | Name | |
LNRef | ItemName | |
Data [1..n] | Branch | |
DataSet [0..n] | Not mapped | |
BufferedReportControlBlock [0..n] | Not mapped | |
UnbufferedReportControlBlock [0..n] | Not mapped | |
LogControlBlock [0..n] | Not mapped | |
Log [0..n] | Not mapped |
Б.4.5 Данные
Каждые данные должны быть представлены ветвями в иерархии ОРС. Признаки класса данных должны быть отображены данными в таблице Б.6.
Таблица Б.6 - Атрибуты Класса Данных
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии | |
DATName | Name | ||
DATRef | Item Name | ||
Presence | Not mapped | ||
DataAttribute [0..n] | |||
DataAttributeTipe | Item or Branch | ||
FunctionalConstraint | ItemPath/ custom Item property | ||
TrgOp | Not mapped | ||
Specialisations of DAType | |||
CompositeComponent [0..n] of DAType | Branch | ||
PrimitiveComponent [0..1] of BasicType | Item | Должно быть отображено в BasicType |
Б.4.6 Тип Атрибута Данных (DataAttributeType)
Б.4.6.1 Общие положения
Любой тип признака данных должен быть отображен ветвью (Соединение Атрибутов Данных(DataAttributes)) или элементами (Примитивные Атрибуты Данных (DataAttributes)) в OPC XML-DA структуре. Должно быть одно ответвление для каждого Составного Элемента (CompositeComponent) и один пункт для каждого Примитивного Элемента (PrimitiveComponent). Пункты Примитивного Элемента (PrimitiveComponent) формируют станицы в OPC XML-DA структуре. Признаки Типа Атрибута Данных (DAType) показаны в таблице Б.7.
Таблица Б.7 - Тип Атрибута Данных (DAType) признаки Класса
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии |
DATName | Name | |
DATRef | Item Name | |
Presence | Not mapped | |
Specialisations of DAType | ||
CompositeComponent [0..n] of DAType | Branch | |
PrimitiveComponent [0..1] of BasicType | Item | Должно быть отображено в BasicType |
Б.4.6.2 Отображение атрибутов БазовыхТипов (BasicTypes)
Базовые Типы (BasicTypes) представлены в таблице Б.8.
Таблица Б.8 - Отображение атрибута BasicType
ГОСТ Р 54418.25.2 BasicType | OPC XML-DA тип | Диапазон значений | Комментарии |
BOOLEAN | boolean | Binary logic value, true | false | |
INT8 | byte | 8-bit signed integer value: -128 to 127 | |
INT16 | short | 16-bit signed integer value: -32768 to 32767 | |
INT24 | int | 32-bit signed integer value: -2**31 to (2**31)-1 | Расширяет диапазон значений |
INT32 | int | 32-bit signed integer value: -2**31 to (2**31)-1 | |
INT128 | long | 64-bit signed integer value: -2**63 to (2**63)-1 | Уменьшает диапазон значений |
INT8U | unsignedByte | 8-bit unsigned integer value: 0 to 255 | |
INT16U | unsignedShort | 16-bit unsigned integer value: 0 to 65535 | |
INT24U | unsignedlnt | 32-bit unsigned integer value: 0 to 4294967295 | Расширяет диапазон значений |
INT32U | unsignedlnt | 32-bit unsigned integer value: 0 to 4294967295 | |
FLOAT32 | float | IEEE single-precision 32-bit floating point value | |
FLOAT64 | double | IEEE single-precision 64-bit floating point value | |
ENUMERATED | unsignedlnt | Ordered set of values, defined where type is used; custom extensions are allowed | |
CODED ENUM | unsignedlnt | Ordered set of values, defined where type is used; custom extensions shall not be allowed | |
VISIBLE STRING | string | Unicode character string (instead of ASCII string) | Кусок указан в определении CDC |
UNICODE STRING | string | Unicode character string | Кусок указан в определении CDC |
Б.4.6.3 Дополнительное определение общих типов данных
Б.4.6.3.1 Закодированное перечисление (Coded enum)
Coded enum должен быть преобразован bunsignedlnt. Бит 0 из Coded Enum должен быть самым значащим битом в unsignedlnt.
Значение=бит [0]2+бит [1] 2+... + бит [N] 2+, где N - число битов в закодированном enum.
Б. 4.6.3.2 Строка Октета (OctetString)
OctetString МЭК должна быть отображена в OPC XML-DA шестнадцатеричной последовательностью. Только символы от 0 до 9, от "a" до "f" и от "A" до "F" могут использоваться.
Б.4.6.4 Массив
"Массивы XXX" ГОСТ Р 54418.25.2 должны быть отображены в OPC XML-DA "ArrayOfXXX", где XXX описано, где тип используется.
Б.4.6.5 Общие типы данных (Common Data Types)
Б.4.6.5.1 Имя Объекта (ObjectName)
ObjectName IEM (VisibleString32) атрибут должен отобразить атрибут "Имя (Name)" (последовательности) внутри OPC XML-DA сервисов.
Б.4.6.5.2 Указатель объектa (ObjectReference)
ObjectReference IEM (VisibleString255) атрибут должен отобразить атрибут "ИмяЭлемента (ItemName)" (последовательности) внутри OPC XML-DA сервисов.
Б.4.6.5.3 Ошибка сервиса (ServiceError)
ServiceError IEM (Пронумерованная (Enumerated)) должна отображаться в OPC XML-DA текстовым (последовательности) элементом элемента OPCError. Список стандартных OPC XML-DA кодов ошибок был расширен со следующими данными в таблице Б.9.
Таблица Б.9 - Новые OPC XML-DA Коды ошибки
Новые OPC XML-DA Коды ошибки |
E_61400_25_INSTANCE_NOT_AVAILABLE |
E_61400_25_INSTANCE_IN_USE |
E_61400_25_ACCESS_VIOLATION |
E_61400_25_ACCESS_NOT_ALLOWED_IN_CURRENT_STATE |
E_61400_25_PARAMETER_VALUE_INAPPROPRIATE |
E_61400_25_PARAMETER_VALUE_INCONSISTENT |
E_61400_25_CLASS_NOT_SUPPORTED |
E_61400_25_INSTANCE_LOCKED_BY_OTHER_CLIENT |
E_61400_25_CONTROL_MUST_BE_SELECTED |
E_61400_25_TYPE_CONFLICT |
E_FAILED_DUE_TO_COMMUNICATIONS_CONSTRAINT |
E_FAILED_DUE_TO_SERVER_CONSTRAINT |
Б.4.6.5.4 Отметка Времени (TimeStamp)
Преобразование данных к OPC XML-DA dateTime типу.
В этом преобразовании не используется характеристика OPC XML-DATimestamp. Причина состоит в том, что TimeStamp информационной модели отражает прошлый момент, когда значение изменилось, в то время как OPC XML-DA Timestamp отражает время, которое сервер знал, и что соответствующее значение было точно.
Таблица Б.9.1 показывает различия в значениях ОРС Timestamp характеристики и Элемента, который отражает Информационную Модель TimeStamp.
Таблица Б.9.1 - Различия между OPC XML-DA и Информационной Моделью МЭК timestamp
Время | Field Value | |
9:59:55 | 0 | |
10:00:00 | 1 | |
10:00:05 | 1 | |
10:00:10 | 1 | |
10:00:15 | 1 | Клиент ОРС Read (10:00:15,1) |
Клиент МЭК Read (10:00:00,1) |
Отображение Timestamp подробно описано в таблице Б.10.
Таблица Б.10 - Отображение Timestamp
IM TimeStamp атрибуты | ОтображениеОРС | Ограничения | |
SecondSinceEpoch | OPC XML-DA dateTime | ||
FractionOfSecond | |||
TimeQuality | LeapSecondsKnown | He нанесенный на карту | |
ClockFailure | Качественная характеристика элемента TimeStamp | "Плохо" | |
ClockNotSynchronized | Качественная характеристика элемента TimeStamp | "Сомнительно" | |
TimeAccuracy | Не отображенный | Закрепленный к n=10. |
Б.4.6.5.5 Качество (Quality)
Информационная модель, определенная в ГОСТ Р 54418.25.2, определяет существование качественного атрибута, который отнесен к значению в некотором состоянии или к атрибутам измерения.
Значения, которые может содержать качественный признак IEM Quality, очень отличаются от тех, которые в OPC XML-DA качественной характеристике. В этом отображениии не используется OPC XML-DA качественная характеристика. IEM Quality будет элементом в OPC XML-DA структуре.
Качественные атрибуты внутри информационной модели необходимо рассматривать как CODED ENUM, сформированный 13 битами, и отображен в OPC XML-DA unsignedint, как дано в таблице Б.11. Качественное значение должно быть вычислено, как показано в Б.4.6.3.1.
Таблица Б.11 - Отображение Атрибута качества (Quality attribute)
Бит(ы) | Attribute Name | Attribute Value | Комментарии |
0 to 1 | validity | good | Value = 0 0 |
invalid | Value = 0 1 | ||
reserved | Value = 1 0 | ||
questionable | Value = 1 1 | ||
2 | overflow | ||
3 | outOfRange | ||
4 | badReference | ||
5 | oscillatory | ||
6 | failure | ||
7 | oldData | ||
8 | inconsistent | ||
9 | inaccurate | ||
10 | source | ||
11 | test | ||
12 | operatorBlocked |
Б.4.6.6 Определение пользовательских характеристик элемента
Сервисы GetDataDirectory и GetDataDefinition требуют в пределах их информации об ответах, которая не может быть предоставлена отображенным элементам. Чтобы предоставить эту информацию, следующие пользовательские характеристики элемента должны быть добавлены.
Б.4.6.6.1 Пользовательская характеристика элемента "FC"
Должна быть добавлена пользовательская характеристика элемента "FC". Эта пользовательская характеристика элемента, присвоенная каждым Data, DataAttribute и DataAttributeComponent, идентифицирует, какие FCs используются в соответствующем элементе. Они представлены, чтобы обеспечить FC ответ в пределах сервиса GetDataDirectory. Они также представлены для использования клиентом, чтобы привести номер Просматриваемых (Browse) сервисов, которые необходимы, чтобы получить полный список элементов, которые составляют FCD или FCDA.
Присутствие этой характеристики элемента обязательно, но ее использование OPC XML-DA клиентом является не обязательным.
Таблица Б.11.1 - Пользовательская характеристика элемента "FC"
ItemName | DataRef.FC/DATRef.FC |
ItemPath | " " (empty string) |
Type | CODEDENUM |
Б.4.6.6.2 Пользовательская характеристика элемента "IMCIass"
Должна быть добавлена пользовательская характеристика элемента "IMCIass". Эта пользовательская характеристика элемента, присвоенная каждому элементу, содержит информацию о классе элемента. Она представлена, чтобы обеспечить ответ в пределах сервиса GetDataDirectory с информацией являются ли возвращенные элементы Data или DataAttribute.
Присутствие этой характеристики элемента обязательно, но ее использование OPC XML-DA клиентом является опциональным.
Таблица Б.11.2 - Пользовательская характеристика элемента "IMCIass"
ItemName | Ref. IMCIass |
ItemPath | " " (empty string) |
Type | ENUMERATED LD (Logical Device) (1) | |
Б.4.6.6.3 Пользовательская характеристика элемента "IMType"
Должна быть добавлена пользовательская характеристика элемента "IMType". Эта пользовательская характеристика элемента, присвоенная каждому элементу, содержит тип атрибута элемента. Она представлена, чтобы обеспечить ответ в пределах сервиса GetDataDirectory.
Присутствие этой характеристики элемента обязательно, но ее использование OPC XML-DA клиентом является опциональным.
Таблица Б.11.3 - Пользовательская характеристика элемента "IMType"
ItemName | Ref. IMType | |
ItemPath | " " (empty string) | |
Type | UNICODE STRING | |
for a LD: | WPP | |
for a LN: | WROT | WMET | WGWN | | |
for a DO: | INS | INC | ALM | | |
for a CDA: | AnalogueValue | Vector | .... | |
for a PDA: | BOOLEAN | INT16 | |
Б.5 Отображение Информационной Модели Обмена для сервиса OPC XML-DA
Б.5.1 Общие положения
В определении отображения сервисов IEM применяются следующие определения:
M: Mandatory (Обязательный). Этот атрибут/элемент требуется или OPC XML-DA или отображаемой спецификацией.
C: Conditional (Условный). Этот атрибут/элемент условный к другому атрибуту или приему параметра в запросе.
O: Optional (Необязательный). Может быть включен, но это не обязательно, таким образом не может ожидаться ни на какой реализации.
N: Not used (Неиспользуемый). Этот атрибут/элемент не должен быть включен в отображение.
Сервисы обмена информации ВЭС, определенные в ГОСТ Р 54418.25.3 IEM, должны отображаться сервисами, определенными в этом разделе.
Б.5.2 Модель Ассоциации (информативная)
Б.5.2.1 Общие положения
Веб-службы построены как connectionless сервисы (без организации соединения), чтобы улучшить масштабируемость по ориентируемым на связь сервисам. Connectionless сервис может вести себя как подключенный сервис, представленный как структурированный сервис.
Раздел Б.5 описывает метод использования заголовка HTTP в порядке для передачи информации, чтобы разделить идентификатор связи во время обмена различных сервисов OPC XML-DA. Отображение не обязывает это условие быть принятым, но рекомендует, чтобы, если эта информация предоставлена сервером, описанный метод использовался.
Класс "две партийные прикладные ассоциации" и ее сервисы, как определено в ГОСТ Р 54418.25.2 и ГОСТ Р 54418.25.3, определяют понятие stateful (структурированность) связи. В отличие от этого OPC XML-DA основано на SOAP и протоколе, не использующем информацию о состоянии HTTP, т.е. сервер рассматривает каждый запрос как независимую операцию, не связанную с любым предыдущим запросом. Отображение требует, чтобы запросы были связаны, устанавливая действительную сессию в пределах прикладного уровня.
Действительная сессия должна быть установлена при использовании ID сессии, которая создана сервером и отправлена, по крайней мере, с каждым запросом. Требуется, чтобы ID сессии было единственным в пределах сервера (т.е. "один к одной связи" между клиентом и ID сессии), и в пределах клиента, (т.е. "один к одной связи" между сервером, представленным его URL и ID сессии). Отображение не предписывает, как обмен ID сессии должен быть осуществлен (например, через rerb HTML или как часть URL).
Требуется, чтобы сервер содержал таймер для каждого ID сессии. Таймер должен быть установлен снова с каждым запросом связанного клиента. Если таймер истечет, т.е. не было никакого дальнейшего запроса клиента в пределах определенного времени, то сервер должен считать сессию закрытой и удалить ID сессии.
Это отображение не предписывает, как должно быть осуществлено установление подлинности клиента, но требуется, что клиент не должен подтверждать подлинность себя снова с каждым запросом. Это может быть получено, например, при использовании ID сессии, чтобы идентифицировать требуемого клиента.
Вышеизложенное рекомендуется для шифрования перемещаемых данных (например, при использовании https), особенно данных, которые перемещены в целях опознавания (имя пользователя/пароль).
Б.5.2.2 Ассоциации атрибутов
Б.5.2.2.1 AssocitationID*
_____________________
* Текст локумента соответствует оригиналу. - .
Формат AssociationID и содержание должны быть местным формированием. На стороне сервера должна быть непосредственная соответственность между AssociationID, связью между клиентом и веб-сервером. На стороне клиента объединение AssociationID и URL сервера должно быть единственным.
Б.5.2.3 Ассоциации сервисов
Б.5.2.3.1 Ассоциации
Установление подлинности заголовка HTTP может быть использовано при желании, чтобы подтвердить подлинность клиента. Этот метод может использоваться только в том случае, если и сервер, и клиент поддерживают опознавание. Все аспекты безопасности - вне области настоящего стандарта.
Ассоциация сервиса не должна отображаться к любому заданному сервису OPC XML-DA. Каждый раз, когда клиент посылает сервису OPC XML-DA запрос без associationID в заголовке HTTP, сервер должен считать это новой ассоциацией, и ответ сервису должен включать в себя идентификатор той ассоциации.
Используемый заголовок HTTP должен следовать за синтаксисом:
Set-cookie: AssociationID=AssocValue; expires=date; path=/SERVICE1; domain=url.
Параметры, посланные в Cookie, описаны в таблице Б.12.
Таблица Б.12 - Пояснение параметра
Параметр | Пояснение |
AssociationID | Идентификатор ассоциации. Сервер должен послать различные идентификаторы за всеми связями, которые он держит. |
Expires | Этот параметр - максимальное Время Существования связи. Формат: Wdy, dd-mmm-yyyy hh:mm:ss по Гринвичу |
Path | Сервисы, которые нуждаются в ассоциации. |
Domain | URL сервера. |
Если associationID будет необходим больше чем в одном сервисе OPC XML-DA, то сервер должен включать в себя различные cookie, каждый из которых связан с одним сервисом OPC XML-DA.
Как только клиент получает эту информацию, идентификатор ассоциации должен быть направлен во все запросы, посланные на сервер: Cookie: AssociationID = AssocValue.
На приеме этого основания сервер мог бы послать тот же самый associationID с новым сроком годности, чтобы сохранять связь открытой дольше, чем предыдущий TTL.
Сервер должен держать таймер так, чтобы если нет сообщения, полученного с одним из AssociationlDs, которые рассматривают как активное, ассоциацию нужно считать утраченной. На приеме сообщения с AssociationID, которое не действительно на стороне сервера, нужно предоставить новое AssociationID так, чтобы была создана новая связь.
Последовательность сервисов обычно устанавливает ассоциацию, как показано на рисунке Б.2.
Рисунок Б.2 - Последовательность сервисов, устанавливающих ассоциацию
Б.5.2.3.2 Сопровождение
Сервисы сопровождения не должны отображаться любому определенному сервису OPC XML-DA. Клиент, который желает закрыть ассоциацию, должен прекратить использовать cookie AssociationID в его сообщениях. Как только набор таймера в сервере истекает, связь нужно считать разомкнутой.
Б.5.2.3.3 Аварийное прекращение работы (информативное)
Общие положения
Б.5.2.3.3 описывает, как механизм аварийного прекращения работы может быть осуществлен в пределах последовательностей OPC XML-DA сообщений.
Сторона Клиента
Запрос аварийного прекращения работы стирает cookie с AssociationID так, чтобы ассоциацию считали законченной.
Показание Аварийного прекращения работы должно быть отправлено при включении каждый раз в ответ серверу с различным AssociationID к данному в запросе. В этом случае показание Аварийного прекращения работы сопровождается показанием Ассоциации и подтверждением обслуживания ОРС, которое необходимо.
Сторона Сервера
Запрос аварийного прекращения работы стирает AssociationID, чтобы ассоциацию рассмотрели.
Показание Аварийного прекращения работы нужно послать при включении каждый раз, когда ассоциацию считают утраченной. Ассоциацию считают утраченной, если не было активности в течение предварительно сконфигурированного времени в сервере.
Б.5.3 Модель класса Сервера
Б.5.3.1 Сервисы класса Сервера
Б.5.3.1.1 GetServerDirectory
Этот сервис позволяет клиенту восстанавливать список Логических Устройств, которые держит сервер. Этот сервис должен отображать Browse OPC XML-DA. Параметры Browse сервиса должны быть представлены, как в таблицах Б.13 и Б.14.
Таблица Б.13
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарий |
Request | Browse | "LogicalDevice" |
Response + | BrowseResponse (+) | LDRef |
Response - | BrowseResponse (-) |
Таблица Б.14 - IEM отображение GetServerDirectory детализированное
Параметры GetServerDirectory | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Browse | |||
E | PropertyNames | N | ||
@ | LocalelD | O | ||
@ | ClientRequestHandle | O | ||
@ | ItemPath | N или " " | Оба без вести пропавшие или оба пустеют | |
@ | ItemName | N или " " | Оба без вести пропавшие или оба пустеют | |
@ | ContinuationPoint | O | См. примечание 1 | |
@ | MaxElementsReturned | O | См. примечание 1 | |
@ | BrowseFilter | N | ||
@ | ElementNameFilter | N | ||
@ | VendorFilter | N | ||
@ | ReturnAIIProperties | N | ||
@ | ReturnPropertyValues | N | ||
@ | ReturnErrorText | O | ||
Response + | BrowseResponse | |||
E | BrowseResult | M | ||
E | Elements | M | Будет существовать так много "Элементов", сколько Логических Устройств в Сервере | |
E | Properties | C | Не должен прибыть в запрос | |
Reference | @ | Name | M | |
@ | ItemPath | M | ||
Reference | @ | ItemName | M | |
@ | Isltem | M | ||
@ | HasChildren | M | Будет "верно" | |
E | Errors | N | Не буду появляться в ответе положительной величины | |
@ | ContinuationPoint | C | ||
@ | MoreElements | C | ||
Response - | BrowseResponse | |||
E | BrowseResult | M | ||
E | Elements | N | В отрицательном ответе не должно быть никакого элемента | |
E | Properties | N | ||
@ | Name | N | ||
@ | ItemPath | N | ||
@ | ItemName | N | ||
@ | Isltem | N | ||
@ | HasChildren | N | ||
ServiceError | Е | PTC Erro | M | См. примечание 2 |
Е | Text | C | ||
@ | ID | M | ||
@ | ContinuationPoint | N | ||
@ | MoreElements | N | ||
Примечания 1 Его использование является дополнительным на стороне клиента. 2 Любой код ошибки, возвращенный в этом обслуживании, должен отобразиться в IEM ServiceError "вышедший из строя из-за сервера". |
Б.5.4 Класс модели логического устройства
Б.5.4.1 Класс сервиса логического устройства
Б.5.4.1.1 GetLogicalDeviceDirectory
Отображение этого сервиса должно быть, как показано в Таблицах Б.15 и Б.16.
Таблица Б.15 - IEM отображение GetLogicalDeviceDirector
ГОСТ Р 54418.25.2 | OPC XML-DA | Комментарий |
Request | Browse | |
Response + | BrowseResponse (+) | |
Response - | BrowseResponse (-) |
Таблица Б.16 - IEM отображение GetLogicalDeviceDirectory детализированное
GetLogicalDevice Directory parameters | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Browse | |||
E | PropertyNames | N | ||
@ | LocalelD | О | ||
@ | ClientRequestHandle | О | ||
@ | ItemPath | M | ||
@ | ItemName | M | Строка должна быть ссылкой LogicalDevice | |
@ | ContinuationPoint | О | ||
@ | MaxElementsReturned | О | ||
@ | BrowseFilter | N | ||
@ | ElementNameFilter | N | ||
@ | VendorFilter | N | ||
@ | ReturnAIIProperties | N | ||
@ | ReturnPropertyValues | N | ||
@ | ReturnErrorText | О | ||
Response + | BrowseResponse | |||
E | BrowseResult | М | ||
E | Elements | М | Так много "Elements" сколько Logical Nodes должно существовать в Logical Device | |
E | Properties | С | Не должен встречаться в запросе | |
@ | Name | М | ||
@ | ItemPath | М | ||
Reference | @ | ItemName | М | |
@ | Is Item | М | ||
@ | HasChildren | М | Должен быть "true" | |
E | Errors | N | Не будут себя проявлять положительно | |
@ | ContinuationPoint | С | ||
@ | MoreElements | С | ||
Response - | BrowseResponse | |||
E | BrowseResult | М | ||
E | Elements | N | Не должно быть элемента с негативным ответом | |
E | Properties | N | ||
@ | Name | N | ||
@ | ItemPath | N | ||
@ | ItemName | N | ||
@ | Isltem | N | ||
@ | HasChildren | N | ||
ServiceError | E | Errors | М | См. таблицу Б.17 |
E | Text | С | ||
@ | ID | М | ||
@ | ContinuationPoint | N | ||
@ | MoreElements | N | ||
Примечание - E: OPC XML-DA service element; @: OPC XML-DA attribute. |
Отображение ServiceError показано в таблице Б.17.
Таблица Б.17 - GetLogicalDeviceDirectory отрицательные ответы отображения ServiceError
IEM ServiceError | OPC Error Code |
Parameter-value-inappropriate | E_INVALIDITEMNAME, E_UNKNOWNITEMNAME |
Failed-due-to-server-constraint | Any other code |
Б.5.5 Логическая модель класса узла
Б.5.5.1 Общие положения
Экземпляр IEM LogicalNode должен быть отделением структуры ОРС.
Б.5.5.2 Логические атрибуты класса узла
Это отображение только поддерживает существование данных в логическом классе узла. Данные должны быть отображены как элементы отделения только ниже логического узла в структуре сервера OPC XML-DA.
Б.5.5.3 Логические сервисы класса узла
Б.5.5.3.1 GetLogicalNodeDirectory
OPC XML-DA отображение позволяет только использование "DATA" lEMCIass. Спецификация любого другого lEMCIass не может быть отображена, используя это отображение.
Если определенные lEMCIass будут DATA, то отображение должно быть, как представлено в таблицах Б.18 и Б.19.
Таблица Б.18 - IEM отображение GetLogicalNodeDirectory
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарий |
Request | Browse | |
Response + | BrowseResponse (+) | |
Response - | BrowseResponse (-) |
Таблица Б.19 - IEM отображение GetLogicalNodeDirectory детализированное
Директивные параметры GetLogicalNode | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Browse | |||
E | PropertyNames | N | ||
@ | LocalelD | O | ||
@ | ClientRequestHandle | O | ||
@ | ItemPath | M | Будет пусто | |
@ | ItemName | M | Последовательность должна быть ссылкой LogicalNode | |
@ | ContinuationPoint | O | ||
@ | MaxElementsReturned | O | ||
@ | BrowseFilter | N | ||
@ | ElementNameFilter | N | ||
@ | VendorFilter | N | ||
@ | ReturnAIIProperties | N | ||
@ | ReturnPropertyValues | N | ||
@ | ReturnErrorText | O | ||
Response + | BrowseResponse | |||
E | BrowseResult | M | ||
E | Элементы | М | Так много "Элементов", сколько Данных должно существовать в Логическом Узле. | |
E | Свойства | N | ||
Ссылка | @ | Имя | M | |
@ | ItemPath | M | ||
@ | ItemName | M | ||
@ | Isltem | M | Будет "верно" | |
@ | HasChildren | M | Будет "верно" | |
Е | Ошибки | N | Не будут появляться в ответе положительной величины | |
@ | ContinuationPoint | C | ||
@ | MoreElements | C | ||
Response - | BrowseResponse | |||
E | BrowseResult | M | ||
E | Элементы | N | В отрицательном ответе не должно быть никакого элемента | |
E | Свойства | N | ||
@ | Имя | N | ||
@ | ItemPath | N | ||
@ | ItemName | N | ||
@ | Isltem | N | ||
@ | HasChildren | N | ||
ServiceError | E | Ошибки | M | См. таблицу Б.20 |
E | Текст | C | ||
@ | УДОСТОВЕРЕНИЕ ЛИЧНОСТИ (ID) | M | ||
@ | ContinuationPoint | N | ||
@ | MoreElements | N | ||
E: OPC XML-DA элемент обслуживания |
Отображение ServiceError показано в таблице Б.20.
Таблица Б.20 - GetLogicalNodeDirectory отображение отрицательных ответов ServiceError IEM
IEM ServiceError | ОРС Error Code |
Parameter-value-inappropriate | E_INVALIDITEMNAME, E_UNKNOWNITEMNAME |
Failed-due-to-server-constraint | Any other code |
Б.5.6 Модель класса данных
Б.5.6.1 Основное положение
Класс Данных IEM должен быть отображен в отделении структуры ОРС. Его элементарный атрибут данных должен быть Items в страницах иерархической структуры OPC XML-DA.
Функциональные ограничения данных.
Функциональные ограничения данных должны отображаться OPC XML-DA ItemName и ItemPath. Формат должен быть представлен как в IEM.
Таблица Б.20.1 - Функциональные ограничения данных
ItemName | LDName/LNName. DataName [.DataName [...]] |
ItemPath | FC |
Функциональные ограничения DataAttribute
Функциональные ограничения DataAttribute должены отображаться OPC XML-DA ItemName и ItemPath. Формат должен быть представлен как в IEM.
Таблица Б.20.2 - Функциональные ограничения DataAttribute
ItemName | LDName/LNName. DataName [.DataName [. ...[DataAttribute[….]]] |
ItemPath | FC |
ItemPath в OPC XML-DA представляется сервером определенного механизма, чтобы помочь серверу считать информацию, требуемую клиентом.
В этом отображении ItemPath определяет функциональное ограничение, которое необходимо клиенту. Это должно использоваться в качестве механизма фильтра. Если будет атрибут, который включает в себя больше чем один функциональный contraint, то ItemPath определит тот, который требуется.
В Browse сервисе, если нет никакого определенного ItemPath, все элементы определенной структуры возвращают уровень. Если клиент определит использование определенного ItemPath, то только элементы, которые включают в себя требуемое функциональное ограничение, должны быть возвращены.
Б.5.6.2 Классы сервисов данных
Б.5.6.2.1 GetDataValues
GetDataValues IEM должен быть отображен OPC XML-DA Read сервисом. Отображение параметров IEM должно быть представлено как в таблицах Б.21 и Б.22.
Таблица Б.21 - IEM отображение GetDataValues
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии |
Request | Read | |
Response + | ReadResponse | |
Response - | BrowseResponse (-) |
Таблица Б.22 - IEM отображение GetDataValues детализированное
Параметры GetDataValues | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Read | |||
E | Варианты | M | ||
@ | ReturnErrorText | O | ||
@ | ReturnDiagnosticlnfo | O | ||
@ | ReturnItemTime | N | ||
@ | ReturnItemPath | C | Или ItemName и ItemPath или ItemHandle должны быть возвращены в ответе | |
@ | ReturnItemName | C | Или ItemName и ItemPath или ItemHandle должны быть возвращены в ответе | |
@ | RequestDeadline | N | ||
@ | ClientRequestHandle | C | Или ItemName и ItemPath или ItemHandle должны быть возвращены в ответе | |
@ | LocalelD | O | ||
Reference | E | ItemList | M | |
@ | ItemPath | N | ||
@ | ReqType | N | ||
@ | MaxAge | N | ||
E | Элементы | M | ||
@ | ItemPath | M | ФК FCD или FCDA | |
@ | ReqType | N | ||
@ | ItemName | M | ObjectReference Данных | |
@ | ClientltemHandle | C | ||
@ | MaxAge | N | ||
Response + | ReadResponse | |||
E | ReadResult | M | ||
E | RltemList | M | ||
DataAttributeValue | E | Items | M | |
E | Diagnostic Info | C | ||
E | Value | M | ||
E | Quality | C | См. пояснение в Б.4.6.5.5 | |
@ | Qualifier ValueType | N | ||
@ | ItemPath | C | Если определено в запросе | |
@ | ItemName | C | Если определено в запросе | |
@ | Clientltem Handle | C | Если определено в запросе | |
@ | TimeStamp | M | См. пояснение в Б.4.6.5.4 | |
@ | ResultID | O | ||
E | Errors | N | Не будут появляться в ответе положительной величины | |
Response - | ReadResponse | |||
E | ReadResult | M | ||
E | RItemList | M | ||
E | Items | M | Элементы, которые могли быть Ридом (Read), должны появиться | |
E | Диагностическая Информация | C | ||
E | Value | M | ||
E | Quality | C | ||
@ | Qualifier ValueType | C | ||
@ | ItemPath | C | Если определено в запросе | |
@ | ItemName | C | Если определено в запросе | |
@ | Handle Clientltem | C | Если определено в запросе | |
@ | TimeStamp | N | См. пояснение в Б.4.6.5.4 | |
@ | ResultID | C | Элементы, процесс которых удалось прочитать, включают это поле | |
ServiceError | E | Errors | M | Будут как определен в Таблице Б.23 |
E | Text | O | ||
@ | ID | M | ||
Примечание - E: OPC XML-DA элемент обслуживания; @: OPC XML-DA признак. |
Или ItemName и ItemPath или ItemHandle должны быть возвращены в ответе.
Если "Ссылка", определенная включением, определит FCDA, который держит basicType внутри, то сервис Read должен включать только один Элемент в запросе. Если "Ссылка" будет FCD или сложным FCDA, то клиент отображенный OPC XML-DA, должен разделить FCD или FCDA на его элементарные признаки, и это должно включать в себя всех их в OPC XML-DA Read сервис. Путь такого разложения выполняет местная задача на стороне клиента.
Уровень отображения на стороне сервера должен отображать ОРС Read сервис для IEM GetDataValues Indication.
Принятие любого отрицательного результата для любого из элементов нужно учитывать как отрицательный ответ сервиса GetDataValues. Отображение ServiceError показано в таблице Б.23.
Таблица Б.23 - GetDataValues отображение отрицательных ответов ServiceError IEM
IEM ServiceError | ОРС Код ошибки |
Access-violation | E_ACCESS_DENIED |
Parameter-value-inappropriate | E_INVALIDITEMNAME |
Parameter-value-inconsistent | E_INVALIDITEMPATH |
Parameter-value-inappropriate | E_UNKNOWNITEMNAME |
Parameter-value-inconsistent | E_UNKNOWNITEMPATH |
Failed-due-to-serve r-constraint | Any other error code |
Б.5.6.2.2 SetDataValues
SetDataValues IEM должен быть отображен в OPC XML-DA Read сервисе. Отображение параметров IEM должно быть представлено как в таблицах Б.24 и Б.25.
Таблица Б.24 - IEM отображение SetDataValues
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии |
Request | Write | |
Response + | ||
Response - | BrowseResponse (-) |
Таблица Б.25 - Детализированная IEM картография SetDataValues
Параметры SetDataValues | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Write | |||
E | Options | M | ||
@ | ReturnErrorText | O | ||
@ | ReturnDiagnosticlnfo | N | ||
@ | ReturnItemTime | N | ||
@ | ReturnItemPath | M | Значение должно быть "верным" | |
@ | ReturnItemName | M | Значение должно быть "верным" | |
@ | RequestDeadline | N | ||
@ | ClientRequestHandle | O | ||
E | ItemList | |||
E | Items | M | ||
E | Diagnostic Info | N | ||
DataAttributeValue | E | Value | M | |
E | Quality | N | ||
@ | ValueType Qualifier | N | ||
Reference | @ | ItemPath | M | ФК FCD или FCDA |
Reference | @ | ItemName | M | ObjectReference Данных |
@ | Clientltem Handle | O | ||
@ | TimeStamp | O | ||
@ | ResultID | O | ||
@ | ReturnValuesOnReply | M | ||
Response + | WriteResponse | |||
E | WriteResult | M | ||
E | RltemList | M | ||
E | Items | M | Элементы, которые могли быть написаны, должны появиться | |
E | Diagnostic Info | C | ||
E | Value | C | ||
E | Quality | C | ||
@ | ValueType Qualifier | N | ||
@ | ItemPath | C | ||
@ | ItemName | C | ||
@ | Clientltem Handle | C | ||
@ | TimeStamp | M | ||
@ | ResultID | O | ||
E | Errors | N | Не будут появляться в ответе положительной величины | |
Response - | WriteResponse | |||
E | WriteResult | M | ||
E | RltemList | O | ||
E | Items | O | ||
E | Diagnostic Info | C | ||
E | Value | C | ||
E | Quality | C | ||
@ | Qualifier ValueType | C | ||
@ | ItemPath | C | ||
@ | ItemName | C | ||
@ | Clientltem Handly | C | ||
@ | TimeStamp | C | ||
@ | ResultID | M | ||
ServiceError | E | Errors | M | Будут как определен в таблице Б.26 |
E | Text | C | ||
@ | ID | M |
Если "Reference (Ссылка)", определенная включением, определит FCDA, который держит basicType внутри, то Write сервис должен включать в себя только один Элемент в запрос. Если "Reference" будет FCD или сложным FCDA, то клиент, отображающий OPC XML-DA, должен разделить FCD или FCDA на его элементарные атрибуты, и это должно включать в себя всех их в ОРС ХМL-DA Write сервис. Путь такого разложения выполняет местная задача на стороне клиента.
Уровень отображения на стороне сервера должен отображать ОРС Write сервис IEM SetDataValues Indication. Write сервис должен быть выполнен как уникальный сервис, т.е. для значения каждого элемента или ни для одного из них. В WriteResponse будут или ResultID для каждого элемента или ни для одного из них.
В отрицательном ответе ServiceError IEM должен отобразить Код ошибки ОРС всех элементов, которые это требуют. Отображение ServiceError представлено в таблице Б.26.
Таблица Б.26 - SetDataValues отображение отрицательных ответов ServiceError IEM
IEM ServiceError | ОРС Код ошибки |
Access-violation | E_ACCESS_DENIED |
Access-violation | E_READONLY |
Parameter-value-inappropriate | E_INVALIDITEMNAME |
Parameter-value-inconsistent | E_INVALIDITEMPATH |
Parameter-value-inappropriate | E_UNKNOWNITEMNAME |
Parameter-value-inconsistent | E_UNKNOWNITEMPATH |
Type-conflict | E_BADTYPE |
Failed-due-to-serve r-constraint | Any other error code |
Б.5.6.2.3 GetDataDirectory
GetDataDirectory IEM должен отображаться OPC XML-DA Browse сервисом. Если ряд элементов превышает максимальное количество ссылок, определенных клиентом в запросе, то последовательность ссылок Browse сервисов должна быть задана.
Текущий или последний методы зависят от числа возвращенных ссылок и пределов, наложенных клиентом в атрибуте MaxElementsReturned Browse сервера, или пределах сервера: "MaxltemsReturned".
Элементами, которые возвращены в пределах ответа, могут быть или Data, или DataAttributes. OPC XML-DA клиент может просить найти значения пользовательских свойств элемента IMCIass, являются ли они возвращенными элементами Data или DataAttribute. Пользовательские свойства элемента IMCIass представлены в Б.4.6.6.2.
Отображение сервиса GetDataDirectory показано в таблицах Б.27 и Б.28.
Таблица Б.27 - IEM отображение GetDataDirectory
ГОСТ Р 54418.25.2 (ссылающийся на ГОСТ Р МЭК 61850-7-2) | OPC XML-DA | Комментарии |
Request | Browse | |
Response + | BrowseResponse (+) | |
Response - | BrowseResponse (-) |
Таблица Б.28 - Детализированное IEM отображение GetDataDirectory
Параметры GetDataDirectory | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Browse | |||
E | PropertyNames | O | IMCIass | |
@ | LocalelD | O | ||
@ | ClientRequestHandle | O | ||
@ | ItemPath | M | ||
@ | ItemName | M | Последовательность должна быть ссылкой Данных | |
@ | ContinuationPoint | O | ||
@ | MaxElementsReturned | O | ||
@ | BrowseFilter | N | ||
@ | ElementNameFilter | N | ||
@ | VendorFilter | N | ||
@ | ReturnAIIProperties | N | ||
@ | ReturnPropertyValues | O | ||
@ | ReturnErrorText | O | ||
Response + | BrowseResponse | |||
E | BrowseResult | M | ||
E | Elements | M | Должно появиться столько элементов, сколько элементов на первом уровне зависит от Данных | |
E | Properties | C | если свойства требуют | |
E | Value | M | если свойства требуют | |
@ | Name | O | если свойства требуют | |
@ | Description | O | если свойства требуют | |
@ | ItemPath | M | если свойства требуют | |
@ | ItemName | M | если свойства требуют | |
@ | ResultID | N | Не будут появляться в ответе положительной величины | |
Reference | @ | Name | M | |
@ | ItemPath | M | ||
@ | ItemName | M | ||
@ | Isltem | M | Будет "верно" | |
@ | HasChildren | M | Будет "верно" | |
E | PTC Erro | N | Не будут появляться в ответе положительной величины | |
@ | ContinuationPoint | C | ||
@ | MoreElements | C | ||
Response - | BrowseResponse | |||
E | BrowseResult | M | ||
E | Elements | N | В отрицательном ответе не должно быть никакого элемента | |
E | Properties | N | ||
@ | Name | N | ||
@ | ItemPath | N | ||
@ | ItemName | N | ||
@ | Isltem | N | ||
@ | HasChildren | N | ||
ServiceError | E | Errors | M | см. таблицу Б.29 |
E | Text | C | ||
@ | УДОСТОВЕРЕНИЕ ЛИЧНОСТИ | M | ||
@ | ContinuationPoint | N | ||
@ | MoreElements | N | ||
Примечание - Е: OPC XML-DA элемент обслуживания; @: OPC XML-DA признак. |
Отображение ServiceError показано в таблице Б.29.
Таблица Б.29 - GetDataDirectory отображение отрицательных ответов ServiceError IEM
IEM ServiceError | OPC Error Code |
Access-violation | E_ACCESS_DENIED |
Parameter-value-inappropriate | E_INVALIDITEMNAME |
IEM ServiceError | OPC Error Code |
Parameter-value-inappropriate | E_UNKNOWNITEMNAME |
Failed-due-to-serve r-constraint | Any other error code |
Б.5.6.2.4 GetDataDefinition
IEM GetDataDefinition сервис должен отобразить в последовательности OPC XML-DA Browse сервис для того, чтобы знать "тип" всех элементов, которые находятся ниже в структуре требуемой ссылки Data.
При приеме сервиса GetDataDefinition клиент должен запрашивать Browse сервис как в GetDataDirectory. Поскольку возвращается каждый элемент, у которого есть набор атрибута "HasChildren" к "True", новый Browse сервис должен быть запрошен. Как только полный список атрибутов, которые составляют данные, оказывается на стороне клиента, так подтверждение должно быть поставлено приложению-клиенту
Отображение OPC XML-DA элементов и признаков является главным образом тем же самым, что и сервисы GetDataDefinition (см. таблицу Б.28). Различие состоит в свойствах элемента, которые может произвольно требовать клиент.
Таблица Б.29.1 - IEM GetDataDefinition
Имущественное имя | Цель |
FC | Получить ФК DataAttributes |
IMType | Получить тип атрибутов DataAttriutes и DAComponents |
Отображение ServiceError определено в таблице Б.29.
Б.5.7 Модель класса Data set (Набор данных)
Примечание - Понятие Набора данных (Data Sets) не существует на стороне сервера. Б.5.7 описывает, как клиент мог использовать сервисы DataSet IEM, чтобы управлять Наборами данных, используя OPC XML-DA сервисы. Это представлено как пример, и не требуется никакого вида соответствия требования реализации с этим отображением.
Б.5.7.1 Класс Data set
OPC XML-DA спецификация не включает элемент, который входит в группу перечисления (FCDs или FCDAs) в статическом положении.
В этом отображении сторона сервера не выдает формируемый DATA - SET.
Функциональность клиента позволяет создание только нестойких DATA SET. DATA SET динамически создаются клиентами и накапливаются внутри на стороне клиента.
Класс IEM Data Sets доступен только на стороне клиента. Клиент внутренне хранит информацию о содержании DataSets так, чтобы включение управляло ими, как будто Data Sets был физически осуществлен в стороне сервера.
Восстановление информации, используя сервисы DataSets, позволяет приложению клиента возвращать текущие характеристики выбранной группы элементов, не имея необходимость определять полный список элементов.
Б.5.7.2 Атрибуты Data Set
Не отображаются.
Б.5.7.3 Сервисы Data Set
Б.5.7.3.1 Общие положения
Создание DATA-SET проверяет элементы, которые просил клиент для создания DATA-SET, располагаемых на сервере. Как только это произошло, клиент накапливает список элементов, которые составляют необходимый DATA-SET
Получение характеристик DATA-SET вызывает отправку в Read сервис всех элементов, которые составляют DATA-SET. С этим сервисом приложение-клиент в состоянии управлять комплектами характеристик данных различных отделений модели. При этом не должен определяться полный список ссылок.
Б.5.7.3.2 CreateDataSet
Сервис IEM CreateDataSet должен отображать последовательности сервиса Browse, чтобы получить полный список простых элементов, определенные списком элементов, которые должны составить DATA-SET.
Если какой-либо из ОРС Browse сервисов выходит из программы в сбой, то обслуживание CreateDataSet возвращает ServiceError к приложению клиента.
Допустим только неустойчивый DATA-SET.
Если обслуживание возвращает подтверждение положительной величины, то клиент должен накопить список признаков исходных данных, связанных с DataSetReference, которые требуют включение. То, как эта информация хранится, является местной проблемой.
Набор сервисов, необходимых для создания DataSet, описан в рисунке Б.3. Таблицы Б.30 и Б.31 описывают отображение сервисных параметров.
Рисунок Б.3 - последовательность сервисов CreateDataSet
Таблица Б.30 - Картография сервисных параметров CreateDataSet
Сервисные параметры CreateDataSet | OPC XML-DA сервис или параметр | Ограничение |
Request | Просмотрите услуги запроса | |
DataSetRefence | - | |
DSMemberRef [1..n] | ItemName | |
Confirmation + | Просмотрите услуги ответа | Если все просматривают услуги succeded |
Result | ||
Confirmation - | Просмотрите услуги ответа | Если кто-либо рассматривает, что обслуживание выходило из строя |
ServiceError | ОРС Errorcode | ServiceError должен быть, как показано в таблице Б.31 |
Таблица Б.31 - CreateDataSet отрицательная картография ответа к ServiceError IEM
IEM ServiceError | OPC XML-DA Код ошибки |
Failed-due-to-server-constraint | Internal client error. Client request a persistent DATA-SET |
lnstance-in-use | Internal client error. Client detects the DATA-SET already exists |
Parameter-value-inconsistent | E_INVALIDITEMNAME |
E_INVALIDITEMPATH | |
Failed-due-to-communication-constraint | Any unmapped error code |
Б.5.7.3.3 DeleteDataSet
Этот сервис удаляет внутреннюю структуру, которая накапливает список признаков исходных данных, которые составляют сервер.
Никакие коммуникационные услуги не нужны.
Б.5.7.3.4 GetDataSetDirectory
Этот сервис не включен в отображение. Используя это отображение, все DATA SET формируются клиентом онлайн так, чтобы информация об элементах, которые составляют DATA SET, была уже известна.
Б.5.7.3.5 GetDataSetValues
IEM GetDataSetValues сервис отображает OPC XML-DA Read сервис. Список Элементов ОРС, которые составляют DATA SET, был накоплен SCSM на стороне клиента во время сервиса CreateDataSet. Отображение сервисных параметров IEM такое же, как в сервисе GetDataValues.
Если DataSetReference определил, что список элементов не накоплен, то обслуживание отражает ServiceError, как показано в таблице Б.32.
Таблица Б.32 - GetDataSetValues отображение отрицательных ответов ServiceError IEM
IEM ServiceError | OPC XML-DA Код ошибки |
Instance-not-available | The DATA-SET requested is not in the list of the DATA-SETs of the client |
Access-violation | E_ACCESS_DENIED |
Failed-due-to-serve r-constraint | Any unmapped error code |
Б.5.7.3.6 SetDataSetValues
Отображения сервисов IEM SetDataSetValues к OPC XML-DA Write сервисам полного списка атрибутов исходных данных, которые составляют DATA SET. Список элементов ОРС, которые составляют DATA SET, был накоплен SCSM на стороне клиента во время сервиса CreateDataSet.
Отображение сервисных параметров IEM - такое же, как показано в SetDataValues.
Если DataSetReference определил, что не имеет списка элементов, то сервис отображает ServiceError, как показано в таблице Б.33.
Таблица Б.33 - SetDataSetValues отображение отрицательных ответов к ServiceError IEM
IEM ServiceError | OPC XML-DA ErrorCode |
Instance-not-available | The DATA-SET requested is not in the list of the DATA-SETs of the client |
Access-violation | E_ACCESS_DENIED |
Type-conflict | E_BAD_TYPE |
Failed-due-to-serve r-constraint | Any unmapped error code |
Б.5.8 Модель класса Report
Б.5.8.1 Общие положения
ГОСТ Р 54418.3 описывает сервер управления механизмом отчетности, где сервер обнаруживает изменения в их информационной модели (события), посылая эту информацию в пределах структуры отчетного сообщения, вытекающего из правил, определенных клиентом в конфигурации механизма сообщения.
В OPC XML-DA механизм сообщения использует другой подход. Клиент должен периодически опрашивать сервер, чтобы получить последний комплект характеристик изменений (события).
Б.5.8.2 OPC XML-DA сообщающие атрибуты
Способом OPC XML-DA ответы отправляются в зависимости от некоторых признаков, включенных в запрос на обслуживание, посланный клиентом. Самые важные признаки в OPC XML-DA следующие:
HoldTime - инструктирует сервер воздержаться от возвращения из требования SubscriptionPolledRefresh, пока указанное абсолютное время сервера не достигнуто.
WaitTime - инструктирует сервер ждать указанной продолжительности (число миллисекунд) после того, как Holdtime достигнут прежде, чем возвратиться, если нет никаких изменений отчета. Изменение в одном из подписанных элементов во время периода ожидания приведет к возвращению сервера немедленно вместо того, чтобы закончить ожидание.
EnableBuffering - определяя EnableBuffering = True, сервер сохранит все значения изменения, обнаруженные при указанной норме, в буфере для возвращения клиенту в следующем запросе SubscriptionPolledRefresh.
Абонентские атрибуты ОРС описаны в таблице Б.34.
Таблица Б.34 - Принужденное значение признаков Подписки ОРС
Признаки ОРС | ГОСТ Р 54418.25 ограничения |
HoldTime | Около 0 |
WaitTime | Больше чем 0 |
EnableBuffering | ВЕРНЫЙ |
Примечание - Используя HoldTime и WaitTime нуля, сервер должен немедленно ответить с последним набором обнаруженных изменений. |
Изменения должны быть буферизованы (EnableBuffering set к истинному), чтобы не потерять любой случай.
Б.5.8.3 OPC XML-DA отчетные службы
OPC XML-DA поддерживает базовые сервисы следующих подписок: Subscribe, SubscriptionPolledRefresh и SubscriptionCancel. Subscribe используется, чтобы запустить подписной контракт с сервером. SubscriptionPolledRefresh вызывают периодически, чтобы приобрести последние изменения значения элемента. SubscriptionCancel используется, чтобы прервать абонентский контракт с сервером.
Б.5.8.4 Отчетные службы ГОСТ Р 54418.3
Б.5.8.4.1 AddSubscription
Сервис AddSubscription определяет ряд переменных, которые сервер должен контролировать, чтобы обнаружить их изменения и уведомить об этом клиента, который требовал такой режим. Сервисные параметры описаны в таблицах Б.35 и Б.36.
Таблица Б.35 - Сервисные ограничения параметра AddSubscription
Request | |
RcbRef | He отображенный к коммуникационному обслуживанию |
RCBType | |
Reportldentifier [0..1] | Не отображенный к коммуникационному обслуживанию |
ReportEnable [0..1] | Не отображенный. ReportEnable всегда считал ВЕРНЫМ |
DataSetReference [0..1] | Не отображенный к коммуникационному обслуживанию |
OptionalFields [0..1] | Порядковый номер = N |
BufferTime [0..1] | Клиент должен просить SubscriptionPolledRefresh каждый раз, когда этот таймер истекает |
TriggerOptions [0..1] | dchg = Y qchg = Y dupd = N |
IntegrityPeriod [0..1] | Клиент должен просить SubscriptionPolledRefresh с признаком RequestAllltems набирать к истинному каждый раз, когда таймер истекает |
DSMemberRef [1.. n] | Только FCDA, который позволен ссылками basicTypes |
Response + | |
Response- | |
ServiceError |
Таблица Б.36 - Отображение параметров серсвиса AddSubscriptions
Параметры AddSubscription | OPC XML-DA параметры | M/C/O/l/N | Ограничение | |
Request | Subscribe | |||
@ | Return ValueslnReply | N | ||
@ | SubscriptionPingRate | M | ||
E | Options | N | ||
E | ItemList | M | ||
@ | ItemPath | N | ||
@ | ReqType | N | ||
@ | Deadband | N | ||
@ | RequestedSampleTime | C | Местная проблема; M, если недобор на уровне списка | |
@ | EnableBuffering | M | Всегда "Верный" | |
E | Items | |||
DSMemberRef | @ | ItemPath | M | ФК FCDA |
@ | ReqType | O | ||
DSMemberRef | @ | ItemName | M | ObjectReference FCDA |
@ | ClientltemHandle | O | ||
@ | Deadband | M | Значение 0 | |
@ | RequestedSampleTime | C | Местная проблема; М., если не набор для каждого элемента на На уровне элемента | |
@ | EnableBuffering | M | Всегда "Верный" | |
Ответ + | SubscribeResponse | |||
@ | ServerSubHandle | M | ||
E | SubscribeResult | M | ||
E | RltemList | M | ||
@ | RevisedSamplingRate | |||
Ссылка | E | Items | M | |
@ | RevisedSamplingRate | O | ||
E | ItemValue | M | ||
E | Errors | N | Не будут появляться в ответе положительной величины | |
Ответ - | SubscribeResponse | |||
@ | ServerSubHandle | M | ||
E | SubscribeResult | M | ||
E | RltemList | M | ||
@ | RevisedSamplingRate | C | ||
Ссылка | E | Items | M | |
@ | RevisedSamplingRate | C | ||
E | ItemValue | M | ||
E | Errors | M | см. таблицу Б.37 | |
Примечание - E: ОРС XML-DA элемент обслуживания; @: ОРС XML-DA признак. |
Если будет какой-либо ошибочный элемент в обслуживании SubscribeResponse, то IEM Addsubscription сервис необходимо считать не пройденным.
После приема ОРС XML-DA сервиса SubscribeResponse без ошибок клиент должен отобразить:
1) внутреннее накопление ServerSubHandle, соединенного с RCBRef, ReportID, DataSetReference и OptFields, полученное в запросе AddSubscription;
2) старт периодического таймера, который должен просить в течение каждого надежного периода SubscriptionPolledRefresh с атрибутами:
HoldTime | 0 |
WaitTime | 0 |
ReturnAllltems | Верный |
Если надежный период будет нолем, то таймер не создается.
3) старт периодического таймера, который должен требовать для каждого BufferTimeSubscriptionPolledRefresh с атрибутами:
HoldTime | 0 |
WaitTime | 0 |
ReturnAllltems | Ложный |
Если buffertime период будет нолем, то клиент должен послать запросы с такой скоростью, с которой считает нужным, чтобы избежать коллапса пропускной способности сети.
Примечание - Используя это отображение, рекомендуется использовать BufferTime выше чем 500 миллисекунд, чтобы улучшить работу относительно электрической сети.
OPC XML-DA подписка будет создана, если по крайней мере один из указанных элементов будет действителен. Если Subscribe запрос выйдет из строя для по крайней мере одного из указанных элементов, то должен быть отображен отрицательный ответ к AddSubscription и подписка должна быть отменена используя сервис SubscriptionCancel OPC-MXL-DA.
AddSubscription отображение отрицательных ответов описано в таблице Б.37.
Таблица Б.37 - AddSubscription отображение отрицательных ответов к IEM ServiceError
IEM ServiceError | Код ошибки OPC |
Instance-not-available | E_INVALIDITEMNAME |
Parameter-value-inappropriate | E_INVALIDITEMPATH |
Instance-not-available | E_UNKNOWNITEMNAME |
Parameter-value-inappropriate | E_UNKNOWNITEMPATH |
Failed-due-to-serve r-constraint | Любой другой код ошибки |
Б.5.8.4.2 RemoveSubscription
IEM RemoveSubscription сервис должен быть отображен к ОРС XML-DA SubscriptionCancel. ServerSubhandle должен быть возвращен в Subscription сервис.
Отображение сервисных параметров RemoveSubscription описано в таблицах Б.38 и Б.39.
Таблица Б.38 - Отображение сервисных параметров RemoveSubscription
RemoveSubscription параметры | OPC XML-DA | M/C/O/l/N | |
Request | SubscriptionCancel | ||
@ | ServerSubHandle | M | |
RCB Ref | @ | ClientRequestHandle | M |
Response + | SubscriptionCancel Response | ||
@ | ClientRequestHandle | M | |
Response - | SubscriptionCancel Response | ||
@ | M | ||
Примечание - E: OPC XML-DA элемент обслуживания; @: OPC XML-DA атрибут. |
Таблица Б.39 - Отображение отказа IEM ServiceError
IEM ServiceError | Код ошибки OPC |
"Случай, не доступный" | Е_NOSUBSCRIPTION |
R-ограничение "Failed-due-to-server-constraint" | E_SERVERSTATE, любой другой кодекс короткого замыкания |
Б.5.8.4.3 Report (Отчет)
Сервис Report должен быть отображен к OPC XML-DA SubscriptionPolledRefreshResponse сервису. Используемый параметр сервиса Report описан в таблицах Б.40 и Б.41.
Таблица Б.40 - Параметры сервиса Report
Report | Ограничение |
RptID | Включенный в сторону клиента картографией |
OptFlds | Включенный в сторону клиента картографией |
SeqNum | Недоступный |
SubSeqNum | Недоступный |
MoreSegmentsFollow | Не используемый |
DatSet | Если требующийся в OptFlds, то это должно быть включено в сторону клиента картографией |
BufOvfl | Доступный |
ConfRev | Недоступный |
TimeOfEntry | Доступный |
DataRef | Доступный |
Value | Доступный |
ReasonCode | Недоступный |
Таблица Б.41 - Отображение параметров сервиса Report
Параметры отчета | ОРС XML-DA параметры | M/C/O/l/N | Ограничение | |
SubscriptionPolledRefresh | ||||
@ | HoldTime | M | Набор к 0 | |
@ | WaitTime | M | Набор к 0 | |
@ | ReturnAllltems | M | Зависит от случая | |
E | Options | |||
E | ServerSubHandle | M | ||
Report | Ответ SubscriptionPolledRefresh | |||
BufferOverflow | @ | DataВufferOverfIow | ||
E | SubscriptionPolledRefreshResult | M | ||
E | InvalidServerSubHandles | M | ||
E | RitemList | M | ||
@ | SubscriptionHandle | M | ||
DataRef и DataValue | E | Items | M | |
E | Errors | M | ||
Примечание - E: ОРС XML-DA элемент обслуживания; @: ОРС XML-DA атрибут |
На приеме SubscriptionPolledRefreshResponse клиент должен будет составить Report сообщения. Соответствующий "EnableBuffering" атрибут, SubscriptionPolledRefreshResponse может включать несколько образцов того же самого элемента. Если такая ситуация произойдет, то сторона клиента должна:
- разделить сообщение на два различных сообщения отчета так, чтобы никакое изменение не было потеряно, если элемент представляет собой значение состояния (ST);
- разделить сообщение или удалить предыдущее значение, если элемент представляет собой уточненное значение (MX).
В зависимости от OptFlds, сохраненных клиентом на Subscribe сервисе, различные элементы Report, такие как Reportid, DatSetRef и т.д. (также сохраненные клиентом), должны быть включены в Report Indication (Показание Отчета).
Б.5.9 Модель контроля
Б.5.9.1 Основное положение
В ГОСТ Р 54418.25 модель контроля получает доступ через протекающие ОРС XML-DA сервисы:
- Read;
- Write;
- Subscribe, SubscriptionPolledRefresh, RemoveSubscription.
Б.5.9.2 IEM Поддерживаемые контролирующие модели
Таблица Б.42 определяет Поддерживаемые контролирующие модели этим отображением.
Таблица Б.42 - Поддерживаемые контролирующие модели в этом отображении
ГОСТ Р 54418.3 | Поддерживаемый |
1 прямое управление "с нормальной безопасностью" | Y |
2 sbo-контроля "с нормальной безопасностью" | Y |
3 прямое управление "с расширенной безопасностью" | Y |
4 sbo-контроля "с расширенной безопасностью" | Y |
Б.5.9.3 IEM Поддерживаемые контролирующие сервисы
Таблица Б.43 определяет Поддерживаемые контролирующие сервисы показанные в этом отображении.
Таблица Б.43 - Поддерживаемые контролирующие сервисы
ГОСТ Р 54418.3 (ГОСТ Р МЭК 61850-7-2) | Поддерживаемый |
Browse | Y |
SelectWithValue | Y |
Operate | Y |
TimeActivatedOperate | Y |
Cancel | Y |
CommandTermination | Y |
Б.5.9.4 Параметры контролирующих сервисов
Некоторые из параметров контролирующих сервисов не являются ни частью информационной Модели, ни делают систематические согласования ни одному из параметров сервиса ОРС XML-DA. Параметры контролирующих сервисов не могут отображаться непосредственно ни одной веб-службой ОРС XML-DA, используя информационную модель.
Чтобы решить эту проблему, параметры контролирующих сервисов отображены к writeable индивидуальными характеристиками элемента, которые назначены в dataAttributes для каждого объекта контроля. Список writeable индивидуальных характеристик элемента описан в таблице Б.44.
Таблица Б.44 - Параметры контролирующих сервисов индивидуальных характеристик элемента
Сервисный параметр контроля | Собственность элемента обычая writeable | ||
ItemName | ItemPath | ГОСТ Р 54418.2 BasicType | |
Т | DataRef.ctlVal.t | CO | TimeStamp |
Проверка | DataRef.ctlVal.test | CO | Булевый |
Проверить | DataRef.ctlVal.check | CO | CodedEnum |
DataRef.ctlVal.service | CO | ENUMERATED | |
AddCause | CO | ENUMERATED | |
TimOperRsp | CO | ENUMERATED | |
Примечания 1 DataRef используется в качестве placeholder для ObjectReference любых данных управления. 2 Если сервис CommandTermination не поддержан сервером, то собственность элемента "cmdState" не должна быть обеспечена ни для какого объекта контроля. 3 Если обязательный сервис Operate - единственный сервис контроля, который поддерживается сервером, собственность элемента "service" не должна быть обеспечена. 4 Если сервер не поддерживает сервис TimeActivatedOperate, то собственность элемента "taoState" не должна быть обеспечена. 5 Значения свойств элемента "cmdState" и "taoState" не должны быть установлены с контролем отрицательных ответов. "cmdState" должен только присутствовать в тех управляемых объектах, где используется расширенная модель безопасности. Большинство сервисов контроля отображено в Write сервисе. Записанная специальная характеристика элемента "service" добавлена, чтобы определить необходимый сервис контроля. |
Отображение AddCause представлено в таблице Б.45.
Таблица Б.45 - Отображение AddCause к Коду ошибки OPC
AddCause | AddCause | Расширенный Код ошибки ОРС | Пере- |
Select-failed | Избранно- | Е_ADDCAUSE_SELECT_FAILED | 3 |
Invalid-position | Недействительное положение | E_ADDCAUSE_INVALID_POSITION | 4 |
Position-reached | Достигнутый положением | E_ADDCAUSE_POSITION_REACHED | 5 |
Parameter-change- | Параметр изменяется в выполнении | E_ADDCAUSE_PARAMETER_CHANGE_IN_EXEC | 6 |
Step-limit | Неродной предел | E_ADDCAUSE_STEP_LIMIT | 7 |
Command-already- | Команда уже в выполнении | E_ADDCAUSE_COMMAND_ALREADY_IN_EXEC | 8 |
Abortion-by-cancel | Прекращение отменой | E_ADDCAUSE_BY_CANCEL | 9 |
Time-limit-over | Время - предел | E_ADDCAUSE_TIME_LIMIT_OVER | 10 |
Б.5.9.5 Отображение контролирующих сервисов
Б.5.9.5.1 Select (Выделенные)
Б.5.9.5.1.1 SelectRequest
Select сервис должен быть отображен в ОРС XML-DA Write сервисе "service" записанной специальной характеристикой элемента со значением "sbo".
Таблица Б.46 - Описание отображения запроса Select сервиса
ГОСТ Р 54418.3 параметра | ОРС XML-DA Элемента / свойство Элемента | Ограничение |
ControlObjectReference | ItemName управляемого объекта. | |
DataRef.ctlVal.service | "sbo" |
Б.5.9.5.1.2 Select Response + (Выбраный Ответ)
Select положительного отклика сервис должен быть отображен в ОРС XML-DA сервисом WriteResponse с положительным результатом.
После ответа значения свойств элемента taoState и cmdState (если есть) должны быть установлены следующим образом:
Особенные свойства элемента Writeable | Значение | Значение |
DataRef.operTm.taoState | "0" | Нет |
DataRef.ctlVal.cmdState | "0" | Нет |
Б.5.9.5.1.3 Select Response + (Выбраный Ответ)
Select отрицательного отклика сервис должен быть отображен в ОРС XML-DA сервисом WriteResponse с ErrorCode, указывающим на аварию.
Специальные характеристики элемента "taoState" и "cmdState" не должны быть изменены.
Б.5.9.5.2 SelectWithValue
Запрос SelectWithValue
Сервис SelectWithValue должен выполняться с помощью ОРС ХМL-DA Write значений элементов и свойств элемента управляемого объекта, приведенного в таблице Б.47.
Таблица Б.47 - Сервисное отображение параметра SelectWithValue
Параметр ГОСТ Р 54418.3 | ОРС XML-DA Элемента/ свойство Элемента | Ограничение |
ControlObjectReference | ItemName управляемого объекта. | |
Value | DataRef.ctlVal DataRef.origin | |
Т | DataRef.ctlVal. T | |
Test | DataRef.ctlVal. Проверка | |
Check | DataRef.ctlVal. Проверить | |
DataRef.ctlVal.service | "sbow" |
Ответ SelectWithValue +
Ответ положительной величины SelectWithValue должен быть выполнен с помощью ответа положительной величины ОРС ХМ L-DA Write. Только в случае если все элементы возвращены с положительным результатом, сервис SelectWithValue может считаться принятым.
После ответа, значения свойств элемента taoState и cmdState (если есть) должны быть установлены следующим образом.
Таблица Б.47.1 - Ответ SelectWithValue
Особое свойство элемента Writeable | Значение | Значение |
DataRef.operTm.taoState | "0" | Нет |
DataRef.ctlVal.cmdState | "0" | Нет |
SelectWithValue отрицательный ответ должен быть выполнен с помощью ОРС XML-DA Write отрицательный ответ. Код ошибки OPC/s должен включать AdditionalCause аварии, показывающий причину отрицательного ответа.
Особые характеристики элементов "taoState" и "cmdState" не должны быть изменены.
Б.5.9.5.3 Cancel (Отмена)
Cancel Request (ОтменаЗапроса)
Сервис Cancel должен быть выполнен с помощью значений элементов и свойств элемента управляемого объекта ОРС XML-DA Write. Отображение параметров показано в таблице Б.48.
Таблица Б.48 - Отображение параметров сервиса Cancel
Параметр ГОСТ Р 54418.3 | ОРС XML-DA Элемента/ свойство Элемента | Ограничение |
ControlObjectReference | ItemName управляемого объекта | |
T | DataRef.ctlVal. T | |
Проверка | DataRef.ctlVal. Проверка | |
DataRef.ctlVal.service | "отменить" |
Cancel Response +
Cancel Response + должен быть выполнен с помощью ОРС XML-DA WriteResponse, который не содержит Ошибок.
После ответа значения свойств элемента taoState и cmdState (если есть) должны быть установлены следующим образом.
Таблица Б.48.1 - Cancel Response+
Особое свойство элемента Writeable | Значение | Значение |
DataRef.operTm.taoState | "0" | Нет |
DataRef.ctlVal.cmdState | "0" | Нет |
Cancel Response-
Cancel Response- должен быть выполнен с помощью ОРС XML-DA WriteResponse, который содержит "Ошибки", указывающие на аварию обслуживания. Коды ошибки должны быть отображены, как показано в таблице Б.49. Коды ошибок AddCause, показанные в таблице Б.45, также могут использоваться.
Таблица Б.49 - Отображение отрицательного ответа в ServiceError IEM
ГОСТ Р МЭК 61850-7-2 ServiceError | Код ошибки ОРС |
Not-supported | E_NOTSUPPORTED |
Object-not-selected | E_SERVERSTATE |
Access-violation | E_ACCESS_DENIED |
Instante-not-available | E_UNKNOWNITEMNAME |
Особые характеристики элемента "taoState" и "cmdState" не должны быть изменены.
Б.5.9.5.4 Operate
Operate Request
Operate Request сервис должен выполняться с помощью ОРС XML-DA Write значений элементов и свойств элемента управляемого объекта, как показано в таблице Б.50.
Таблица Б.50 - Отображение Operate Request сервиса
Параметр ГОСТ Р 54418.3 | ОРС XML-DA Элемента/ собственность Элемента | Ограничение |
ControlObjectReference | ItemName управляемого | |
Value | DataRef.ctlVal DataRef.origin DataRef.ctlNum | |
T | DataRef.ctlVal. T | |
Test | DataRef.ctlVal. Проверка | |
Check | DataRef.ctlVal. Проверить | |
DataRef.ctlVal.service | "прекратить" |
Operate Response+
Operate Response+ должен выполняться с помощью ОРС XML-DA WriteResponse, который содержит WriteResult, указывающий на успех. После ответа значения свойств элемента taoState и cmdState (если есть) должны быть установлены, как показано в таблице Б.50.1.
Таблица Б.50.1 - Operate Response+
Особое свойство элемента Writeable | Значение | Значение | Ограничение |
DataRef.operTm.taoState | "0" | Нет | |
DataRef.ctlVal.cmdState | "0" | Нет | Если Operate используется в пределах модели контроля с нормальной безопасностью |
"1" | выполнение команды | Если Operate используется в пределах модели контроля с расширенной безопасностью |
Operate Response-
Operate Response- должен выполняться с помощью ОРС XML-DA WriteResponse, который содержит Ошибку, указывая на аварию обеспечения. Коды ошибки должны быть отображены, как показано в таблицах Б.51 и Б.45.
Таблица Б.51 - Отображение негативного ответа IEM ServiceError
ГОСТ Р МЭК 61850-7-2 ServiceError | Код ошибки OPC |
Not-supported | E_NOTSUPPORTED |
Object-not-selected | E_SERVERSTATE |
Access-violation | E_ACCESS_DENIED |
Instante-not-available | E_UNKNOWNITEMNAME |
Failed-due-to-server-constraint | Любой другой Код ошибки ОРС |
После ответа значения свойств элемента taoState и cmdState (если есть) должны быть установлены, как показано в таблице Б.51.1.
Таблица Б.51.1 - Operated ServiceError IEM
Собственность элемента обычая Writeable | Значение | Значение | Ограничение |
DataRef.operTm.taoState | "0" | Нет | |
DataRef.ctlVal.cmdState | "0" | Нет | Если Operate используется в пределах простой модели контроля за безопасностью |
Б.5.9.5.5 TimeActivatedOperate (Время активации действия)
Основное положение
Запрос с первичным ответом TimeActivatedOperate должен сопоставляться с сервисом ОРС XML-DA Write.
Вторичный ответ должен сопоставляться либо с ОРС XML-DA Subscribe оператора "operTm.taoState" настроек контролируемого объекта, либо может быть получен, используя сервис Read, который будет отслеживать изменение настроек оператора "operTm.taoState".
По получении положительного ответа оператора WriteResponse, клиент ОРС XML-DA должен запрашивать (перебирать) значения taoState и другие настройки, чьи значения необходимы для ответа TimeActivatedOperate. До тех пор пока taoState='timer-activated", клиент ОРС XML-DA должен продолжать запрос величин.
Если taoState изменяет свою величину на "command-executed" (команда выполнена), то клиент должен создать положительное подтверждение TimeActivatedOperate, используя TimOperRsp='command-executed".
Если taoState изменяет свою величину на любой код AddCause (дополнительная причина), то пользователь должен отрицательно подтверждать TimeActivatedOperate.
Примечание - В зависимости от пользователя запрашиваются значения для вторичного отклика через Read service (Сервис чтения) или через Subscribe mechanism (механизм Описания) (=Subscribe+ SubscriptionPolledRefresh+SubscriptionCancel).
TimeActivatedOperateRequest (Запрос времени активации действия)
Сервис TimeActivatedOperateRequest должен быть реализован через использование ОРС XML-DA Write (Записи) элементов и элементарных свойств контролируемого объекта. Параметры сервера TimeActivatedOperate описаны в таблице Б.52.
Таблица Б.52 - Отображение параметров сервера TimeActivatedOperate
ГОСТ Р 54418.25.3 параметр | ОРС XML-DA элемент/свойство элемента | Заключение |
ControlObjectReference (Ссылка контроля объекта) | ItemName (имя элемента) контролируемого объекта | |
Value (Значение) | DataRef.ctlVal | |
T | DataRef.ctlVal.T | |
Test (Тест) | DataRef.ctlVal.Test | |
Check (Проверка) | DataRef.ctlVal.Check | |
DataRef.ctlVal.service | "taOperate" |
TimeActivatedOperateResponse+(timer-activated)
Положительный ответ TimeActivatedOperate должен выполняться через ОРС XML-DA WriteResponse (ОРС XML-DA), который не содержит ErrorCodes. С таким ответом значения свойств элементов taoState и cmdState должны быть установлены следующим образом:
Writeable Custom Item Property (Вводимые пользовательские настройки элемента) | Value (Значение) | Meaning (Смысл) | Constraint (Заключение) |
DataRef.operTm.taoState | "1" | Waiting/timer activated ожидание/активация | |
DataRef.ctlVal.cmdState | "0" | Not-in-use (не используется) |
TimeActivatedOperateResponse-
Отрицательный ответ TimeActivatedOperate должен выполняться через ОРС XML-DA WriteResponse (ОРС XML-DA), указывающий сбой в ErrosCodes, как определено в таблице Б.53, или с использованием кодов AddCause, определенных в таблице Б.45.
Таблица Б.53 - TimeActivatedOperate отрицательный ответ, отображаемый на IEM ServiceError
ГОСТ Р МЭК 61850-7-2 ServiceError | OPC Error Code (код ошибок) |
Not-supported (не-поддерживается) | Е_NOTSUPPORTED |
Object-not-selected (объект-не-выделен) | Е_SERVERSTATE |
Access violation (ошибка доступа) | Е_ACCESSDENIED |
Instante-not-available (в данный-момент-не-доступно) | Е_UNKNOWNITEMNAME |
Failed-due-to-server-constraint (отказ-по-заключению-сервера) | Any other OPC error name |
TimeActivatedOperateResponse+ (command-executed)
Второй положительный ответ TimeActivatedOperate не имеет связи с сервером. Клиент должен или прописать в taoState настройки элемента, или обратиться к OPC XML-DA Read Service, чтобы описать ситуацию.
По истечении выдержки времени желаемое действие должно быть активировано. Если активация прошла успешно, то установленные настройки должны быть установлены по умолчанию как указано ниже.
Вводимые пользовательские настройки элемента | Значение | Смысл | Заключение |
DataRef.operTm.taoState | "2" | Command-executed | |
DataRef.ctlVal.cmdState | "0" | Not-in-use | Если TimeActivatedOperate используется в простой наружной модели управления |
"1" | Executing-command команда выполнения | Если TimeActivatedOperate используется в нормальной наружной модели управления |
TimeActivatedOperateResponse- (second response) (вторичный ответ)
Если активация не прошла успешно, то тогда должно быть установлено только значение настроек элемента taoState как указано ниже.
Вводимые пользовательские настройки элемента | Значение | Смысл | Заключение |
DataRef.operTm.taoState | AddCause Дополнительная причина |
Б.5.9.5.6 CommandTermination (Команда Завершения)
При получении положительного Operate Response или вторичного положительного ответа TimeActivatedOperate "cmdState" свойству элемента присваивается значение "command-executed" (команда выполнена).
Если статус изменился на желаемое значение, то "cmdState" устанавливается на "status-changed" ("статус-изменился"). В противном случае, cmdState устанавливается на AddCause.
Пользователь ОРС XML-DA запрашивает "cmdState" через Read Service или Subscribe Mechanism.
Отображение сервиса CommandTermination описано в таблицах Б.54 и Б.55.
Таблица Б.54 - CommandTermination + service parameter mapping (Команда завершения + отображение параметров сервиса)
Параметр ГОСТ Р 54418.3 | ОРС XML-DA элемент/ свойство элемента | Заключение |
ControlObjectReference | ItemName of the controllable | |
T | DataRef.ctlVal.T | |
Test | DataRef.ctlVal.Test | |
DataRef.ctlVal.cmdState | "status-changed" |
Таблица Б.55 - CommandTermination - service parameter mapping (Команда завершения - отображение параметров сервиса)
Параметр ГОСТ Р 54418.3 | ОРС XML-DA элемент/ свойство элемента | Заключение |
ControlObjectReference | ItemName of the controllable object. | |
T | DataRef.ctlVal.T | |
Test | DataRef.ctlVal.Test | |
AddCause | DataRef.ctlVal.cmdState | AddCause error codes |
Б.6 Детали стека протокола
Чтобы отображение было полным, должен использоваться стек протоколов, приведенный в таблице Б.56.
Спецификации для уровня канала данных и физического уровня очень специфичны для реализации и выходят за рамки серии стандартов ГОСТ Р 54418.25.
Таблица Б.56 - Детали стека протоколов
OSI model layer | Specification | M/O | ||
Name | Service specification | Protocol specification | ||
Application | OPC XML-DA | OPC XMLDA 1.01 | M | |
SOAP | [8] | M | ||
Hypertext Transfer | [18] | M | ||
Presentation Презентация | - | - | - | - |
Session Сессия | - | - | - | - |
Transport Транспорт | Transport Layer Secure (TLS) | [20] | O | |
Internet Control Message Protocol (ICMP) | [11] | M | ||
Transmision Control | [12] | M | ||
Network Сеть | Internet Protocol (IP) | [10] | M | |
Address Resolution | [13] | M | ||
Data Link Канал данных | Реализация специфична и выходит за рамки ГОСТ Р 54418.25 | - | ||
Physical Физический | Реализация специфична и выходит за рамки ГОСТ Р 54418.25 | - | ||
Примечание - Использование HTTPS (SSL) специфично и выходит за рамки данного отображения. |
Приложение В
(обязательное)
Отображение специфичного сервиса связи
В.1. Основные положения
В.1.1 Введение к отображению в [23], определенных в [22]
Это приложение описывает использование [22] для отображения информационной модели и модели обмена информацией, определенных в ГОСТ Р 54418.25.2 и ГОСТ Р 54418.25.3, в [23].
Почти все сервисные модели, указанные в ГОСТ Р 54418.25.3, отображены в [23] как "определенные" в [22] и обсуждаются в настоящем приложении. Два сервиса (AddSubscriptions и RemoveSubcription), определенных в настоящем стандарте, сопоставляются с [22]. Это дополнительное отображение определяется в настоящем приложении.
QueryLog сервис, определенный в [22], поддерживается параметрами фильтра (поддерживается в [23], но не используется в [22]).
В.1.2. Масштаб отображения в серии стандартов [23], определенного в [22]
Масштабом отображения, определенного в приложении В, является использование [23] для представления информационной модели и модели обмена информацией, определенных в соответствии с ГОСТ Р 54418.25.2 и ГОСТ Р 54418.25.3.
Отображение, определенное в [22], главным образом относится к обмену информацией в режиме реального времени. Пользователями сервисов могут быть системы, которым необходимо получить информацию в режиме реального времени, чтобы отображать и контролировать производственные процессы и соответствующее оборудование.
В.1.3. Архитектура отображения
Архитектура отображения состоит из:
1) отображения информационной модели на моделях [23] MMS моделей (см. В.4);
2) отображения сервиса обмена информацией на сервисах [23] MMS услуг (см. В.5);
3) стеков связи (см. В.6).
Отображение для ГОСТ Р 54418.25.3 определяется по [22], кроме двух дополнительных сервисов и расширения QueryLog сервиса.
Информационная модель ВЭС, определенных в ГОСТ Р 54418.25.2, отображается в иерархической структуре, как определено в [22]. Соответствующие сервисы отображаются, как определено в этих пунктах.
Схематическое отображение представлено на рисунке В.1.
Информационная модель ВЭС из ГОСТ Р 54418.25.2 намеренно сохраняют при сопоставлении с сервисами [22] MMS.
Это означает, что:
- сервер реализует иерархическую информационную модель ВЭС из ГОСТ Р 54418.25.2, которая может быть восстановлена сервисами в соответствии с таблицей В.1.;
- пользователю необходимо интерпретировать информационную модель ВЭС;
- клиент получает доступ к иерархической информационной модели ВЭС ГОСТ Р 54418.25.2 через сервисы, предоставляемые [22] и [23], как определено в настоящем приложении.
Рисунок В.1 - Архитектура отображения (схематичная)
Таблица В.1 содержит отображение информационных моделей и сервисов обмена информацией в [23], как определено в [22]. Графа М/О указывает, являются ли сервисы, определенные в соответствии с ГОСТ Р 54418.25.3, обязательными или необязательными. "Y" обозначает "YES" (да), сервис поддерживается, в то время как "N" означает, что не поддерживается.
Таблица В.1 - Отображение ГОСТ Р 54418.25.3 IEM в [23] в соответствии со [22]
ГОСТ Р 54418.25.3 1M Class | ГОСТ Р 54418.25.3 IEM Services | M/O | Ото- | Серия стандартов [23] model/services |
SERVER (сервер) | Y(да) | Server | ||
GetServerDirectory | O | Y | GetNameList (вывод имени) | |
ASSOCIATION (связь) | Application association (связь с приложением) | |||
Associate (связать) | M | Y | Initiate (инициировать) | |
Release (выпустить) | M | Y | Conclude (выводить) | |
Abort (прервать) | O | Y | Abort (прервать) | |
Reject (отклонить) | ||||
Cancel (отменить) | ||||
Identify (идентифицировать) | ||||
LOGICAL-DEVICE (логический аппарат) | Y | Domain (домен) | ||
GetLogical DeviceDirectory | O | Y | GetNameList | |
LOGICAL-NODE (логический узел) | Y | |||
GetLogical DeviсеDirectory | O | Y | GetNameList | |
DATA (данные) | ||||
GetDataValues | M | Y | Read | |
SetDataValues | M | Y | Write | |
GetDataDirectory | O | Y | GetVariableAccessAttribute | |
GetDataDefinition | O | Y | GetVariableAccessAttribute | |
DATA-SET (файл) | ||||
GetDataSetValues | M | Y | Read | |
SetDataSetValues | O | Y | Write | |
CreateDataSet | O | Y | DefineNamedVariableList | |
DeleteDataSet | O | Y | DeleteNamedVariableList | |
GetDataSetDirectory | O | Y | GetVariableListAttributes | |
REPORTING (отчет) | NamedVariable | |||
Report | information Report | |||
GetBRCBValues | O | Y | Read | |
SetBRCBValues | O | Y | Write | |
GetURCBValues | O | Y | Read | |
SetURCBValues | O | Y | Write | |
AddSubscription | O | Y | (DefineNamedVariableList) | |
Write (to RCB) | ||||
RemoveSubscription | O | Y | Write (to RCB) | |
(DeletNamedVariableList) | ||||
LOG-CONTROL-BLOCK (блок записи) | Y | NamedVariable | ||
GetLCBValues | O | Y | Read | |
SetLCBValues | O | Y | Write | |
LOG (регистратор) | Y | Journal | ||
GetLogStatusValues | O | Y | InitializeJournal | |
QueryLogByTime | O | Y | ReadJournal | |
QueryLogAfter | O | Y | ReadJournal | |
CONTROL (управление) | Control | |||
Select | O | Y | Write | |
SelectWithValue | O | Y | Write | |
Cancel | O | Y | Write | |
Operate | M | Y | Write | |
CommandTermination | O | Y | information Report | |
TimeActivatedOperate | O | Y | Write |
В.2. Специальные ссылки к настоящему приложению
При использовании настоящего приложения дополнительную информацию можно получить из [10]-[13], [24]-[33] и [38].
В.3 Сокращения
Сокращения приведены в разделе 4 настоящего стандарта.
Примечание - В настоящем приложении вместо термина ACSI используется термин IEM.
В.4 Отображение ГОСТ Р 54418.25 Информационной Модели в [23], как указано в [22]
Информационная модель ВЭС, определенных в ГОСТ Р 54418.25.2, отображается в иерархической структуре [23], как определено в [22] (разделы 7, 17 и 20). Соответствующие сервисы отображаются в [23], как определено в [22] (и показано в таблице В.1).
В.5 Отображение расширенной Модели Обмена Информацией [23]
В.5.1 Основные положения
Настоящий раздел описывает, как дополнительные выдержки IEM сервисов, определенных в ГОСТ Р 54418.25.3 (Addsubscriptions и Removesubcription) и дополнительные настройки фильтра сервиса QueryLog должны отображаться в сервисах MMS, как указано в следующих подразделах.
В.5.2 AddSubscription (добавить выписку)
Данный сервис должен отображать следующую последовательность трех MMS сервисов:
- шаг 1: Создание запрашиваемого набора данных (DefineNamedVariableList) в соответствии с таблицей В.2;
- шаг 2: Конфигурация Отчетного Блока Управления (Запись) в соответствии с таблицей В.3;
- шаг 3: Активация Отчетного Блока Управления (Запись) в соответствии с таблицей В.4.
Эти команды должны быть запущены с момента положительного отклика предыдущих. В случае, если хоть один из MMS сервисов даст сбой, служба Addsubscription должна рассматриваться как сбой.
Шаг 1 может быть не нужен в случае существования NamedVariableList. Он может использоваться несколькими Отчетными Блоками Управления или Блоками Регистратора Управления.
Таблица В.2 - Отображение сервиса AddSubscribtion (Шаг 1)
AddSubscription parameters | MMS service or parameter | Заключение |
Request | DefineNamedVariableList request | |
service | ||
DataSetReference | variableListName | |
DSMemberRef [1..n] | listOfVariable | |
Response+ | DefineNamedVariableList response | |
service | ||
Response- | ||
ServiceError | MMS Service Error | См. таблицу В.5 |
Таблица В.3 - Отображение сервиса AddSubscribtion (Шаг 2)
AddSubscription parameters | MMS service or parameter | Заключение |
Request | Write request service | |
ClientHandle | VariableAccessSpecification | |
(ListOfVariable) | ||
RCBType | VariableAccessSpecification | |
(ListOfVariable) | ||
MMS Data | Появляется только если RCBType указывает RCB тип URCB | |
Reportldentifier [0..1] | MMS Data | |
DataSetReference [0..1] | MMS Data | |
OptionalFields [0..1] | MMS Data | |
BufferTime [0..1] | MMS Data | |
TriggerOptions [0..1] | MMS Data | |
TrgOp of the referenced BRCB/URCB | ||
См. ГОСТ P МЭК 61850-7-2 (подраздел 14.2) | ||
IntegrityPeriod [0..1] | MMS Data | |
IntgPd of the referenced BRCB/URCB | ||
См. ГОСТ P МЭК 61850-7-2 (подраздел 14.2) | ||
Response+ | Write response services | |
Success on all the elements | ||
Response- | Write response services | |
ServiceError | Failure on any of the elements | см. таблицу В.5 |
Примечание - Элемент Resv будет включен вследствие того, что некоторые сервисы требуют предварительную резервацию Unbuffered ReportControlBlock перед открытием доступа к их настройкам. |
Таблица В.4 - Отображение сервиса AddSubscribtion (Шаг 3)
AddSubscription parameters | MMS service or parameter | Заключение |
Request | Write request service | |
ClientHandle | VariableAccessSpecification | |
(ListOfVariable) | ||
RCBType | VariableAccessSpecification | |
(ListOfVariable) | ||
ReportEnable [0..1] | MMS Data | |
RptEna of the referenced BRCB/URCB | ||
Response + | Write response services | |
Success | ||
Response- | Write response services | |
ServiceError | Failure | см. таблицу В.5 |
Таблица В.5 описывает возможные негативные последствия и код ошибки, который должен предусматриваться на уровне приложения.
Таблица В.5 - Отрицательный ответ AddSubscription
IEM service error | MMS service error | Пояснение | |
Error class | Error code | ||
lnstance-in-use | Definition (описание) | Object-exists (объект существует) | Набор данных существует |
Parameter-value-inconsistent | Definition | Invalid-address (неправильный адрес) | ссылка неверна |
Parameter-value-inappropriate | Resource (ресурс) | Memory-unavailable (память недоступна) | Число DSMemberRefs выше чем максимально допустимое устройством |
MMS DataAccessError | |||
access-violation | Object-access-denied (доступ отклонен) | Клиент не имеет прав к доступу | |
Parameter-value-inappropriate | Object-non-existing (объект не существует) | Указанный клиентом RCB не существует | |
lnstance-in-use | Temporarily-unavailable (временно недоступен) | RCB уже используется клиентом | |
Parameter-value-inconsistent | Object-value-invalid (значение неверно) | Другие параметры не поддерживаются |
В.5.3 RemoveSubscription (удалить выписку)
Данный сервис должен отображать следующую последовательность MMS сервисов:
- шаг 1: Деактивация Отчетного Блока Управления (Запись) см. таблицу В.6;
- шаг 2: Удаление связанного набора данных (DeleteNamedVariableList) см. таблицу В.7.
Команда DeleteNamedVariableList должна быть запущена при условии выполнения первой. В любом случае NamedVariableList не нуждается в удалении. Он может использоваться другим Отчетным Блоком Управления или Регистратором Блока Управления.
Таблица В.6 - Отображение сервиса RemoveSubscribtion (Шаг 1)
AddSubscription parameters | MMS service or parameter | Заключение |
Request (запрос) | Write request service (запрос) | |
ClientHandle (ручное управление) | VariableAccessSpecification. (ListOfVariable) (список переменных) | |
RCBType (модель RCP) | VariableAccessSpecification. (ListOfVariable) (список переменных) | |
ReportEnable [0..1] | MMS Data RptEna, относящиеся к BRCB/URCB. См. ГОСТ P МЭК 61850-7-2 (подраздел 14.2) | |
MMS Data RptEna относящиеся к BRCB/URCB. См. ГОСТ P МЭК 61850-7-2 (подраздел 14.2) | Появляется только если RCBType указывает RCB тип URCB | |
Response+ (положительный ответ) | Write response services | |
Success (успех) | ||
Response- (отрицательный ответ) | Write response services | |
Failure (сбой) | См. таблицу В.8 |
Таблица В.7 - Отображение сервиса RemoveSubscribtion (Шаг 2)
AddSubscription parameters | MMS service or parameter | Заключение |
Request (запрос) | DeleteNamedVariableList request service (запрос сервиса) | |
ClientHandle (ручное управление) | ListOfVariableListName | |
Response+ (положительный ответ) | DeleteNamedVariableList response service (ответ сервиса) | |
numberDeleted | ||
Response- (отрицательный ответ) | Write response services | |
MMS ServiceError | См. таблицу В.8 |
Таблица В.8 описывает возможные негативные последствия и код ошибки, который должен предусматриваться на уровне приложения.
Таблица В.8 - RemoveSubscription Отрицательный ответ
IEM service error | MMS service error | Пояснение | |
Error class | Error code | ||
lnstance-in-use (объект используется) | Definition (описание) | Object-undefined (объект неопределен) | Набор данных не существует |
access-violation (ошибка доступа) | Access (доступ) | Object-access-denied (доступ отклонен) | Набор данных не может быть удален вследствие прав доступа или преднастройки |
Parameter-value-inappropriate (неподходящее значение-параметр) | Service (сервис) | Object-state-conflict (ошибка статуса объекта) | Набор данных не может быть удален, т.к. используется управляющим блоком |
MMS DataAccessError | |||
access-violation (ошибка доступа) | Object-access-denied (доступ отклонен) | Клиент не имеет прав к доступу или выполнять запрашиваемую операцию | |
Parameter-value-inappropriate (значение-параметр несовместимо) | Object-non-existing (объект не существует) | Указанный клиентом RCB не существует | |
lnstance-in-use | Temporarily-unavailable (временно недоступен) | RCB уже используется клиентом |
В.5.4 Extended Logging services (расширенные службы регистрации (протоколы))
В.5.4.1 Основное положение
В.5.4.1.1 Основное положение
Расширенные протоколы, указанные в ГОСТ Р 54418.25.3 (подраздел 9.9) описывают использование параметра для фильтрации входных записей, которые должны быть извлечены при их запросе (входных записей) клиентом с сервера. Этот параметр не указан в отображении MMS, описанного в [22] (пункт 17.3.4).
Как только запросы продлены, ответы включают те же поля. Если фильтр используется, то одной лишь разницей является количество откликов входных записей (в соответствии с форматом ответа).
В.5.4.1.2 QueryLogByTime отображение
Отображение сервиса QueryLogByTime должно быть определено в таблице В.9.
Таблица В.9 - QueryLogByTime отображение
IEM QueryLogByTime request | MMS ReadJournal-Request | ||
Parameter | Type | Parameter | MMS definition |
Log Reference | ObjectReference | journalName | ObjectName |
RangeStartTime | EntryTime | startingTime | TimeOfDay |
RangeStopTime | EntryTime | endidngTime | TimeOfDay |
DataFilter [1..n] | ObjectReferences | listOfVariables | Sequence of VisibleStrings |
В.5.4.1.3 QueryLogAfter отображение
Отображение сервиса QueryLogByTime определено в таблице В.10.
Таблица В.10 - QueryLogAfter отображение
IEM QueryLogAfter request | MMS ReadJournal-Request | ||
Parameter | Type | Parameter | MMS definition |
Log Reference | ObjectReference | journalName | ObjectName |
EntryToStartAfter | EntryTime | timeSpecfication | TimeOfDay |
Entry | EntrylD | entrySpecification | OCTET STRING |
DataFilter [1..n] | ObjectReferences | listOfVariables | Sequence of VisibleStrings |
В.6 Детали стека протоколов
В.6.1 Основное положение
Информационная модель ВЭС для связи клиент-сервер, определенная в ГОСТ Р 54418.25.2, должна использовать стек протоколов, определенных в В.6.2 и В.6.3.
В.6.2 A-Профиль
Сервисы и протоколы A-Профиля клиент/сервер должны быть, как показано в таблице В.11.
Таблица В.11 - Службы и протоколы для клиент/сервер А-Профиля
OSI model layer | Specification | m/o | ||
Name | Service specification | Protocol specification | ||
Application | Manufacturing Message Specification | [24] | [25] | m |
Association ControlService Element | [26] | [27] | m | |
Presentation | Connection Oriented | [28] | [29] | m |
Presentation | ||||
Abstract Syntax | ГОСТ P ИСО 8324 | ГОСТ P ИСО/МЭК 8825-1 | m | |
Session | Connection Oriented | ГОСТ P ИСО 8326 | [30] | m |
Session |
Реализация соглашения
Данный A-Профиль должен соответствовать соглашениям, указанным в [22] (пункт 6.2.2).
В.6.3 TCP/IP T-Профиль
Сервисы и протоколы TCP/IP Т-Профиля должны быть такими, как показано в таблице В.12.
Спецификации для уровня канала данных и физического уровня очень специфичны для реализации и выходят за рамки серии стандартов ГОСТ Р 54418.25.
Таблица В.12 - Службы и протоколы для клиент/сервер TCP/IP T-Профиль
OSI Model Layer | Specification | m/o | ||||
Name | Service specification | Protocol specification | ||||
Transport | ИСО Transport on top of TCP | [38] | m | |||
Internet Control Message Protocol (ICMP) | [11] | m | ||||
Transmission Control Protocol (TCP) | [12] | m | ||||
Network | Internet Protocol | [10] | m | |||
An Ethernet Address Resolution Protocol (ARP) | [13] | m | ||||
DataLink | Реализация специфична и выходит за рамки серии стандартов ГОСТ Р 54418.25 | - | ||||
Physical | - |
Реализация соглашения
TCP _KEEPALIVE
В соответствии с [12] должна быть реализована функция TCP _KEEPALIVE. Значение TCP KEEPALIVE должно быть конфигурируемо. Диапазон допустимых значений должен быть указан в декларации реализации PIXIT. Значения TCP должны быть указаны в секундах.
Примечание - Рекомендуется, чтобы минимальные-максимальные значения допустимого диапазона были не выше 20 с. Также рекомендуется, чтобы TCP_KEEPALIVE был конфигурируем минимум к 1 с. Это приводит к рекомендованному диапазону от 1 до 20.
Транспорт селектор:
Размер Транспорт Селектора должен быть максимум 4 октета.
Приложение Г
(обязательное)
Отображение специального сервиса связи
Г.1. Основные положения
Г.1.1. Введение к отображению ГОСТ Р МЭК 60870-5-104, указанного в [35]
В настоящем приложении описано использование [35] для отображения в ГОСТ Р 54418.25 классах Информационной Модели (IM) и сервисах Модели Обмена Информацией (IEM) в ГОСТ Р МЭК 60870-5-104.
Сервис моделей, определенных в ГОСТ Р 54418.25.3, отображается в ГОСТ Р МЭК 60870-5-104, как определено в [35]. На отображение, определенное в стандарте [35], ссылаются в данном приложении.
Данное приложение включает в себя следующие разделы:
- Г.1 - содержит общее введение отображения в ГОСТ Р МЭК 60870-5-104;
- Г.2 - содержит список нормативных ссылок для отображения в ГОСТ Р МЭК 60870-5-104;
- Г.3 - содержит список сокращенных терминов, используемых в настоящем приложении;
- Г.4 - содержит отображение Информационной Модели в ГОСТ Р МЭК 60870-5-104;
- Г.5 - содержит отображение Информационной Модели Данных в ГОСТ Р МЭК 60870-5-104;
- Г.6 - содержит отображение Модели Обмена Информацией в ГОСТ Р МЭК 60870-5-104 услугах;
- Г.7 - предоставляет детали стека протокола для ГОСТ Р МЭК 60870-5-104;
- Г.8 - предусматривает использование SCL (Язык Конфигурации Подстанции) расширение для включения ГОСТ Р МЭК 60870-5-104 информации (информационный пункт).
Г.1.2 Область применения отображения в ГОСТ Р МЭК 60870-5-104, представленного в [35]
Областью применения отображения, определенного в данном приложении, является использование ГОСТ Р МЭК 60870-5-104 для достижения процессов обмена информацией, необходимой для операций ВЭС.
Область применения [35] показывает принцип, как добиться реального времени процесса обмена информацией, необходимого для оперативных целей, между подстанцией или электростанцией, например ВЭС, использующие CDC в основе модели данных и центра(-ов) управления с помощью связи через a Wide Area Network (WAN), соответствующей определению ГОСТ Р МЭК 60870-5-101 / ГОСТ Р МЭК 60870-5-104. Массив информации реального времени обеспечивает устройства (IED), которые могут варьироваться в зависимости от оперативных потребностей. Исполнители могут быть региональные и национальные центры управления, которые получают в реальном времени информацию в целях мониторинга и контроля за процессами.
Отображения, описанные в настоящем приложении, основаны на определениях серии стандартов ГОСТ Р 54418.25 и ГОСТ Р МЭК 60870-5-104. Область применения отображения ГОСТ Р МЭК 60870-5-104 - совокупность указанных в Г.1.3.
Г.1.3 Отображение архитектуры
Отображение архитектуры состоит из трех частей:
1) отображение информационной модели;
2) сопоставление данных (часть информационной модели);
3) отображение службы обмена информацией.
Указанное отображение основано с помощью Common Adres of ASDU (CASDU) и Information Object Addres (IOA), чтобы привести в соответствие использованные модели LD и LN и передачи информации реального времени (данных) с использованием стандартизированных ASDUs. То же самое применяется для сервисов и функций Basic Application в ГОСТ Р МЭК 60870-5-104.
Информационная модель ВЭУ, определенная в ГОСТ Р 54418.25.2, должна отображаться иерархической структурой.
Концептуальное отображение показано на рисунке Г.1. Информационная модель ВЭС серии стандартов ГОСТ Р 54418.25 предназначена для сохранения когда сопоставляется с сервисом ГОСТ Р МЭК 60870-5-104.
Данное соответствие между основными объектами моделей ГОСТ Р 54418.25 и ГОСТ Р МЭК 60870-5-104 определяет, что:
- сервер и клиент реализуют определенную модель ВЭУ ГОСТ Р 54418.25 конфигурацией;
- конфигурация может быть сделана по-разному: или онлайновой конфигурацией или с дополнительным использованием Substation Configuration Language - файл SCL согласно Г.8;
- клиент получает доступ к иерархической информационной модели ВЭС ГОСТ Р 54418.25.2 через сервисы, предоставленные ГОСТ Р МЭК 60870-5-104, чтобы обмениваться данными реального времени.
Рисунок Г.1 - Архитектура отображения (концептуальная)
Службы обмена информации ВЭС, определенные в ГОСТ Р 54418.25.3 IEM, должны быть отображены в сервисах, перечисленных в таблице Г.1. Графа M/O указывает, определяется ли служба в ГОСТ Р 54418.25.3 как обязательная или дополнительная. "Y" обозначает "Да", служба поддерживается, тогда как "N" обозначает, что поддержки нет.
Таблица Г.1 - Сервисы, отображающие краткий обзор ГОСТ Р 54418.25 IM и IEM
ГОСТ Р 54418.25.2 IM Class | ГОСТ Р 54418.25.3 IEM Services | M/O | Вклю- | Maps to ГОСТ Р МЭК 60870-5 Services |
SERVER | Outstation (управляемая станция) | |||
GetServerDirectory | O | N | n.a. (добавляется дополнительно службами за пределами ГОСТ Р МЭК 60870-5-104) | |
ASSOCIATION | Connection | |||
Associate | M | Y | Establish; ГОСТ Р МЭК 60870-5-104, subclause 7.1 Station initialization | |
Abort | O | N | n.a.a | |
Release | O | Y | Close; ГОСТ Р МЭК 60870-5-104, subclause 7.1 | |
LOGICAL-DEVICE | CASDU | |||
GetLogicalDeviceDirectory | O | N | n.a. (добавляется дополнительно службами снаружи ГОСТ Р МЭК 60870-5-104). | |
LOGICAL-NODE | ||||
GetLogicalNodeDirectory | O | N | n.a. (добавляется дополнительно службами снаружи ГОСТ Р МЭК 60870-5-104) | |
DATA | ||||
GetDataValues | M | Y | Read command ASDU Tl <102> (Read процедура, определенная в ГОСТ Р МЭК 60870-5-104, subclause 7.4.14). | |
SetDataValues | M | Y | ASDU TI <111> "Параметр измеренного значения, масштабируемого значения" или ASDU Tl <112> "Параметр измеренного значения, короткого значения с плавающей точкой" опционально используется для установки атрибута db из CDCs MV и CMV (процедура загрузки параметра определяется в ГОСТ Р МЭК 60870-5-101, subclause 7.4.9) | |
GetDataDirectory | O | N | п.а. (добавляется дополнительно службами снаружи ГОСТ Р МЭК 60870-5-104) | |
GetDataDefinition | O | N | n.a. (добавляется дополнительно службами снаружи ГОСТ Р МЭК 60870-5-104) | |
DATA-SET | ||||
GetDataSetValues | M | N | ||
SetDataSetValues | O | N | ||
CreateDataSet | O | N | ||
DeleteDataSet | O | N | ||
GetDataSetDirectory | O | N | ||
REPORTING | ||||
AddSubscription | O | N | ||
RemoveSubscription | O | N | ||
Report | O | Y | Непосредственная передача с применяемым ASDUs | |
BRCB | ||||
GetBRCBValues | O | N | ||
SetBRCBValues | O | N | ||
URCB | ||||
GetURCBValues | O | N | ||
SetURCBValues | O | N | ||
LOG | ||||
GetLogStatusValues | O | N | ||
QueryLogByTime | O | N | ||
QueryLogAfter | O | N | ||
SetLCBValues | O | N | ||
CONTROL | ||||
Select | O | Y | ASDU TI <58, 59, 60, 62, 63> Select (S/E=0) | |
SelectWithValue | O | Y | ASDU TI <58, 59, 60, 62, 63> | |
Cancel | O | Y | ASDU TI <58, 59, 60, 62, 63> COT <8> deactivation | |
Operate | M | Y | ASDU TI <58, 59, 60, 62, 63> Execute (S/E=1) | |
CommandTermination | O | Y | ASDU TI <58, 59, 60, 62, 63> COT <10> ActTerm | |
TimeActivatedOperate | O | N | ||
Примечания Не применимо для отображения в ГОСТ Р МЭК 60870-5-104 ASDUs для непосредственной передачи: 30>,<31>,<32>,<33>,<35>,<36>,<37>,<39>,<40> как представлено в [15] (пункт 9.3.2). |
Г.2 Ссылки, характерные для отображения к ГОСТ Р МЭК 60870-5-104
ГОСТ Р МЭК 61850-5-2011 Сети и системы связи на подстанциях. Часть 5. Требования к связи для функций и моделей устройств
ГОСТ Р МЭК 60870-5-101-2006 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 101. Обобщающий стандарт по основным функциям телемеханики
ГОСТ Р МЭК 60870-5-104-2004 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей
ГОСТ Р МЭК 61850-7-1-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 1. Принципы и модели
ГОСТ Р МЭК 61850-7-2-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI)
ГОСТ Р МЭК 61850-7-3-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 3. Классы общих данных
При пользовании настоящим приложением дополнительную информацию можно получить из [35] и [36].
Г.3 Сокращения
Сокращения приведены в разделе 4 настоящего стандарта.
Г.4 Отображение ГОСТ Р 54418.25 Информационной Модели с ГОСТ Р МЭК 60870-5-104, как указано в [34]
Г.4.1 Основные положения
Отображение иерархической информационной модели WPP ГОСТ Р 54418.25.2 к ГОСТ Р МЭК 60870-5-104 протоколу, основывается на конфигурации, приведенной на рисунке Г.1. Сконфигурированные данные определяются как в Процесс Изображения (PI).
IM данные ГОСТ Р 54418.25.2 уникальны и определяются его однозначностью в иерархической модели ГОСТ Р 54418.25.2. Отображение ГОСТ Р МЭК 60870-5-104 должно поддержать уникальную схему нумерации единственных данных. Определение достигается назначением LD-уникального номера, определяющего CASDU. LNs присваиваются серии чисел адреса IOA.
Десятичный подход используется для определения LDs и LNs. Таблица Г.2 дает краткий обзор двух возможных схем адресации, отображения IM ГОСТ Р 54418.25 LDs и LNs с ГОСТ Р МЭК 60870-5-104. Рекомендуется использовать инструмент Разработки Данных, чтобы управлять использованием CASDU и чисел IOA, чтобы получить уникальную схему нумерации.
CDC отображается в ASDUs ГОСТ Р МЭК 60870-5-104. Для каждого отдельного данного будет уникальная комбинация адреса (CASDU и IOA) и в ASDU. Г.5.1.2 описывает отображение CDC проекта стандарта ГОСТ Р 54418.25.2 к основному CDC, унаследованного от ГОСТ Р МЭК 61850-7-3. Г5.1.3 описывает отображение основных CDC для ASDUs к используемому ГОСТ Р МЭК 60870-5-104.
Настоящее приложение касается отображения ГОСТ Р МЭК 60870-5-104. Стек протокола, который будет использоваться для этого отображения, описывается в Г.7.
Таблица Г.2 - Пример отображения LD и LN для CASDU и IAO
ГОСТ Р 54418.25 | ГОСТ Р МЭК 60870-5-104 | Комментарии | |||
LD | LN | CASDU | IAO from | IAO to | |
WPP | X | LN согласно операционной потребности | |||
WTG1 | X+1 | LN согласно операционной потребности | |||
WTGn | X+n | LN согласно операционной потребности | |||
WALM | X+1 | 10000 | 19999 | Альтернатива А: Эта альтернатива использует определенную схему нумерации а для того, чтобы присвоить LD и LN числа LD присвоенное uniqueCASDU число в пределах системы. Класс LN использует диапазон адресов IOA. Диапазон может влиять на число данных размещенных LN. Если число данных мало, а число 1000-и адресов может быть использовано для LN. Уникальные адреса для данных получаются определенным числом CASDU для LD и адреса IOA. | |
WMET | 20000 | 29999 | |||
WAPC | 30000 | 39999 | |||
WRPC | 40000 | 49999 | |||
WTUR | 100000 | 109999 | |||
WROT | 110000 | 119999 | |||
WTRM | 120000 | 129999 | |||
WGEN | 130000 | 139999 | |||
WCNV | 140000 | 149999 | |||
WTRF | 150000 | 159999 | |||
WNAC | 160000 | 169999 | |||
WYAW | 170000 | 179999 | |||
WTOW | 180000 | 189999 | |||
WALM | 190000 | 199999 | |||
WSLG | 200000 | 209999 | |||
WALG | 210000 | 219999 | |||
WREP | 220000 | 229999 | |||
WALM | X | Альтернатива Б: Для этой альтернативы у всех LDs в области, определенной как ветропарк, есть то же самое число CASDU. Определение класса LN числа IOA, свободно определенные поставщиком или адаптером к схеме нумерации, используемой утилитой. | |||
WMET | |||||
WAPC | |||||
WRPC | |||||
WTUR | |||||
WROT | |||||
WTRM | |||||
WGEN | |||||
WCNV | |||||
WTRF | |||||
WNAC | |||||
WYAW | |||||
WTOW | |||||
WALM | |||||
WSLG | |||||
WALG | |||||
WREP |
Г.4.2 Отображение класса Логического Устройства IM
Класс Логического устройства должен быть привязан к Common Adres ASOU (CASOU) в соответствии с таблицей Г.3.
Таблица Г.3 - Отображение Логического устройства
ГОСТ Р 54418.25.2 IM class | Maps to |
Logical Device, e.g. WPP or WTs | CASDU |
Logical Device - LD | One number is assigned for each LD |
Примечание - CASDU может быть структурирован или неструктурирован. Например, CASDU может идентифицировать ID Станции и ЛОГИЧЕСКИЙ ID Экземпляра Устройства. Рекомендуется сделать схему адресации, чтобы иметь уникальный адрес для определенной станции. Например, для маленьких станций, один CASDU может быть присвоен для станции, у всего LD тогда будет тот же самый CASDU. Для большой станции могут использоваться несколько CASDUs, чтобы идентифицировать каждый LD. Полное максимальное количество CASDUs для одной ссылки 65534.
Г.4.3 Отображение класса Логического Узла IM
Каждый класс логического узла должен быть отображен на определенный диапазон чисел согласно таблице Г.4. Пример схемы для того, чтобы пронумеровать каждое данное представлен в таблице Г.2
Таблица Г.4 - Отображение Логического узла
ГОСТ Р 54418.25.2 IM class | Maps to |
Logical Node | IOA address |
Logical Node - LN | A serie of IOA addresses shall be assigned to each LN class |
Примечание - Все атрибуты класса LN неявно определяются и видимы. IOA может быть структурирован или неструктурирован. Для обоих случаев рекомендуется десятичный подход для того, чтобы определить адреса IOA. Полное максимальное количество адресов IOA на CASDU на одной ссылке - 65536.
Г.5 Отображение ГОСТ Р 54418.25 Информационной Модели данных с ГОСТ Р МЭК 60870-5-104
Г.5.1 Отображение Классов Общих Данных (Common Data Classes - CDC)
Г.5.1.1 Основные положения
Каждый Класс Общих данных (CDC) состоит из одного или более атрибутов данных определенного типа данных. Каждый атрибут данных и тип данных должны быть отображены на один определенный IOA (как в Г.4.3) и один определенный ASDU.
Отображение, показанное в таблицах Г.5 и Г12, нужно считать как отображение значения по умолчанию - тщательно выбранным из множества отображающихся возможностей.
Примечание - Требования для отображения LD, LN на CASDU и IOA могут изменяться по различным областям применения. Самый подходящий способ отображения должен быть определен на утилите или основании проекта в зависимости от определенных потребностей. CASDU и IOA в ГОСТ Р МЭК 60870-5-101 / ГОСТ Р МЭК 60870-5-104 являются только числами, которые должны быть уникальными в пределах одной утилиты/проекта.
Отображение Классов Общих данных разделено на следующие разделы:
- отображение CDC, определенных в Информационной Модели ГОСТ Р 54418.25.2;
- отображение основных CDC, унаследованных от ГОСТ Р МЭК 61850-7-3;
- отображение комплекса CDC, унаследованных от ГОСТ Р МЭК 61850-7-3.
Г.5.1.2 Отображение Классов Общих Данных (CDC), определенных в Информационной Модели ГОСТ Р 54418.25
Г.5.1.2.1 Основное положение
Отображение классов общих данных, определенных в информационной модели ГОСТ Р 54418.25.2, основано на простом CDCs, унаследованном от ГОСТ Р МЭК 61850-7-3, представленных в таблице Г.5.
Таблица Г.5 - CDC определенные в ГОСТ Р 54418.25.2
CDC (Attribute data types) | CDC Inhered from ГОСТ P МЭК 61850-7-3 |
STV Status value | Отображенный через |
SPV Setpoint value | Отображенный через |
ALM Alarm | Отображенный через |
CMD Command | Отображенный через CDC INC Controllable integer status |
CTE Event Counting | Отображенный через CDC INS Integer status for data component ActCtVal CDC |
TMS State timing | Отображенный через CDC SPC Controllable single point for data component manRs CDC INS Integer status for data component actTmVal and for data component oldTmVal |
ASS Alarm Set Status | He поддерживается |
Г.5.1.2.2 Отображение Значения Статуса CDC и класса STV
Обязательные Данные класса общих данных STV изображаются в таблице Г.6.
Таблица Г.6 - CDC: Значение Статуса, STV класс
STV Класс | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Объяснение и Значение/Диапазон | M/O/C |
DataName | Inherited from Data Class (see ГОСТ Р МЭК 61850-7-2) | ||||
Data | |||||
Информация статуса | |||||
actSt | INS | Фактическое состояние | M |
Данные [actSt] INS должны быть отображены, как представлено в [35] (подраздел 7.4).
Г.5.1.2.3 Отображение CDC Заданное Значение, SPV класса
Обязательные Данные класса общих данных SPV представлены в таблице Г.7.
Таблица Г.7 - CDC: Заданное Значение, SPV класс
STV Класс | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Значение/Диапазон значений | M/O/C |
DataName | Inherited from Data Class (см. ГОСТ P МЭК 61850-7-2) | ||||
Data | |||||
Информация о статусе и управлении | |||||
actVal | АРС | Требования значений сета или параметра | M |
Данные [actVal] - АРС. Должны быть отображены, как представлено в Г.5.1.3.2.
Г.5.1.2.4 Отображение CDC Сигнализации, ALM класса
Обязательные Данные ALM класса общих данных представлены в таблице Г.8.
Таблица Г.8 - CDC: Сигнализация, ALM класс
ALM class | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Объяснение и Значение/Диапазон | M/O/C |
DataName | Inherited from Data Class (см. ГОСТ P МЭК 61850-7-2) | ||||
Data | |||||
Control and status information | |||||
actSt | INS | Значение аварийного состояния | M | ||
almAck | SPC | Acknowledgement | M |
Данные [actSt] INS. Должны быть отображены, как представлено в [35] (подраздел 7.4).
Данные [almAck] SPC. Должны быть отображены, как представлено в [35] (подраздел 7.17).
Г.5.1.2.5 Отображение команды CDC, класса CMD
Обязательные Данные CMD класса общих данных представлены в таблице Г.9.
Таблица Г.9 - CDC: Команда , CMD класс
ALM class | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Объяснение и Значение/Диапазон | M/O/C |
DataName | Inherited from Data Class (см. ГОСТ P МЭК 61850-7-2) | ||||
Data | |||||
Control and status information | |||||
actSt | INC | Фактическое состояние управления | M |
Данные [actSt] INC. Должны быть отображены, как представлено в [35] (подраздел 7.19).
Г.5.1.2.6 Отображение CDC Подсчета Событий, СТЕ класса
Обязательные Данные класса общих данных СТЕ представлены в таблице Г.10.
Таблица Г.10 - CDC: Счет событий, СТЕ класс
ALM class | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Объяснение и Значение/Диапазон | M/O/C |
DataName | Inherited from Data Class (см. ГОСТ P МЭК 61850-7-2) | ||||
Data | |||||
Control and status information | |||||
actCtVal | INS | Количество фактического события | M | ||
manRs | SPC | Руководство вызова перезагрузки | M |
Данные [actCtVal] INS и должны быть отображены как представлено в [35] (подраздел 7.4). Данные [manRs] SPC. Они должны быть отображены, как представлено в [35] (подраздел 7.17).
Г.5.1.2.7 Отображение Синхронизация структуры CDC, класса TMS
Обязательные Данные TMS класса общих данных представлены в таблице Г.11.
Таблица Г.11 - CDC: Синхронизация структуры CDC, класс TMS
ALM class | |||||
Имя атрибута | Тип атрибута | FC | TrgOp | Объяснение и Значение/Диапазон | M/O/C |
DataName | Inherited from Data Class (см. ГОСТ P МЭК 61850-7-2) | ||||
Data | |||||
Control and status information | |||||
manRs | SPC | Руководство вызова перезагрузки | M | ||
actTmVal | INS | Фактическая продолжительность времени состояния | M | ||
oldTmVal | INS | Продолжительность состояния в предыдущий раз | M |
Данные [manRs] являются SPC и должны быть отображены как SPC CDC, как представлено в [35] (подраздел 7.17). Данные [actTmVal] являются INS и должны быть отображены как INS CDC, как представлено в [35] (подраздел 7.4).
Данные [oldTmVal] являются INS и должны быть отображены как INS, как представлено в [35] (подраздел 7.4).
Г.5.1.2.8 CDC Отображение Состояние Набора Аварийного сигнала CDC, класса ASS
Это отображение не поддерживает этот класс общих данных. Состояние аварийных сигналов должно быть получено, получая доступ к различным аварийным сигналам, которые создают информационную модель.
Г.5.1.3 Отображение основных CDC, унаследованное от ГОСТ Р МЭК 61850-7-3
Г.5.1.3.1 Основное положение
Каждый Класс Общих данных состоит из данных и связанных атрибутов. Таблица Г.12 определяет отношение между CDC и связанным ASDUs, который будет использоваться для того, чтобы отображаться на ГОСТ Р МЭК 60870-5-104.
Таблица Г.12 - Отображение структуры основных CDC
CDCs defined in ГОСТ Р МЭК 61850-7-3 | Mapping details defined in: | |
CDC (Attribute data types) | ASDU type | |
SPS Single point status | monitor direction (status): Tl<30> as event Tl<1> as part of Gl | [35] (подраздел 7.2) |
DPS Double point status | monitor direction (status): Tl<31> as event TI<3> as part of Gl | [35] (подраздел 7.3) |
INS Integer status | monitor direction (status): Tl<35> or TI<33> as event Tl<11> or TI<7> as part of Gl | [35] (подраздел 7.4) |
BCR Binary counter reading | monitor direction (status): Tl<37> as event Tl<15> as part of CI | [35] (подраздел 7.8) |
SPC Controlable Single Point | monitor direction (status): | [35] (подраздел 7.17) |
DPC Controllable Double Point | monitor direction (status): | [35] (подраздел 7.18) |
INC Controllable Integer status | monitor direction (status): | [35] (подраздел 7.19) |
APC Controllable analogue set point information | monitor direction (status): | Г5.1.3.2 |
MV Measured value | monitor direction (status): Tl<36> as event TI<13>as part of GI | [35] (подраздел 7.9) |
Примечание - DPS и DPC не используются в ГОСТ Р 54418.25.2, но определяются так, как они могут быть использованы в расширениях модели. TI := Тип идентификатора GI := Общий Опрос или опрос станции ASDU TI <100> CI := Встречный опрос ASDU TI <101> |
Примечание - Показанные отображения включают в себя метку времени и применимы для наблюденной информации, если она отправлена как событие. Если информация отправляется как часть GI (Общий опрос Опроса/Станции) или CI (Встречный Опрос), то полное отображение применимо кроме метки времени. Весь GI, данные CI отправляются, исключая метку времени.
DataAttributes классов общих данных, изображенных в таблице Г.12 и должны быть отображены как определено в [35] (раздел 7).
Классы Общих данных WDPL и LPL настоящего стандарта не могут быть отображены в ASDUs ГОСТ Р МЭК 60870-5-104.
CDC, используемые для управления электростанции, используют различные модели управления, как определено в ГОСТ Р МЭК 61850-7-2. Та же самая модель управления должна быть сконфигурирована в сервере и клиенте. Рекомендуется выбрать модель управления, которая дает достаточную безопасность для управляемого объекта.
Г.5.1.3.2 Отображение CDC Управляемое Аналоговое значение процесса, класса АРС
DataAttributes АРС класса общих данных, представленные в таблице Г.13, должны быть отображены как показано в таблицах Г.14 (для атрибутов с Функциональным Ограничителем MX) и Г.15 (для атрибутов с Functional Constraint СО).
Таблица Г.13 - CDC: Управляемое Аналоговое значение процесса, АРС класс
АРС class | ||||||
Имя атрибута | Тип атрибута | FC | TrgOp | Значение/Диапазон значений | M/O/C | |
DataName | Inherited from Data Class (см. ГОСТ Р МЭК 61850-7-2) | |||||
DataAttribute | ||||||
setpoint and measured attributes | ||||||
ctlVal | AnalogueValue | CO | M | |||
origin | Originator | CO, MX | O | |||
mxVal | AnalogueValue | MX | dchg | M | ||
q | Quality | MX | qchg | M | ||
t | TimeStamp | MX | M | |||
Configuration, describtion and extention | ||||||
ctlModel | ctlModels | CF | M |
Таблица Г.14 определяет отображение для атрибутов данных АРС с Функциональным Ограничителем MX. Атрибуты данных [mxVal + t + q] должны отображаться на ГОСТ Р МЭК 60870-5-104 Tl ASDU <36> "Измеренное значение, короткое значение с плавающей точкой с дескриптором времени CP56Time2a".
Таблица Г.15 определяет отображение для атрибутов данных АРС с Functional Constraint СО. Атрибут данных [ctlVal + источник] или [ctlVal + источник + Т] должны отображаться на ГОСТ Р МЭК 60870-5-104 Tl ASDU <63> "Команда заданного значения, короткое значение с плавающей точкой с дескриптором времени CP56Time2a".
Примечание - Атрибуты Т и ctrlModel определены в ГОСТ Р МЭК 61850-7-2 (раздел 17).
Таблица Г.14 - CDC: Управляемая аналоговая информация о заданном значении (APC), отображение атрибутов данных Функционального Ограничителя MX
CDC класс | ГОСТ Р МЭК 60870-5-101 / ГОСТ Р МЭК 60870-5-104 отображение | |||
APC | Tl <36> | |||
Имя атрибута | Тип атрибута | DAComponent | Информационный элемент | ГОСТ Р МЭК 60870-5-101 / ГОСТ Р МЭК 60870-5-104 Object Group Mapping |
mxVal | AnalogueValue | mxVal.f FLOAT32 | IEEE STD 754 | R32.23{Fraction,Exponent,Sign} |
t | TimeStamp | CP56Time2a | Seven octet binary time, CP562a - Time of occurrence of dchg or qchg | |
q | Quality | QDS | validity -> IV |
Таблица Г.15 - CDC: Управляемое Аналоговое заданное значение, отображение класса APC данных и приписанный Functional Constrant CO
CDC класс | ГОСТ Р МЭК 60870-5-104 отображение | |||
APC | Tl <63> (with time tag) | |||
Имя атрибута | Тип атрибута | DAComponent | Информационный элемент | ГОСТ Р МЭК 60870-5-104 отображение групп элементов |
ctlVal | AnalogueValue | ctlVal.f | IEEE STD 754 | R32.23{Fraction, Exponent, Sign} |
origin. orldent | OCTET STRING64 | FLOAT32 | COT | Originator Address := U18[9..16] <0..255> |
origin. orCat | ENUMERA TED | COT | Cause :=Ш6[1..6]<0..63> |
Г.5.1.4 Отображение сложных Классов Общих данных, унаследованных от ГОСТ Р МЭК 61850-7-3
Г.5.1.4.1 Основное положение
Таблица Г.16 определяет отношение между сложным CDCs, унаследованным от ГОСТ Р МЭК 61850-7-3 и связанным ASDUs, который будет использоваться для того, чтобы отображаться в ГОСТ Р МЭК 60870-5-104.
Таблица Г.16 - Отношение между сложным CDCs и ГОСТ Р МЭК 60870-5-104 ASDUs
CDC унаследованным от ГОСТ Р МЭК 61850-7-3 (Тип атрибута данных) | ГОСТ Р МЭК 60870-5-104 Отображение | Отображение деталей, определенных в |
CMV - Complex Measured Value Value | Отображенный как ряд классов общих данных CMV. | [15] (подраздел 7.10) |
WYE - Three Phase Value | Отображенный как ряд классов общих данных CMV. | [15] (подраздел 7.11) |
DEL - Three Phase Value | Отображенный как ряд классов общих данных CMV. | [15] (подраздел 7.12) |
DataAttributes комплекса общих классов данных, описанных в таблице Г.16, должны быть отображены, как определено в [35] (раздел 7).
Г.6 Отображение Модели Обмена информацией к сервису ГОСТ Р МЭК 60870-5-104
Г.6.1 Список моделей сервиса и соответствующих отображений
Услуги моделей, определенных в ACSI (см. ГОСТ Р МЭК 61850-7-2), и сопоставление с ГОСТ Р МЭК 60870-5-104 / ГОСТ Р МЭК 60870-5-101 приводится в таблице Г.17. Отображение услуг определяется в соответствии с [35] (раздел 8).
Таблица Г.17 - Отображение сервиса ГОСТ Р 54418.25 ACSI в сервисе ГОСТ Р МЭК 60870-5-104
ГОСТ Р МЭК 61850-7-2 Сервис | Отображение к | Определено в | |
Server | Outstation (controlled station) | ||
GetServerDirectory | n.a. (должны быть добавлены при необходимости со службами за пределами ГОСТ Р МЭК 60870-5-104 и ГОСТ Р МЭК 60870-5-101 | [35] (подраздел 8.2) | |
Association | Connection | ||
Associate | Establish; ГОСТ Р МЭК 60870-5-104 (подраздел 7.1) | [35] (подраздел 8.3) | |
Abort | n.a. | ||
Release | Close; ГОСТ Р МЭК 60870-5-104 (подраздел 7.1) | ||
Logical Device | CASDU | ||
GetLogicalDeviceDirectory | n.a. (быть добавленным дополнительно со службами за пределами ГОСТ Р МЭК 60870-5-104) | ||
Logical Node | Один или несколько из IOA(s) | ||
GetLogicalNodeDirectory | n.a. (быть добавленным дополнительно со службами за пределами ГОСТ Р МЭК 60870-5-104) | [35] (подраздел 8.4) | |
GetAIIDataValues | Interrogation command TI <100> | ||
Data | Один или несколько из ASDU(s) | ||
GetDataValues | Read command ASDU TI <102> | [35] (подраздел 8.5) | |
SetDataValues | ASDU TI <111> "Параметр измеренного значения, масштабируемого значения" или ASDU TI <112> "Параметр измеренного значения, короткого значения с плавающей точкой" опционально используемый, чтобы установить db атрибута MV CDCs и CMV (процедура загрузки параметра определяется в ГОСТ Р МЭК 60870-5-101 (пункт 7.4.9) | ||
GetDataDirectory | n.a. (быть добавленным дополнительно со службы за пределами ГОСТ Р МЭК 60870-5-104) | ||
GetDataDefinition | n.a. (быть добавленным дополнительно со службы за пределами ГОСТ Р МЭК 60870-5-104) | ||
Data Set | n.a. | ||
GetDataSetValues | n.a. | ||
SetDataSetValues | n.a. | ||
CreateDataSet | n.a. | ||
DeleteDataSet | n.a. | ||
GetDataSetDirectory | n.a. | ||
Setting Group Control Block | |||
SelectActiveSG | Single command ASDU Tl<58> | [35] (подраздел 8.6) | |
SelectEditSG | n.a. | ||
SetSGValues | n.a. | ||
ConfirmEditSGValues | n.a. | ||
GetSGValues | n.a. | ||
GetSGCBValues | n.a. | ||
Report Control Block | |||
Report | Самопроизвольная передача с применимым ASDUs | [35] (подраздел 8.7) | |
GetBRCBValues | n.a. | ||
SetBRCBValues | n.a. | ||
GetURCBValues | n.a. | ||
SetURCBValues | n.a. | ||
LOG Control Block | n.a. | ||
GetLCBValues | n.a. | ||
SetLCBValues | n.a. | ||
LOG | n.a. | ||
GetLogStatusValues | n.a. | ||
QueryLogByTime | n.a. | ||
QueryLogAfter | n.a. | ||
Control | Управляемый информационный объект | ||
Select | n.a. | [35] (подраздел 8.8) | |
SelectWithValue | ASDU Tl <58,59,60,62,63> | ||
Cancel | ASDU Tl <58,59,60,62,63> | ||
Operate | ASDU Tl <58,59,60,62,63> | ||
CommandTermination | ASDU Tl <58,59,60,62,63> | ||
TimeActivatedOperate | n.a. | ||
He применимый для отображения на ГОСТ Р МЭК 60870-5-101. ASDUs для самопроизвольной передачи: <30>, <31>, <32>, <33>, <35>, <36>, <37>, <39>, <40> как выбрано в Разделе Г.7. Эти сервисы описаны в ГОСТ Р МЭК 61850-7-2. |
Г.6.2 Отображение класса Контроля
Г.6.2.1 Основное положение
Только два случая от модели класса УПРАВЛЕНИЯ в ГОСТ Р 54478.25.3* (определено в ГОСТ Р МЭК 61850-7-2) могут быть отображены на передачу команды "Basic application functions" (определено в ГОСТ Р МЭК 870-5-5), используемый в ГОСТ Р МЭК 60870-5-104 почти незаметно для пользователя:
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р 54418.25.3. - .
- случай 3: Прямое управление с улучшенной безопасностью (описанное в Г.6.2.3), которое отображается на функциональную "прямую команду", определенную в ГОСТ Р МЭК 870-5-5 (подраздел 6.8);
- случай 4: SBO контролер с улучшенной безопасностью (описанный в Г.6.2.4), который отображается на функцию, "выбор и выполнение команды", определенную в ГОСТ Р МЭК 870-5-5 (подраздел 6.8).
Чтобы использовать lEDs в существующих установках, которые используют "Прямое управление с нормальной безопасностью" отображения класса УПРАВЛЕНИЯ, и избегать изменения установок, параметров для класса управления в этих lEDs, дополнительное отображение определяется следующим образом:
- случай 1: Прямое управление с нормальной безопасностью (описанное в D.6.2.2), которое отображается на функциональную "прямую команду", определенную в ГОСТ Р МЭК 870-5-5 (подраздел 6.8).
Примечание - Не у всех ASDUs необходимый для функциональной "прямой команды" ГОСТ Р МЭК 870-5-5 есть соответствующее ГОСТ Р МЭК 61850 сообщение, что означает, что в некоторых случаях два ASDUs должны быть сгенерированы в результате одного сообщения в соответствии с ГОСТ Р МЭК 61850 (никакое непосредственное отображение сообщений невозможно).
Для случая 3 "SBO с нормальной безопасностью" Модель управления соответствующего отображения на основную прикладную функцию "передача команды" ГОСТ Р МЭК 870-5-5 возможна.
Функции для отображения Модели управления показываются в схемах устройством независимой функции, вызванной "отображатель Ctrl" как пример.
Эта функция должна использоваться, когда отображение будет дополнительно сделано в устройстве шлюза, которое связывается с IED, который взаимодействует с устройством, которым управляют. Последовательность и синхронизация служб, как показано в схемах, должны быть непротиворечивыми независимо от того, реализуется ли модель управления в единственном IED, или если шлюз используется.
Схемы также показывают примеры в последовательности взаимодействий с устройством, которым управляют. Рассмотрение интерфейса устройства, которым управляют, находится вне контекста этого стандарта, но пример включается, чтобы показать полную ссылку от служб управления ГОСТ Р 54418.25.3 к управлению физического устройства.
Модель управления реализуется в сервере, и та же самая модель управления должна быть реализована на стороне клиента. Сервер ответственен за принятие мер, чтобы предотвратить неправильное функционирование, в случае, если есть несоответствие между моделью управления, выполняемой клиентом, и моделью управления, выполняемой сервером.
Г.6.2.2 Прямое Управление с Нормальной Безопасностью (дополнительной)
Г.6.2.2.1 Основное положение
Прямое Управление с Нормальными Службами безопасности должно быть отображено, как определено в [35] (пункт 8.8.2).
Г.6.2.2.2 Прямое Управление с Нормальной Безопасностью с корректировкой данных - положительный случай
Рисунок Г.2 показывает положительный случай для модели контроля Прямого Управления с Нормальной Безопасностью и корректировкой данных.
Рисунок Г.2 - Прямое Управление с Нормальной Безопасностью с корректировкой данных - положительный случай
Г.6.2.2.3 Прямое Управление с общей Нормальной Безопасностью - отрицательный случай a) no Oper_resp from server/IED
Рисунок Г.3 показывает отрицательный случай а) без Oper_resp из server/IED для модели контроля Прямого Управления с Нормальной Безопасностью.
Рисунок Г.3 - Прямое Управление с общей Нормальной Безопасностью - отрицательный случай а)
Г.6.2.2.4 Прямое Управление с общей Нормальной Безопасностью - отрицательный случай б) negative Oper_resp from server/IED (отрицательный оперативный ответ от сервера)
Рисунок Г.4 показывает отрицательный случай б) negative Oper_resp from server/IED модели контроля Прямого Управления с Нормальной Безопасностью.
Рисунок Г.4 - Прямое Управление с общей Нормальной Безопасностью - отрицательный случай б)
Г.6.2.2.5 Прямое Управление с общей Нормальной Безопасностью с обновлением состояния - отрицательный случай в) no status update detected (не зафиксировано обновления состояния)
Рисунок Г.5 показывает отрицательный случай в) no status update detected для модели контроля Прямого Управления с общей Нормальной Безопасностью с обновлением состояния.
Рисунок Г.5 - Прямое Управление с общей Нормальной Безопасностью с обновлением состояния - отрицательный случай в)
Г.6.2.2.6 Прямое Управление с общей Нормальной Безопасностью без обновления состояния - положительный случай
Рисунок Г.6 показывает положительный случай для модели контроля Прямого Управления с общей Нормальной Безопасностью без обновления состояния.
Рисунок Г.6 - Прямое Управление с общей Нормальной Безопасностью без обновления состояния - положительный случай
Г.6.2.3 Прямое Управление с Улучшенной Безопасностью
Г.6.2.3.1 Общие положения
Сервисы Прямого Управления с Улучшенной Безопасностью следует отображать как определено в [35] (пункт 8.8.3).
Г.6.2.3.2 Прямое Управление с Улучшенной Безопасностью - положительный случай
Рисунок Г.7 показывает положительный случай для модели контроля Прямого Управления с Улучшенной Безопасностью.
Рисунок Г.7 - Прямое Управление с Улучшенной Безопасностью - положительный случай
Г.6.2.3.3 Прямое Управление с Улучшенной Безопасностью - отрицательный случай a) no Oper_resp from server/IED
Модель контроля соответствует Прямому Управлению с Улучшенной Безопасностью - отрицательный случай а) см. схему на рисунке Г.3.
Г.6.2.3.4 Прямое Управление с Улучшенной Безопасностью - отрицательный случай б) negative Oper_resp from server/IED
Модель контроля соответствует Прямому Управлению с Улучшенной Безопасностью - отрицательный случай б). Смотри схему на рисунке Г.4.
Г.6.2.3.5 Прямое Управление с Улучшенной Безопасностью - отрицательный случай в) no status change detected by server/IED
Рисунок Г.8 показывает отрицательный случай в) отсутствие изменения статуса, обнаруженное сервером/IED для модели контроля Прямого Управления с Улучшенной Безопасностью.
Рисунок Г.8 - Прямое Управление с Улучшенной Безопасностью - отрицательный случай в)
Г.6.2.3.6 Прямое Управление с Улучшенной Безопасностью - отрицательный случай г) no CMDTerm_req from server/IED
Рисунок Г.9 показывает отрицательный случай г) no CMDTerm_req from server/IED для модели контроля Прямого Управления с Улучшенной Безопасностью.
Рисунок Г.9 - Прямое Управление с Улучшенной Безопасностью - отрицательный случай г)
Г.6.2.4 SBO-Управление с Улучшенной Безопасностью
Г.6.2.4.1 Основное положение
Сервисы SBO-Управления с Улучшенной Безопасностью следует отображать, как определено в [35] (пункт 8.8.4).
Г.6.2.4.2 SBO-Управление - положительный случай
Рисунок Г.10 показывает положительный случай для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.10 - SBO-Управление - положительный случай
Г.6.2.4.3 SBO-Управление - отрицательный случай a) no _rsp from server/IED
Рисунок Г.11 показывает отрицательный случай a) no_rsp from server/IED (нет ответа от сервера) для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.11 - SBO-Управление - отрицательный случай а)
Г.6.2.4.4 SBO-Управление - отрицательный случай б) negative_rsp from server/IED (отрицательный ответ от сервера)
Рисунок Г.12 показывает отрицательный случай б) negative_rsp from server/IED (отрицательный ответ от сервера) для модели контроля SBO-Управления и обеспечения безопасности.
Рисунок Г.12 - SBO-Управление - отрицательный случай б)
Г.6.2.4.5 SBO-Управление - отрицательный случай в) second select of same object (повторный выбор того же объекта)
Рисунок Г.13 показывает отрицательный случай в) second select of same object (повторный выбор того же объекта) для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.13 - SBO-Управление - отрицательный случай в)
Г.6.2.4.6 SBO-Управление с Улучшенной Безопасностью - положительный случай
Рисунок Г.14 показывает положительный случай для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.14 - SBO-Управление с Улучшенной Безопасностью - положительный случай
Г.6.2.4.7 SBO-Управление с Улучшенной Безопасностью - отрицательный случай a) no status change detected by server/IED (нет изменения статуса, зафиксированного сервером)
Рисунок Г.15 показывает отрицательный случай a) no status change detected by server/IED для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.15 - SBO-Управление с Улучшенной Безопасностью - отрицательный случай а)
Г.6.2.4.8 SBO-Управление с Улучшенной Безопасностью - отрицательный случай б) no CmdTerm_req from server/IED
Рисунок Г.16 показывает отрицательный случай б) no CmdTerm_req from server/IED для модели контроля SBO-Управления с Улучшенной Безопасностью.
Рисунок Г.16 - SBO-Управление с Улучшенной Безопасностью - отрицательный случай б)
Г.7 Выбор стека протоколов для ГОСТ Р МЭК 60870-5-104 (Детализация стека протоколов)
Г.7.1 Основные положения
Отображение в ГОСТ Р МЭК 60870-5-104 реализуется для прикладных данных (ASDUs) и сервисов (Базовые Прикладные Функции) в соответствии с [35] (раздел 9).
Г.7.2 Структура прикладных данных
Структура прикладных данных большей частью определена в [15] (подраздел 9.2), а также структура прикладных данных, указанная в ГОСТ Р МЭК 60850-5-104*, определена в [35] (пункт 9.2.3).
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р МЭК 60870-5-104. - .
Г.7.3 Способность к взаимодействию ГОСТ Р МЭК 60870-5-104
Отображение в ГОСТ Р МЭК 60870-5-104 производится для прикладных данных (ASDUs) и сервисов (Базовые Прикладные Функции) в зависимости от отмеченных флажками объектов в таблице Взаимосовместимости в [35] (пункт 9.3.2). Это подгруппа ГОСТ Р МЭК 60850-5-104*.
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р МЭК 60870-5-104. - .
Г.8 Использование SCL (язык описания конфигурации системы) расширения для включения ГОСТ Р МЭК 60850-5-101*/ГОСТ Р МЭК 60850-5-104 *информации (информативная секция)
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р МЭК 60870-5-101, ГОСТ Р МЭК 60870-5-104. - .
Г.8.1 Основные положения
Настоящее приложение фокусируется на отображении моделей ВЭС, определенных в серии стандартов ГОСТ Р 54418.25 и ГОСТ Р МЭК 60870-5-104. [35] использует SCL файл, который отвечает не только за отображение, определенное в настоящем приложении, но и за широкий массив моделей, базирующихся на ГОСТ Р МЭК 61850. Выбранные части [35] могут использоваться для ВЭС.
Г.8.2 Иерархия информационной модели SCL
Файл SCL включает в себя пять элементов высшего уровня: Header, Substation, Communication, IED и DataTypeTemplates. Признаки, связанные с ГОСТ Р МЭК 60850-5-101*/ ГОСТ Р МЭК 60850-5-104*, включены главным образом в секции IED, но также и части DataTypeTemplates для того, чтобы уменьшить потребность назначать идентификатор типа на все элементы DAI информационной модели. Детально атрибуты описаны в [35] (А.2 (приложение А)).
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р МЭК 60870-5-101, ГОСТ Р МЭК 60870-5-104. - .
Г.8.3 Синтаксис Внутренних секций ГОСТ Р МЭК 60850-5-101*/ГОСТ Р МЭК 60850-5-104 *
Внутренние секции для того чтобы описать содержание могут включать в себя два атрибута, называемые "источником" и "типом". Использование Внутренних секций для описания информации ГОСТ Р МЭК 60850-5-101*/ГОСТ Р МЭК 60850-5-104* должно применять атрибут "тип" со значением "МЭК_60870_5_101" или "МЭК_60870_5_104". Содержание Внутренней секции описано в привязанной схеме. Схема Внутренних секций ГОСТ Р МЭК 60870-5-104 описана в [35] (А.4.2 и А.4.3 (приложение А)).
________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р МЭК 60870-5-101, ГОСТ Р МЭК 60870-5-104. - .
Г.8.4 ГОСТ Р МЭК 60870-5-104 коммуникационные параметры конфигурации использования SCL
Коммуникационный раздел файла SCL может быть использован для того, чтобы получать от ГОСТ Р МЭК 60870-5-104 определенную информацию о задержках, адресах и коммуникационных портах. Подробное содержание описано в [35] (А.6 (приложение А)).
Приложение Д
(обязательное)
Специальный коммуникационный сервис отображения - Отображение в DNP3
Д.1 Основные положения
Д.1.1 Введение в отображение в DNP3
Настоящее приложение показывает принцип отображения информационной модели и информационно-обменной модели, определенных в стандартах ГОСТ Р 54418.25.2 и ГОСТ Р 54418.25.3 в DNP3.
Д.1 содержит общее введение в отображение в DNP3.
Д.2 содержит список нормативных ссылок для отображения в DNP3.
Д.3 содержит список условных обозначений, используемых в приложении Е.
Д.4 содержит описание отображения информационной модели сервисам DNP3.
Д.5 содержит описание отображения информационно-обменной модели DNP3.
Д.6 определяет элемент совместимости (документируемый профиль устройства) для отображения в интерфейс DNP3.
Д.1.2 Задача отображения в DNP3
Задача отображения сервисам DNP3 - это обмен в реальном времени текущей информацией, требующейся для эксплуатационных целей. Объем текущей информации, передаваемой серверу, может изменяться в зависимости от эксплуатационных требований. Участниками обмена могут быть локальные, региональные или международные центры управления, которые получают информацию в реальном времени о текущем состоянии (статус и измерительную информацию) и отправляют команды для управления или установки значений. Национальные или международные контрольные центры могут быть связаны с центрами SCADA (система диспетчерского контроля и сбора данных), которые включают в себя функции управления ВЭС, для того чтобы обеспечить самоадаптацию замкнутой системы к условиям и требованиям электросиловых соединений.
Примечание - Обмен этой информацией в реальном времени отображает небольшое количество атрибутов данных (DataAttributes) классов общих данных, определенных в ГОСТ Р 54418.25.2.
Д.1.3 Структура отображения
Структура отображения состоит из двух частей:
- отображение информационной модели и классов данных;
- отображение информационно-обменных сервисов.
В DNP3 передача данных базируется на структуре "управляющий - удаленная станция". Указанные отображения для классов данных ГОСТ Р 54418.25 могут быть основаны на одном или обоих из следующих механизмов:
- основной: DNP3 XML схема отображения Точек Данных (Data Points), относящихся к DNP3 в ГОСТ Р 54418.25 Объектные Модели, описанные в 8.4 из DNP3 Спецификации Части 8, Совместимость. DNP3 XML схема может быть использована для описания отображения между точками данных DNP3 или атрибутами данных объектных моделей, определенных в ГОСТ Р 54418.25.2;
- дополнительный: Наборы Данных DNP3 способны передавать информационную модель компонентов ВЭС. Если Наборы Данных DNP3 используются для отображения классов данных, то информационная модель ВЭС, определенная в ГОСТ Р 54418.25.2, будет отображена в DNP3 дескрипторов Наборов Данных с объектами DNP3, как определено в DNP3 Объектной Библиотеке, использующей отображение, описанное в Д.4.
Когда используется дополнительная процедура отображения в DNP3 Набора Данных, то DNP3 XML процедура отображения может быть оставлена неиспользуемой.
Когда используется DNP3 XML отображение, то файл отображения XML показывает формирование пакетов данных информационной модели и этого отображения стандартным объектным данным и сервисам DNP3.
Когда DNP3 Наборы Данных используются для отображения:
- сервер формирует пакеты данных информационной модели ГОСТ Р 54418.25.2, которая может быть прочитана сервисами чтения DNP3 Объектной Группы 0;
- управляющий/клиент станции подтверждает Атрибуты Данных из информационной модели ГОСТ Р 54418.25.2 через сервисы, обеспечиваемые DNP3.
Примечание - Результатом отображения между DNP3 и ГОСТ Р 54418.25 является формирование пакетов данных имен пути. Концепция отображения показана на рисунке Д.1. Информационная Модель ГОСТ Р 54418.25.2 должна быть скрыта при отображении в DNP3. Это, в особенности, означает, что:
- сервер формирует пакеты данных информационной модели ГОСТ Р 54418.25.2, которая может быть прочитана сервисами чтения DNP3 Объектной Группы 0;
- управляющий/клиент станции подтверждает Атрибуты Данных из информационной модели ГОСТ Р 54418.25.2 через сервисы, обеспечиваемые DNP3.
Рисунок Д.1 - Структура отображения (концепция)
Сервисы моделей, описанных в ГОСТ Р 54418.25.3 IEM, и отображения в DNP3 сведены и сопоставлены в таблице Д.1. Графа М/О показывает, каким образом сервис определен в ГОСТ Р 54418.25.3: как основной или дополнительный.
Таблица Д.1 - Сервисы, используемые коммуникационным профилем Сервер/Клиент
ГОСТ Р 54418.25.2 IM класс | ГОСТ Р 54418.25.3 IEM Сервисы | M/O | Отображается в DNP3 | ||
Сервер | Удаленная управляемая станция (controlled station) | ||||
GetServerDirectory | O | Read Object Group 0 b | |||
ASSOCIATION | |||||
Associate | M | RESET of remote link (serial | |||
links); DNP3 Data Link Layer or | |||||
initiate TCP connection (Ethernet | |||||
links); DNP3 IP Networking | |||||
Abort | O | n.a. (serial links) or close | |||
TCP connection (Ethernet links); | |||||
DNP3 IP Networking | |||||
Release | O | n.a. (serial links) or close | |||
TCP connection (Ethernet links); | |||||
DNP3 IP Networking | |||||
LOGICAL-DEVICE | Data link address | ||||
Get Logical Device Directory | O | Read Object Group 0 | |||
LOGICAL-NODE | |||||
Get Logical NodeDirectory | O | n.a. | |||
DATA | |||||
GetDataValues | M | Read (Function Code 1) | |||
SetDataValues | M | Write (Function Code 2) | |||
GetDataDirectory | O | n.a. | |||
GetDataDefinition | O | n.a. | |||
DATA-SET | |||||
GetDataSetValues | M | Read (Function Code 1) | |||
SetDataSetValues | O | Write (Function Code 2) | |||
Create DataSet | O | n.a. | |||
DeleteDataSet | O | n.a. | |||
GetDataSetDirectory | O | n.a. | |||
REPORT | |||||
Report | O | n.a. | |||
GetBRCBValues | O | n.a. | |||
SetBRCBValues | O | n.a. | |||
GetURCBValues | O | n.a. | |||
SetURCBValues | O | n.a. | |||
AddSubscription | O | n.a. | |||
RemoveSubscription | O | n.a. | |||
LOG-CONTROL-BLOCK | |||||
GetLCBValues | O | n.a. | |||
SetLCBValues | |||||
LOG | |||||
GetLogStatusValues | O | n.a. | |||
QueryLog8yTime | O | n.a. | |||
QueryLogAfter | O | n.a. | |||
CONTROL | |||||
Select | O | Select (Function Code 3) | |||
SelectWithValue | O | Select (Function Code 3) | |||
Cancel | O | n.a. | |||
Operate | M | Operate (Function Code 4) | |||
CommandTermination | O | Operate (Function Code 4) | |||
TimeActivatedOperate | O | n.a. | |||
не применимо для отображения в DNP3. требуется только когда получено отображение DNP3 Data Set |
Д.2 Специальные справочные ссылки для сервисов DNP3
При пользовании настоящим приложением дополнительную информацию можно получить из [39]-[47].
Д.3 Сокращения
Сокращения приведены в разделе 4 настоящего стандарта.
Д.4 Отображение информационной модели ГОСТ Р 54418.25 в DNP3
Д.4.1 Взаимосвязь Класса Общие Данные и Аналогов Наборов Данных
ГОСТ Р 54418.25.2 специфицирует классы общих данных, относящихся к приложениям, применяемым при работе с ВЭС. Специальные классы общих данных в ГОСТ Р 54418.25.2 следует отображать в специальные аналоги наборов данных в DNP3. Так как ГОСТ Р 54418.25.2 наследует классы общих данных из ГОСТ Р МЭК 61850-7-3 и существует возможность индивидуализации этих классов, универсальный уникальный идентификатор (UUID) в DNP3 резервируется для каждого из классов общих данных в ГОСТ Р 54418.25.2. Единичное пространство имен (Namespace) DNP3 резервируется для всех классов общих данных в ГОСТ Р 54418.25.2. Отображение будет применяться со стороны удаленной станции (стороны сервера).
Д.4.2 Взаимосвязь Отображения Свойств (Quality) с SQ2
Таблица Д.2 определяет отображение для атрибутов свойств в ГОСТ Р МЭК 61850-7-3 и ГОСТ Р 54418.25.2 классов общих данных. Относящиеся к ГОСТ Р МЭК 61850-7-3 и ГОСТ Р 54418.25.2 атрибуты данных [q] следует отображать в битовых строках (двоичных последовательностях) DNP3 в аналогах наборов данных DNP3.
Таблица Д.2 - Отображение свойств
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа |
validity -> IV/NT | |||
good I invalid -> on-line I off-line | |||
detailQual -> OV | |||
overflow -> over-range | |||
source -> SB | |||
substituted -> local forced | |||
operatorBlocked -> BL | |||
blocked -> force off-line |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "q".
Д.4.3 CDC (Общий класс данных) Измеренных Значений (MV)
Таблица Д.3 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных Измеренных значений (MV). Атрибуты данных [mag+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.3 - CDC: отображение MV
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {29787E 1 0-484F-4B22-A7BF-1 C669D3748E8} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "MV" |
mag | AnalogueValue | DAEL: FL T32 | 32-битное значение с плавающей точкой |
q | Quality | DAEL: BSTR | SQ2 - Выходная программа (справка с таблицей Е.2) |
t | TimeStamp | DAEL: TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть относящимся к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "mag".
Д.4.4 CDC Параметры значений уставок (SPV)
Таблица Д.4 определяет отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных Параметров значений уставок (SPV). Основные атрибуты данных [chaManRs+actVal+oldVal] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.4 - CDC: отображение SPV
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {50 FC4 FE5-BBA8-4CB4-934 F-0637B 19832F6} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "SPV" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
chaManRs. ctlVal | BOOLEAN | CTLV:BSTR | FLAG={BS8 [0..7] |
chaManRs. origin. OrCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
chaManRs.origin, orldent | OCTET STRING64 | CTLV:OSTR | 64 байта |
chaManRs.origin. orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
chaManRs.origin, orldent | OCTET STRING64 | DAEL:OSTR | 64 байта |
chaManRs.stVal | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
chaManRs.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
chaManRs.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
chaManRs.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
actVal.ctlVal | AnalogueValue | CTLV:FL T32 | 32-битное значение с плавающей точкой |
actVal.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
actVal.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта |
actVal.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
actVal.origin.orldent | OCTET STRING64 | DAEL:OSTR | 64 байта |
actVal.mxVaI | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
actVal.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
actVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
actVal.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
oldVal.ctlVal | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
oldVal.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
oldVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
oldVal.ctl Model | CtlModels | DAEL:INT32 | 32-битное целое значение |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actVal.mxVal".
Д.4.5 CDC Значение состояния (STV)
Таблица Д.5 определяет отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных Значений состояния (STV). Основные атрибуты данных [actSt+oldSt] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.5 - Отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных Значений состояния (STV)
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {36798E8E-2138-4 77D.868E-A5B6ADFA041 О} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "STV" |
actSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
actSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
actSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
oldSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
oldSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
oldSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actSt.stVal".
Д.4.6 CDC Сигнал неисправности (ALM)
Таблица Д.6 определяет отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных ALM. Основные атрибуты данных [almAck+actSt+oldSt] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.6 - CDC: отображение ALM
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {E53A 1962-00 FC-4506-A509-E 1 A430A491 FA} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "ALM" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
almAck.ctlVal | BOOLEAN | CTLV:BSTR | FLAG={BS8 [0 ..7] |
almAck.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
almAck.origin.orl dent | OCTET STRING64 | CTLV:OSTR | 64 байта |
almAck.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
almAck.origin.orl dent | OCTET STRING64 | DAEL:OSTR | 64 байта |
almAck.stVal | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
almAck.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
almAck.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
almAck.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
actSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
actSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
actSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
oldSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
oldSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) |
oldSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actSt.stVal".
Д.4.7 CDC Команда (CMD)
В таблице Д.7 определено отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных CMD. Основные атрибуты данных [actSt+oldSt] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.7 - CDC: отображение CMD
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {3A7C7799-3379-4CC5-B 1 FO-AE5F865E 1AC 1} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "CMD" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
actSt.ctlVal | Ctxlnt | CTLV:INT32 | 32-битное целое значение |
actSt.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
actSt.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта |
actSt.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
actSt.origin.orl dent | OCTET STRING64 | DAEL:OSTR | 64 байта |
actSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
actSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
actSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
actSt.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
oldSt.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
oldSt.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
oldSt.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actSt.stVal".
Д.4.8 CDC Учет Событий (CTE)
В таблице Д.8 определено отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных CTE. Основные атрибуты данных [manRs+hisRs+actCtVal+oldCtVal] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.8 - CDC: отображение CTE
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {DC8804E 1-A36F-41 05-8335-27D5344F1 BDD} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "СТЕ" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
manRs.ctlVal | BOOLEAN | CTLV:BSTR | FLAG={BS8 [0..7] |
manRs.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
manRs.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта |
manRs.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
manRs.origin.orldent | OCTET STRING64 | DAEL:OSTR | 64 байта |
manRs.stVal | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
manRs.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Е.2) |
manRs.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
manRs.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
hisRs.ctlVal | Ctxlnt | CTLV:INT32 | 32-битное целое значение |
hisRs.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение |
hisRs.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта |
hisRs.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение |
hisRs.origin.orldent | OCTET STRING64 | DAEL:OSTR | 64 байта |
hisRs.stVal | INT32 | DAEL:UINT32 | 32-битное целое значение |
hisRs.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
hisRs.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
hisRs.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение |
actCtVal.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
actCtVal.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
actCtVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
oldCtVal. stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение |
oldCtVal. q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
oldCtVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actCtVal.stVal".
Д.4.9 CDC Временная привязка состояния (TMS)
В таблице Д.9 определено отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных TMS. Основные атрибуты данных [manRs+hisRs+actTmVal+oldTmVal] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.9 - CDC: отображение TMS
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных | |
- | - | UUID:OSTR | {FE568612-8574-4B85-999F-21 E 14C7977B4} | |
- | - | NSPC:VSTR | "МЭК 61400-25-2" | |
- | - | NAME:VSTR | "TMS" | |
- | - | CTLS:UINT | Один байт контроля статуса элемента | |
manRs.ctlVal | BOOLEAN | CTLV:BSTR | FLAG={BS8 [0..7] | |
manRs.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение | |
manRs.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта | |
manRs.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение | |
manRs.origin.orldent | OCTET STRING64 | DAEL:OSTR | 64 байта | |
manRs.stVal | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] | |
manRs.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) | |
manRs.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения | |
manRs.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение | |
- | - | CTLS:UINT | Один байт контроля статуса элемента | |
hisRs.ctlVal | Ctxlnt | CTLV:INT32 | 32-битное целое значение | |
hisRs.origin.orCat | ENUMERATED | CTLV:INT32 | 32-битное целое значение | |
hisRs.origin.orldent | OCTET STRING64 | CTLV:OSTR | 64 байта | |
hisRs.origin.orCat | ENUMERATED | DAEL:INT32 | 32-битное целое значение | |
hisRs.origin.orldent | OCTET STRING64 | DAEL:OSTR | 64 байта | |
hisRs.stVal | INT32 | DAEL:UINT32 | 32-битное целое значение | |
hisRs.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) | |
hisRs.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения | |
hisRs.ctlModel | CtlModels | DAEL:INT32 | 32-битное целое значение | |
actTmVal.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение | |
actTmVal.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) | |
actTmVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения | |
oldTmVal.stVal | Ctxlnt | DAEL:INT32 | 32-битное целое значение | |
oldTmVal.q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) | |
oldTmVal.t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р 54418.25.2 атрибутом имени, например "actTmVal.stVal".
Д.4.10 CDC Состояние Единичной Точки (SPS)
Таблица Д.10 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных SPS. Атрибуты данных [stVal+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.10 - CDC: отображение SPS
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {D446D178-8B19-40ED.9F63-BA4E4DB3E3BA} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "SPS" |
stVal | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "stVal".
Д.4.11 CDC Постоянное Состояние (Integer Status) (INS)
Таблица Д.11 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных INS. Атрибуты данных [stVal+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.11 - CDC: отображение INS
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {9A056CCD. BC92-42EE-ADEA-4B532764AB26} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "INS" |
stVal | INT32 | DAEL:INT32 | 32-битное целое значение |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "stVal".
Д.4.12 CDC Управляемая одиночная точка (SPC)
В таблице Д.12 определено отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных SPC. Атрибуты данных [stVal+t+q+ctlVal] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.12 - CDC: отображение SPC
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {FB 1 BDB9F-9D41-4DDA-AFDC-BC 1 E6911 В3Е 1} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "SPC" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
ctlVal | BOOLEAN | CTLV:BSTR | FLAG={BSS [0..7] |
stVal | BOOLEAN | DAEL:BSTR | FLAG={BSS [0..7] |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "stVal".
Д.4.13 CDC Управляемое постоянное состояние (INC)
В таблице Д.13 определено отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных INC. Атрибуты данных [stVal+t+q+ctlVal] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.13 - CDC: отображение INC
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {FC47BCBE-D3CF-4SFA-S311-6CF399C29DE4} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "INC" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
ctlVal | INT32 | CTLV:INT32 | 32-битное целое значение |
stVal | INT32 | DAEL:INT32 | 32-битное целое значение |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "stVal".
Д.4.14 CDC Счетчик двоичный импульсов (BCR)
В таблице Д.14 определено отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных BCR. Атрибуты данных [actVal+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.14 - CDC: отображение BCR
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {59C03F2E-9DC7 -4D5F -S650-92C29FASBFFA} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "BCR" |
actVal | INT128 | DAEL:OSTR16 | 128-битное целое значение |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "actVal".
Д.4.15 CDC Управляемая аналоговая точка данных (APC)
Таблица Д.15 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных АРС. Атрибуты данных [setMag+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.15 - CDC: отображение APC
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {S6AF9D 1 F-B5BF-4F7F-9FB 1-S090090EBDS7} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "АРС" |
- | - | CTLS:UINT | Один байт контроля статуса элемента |
setMag | AnalogueValue | CTLV:FL T32 | 32-битное целое значение |
setMag | AnalogueValue | DAEL:FL T32 | 32-битное целое значение |
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "setMag".
Д.4.16 CDC Фаза как обоснование связанных измеренных значений трехфазной системы (WYE)
Таблица Д.16 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных WYE. Атрибуты данных [(phsA I phsB I phsC I neut I net I res)+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.16 - CDC: отображение WYE
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {FCB770FF-OCA 7 -437C-B6ES-SFOAOC56ABF5} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "WYE" |
phsA.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsA.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsB.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsB.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsC.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsC.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
neut.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
neut.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
net.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
net.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
res.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
res.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
q (note 2) | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
t (note 1) | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть отнесено к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "phsA.cVal.mag".
DNP3 отображение должно отображать одно значение атрибута "t" около одной отметки времени.
DNP3 отображение должно отображать все индивидуальные значения атрибута "q" через ORing около одной битовой строки DNP3 для флага достоверности, который будет указывать на статус "off line", если любой из индивидуальных атрибутов "q" "off line".
Д.4.17 CDC Междуфазные связанные измеренные значения трехфазной системы (DEL)
Таблица Д.17 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных DEL. Атрибуты данных [(phsAB I phsBC I phsCA)+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.17 - CDC: отображение DEL
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {A51 B25C2-BOD B.48B2-9038-522D E9D5FB9B} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "DEL" |
phsAB.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsAB.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsBC.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsBC.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsCA.cVal.mag | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
phsCA.cVal.ang | AnalogueValue | DAEL:FL T32 | 32-битное значение с плавающей точкой |
q (note 2) | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с таблицей Д.2) |
t (note 1) | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть относящимся к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "phsAB.cVal.mag".
DNP3 отображение должно отображать одно значение атрибута "t" около одной отметки времени.
DNP3 отображение должно отображать все индивидуальные значения атрибута "q" через ORing около одной битовой строки DNP3 для флага достоверности, который будет указывать на статус "off line", если любой из индивидуальных атрибутов "q" "off line".
Д.4.18 CDC Указатель устройств (WDPL)
Таблица Д.18 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61400-25-2 общих классов данных WDPL. Атрибуты данных [vendor+tmOffset+tmUseDT+tmDT] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.18 - CDC: отображение WDPL
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {4DE9717C-E402-4961-99D9-2ABE3D121847} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "WDPL" |
vendor | VISIBLE STRING255 | DAEL:VSTR | 255 символов |
tmOffset | INT16 | DAEL:INT32 | Временной интервал от UTC в минутах |
tmUseDT | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
tmDT | BOOLEAN | DAEL:BSTR | FLAG={BS8 [0..7] |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть относящимся к стандарту ГОСТ Р 54418.25.2 атрибутом имени, например "vendor".
Д.4.19 CDC Указатель Логических Узлов (LPL)
Таблица Д.19 определяет отображение для атрибутов данных в ГОСТ Р МЭК 61850-7-3 общих классов данных LPL. Атрибуты данных [vendor+swRev+d] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.19 - CDC: отображение LPL
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | {8FA4508F-154 7 -4 76F-829D. B3FCB35CA427} |
- | - | NSPC:VSTR | "МЭК 61400-25-2" |
- | - | NAME:VSTR | "LPL" |
vendor | VISIBLE STRING255 | DAEL:VSTR | 255 символов |
swRev | VISIBLE STRING255 | DAEL:VSTR | 255 символов |
d | VISIBLE STRING255 | DAEL:VSTR | 255 символов |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть относящимся к ГОСТ Р МЭК 61850-7-3 атрибутом имени, например "vendor".
Д.4.20 CDC Установка статуса Сигнала Неисправности (ASS)
Таблица Д.20 определяет отображение для атрибутов данных в ГОСТ Р 54418.25.2 общих классов данных ASS. Атрибуты данных [(ARRAY of stVal)+t+q] будут отображены в DNP3 аналогами наборов данных.
Таблица Д.20 - CDC: отображение ASS
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | UUID:OSTR | (смотри Е.4.22) |
- | - | NSPC:VSTR | (смотри Е.4.22) |
- | - | NAME:VSTR | "ASS" |
stVal[0] | CODED ENUM | DAEL:BSTR | FLAG ={BS8 [0..7] |
Status = BS1 [1..0] <0, Off; | |||
1, Подтверждение; 2, Предупреждение; 3; Активация>} | |||
stVal[1] | CODED ENUM | DAEL:BSTR | FLAG ={BSS [0..7] |
Status = BS1 [1..0] <0, Off; | |||
1, Подтверждение; 2, Предупреждение; 3; Активация>} | |||
stVal[2] | CODED ENUM | DAEL:BSTR | FLAG ={BSS [0..7] |
Status = BS1 [1..0] <0, Off; | |||
1, Подтверждение; 2, Предупреждение; 3; Активация>} | |||
stVal[n] | CODED ENUM | DAEL:BSTR | FLAG = {BSS [0..7] |
Status = BS1 [1..0] <0, Off; | |||
1, Подтверждение; 2, Предупреждение; 3; Активация>} | |||
q | Quality | DAEL:BSTR | SQ2 - Выходная программа (справка с Таблицей Е.2) |
t | TimeStamp | DAEL:TIME | Шесть байтов двоичного времени - Время измерения |
Дополнительное значение, связанное с каждым элементом данных DNP3, должно быть относящимся к ГОСТ Р 54418.25.2 атрибутом имени, например "stVal[0]".
Примечание - Как количество элементов в массиве состояния сигнала неисправности является зависимым от реализации, производители, при отображении этого класса общих данных в DNP3 аналоги наборов данных должны регистрировать пространства имен с Пользовательской группой DNP Реализованный аналог набора данных может затем быть определен в пределах этой той области имен и UUID, приобретенного для реализованного набора данных, как показано в Д.4.22. Пространство имен и значение UUID таким образом полученные используются для NSPC и UUID, показанных в таблице Д.20.
Д.4.21 Взаимосвязь класса Атрибутов Данных и Дескрипторов Наборов Данных
ГОСТ Р 54418.25.2 специфицирует классы атрибутов данных, относящихся к приложениям, применяемым при работе с ВЭС. Специальные классы атрибутов данных в ГОСТ Р 54418.25.2 следует отображать в специальные дескрипторы наборов данных в DNP3. Отображение будет применяться со стороны удаленной станции (стороны сервера).
Таблица Д.21 определяет отображения для атрибутов данных в ГОСТ Р 54418.25.2 классы атрибутов данных WGEN.Spd. Класс атрибут данных [например, WGEN.Spd] следует отображать в DNP3 дескриптор класса данных.
Таблица Д.21 - Образец отображения класса Атрибутов Данных
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | NAME | "WGEN_Spd" |
WGEN.Spd | MV | PTYP | UUID of prototype for MV {297S7E10-4S4F-4B22- |
A7BF-1 C669D374SES} |
Таблица Д.22 определяет отображение для атрибутов данных в ГОСТ Р 54418.25.2 класса данных WGEN. Класс данных [например, WGEN] будет отображаться в DNP3 дескриптором класса данных.
Таблица Д.22 - Образец отображения класса Данные
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | NAME | "WGEN" |
WGEN.OpTmRs | TMS | PTYP | UUID of prototype for TMS {FE56S612-S574-4BS5-999F-21 E 14C7977B4} |
WGEN.GnOpMod | STY | PTYP | UUID of prototype for STY {3679SESE-213S-4 77D.S6SE-A5B6ADFA041 O} |
WGEN.CISt | STY | PTYP | UUID of prototype for STY {3679SESE-213S-4 77D.S6SE-A5B6ADFA041 O} |
WGEN.Spd | MV | PTYP | UUID of prototype for MV {29787E10-484F-4B22-A7BF-1 C669D3748E8} |
WGEN.w | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.VAr | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.GnTmpSta | MV | PTYP | UUID of prototype for MV {29787E10-484F-4B22-A7BF-1 C669D3748E8} |
WGEN. GnTmpRtr | MV | PTYP | UUID of prototype for MV {29787E10-484F-4B22-A7BF-1 C669D3748E8} |
WGEN. GnTmplnlet | MV | PTYP | UUID of prototype for MV {29787E10-484F-4B22-A7BF-1 C669D3748E8} |
WGEN.StaPPV | DEL | PTYP | UUID of prototype for DEL {A51B25C2-BOD B.48 B2-9038-522 D E9 D 5 F B9 B} |
WGEN.StaPhV | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.StaA | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.RtrPPV | DEL | PTYP | UUID of prototype for DEL {A51B25C2-BOD B.48 B2-9038-522 D E9 D 5 F B9 B} |
WGEN. RtrPhV | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.RtrA | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.RtrExtDC | MV | PTYP | UUID of prototype for MV {29787E10-484F-4b22-A7BF-1 C669D3748E8} |
WGEN.RtrExtAC | MV | PTYP | UUID of prototype for MV {29787E10-484F-4b22-A7BF-1 C669D3748E8} |
Таблица Д.23 определяет отображение для выбора из атрибутов данных в ГОСТ Р 54418.25.2 класс данных WGEN. Выбор из атрибутов данных от класса данных [например, WGEN] будет отображен в DNP3 дескриптором класса данных.
Таблица Д.23 - Образец частичного отображения Класса Данных.
Атрибут имени | Тип атрибута | DNP3 Спецификация данных | DNP3 отображение элемента данных |
- | - | NAME | "WGEN_SpD.PwrAt-PwrRt-StaA" |
WGEN.Spd | MV | PTYP | UUID of prototype for MV {29787E10-484F-4B22-A7BF-1 C669D3748E8} |
WGEN.PwrAt | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.PwrRt | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
WGEN.StaA | WYE | PTYP | UUID of prototype for WYE {FCB770FF-OCA7-437C-B6E8-8FOAOC56ABF5} |
Д.4.22 Роль группы пользователей DNP
DNP3 администрируется независимым органом под наименованием Группа Пользователей DNP, ассоциация производителей и пользователей протокола. Функцией этой группы пользователей является добровольная регистрация реализаций DNP3 и обслуживание как неангажированного посредника для внедрения использования DNP3 для различных классов устройств (например, измерительные приборы, регуляторы, переключатели и т.д.). Производители, в первую очередь для начала всякого использования DNP3, могут стать членами группы пользователей для выяснения того, какие достижения DNP3 уже существуют и какие функции должны поддерживать их устройства. Пользовательская группа объединяет пользователей и производителей, которые представляют опытную базу и рыночные исследования, которые подтверждают, что достижения DNP3 являются соответствующими и отвечающими интересам большого множества потенциальных пользователей.
DNP3 использует аналоги наборов данных для указания структуры и упорядочивания данных в пределах набора данных в целом или части набора данных. Настоящий стандарт специфицирует аналоги наборов данных для использования в DNP3 наборов данных. DNP3 использует пространства имен для назначения уникальных значений общим именам, которые могут в остальных случаях быть закреплены за теми же самыми именами, используемыми в любых местах. Участники пользовательской группы DNP3 подтверждают добровольную регистрацию Пространства Имен затребованную производителем или пользователем. Как только Пространство имен однажды зарегистрировано, так производитель или пользователь свободен определять, переопределять или удалять любые аналоги наборов данных из этого пространства имен. Каждому аналогу набора данных присваивается UUID для его уникальной идентификации при определении или изменении. Любой пользователь или производитель свободен употреблять наборы данных, определенные аналогами наборов данных в любых пространствах имен, в которых имеется понятие об этих аналогах наборов данных. Это разрешает создание закрытых наборов данных, где требуется, а также запрашивается разрешение на распространение наборов данных для широкого использования. Примеры таких аналогов наборов данных описаны в настоящем стандарте.
Д.5 Отображение Информационно-Обменной Модели в DNP3 сервисы
Следующие сервисы, определенные в ГОСТ Р 54418.25.3, должны быть отображены в сервисы, определенные в DNP3:
- Модель Данных (GetDataValue, SetDataValue);
- Модель управления (Select, SelectWithValue, Operate, CommandTermination).
Отображение в DNP3 обеспечивают сервисы, предназначенные только для текущего обмена данными.
Назначение этого отображения есть использование сервисов DNP3 так как они есть. Никаких развитий определений обеспечиваемых DNP3 не предусматривается.
Д.6 Детали стека протоколов
Д.6.1 DNP3 Документ Профиля Устройства
Минимальная реализация для совместимости с ГОСТ Р 54418.25 должна иметь профиль устройства, которое разрешает установки, показанные в таблицах Д.6.1, Д.6.2, Д.6.3. Совместимые устройства могут поддерживать и другие опции в добавление к установкам отмеченным здесь.
Таблица Д.6.1
Идентификация устройства | Возможности |
1.1.7 Уровни поддержки DNP для: | Только управляющие устройства должны включать в себя, по крайней мере: |
1.4 Уровень связей | Возможности |
1.4.5 Посылает подтвержденные пользовательские структуры данных Список условий, при которых устройство передает подтвержденные сервисы уровня связи (TEST_LINK_STATES,RESET_LINK_STATES, CONFIRMED_USER_DATA) | Установленные или конфигурируемые, так чтобы никогда не отправлять подтвержденные пользователем структуры данных. |
1.5 Уровень Приложений | Возможности |
1.5.1 Максимальное количество байтов, переданных на Фрагменте Уровня Приложений кроме Передачи Файлов: Этот объем не включает любую транспортировку или структуру байтов. | Для Управляющих: Установленные или конфигурируемые, так чтобы включать 292 |
1.6 Следующие пункты заполняются только для управляющих | Возможности |
1.6.1 Пауза ожидающая Полного Ответа Уровня Приложений(ms): | Конфигурируется |
1.7 Следующие пункты заполняются только для удаленных станций | Возможности |
1.7.1 Пауза ожидающая Подтверждения Приложения требуемого ответного сообщения: | Конфигурируется |
1.8 Поддержка незапрашиваемых ответов удаленной станции | Возможности |
1.8.1 Поддержка незапрашиваемого отчета | Конфигурируется, выбор On/Off |
1.8.3 Пауза подтверждения незапрашиваемого ответа: | Конфигурируется |
1.9 Условия запуска незапрашиваемых ответов для удаленной станции | Возможности |
1.9.8 Выдержка времени после того, как замечено событие любого класса: | Конфигурируется |
3.1 Единичный бит двоичного ввода | Возможности |
3.1.2 Изменение событий сообщает, когда запрашивается вариант 0: | Вариант 2 - с абсолютным временем |
3.3 Статус двоичного вывода и контрольный блок выходной передачи сигнала | Возможности |
3.3.9 Максимальное время между выбором и командой: | Конфигурируется (по умолчанию = 10 секунд) |
3.4 Счетчики/Замороженные счетчики | Возможности |
3.4.9 Счетчики установлены на: | 32 бита (4 294 967 295) |
Таблица Д.6.2
Индекс точки | Имя | Поддерживаемые операции управления | Имя для состо- | Имя для состо- | Исходный класс, связанный с событием (1, 2, 3 или отсутствием) | Описа- | |||||||||||
Select/ | Direct Operate | Direct Operate- No Ack | Pulse On | Pulse Off | Latch On | Latch Off | Trip | Close | Count >1 | Cancel Currently Running Operation | Изме- | Команда | |||||
Всегда | Всегда | Всегда | Конфигу- | Никогда | Конфигу- | Конфигу- | Конфигу- | Конфигу- | Никогда | Никогда |
DNP3 Документ Профиля Устройства
Таблица Д.6.3 - Функциональная совместимость
DNP Объектная группа и описание | Запрос | Ответ | ||||
Группа номер Num | Вариант номер Num | Описание | Функцио- | Квалифи- | Функцио- | Квалифи- |
0 | 254 | Device Attributes - Non-specific all attributes request | 1 | 00, 01, 06 | 129 | 58 |
0 | 255 | Device Attributes - List of attribute variations | 1 | 00, 01, 06 | 129 | 58 |
50 | 1 | Time and Date - Absolute time | 1 | 07(qty=1) | 129 | 07(qty=1) |
2 | 07(qty=1) | - | - | |||
50 | 3 | Time and Date - Absolute time at last recorded time | 2 | 07(qty=1) | - | - |
52 | 1 | Time Delay - Coarse | 129 | 07(qty=1) | ||
52 | 2 | Time Delay - Fine | 129 | 07(qty=1) | ||
60 | 1 | Class Objects - Class 0 Data | 1 | 06 | - | - |
60 | 2 | Class Objects - Class 1 Data | 1 | 06, 07, 08 | - | - |
20, 21 | 06 | - | - | |||
60 | 3 | Class Objects - Class 2 Data | 1 | 06, 07, 08 | - | - |
20, 21 | 06 | - | - | |||
60 | 4 | Class Objects - Class 3 Data | 1 | 06, 07, 08 | - | - |
20, 21 | 06 | - | - | |||
80 | 1 | Internal Indications - Packed Format | 2 | 00 | - | - |
(index=7) | ||||||
85 | 0 | Data Set Prototype - All Var | 1 | 06 | - | - |
85 | 1 | Data Set Prototype - with UUID | 1 | 00, 01, 06, | 129 | 58 |
17, 28 | ||||||
2 | 58 | - | - | |||
86 | 0 | Data Set Descriptor - All Var | 1 | 06 | - | - |
22 | 00, 01, 06, | - | - | |||
17, 28 | ||||||
86 | 1 | Data Set Descriptor - Data Set Contents | 1 | 00, 01, 06, | 129 | 58 |
17, 28 | ||||||
2 | 58 | - | - | |||
86 | 2 | Data Set Descriptor - Characteristics | 1 | 00, 01, 06, | 129 | 00,01,17, |
17,28 | 28 | |||||
86 | 3 | Data Set Descriptor - Point Index Attributes | 1 | 00,01,06, | 129 | 58 |
17,28 | ||||||
2 | 58 | - | - | |||
87 | 0 | Static Data Set - All Var | 1 | 06 | - | - |
87 | 1 | Static Data Set - Present Value | 1 | 00, 01, 06, | 129 | 58 |
17, 28 | ||||||
2 | 58 | - | - | |||
3, 4, 5, 6 | 58 | 129 | 58 | |||
88(а) | 0 | Event Data Set - All Var | 1 | 06, 07, 08 | - | - |
88(а) | 1 | Event Data Set - Snapshot | 1 | 06, 07, 08 | 129,130 | 58 |
No Object (function code only) Cold Restart | 13 | |||||
No Object (function code only) Delay Measurement | 23 | |||||
Примечание - Объектные группы 0 и с 85 по 88 требуются только в том случае, если дополнительное отображение наборов данных поддерживается |
Приложение Е
(обязательное)
Синхронизация по времени
Е.1 Основное положение
Любое соответствие требованиям внедрения в настоящем стандарте и объявления поддержки для объектов, содержащих признак типа МЕТКИ ВРЕМЕНИ (TIMESTAMP), должны использовать протокол SNTP, как минимум, чтобы гарантировать синхронизацию на ВЭС. Использование других, более точных, протоколов синхронизации в настоящем стандарте не рассматривается.
Чтобы получить ту же самую интерпретацию признака TimeQuality МЕТКИ ВРЕМЕНИ, должны применяться следующие правила:
- при запуске устройства его метка ClockNotSynchronized должна быть установлена на значение TRUE до тех пор, пока устройство синхронизируется с внешним сервером SNTP или другим, более точным, источником синхронизации (например, GPS, РТР или IRIG-B);
- если никакого другого, более точного, внешнего источника синхронизации не существует и сервер SNTP не отвечает на запросы синхронизации или ответы SNTP прибывают с индикатором LI, указывающим, что TimeServer не надежно, то метка ClockNotSynchronized будет установлена после определенного перерыва, определенного производителем, среди дополнительной информации Внедрении Протокола для Тестирования (PIXIT) документа. Этот перерыв зависит от точности внутренних часов и должен гарантировать указанное максимальное отклонение (PIXIT);
- если информацию о TimeStamp нельзя считать действительной из-за, например, ошибки внутренних часов, то должна быть установлена метка ClockFailure;
- значение TRUE для атрибутов TimeQuality таких, как ClockNotSynchronized или ClockFailure, указывает на то, что метка времени недействительна и значение должно остаться установленным для всех объектов данных, содержащих атрибуты МЕТКИ ВРЕМЕНИ, до тех пор, пока часы не будут успешно синхронизированы.
Е.2 A-Профиль
A-Профиль для Сервисов Синхронизации Времени определены в [35] (пункт 6.5.1).
Е.3 T-Профиль
T-Профиль для Сервисов Синхронизации Времени определены в [35] (пункт 6.5.2).
Приложение Ж
(справочное)
Интерфейсы - Рекомендации по реализации
Ж.1 Основные положения
Для того чтобы получить руководство к пониманию серии стандартов ГОСТ Р 54418.25, следующие решения подразумеваются как показательные образцы того, что серия стандартов ГОСТ Р 54418.25 сопоставляется с реальной системой.
Серия стандартов ГОСТ Р 54418.25 не ограничивает внедрения информации, сервисных моделей, коммуникационных стеков, действий и интерфейсов программных приложений (APIs).
Примечание - Пример не является репрезентативным. Применение множества других подходящих интерфейсов возможно с обеих сторон.
Ж.2 Пример интерфейсов реальной системы
Информационный обмен между ВЭС (WPP) и контролирующими системами главным образом включает в себя - согласно схеме, приведенной на рисунке Ж.1, - клиент, сервер, некоторые интерфейсы и действия.
Сервер (WPP сервер) представляет собой информационную и информационно-обменную модели. Клиент (WPP клиент) представляет собой дополнительные условия серверу. Например, сервис, который обеспечивает сервер, может быть запрошен клиентом. Клиент сам по себе не специфицируется: он главным образом выполняет дополнительные серверу функции.
Полная цепь от источника информации к визуализации SCADA показана следующим образом (слева направо на схеме):
- источник значений данных - реальная WPP. Обмен данными (сырыми) значениями между реальным процессом WPP и сервером WPP осуществляет интерфейс 1 (IF1) и (IF2) - эти интерфейсы определяются реализацией. Сколько интерфейсов осуществлено со стороны сервера - определяется реализацией;
- сервер WPP добавляет полезную информацию к необработанным данным (например, иерархические имена, отметки времени, качество и т.д.). Это определено в модели и добавление имени и т.д. определяется как Действие 1 (Act1) - это действие определяется реализацией;
- модель информации (как это отмечено с сетевой точки зрения), определенная в ГОСТ Р 54418.25.2 - построение модели определяется реализацией;
- мониторинг изменения значений текущих данных освобожден от источника данных в реальном времени, представленного (Act1), - это действие - определяется реализацией, поведение и услуги - в ГОСТ Р 54418.25.3;
- обмен значениями данных между сервером WPP и контролирующей системой управления через (IF3) - поведение и услуги определены в настоящем стандарте;
- обмен изображения модели, расположенной на сервере с другой системой (IF3), - поведение и услуги определены в настоящем стандарте;
- обмен значениями данных между (коммуникация) клиентом и приложениями клиента (визуализация, HMI) через (IF4) и (Act2) - это действие - определяется реализацией.
Рисунок Ж.1 - Варианты реализации (пример)
Интерфейс (IF3) является единственным интерфейсом, который определен в группе стандартов ГОСТ Р 54418.25. Этот интерфейс (IF3) определен информацией, которая доступна через этот интерфейс, и сообщениями, которые несут сервисные параметры и значения.
Приложение ДА
(обязательное)
Сведения о соответствии ссылочных национальных и межгосударственных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте
Таблица ДА.1
Обозначение ссылочного национального стандарта | Степень соответ- | Обозначение и наименование ссылочного международного стандарта |
IDT | МЭК 870-5-5-95 "Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 5. Основные прикладные функции" | |
IDT | ИСО 8326-87 "Системы обработки информации. Взаимосвязь открытых систем. Определение базовых услуг сеансового уровня в режиме с установлением соединения" | |
IDT | ИСО/МЭК 8824-90 "Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)" | |
IDT | ИСО/МЭК 8825-1-98 "Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования" | |
IDT | МЭК 60870-5-101:2003 "Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 101. Обобщающий стандарт по основным функциям телемеханики" | |
IDT | МЭК 60870-5-104:2000 "Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для МЭК 870-5-101 с использованием стандартных транспортных профилей" | |
IDT | МЭК 61850-6:2004 "Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях" | |
IDT | МЭК 61850-7-1:2003 "Сети и системы связи на подстанциях. Часть 7-1. Базовая структура связи для подстанции и линейного оборудования. Принципы и модели" | |
IDT | МЭК 61850-7-2:2003 "Сети и системы связи на подстанциях. Часть 7-2. Базовая структура связи для подстанций и линейного оборудования. Абстрактный интерфейс услуг связи (ACSI)" | |
IDT | МЭК 61850-7-3:2003 "Сети и системы связи на подстанциях. Часть 7-3. Базовая структура связи для подстанций и линейного оборудования. Классы общих данных" | |
MOD | IEC 61400-25-2(2006) "Турбины ветровые. Часть 25-2. Коммуникации для текущего контроля и управления ветровыми электростанциями. Информационные модели" | |
MOD | IEC 61400-25-3(2006) "Турбины ветровые. Часть 25-3. Коммуникации для текущего контроля и управления ветровыми электростанциями. Модели информационного обмена" | |
MOD | IEC 61400-25-5(2006) "Турбины ветровые. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия спецификации" | |
Примечание - В настоящей таблице использованы следующие условные обозначения: - IDT - идентичные стандарты; - MOD - модифицированные стандарты. |
Библиография
[1] | ISO/IEC 10646:2014 Information technology - Universal Coded Character Set (UCS) | |
[2] | ISO 639-2:1998 Codes for the representation of names of languages - Part 2: Alpha-3 code | |
[3] | W3C, Web Services Architecture, http://www.w3.org/TR/2002/WD-ws-arch-20021114/ | |
[4] | W3C, Extensible Markup Language (XML) 1.0, http://www.w3.org/TR/2000/REC-xml-20001006 | |
[5] | W3C, Name spaces in XML, http://www.w3.org/TR/REC-xml-names | |
[6] | W3C, XML Schema Part 0: Primer, http://www.w3.org/TR/xmlschema-0 | |
[7] | W3C, XML Schema Part 1: Structures, http://www.w3.org/TR/xmlschema-1 | |
[8] | SOAP ver. 1.1, W3C Note "Simple Object Access Protocol (SOAP) 1.1, 8 May 2000. . w3. org/TR/2006/NOTE-soap 11-ror-httpbind ing-20060321 l#reqoptrespbi nd ing and http://www.w3.org/ TR/2000/NOTE-SOAP-20000508/ | |
[9] | W3C, XML Schema Part 2: Data Types, | |
[10] | RFC 791, Internet Protocol specification (IP) | |
[11] | RFC 792, Internet Control Message Protocol (ICMP) | |
[12] | RFC 793, Transmission Control Protocol (TCP) | |
[13] | RFC 826, Ethernet Address Resolution Protocol | |
[14] | RFC 919, Broadcasting internet datagrams | |
[15] | RFC 922, Broadcasting internet datagrams in presence of subnets | |
[16] | RFC 950, Internet Standard Subnetting Procedure | |
[17] | RFC 1112, Host Extensions for IP Multica | |
[18] | RFC 2616, Hypertext Transfer Protocol - HTTP/1. 1 | |
[19] | RFC 2817, Upgrading to TLS Wthin HTTP/1. 1 | |
[20] | RFC 2246, Transport Layer Security (TLS) protocol | |
[21] | RFC 4122, Universally Unique IDentifier (UUID) URN Namespace | |
[22] | IEC 61850-8-1 | Communication networks and systems in substations - Part 8-1: Specific Communication Service Mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3 |
[23] | ISO 9506 series | Industrial automation systems - Manufacturing Message Specification |
[24] | ISO 9506-1:2003 | Industrial automation systems - Manufacturing Message Specification - Part 1: Service definition |
[25] | ISO 9506-2:2003 | Industrial automation systems - Manufacturing Message Specification - Part 2: Protocol specification |
[26] | ISO/IEC 15953:1999 | Information technology - Open Systems Interconnection - Service definition for the application service object association control service element |
[27] | ISO/IEC 15954:1999 | Information technology - Open Systems Interconnection - Connection-mode protocol for the application service object association control service element |
[28] | ISO/IEC 8822:1994 | Information technology - Open Systems Interconnection - Presentation service definition |
[29] | ISO/IEC 8823-1:1994 | Information technology - Open Systems Interconnection - Connection-oriented presentation protocol: Protocol specification |
[30] | ISO/IEC 8824-1:2008 | Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Part 1: |
[31] | ISO/IEC 8825-1:2008 | Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) - Part 1: |
[32] | ISO/IEC 8326:1996 | Information technology - Open Systems Interconnection - Session service definition |
[33] | ISO/IEC 8327-1:1996 | Information technology - Open Systems Interconnection - Connection-oriented session protocol: Protocol specification |
[34] | IEC 60870-5-104(2006) | Telecontrol equipment and systems - Part 5-104: Transmission protocols - Network access for IEC 60870-5-101 using standard transport profiles |
[35] | IEC/TS 61850-80-1(2008) | Communication networks and systems for power utility automation - Part 80-1: Guideline to exchanging information from a CDC-based data model using IEC 60870-5-101 or IEC 60870-5-104 |
[36] | IEC 61850 series | Communication networks and systems for power utility automation |
[37] | IEC 60870-5-5(1995) | Telecontrol equipment and systems - Part 5: Transmission protocols - Section 5: Basic application functions |
[38] | RFC 1006 | ISO Transport Service on top of the TCP Version: 3 |
[39] | DNP3 Specification Volume 2 Application Layer, Version 2.01, 3 February 2007, DNP Users Group | |
[40] | DNP3 Specification Volume 3 Transport Function, Version 2.01, 3 February 2007, DNP Users Group | |
[41] | DNP3 Specification Volume 4 Data Link Layer, Version 2.01, 3 February 2007, DNP Users Group | |
[42] | DNP3 Specification Volume 6 DNP3 Object Library Part 1, Version 2.01, 3 February 2007, DNP Users Group | |
[43] | DNP3 Specification Volume 6 DNP3 Object Library Part 2, Version 2.02, 5 May 2007, DNP Users Group | |
[44] | DNP3 Specification Volume 7 IP Networking, Version 2.11, 3 February 2007, DNP Users Group | |
[45] | DNP3 Specificaiton Volume 8 Interoperability, Version 2.02, 20 February 2007, DNP Users Group | |
[46] | DNP3 Specification Volume 8 Appendix 1 Device Profile, Version 2.03, 30 May 2007, DNP Users Group | |
[47] | DNP Technical Bulletin TB2004-004e Data Sets, 30 March 2006, DNP Users Group |
УДК 621.311.24:006.354 | ОКС 27.180 | |
Ключевые слова: возобновляемая энергетика, ветроэнергетика, системы контроля, коммуникационные системы, модели обмена информацией |
Электронный текст документа
и сверен по:
, 2015