ГОСТ Р 54418.25.3-2014 (МЭК 61400-25-3:2006). Национальный стандарт Российской Федерации. Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-3. Коммуникации для текущего контроля и управления ветровыми электростанциями. Процессы передачи информации при отслеживании состояния и управления ветроэлектрическими установками

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

от 19 сентября 2014 г. № 1134-ст

(МЭК 61400-25-3:2006)

ОКС 27.180

1 июля 2016 года

Предисловие

1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский институт энергетических сооружений» (ОАО «НИИЭС») на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 330 «Процессы, оборудование и энергетические системы на основе возобновляемых источников энергии»

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

4 Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 61400-25-3:2006 «Турбины ветровые. Часть 25-3. Коммуникации для текущего контроля и управления ветровыми электростанциями. Модели информационного обмена» (IEC 61400-25-3:2006 «Wind turbines. Part 25-3. Communications for monitoring and control of wind power plants. Information exchange models») путем изменения отдельных фраз (слов, значений показателей), которые выделены в тексте курсивом

Внесение указанных технических отклонений направлено на учет особенности объекта и/или аспекта стандартизации, характерные для Российской Федерации

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

Группа стандартов ГОСТ Р 54418.25 устанавливает требования к информационной связи между компонентами ветроэнергетических станций, такими как ветротурбины и объекты системы управления и сбора данных (SCADA). Внутренние информационные связи между компонентами ветроэнергетических станций в группе стандартов ГОСТ Р 54418.25 не рассматриваются.

Группа стандартов ГОСТ Р 54418.25 предназначена для коммуникационной среды, поддерживаемой моделью клиент-сервер. Определены три области, сформированные отдельно, для обеспечения реализации масштабной модели:

1. информационные модели ветровой электростанции (ВЭС);

2. информационно-обменные модели (модели информационного обмена);

3. отображение моделей на стандартный профиль коммуникации.

Информационная модель ветровой электростанции и информационно-обменная модель рассматриваются вместе и представляют собой интерфейс между клиентом и сервером. В этой связке серверы информационной модели ВЭС служат для интерпретации доступных данных ветровой электростанции. Информационная модель ВЭС используется клиентским сервером для предложения унифицированной, компонентно-ориентированной точки зрения на ветровой электростанции. Информационно-обменная модель отражает все активные обмены сервера. Группа стандартов ГОСТ Р 54418.25 обеспечивает унификацию разнородных интерфейсов клиента и серверов разных производителей и поставщиков.

Концептуальная коммуникационная модель группы стандартов ГОСТ Р 54418.25 представлена на рисунке 1.

в группе стандартов ГОСТ Р 54418.25

В соответствии с рисунком 1 группа стандартов ГОСТ Р 54418.25 характеризует сервер по следующим аспектам:

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

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

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

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

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

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

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

Настоящий стандарт определяет сервисы моделирования обмена информацией в интеллектуальных электронных устройствах ветроэнергетических установок. Данные сервисы далее называются «Абстрактный интерфейс услуг связи (ACSI)». Интерфейс ACSI был определен как независимый от базовых систем связи.

Информационно-обменная модель определена в терминах:

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

Методика описания ACSI абстрагирована от всего разнообразия подходов к реализации взаимодействия различных устройств.

Эти определения абстрактных служб должны отражаться в конкретных определениях объекта, которые должны использоваться для специального протокола. Преобразование в стеки специального протокола изложено в ГОСТ Р 54418.25.4.

Примечания

1 Абстрагирование в ACSI имеет два значения. Первое — смоделированы только те аспекты реального устройства (например, ротор) или реальной функции, которые видны и доступны из сети связи. Это абстрагирование позволяет создать иерархические модели классов и их режимы, описанные в ГОСТ Р 54418.25.2. Второе — интерфейс ACSI абстрагирован от ряда аспектов конкретных определений (например, каким образом происходит обмен информацией между устройствами). Определено только концептуальное взаимодействие. Конкретный обмен информацией описан в ГОСТ Р 54418.25.2.

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

Настоящий стандарт определяет абстрактный интерфейс услуг связи (ACSI), описывающий связи между клиентом и удаленным сервером для:

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

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

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

ГОСТ Р МЭК 61850-7-2-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI) (МЭК 61850-7-2-2009, IDT)

ГОСТ Р 54418.25 (все части) Возобновляемая энергетика. Установки ветроэнергетические. Коммуникации для текущего контроля и управления ветровыми электростанциями

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

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

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

3.1 аналоговая информация ВЭС (wind power plant analogue information): Непрерывная информация о реальном состоянии или поведении системы или компонентов системы.

Пример - Измеренное значение, обрабатываемое значение, трехфазное значение, заданное значение, параметр.

3.2 ветровая электростанция; ВЭС (wind power plant): Электростанция, состоящая из двух и более ветроэнергетических установок, предназначенная для преобразования энергии ветра в электрическую энергию и передачи ее потребителю.

3.3 ветроколесо ветроэнергетической установки (wind turbine): Устройство для преобразования ветровой энергии в механическую энергию вращения ветроколеса.

3.4 внешняя система управления (actor): Система, принимающая участие в мониторинге, контроле за состоянием и режимом работы ВЭС, но не принимающая непосредственного участия в управлении оборудованием ВЭС, в частности, в управлении и сборе данных (SCADA).

Примечание - Существуют другие обозначения: «Центральная система управления», «Система мониторинга и контроля», «Система дистанционного управления».

3.5 диагностика коммуникационной системы (diagnostics): Управленческая функция, используемая для настройки и обеспечивающая самоконтроль и выявление причин сбоев в коммуникационной системе.

3.6 диспетчерский контроль (управление) и сбор данных (SCADA): Система, основанная на процессоре, который получает информацию от интеллектуальных электронных устройств (IED), определяет требования к контролю и посылает команды IED.

3.7 извлечение данных (data retrieval): Операционная функция, используемая для сбора данных о ВЭС.

3.8 измеренные данные (measured data): Выборка значений количественных оценок процесса и связанных с ним атрибутов, таких как метка времени и качества.

3.9 интеллектуальное электронное устройство (IED): Любое устройство, включающее один или несколько процессоров с функцией получения данных от внешнего отправителя или отправки данных на внешний приемник.

Пример - Контроллер ВЭУ может иметь соединения с другими контроллерами ВЭС как в качестве клиента, так и в качестве сервера, или одновременно и того и другого.

3.10 информация (information): Содержание сигналов, которыми обмениваются участники коммуникационной среды.

Примечание — Основным элементом информации являются необработанные данные от компонента ВЭС, которые должны быть переработаны в соответствии с требованиями группы стандартов ГОСТ Р 54418.25. Категории информации: источник информации (аналоговая, дискретная и др. информация), извлеченная информация (статистическая и накопленная информация).

3.11 информационный обмен (information exchange): Коммуникационный процесс между двумя системами (компонентами ВЭС и внешней системой управления) для передачи и получения соответствующей информации, требующий определенных коммуникационных функций, состоящих из одной или нескольких служб.

3.12 команда (command): Контролируемая информация о состоянии системы (разблокирована/заблокирована, активна/неактивна).

3.13 компонент ВЭС (wind power plant component): Техническая система, используемая в работе ВЭС, такая как ветровая турбина, система управления ВЭУ, метеорологическая или электрическая системы.

3.14 логическое устройство (logical device): Объекты, которые представляют собой набор типовых функций ВЭС.

3.15 метеорологическая система (meteorological system): Компонент ВЭС, отвечающий за мониторинг условий окружающей среды, например скорость и направление ветра, давление, температура и т.д. Система предоставляет данные для различных целей, например определения соотношения метеорологических данных и количества производимой электрической энергии отдельных ВЭУ для оценки использования энергии ветра.

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

3.17 необязательный к исполнению (optional): Контент, который может быть дополнительно представлен в соответствии с группой стандартов ГОСТ Р 54418.25.

3.18 обработанное значение (processed value): Измеренная величина с соответствующими атрибутами данных, такими как метка времени и качество, обработанная с использованием соответствующих атрибутов методов расчета.

3.19 обязательный к исполнению (mandatory): Контент, который должен быть представлен в соответствии с группой стандартов ГОСТ Р 54418.25.

3.20 операционная функция (operational function): Функция получения информации и передачи команд для нормальной повседневной эксплуатации ВЭС. Ее типы: мониторинг, ведение регистрационного журнала, отчетность, поиск данных, контроль.

3.21 отчет (report): Актуальная информация, посланная для обязательной отчетности. Отчет может содержать все виды информации, определенные в [3].

3.22 отчетность (reporting): Оперативная функция по передаче отчетных данных с сервера клиенту, инициированная процессом сервера.

3.23 параметр (parameter): Контролируемая информация, предназначенная для получения состояния или исправления поведения системы.

3.24 регистрационный журнал (log): Сборник информации о режиме и эксплуатационном состоянии ВЭС. Хронологический список источников информации за определенный период времени.

3.25 регистрация (logging): Оперативная функция записи последовательных данных (часто в хронологическом порядке) о режиме и состоянии ВЭС и ее компонентов, событиях с участием ВЭС и ее компонентов.

3.26 сигнализация (alarm): Система представления персоналу информации о состоянии ВЭС. За безопасностью ветроэнергетической установки следит система управления ветроэнергетической установки (ВЭУ).

3.27 система управления ВЭС (wind power plant management system): Компонент ВЭС, который отвечает за выбор, ведение и документирование режима работы ВЭС, обеспечивает адаптацию полной системы ВЭС к статическим и динамическим условиям работы и требованиям взаимодействия ВЭУ с электроэнергетической системой.

Примечание — Система управления ВЭС может включать в себя другие функции (например, функции контроля шума и звукоизоляции, предупреждение об обледенении, громоотвод), которые не описаны в группе стандартов ГОСТ Р 54418.25.

3.28 событие (event): Переходное состояние статуса, сигнала, команды.

3.29 статус (status): Параметр состояния компонента или системы (st1/st2/..stn).

3.30 три фазы данных (three phase data): Измеренное значение в трехфазной электрической цепи с соответствующими атрибутами данных (метка времени, качество и расчет).

3.31 управление (control): Оперативная функция, используемая для ввода и изменения параметров режима, вмешательства, контроля, параметризации и оптимизации режима и состояния ВЭС.

3.32 управление доступом (user/access management): Функция управления, используемая для настройки, изменения, удаления пользователей (административно), назначение прав доступа (административно) и контроля доступа.

Примечание - Функция управления может не включать услуги связи.

3.33 управленческая функция (management function): Функция управления обменом информацией на определенном уровне системы коммуникации. Функции управления обменом информацией — это управление вида доступа пользователям, синхронизация времени, диагностика и настройка.

3.34 функция связи (communication function): Функция информационного обмена с ВЭС, используемая разработчиком для настройки и контроля информационного обмена.

4 Обозначения и сокращения

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

ACSI — абстрактный интерфейс услуг связи (в соответствии с ГОСТ Р МЭК 61850-7-2);

FCD — функционально связанные данные;

FCDA — атрибут функционально связанных данных;

IED — интеллектуальное электронное устройство (ИЭУ);

IEM — модель информационного обмена;

LCB — управляющий блок регистрации;

LD — логическое устройство;

LN — логический узел;

LOG — регистрирование;

LPHD — логический узел физического устройства;

RCB — блок управления отчетами;

SCADA — диспетчерский контроль и сбор данных;

SCSM — специфическое отображение сервиса связи (определено в [1]);

SG — группа настроек;

WPP — ветроэнергетическая установка (ВЭУ);

WT — ветротурбина (ВТ);

XML — открытый язык разметки;

GUI — графический интерфейс пользователя.

5 Общие сведения

В настоящем стандарте рассмотрены информационно-обменные модели (модели информационного обмена), которые могут быть применены клиентом и сервером для доступа к содержимому и структуре информационной модели ВЭУ, определенной в [2].

В разделе 6 приведен обзор моделей информационного обмена для операционных и управляющих функций.

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

Раздел 8 дает обзор моделей информационного обмена для управляющих функций.

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

• прикладная ассоциация;
• класс сервера/Server;
• класс логического устройства/LogicalDevice (поиск самоописания и т.д.);
• класс логического узла/LogicalNode (поиск самоописания и т.д.);
• класс данных/Data (получение значения, установка значения, поиск самоописания и т.д.);
• класс набора данных/DataSet (получение значений, установка значений, создание набора данных, поиск самоописания и т.д.);
• класс управляющего блока отчета/Report Control Block (получение атрибутов, установка атрибутов, отчет и т.д.);
• классы управляющего блока регистрации/журналом и классы регистрирования/журнала (получение атрибутов, установка атрибутов, поиск записей регистрации и т.д.);
• класс управления/control (выбор, действие и т.д.).

Приложение А представляет собой примеры необходимых сервисов выдачи отчетов и регистрации.

В приложении Б представлена зависимость сервисов ACSI и функциональных ограничений.

В приложении В представлена зависимость между ACSI, определенным в ГОСТ Р МЭК 61850-7-2, и настоящим стандартом.

6 Обзор моделей информационного обмена

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

• операционные функции;
• управляющие функции.

Данные группы представлены и подробно описаны в следующих разделах.

Необходимые службы для каждой модели информационного обмена указаны в соответствующих таблицах в разделе 9.

Экземпляр информационной модели ВЭУ (логическое устройство, логический узел, данные, атрибуты данных и объекты блока управления) должен быть доступен экземплярам модели информационного обмена, приведенным в таблице 1. В первых двух столбцах таблицы перечислены функциональные группы и их модели информационного обмена, кратко описанные в третьем столбце. В четвертом и пятом столбцах определено, какие типы данных и принципы передачи применимы для каждой модели информационного обмена. В последней колонке отражены модели служб ACSI, используемые для соответствующих моделей информационного обмена.

Модели информационного обмена должны реализовываться соответствующими моделями ACSI и ассоциативными службами (как показано в последнем столбце таблицы 1). Цель таблицы — дать обзор общеупотребимой терминологии в домене ВЭУ.

Таблица 1

Функциональная группа	Модель информационного обмена	Краткое описание	Категории информации	Принципы передачи	Модели служб ACSI
Операционные (см. 7)	Авторизация (см. 7.2)	Аутентификация и ограничение доступа к операционным и управляющим функциям	Короткие текстовые сообщения	Передача данных по требованию Передача команды	ASSOCIATION
	Управление (см. 7.3)	Управление операционными устройствами	Команды установок	Передача команды Передача	CONTROL
	Мониторинг (см. 7.4)	Мониторинг текущих данных и изменений данных, вносимых операционными устройствами	Измеренные данные Обработанные данные (средние величины, Min/Max) Статус Тревога Событие Таймер Счетчик Установки Параметры Команды Данные временного ряда (Лог тревога/событие, Лог команд, Лог установок) (Аналоговые величины, двоичные величины)	Периодическая передача данных (все данные или только данные, которые изменились начиная с последней передачи) Передача данных по требованию Случаи самопроизвольной передачи данных	LOGICAL-DEVICE
					LOGICAL-NODE
					DATA
					DATA-SET
					BUFFERED-REPORT-CONTROL
					UNBUFFERED-REPORT-CONTROL
					LOG
					LOG-CONTROL
					(более подробные сведения о службах ACSI в 9)
	Отчетность и регистрация (см 7.4)	Управляемые триггером непрерывные просмотр и запись величин и событий	Записи (Логи) Отчеты Статистика Характеристики Тенденции События Короткие текстовые сообщения
Управляющие (см. 8)	Диагностирование (см. 8.5)	Самоконтроль устройств	Применимо к категориям информации мониторинга, отчетности и регистрирования	Периодическая передача данных (все данные или только данные, которые изменились начиная с последней передачи) Передача данных по требованию Случаи самопроизвольной передачи данных	LOGICAL-DEVICE
					LOGICAL-NODE
					DATA
					DATA-SET
					BUFFERED-REPORT-CONTROL
					UNBUFFERED-REPORT-CONTROL
					LOG
					LOG-CONTROL
					(более подробные сведения о службах ACSI в 9)
	Управление пользователями и доступом (см. 8.2)	Настройка пользователей, прав доступа и контроля доступа	Определено системой
	Установка (см. 8.3)	Управление конфигурацией устройства	Определено системой
	Синхронизация времени (см. 8.4)	Синхронизация времени устройства	Определено SCSM

7 Операционные функции

7.1 Общие сведения

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

• модель соединения и авторизации;
• модель управления;
• модель мониторинга, регистрации событий и составлении отчетов по событиям.

7.2 Модель соединения и авторизации

Рисунок 2 — Концепция модели соединения и авторизации

Требования к связи между клиентом и сервером следующие:

• установление подлинности: идентификация пользователь/клиент;
• авторизация и контроль доступа: гарантия наличия у пользователя надлежащих прав доступа (как минимум имя пользователя и пароль);

- безопасность: сообщения и компьютерная инфраструктура защищены от неразрешенной модификации или порчи;

• конфиденциальность: объекты информационной модели ВЭУ защищены и доступны только определенным пользователям/клиентам;
• защита от неправомерных отказов: предотвращения отрицания факта участия в обмене пользователем/клиентом, участвующем в обмене данными;
• предотвращение отказа устройства: предотвращение блокировки доступа клиентом/сервером авторизованным пользователям.

Реальные службы модели авторизации предусмотрены особыми отображениями <*>. Основанные на особых выбранных отображениях, фактический уровень безопасности и поддержка определенных сервисов могут быть различными.

---

<*> В международной практике представлены в [2]

7.3 Модель управления

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

Рисунок 3 — Концепция модели управления

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

Примечание — Процесс управления физическим объектом является локальной проблемой устройства, которое подключено к серверу. Группа стандартов ГОСТ Р 54418.25 определяет только внешнее видимое поведение устройства. Модель управления, определенная для сервера, обеспечивает несколько параметров, которые определяют процесс управления. Поведение клиента дополняет поведение сервера.

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

7.4 Модель мониторинга, регистрации и выдачи отчетов

Принципиальные модели информационного обмена для мониторинга, регистрации и выдачи отчетов представлены на рисунке 4. Модели включают в себя три независимых метода поиска информации:

• величины могут быть представлены клиенту согласно модели отчетности издатель/подписчик (средняя часть рисунка). Сервер конфигурируется (локально или службами эксплуатации) для передачи величин самопроизвольно или периодически. Клиент получает сообщения (отчеты) всякий раз, когда на сервере выполняются условия триггера. Модель издатель/подписчик может буферизировать события в случае, если линия связи не функционирует, и передать все буферизированные события по порядку, как только связь заработает снова, в случае буферизированного отчета. В случае небуферизированного отчета не гарантируется доставка событий если откажет линия связи;

Методы поиска		Срочный информационный обмен	Может терять изменения (порядка)	Возможность большому числу клиентов получать информацию	Последнее изменение данных произвел	Обычный клиент (но не исключительно)
Данные по запросу		НЕТ	ДА	ДА	-	Браузер
Отчетность	Подписка	ДА	ДА/НЕТ	ДА	Сервер	Графический интерфейс пользователя в реальном времени
	Небуферизированный отчет	ДА	ДА	ДА	-	Графический интерфейс пользователя в реальном времени
Отчетность	Буферизированный отчет	ДА	НЕТ	ДА	Сервер	Концентратор данных
Регистрирование		НЕТ	НЕТ	ДА	Клиент	Эксплуатация установки, технические станции

Каждый метод поиска имеет конкретные характеристики. Метода, удовлетворяющего всем требованиям применимости не существует. Во время системного проектирования проектировщик должен проанализировать требования и сравнить их с (примененными) методами, обеспечивающими совместимость устройства с ГОСТ Р 54418.25.

8 Функции управления

8.1 Основная часть

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

• пользовательская модель безопасности управления/доступа;
• модель установки;
• модель синхронизации времени;
• модель диагностики (самомониторинга).

Функциональные ограничения служб ACSI приведены в приложении В.

8.2 Пользовательская модель безопасности управления/доступа

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

8.3 Модель установки

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

8.4 Модель синхронизации времени

Для синхронизации различных часов в системе необходимо особое планирование, выбранное и установленное согласно [2].

8.5 Модель диагностики (самомониторинга)

Диагностика или функции самомониторинга предназначены для определения состояния системы, к примеру, полное функционирование устройства, частичное функционирование или бездействие. Информация, полученная в результате диагностирования, определена в логическом узле LPHD, который описан в [3].

9 ACSI для информационных моделей ветроэнергетических установок

9.1 Основные положения

Модели обмена информацией, определенные в разделах 7 и 8, являются кратким обзором моделей, требующих совместимости с ГОСТ Р 54418.25. Раздел 9 содержит подробное описание всего требуемого обслуживания.

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

Рисунок 5 — Концепция модели обмена информацией ВЭУ

Спецификация в данном разделе обеспечивает высокий уровень определения служб. Нормативное определение деталей служб и моделей ACSI установлено в ГОСТ Р МЭК 61850-7-2.

9.2 Службы соединения и авторизации

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

• класс определений соединений;
• принципы контроля доступа (как ограничить доступ к серверу).

Применение модели соединения определяет службы, управляющие соединениями между клиентом и сервером (прикладная ассоциация двух абонентов).

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

Таблица 3

Сервисы прикладной ассоциации двух абонентов	О/Н
Associate	О
Abort	Н
Release	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса прикладной ассоциации двух абонентов должны быть как определено ГОСТ Р МЭК 61850-7-2 (раздел 7).

9.3 Сервисы класса Server

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

Таблица 4

Сервисы SERVER	О/Н
GetServerDirectory	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса Server определены ГОСТ Р МЭК 61850-7-2 (раздел 6).

9.4 Сервисы класса LogicalDevice

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

LogicalDevice

Сервисы LOGICAL-DEVICE	О/Н
GetLogicalDeviceDirectory	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса LogicalDevice должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (раздел 8).

9.5 Сервисы класса LogicalNode

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

LogicalNode

Сервисы LOGICAL-NODE	О/Н
GetLogicalNodeDirectory	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса LogicalNode должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (раздел 9).

9.6 Сервисы класса Data

Данные DATA (например, состояние ротора) — это совокупность DataAtributes (например, фактическое значение, качество, метка времени). Любое DATA имеет значение в контексте его использования. Экземпляры класса DATA (т.е. DataAttributes) могут быть доступны напрямую для сервисов, приведенных в таблице 7.

Таблица 7

Сервисы DATA	О/Н
GetDataValues	О
SetDataValues	О
GetDataDirectory	Н
GetDataDefinition	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса Data должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (раздел 10).

Пример - GetDataValue «WindPowerPlant12/WGEN.PwrAt.phsA.cVal.mag.f[MX]» возвращает значение текущей величины с плавающей запятой.

9.7 Сервисы класса DataSet

Набор данных DATA-SET — это группа ссылок на DATA. Наборы данных могут быть доступны напрямую для сервисов, показанных в таблице 8. Наборы данных могут использоваться ReportControlBlocks для определения, какое DATA должно быть отслежено и сообщено в зависимости от определенных критериев (определен соответственно с DATA или ReportControlBlock).

Таблица 8

Сервисы DATA-SETs	О/Н
GetDataSetValues	О
SetDataSetValues	Н
CreateDataSet	Н
DeleteDataSet	Н
GetDataSetDirectory	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса DataSet должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (раздел 11).

Примечание

1 Набор данных DATA-SET только ссылается на данные DATA — он не содержит данных DATA. Если удалить набор данных DATA-SET, то данные DATA останутся.

2 Набор данных DATA-SET может пониматься как обеспечение кратких условных ссылок (обозначений) многих экземпляров класса DATA, которые могут быть доступны по одной ссылке — вместо списка ссылок. На наборы данных DATA-SETs ссылаются управляющие блоки для выдачи отчетов и регистрации.

9.8 Сервисы класса Report Control Block

9.8.1 ACSI совместимые сервисы

Управление отчетом REPORT-CONTROL обеспечивает непосредственно механизм выдачи отчета о величинах данных по некоторому условию (например, при изменении величины, качества информации или периодически). Работа управления отчетом REPORT-CONTROL обусловлена значениями их атрибутов (например, активность/неактивность выдачи отчетов, использование порядкового номера). Управление отчетом REPORT-CONTROL ссылается на экземпляр класса набора данных DATA-SET. Управление отчетом REPORT-CONTROL обеспечивает непосредственно сервис отчета Report; атрибуты экземпляра класса REPORT-CONTROL могут быть доступны напрямую для сервисов, указанных в таблице 9.

Таблица 9
REPORT-CONTROL
Сервисы	О/Н
Report	Н
GetBRCBValues	Н
SetBRCBValues	Н
GetURCBValues	Н
SetURCBValues	Н
AddSubscription <*> Н RemoveSubscription <*> Н <*> Сервисы AddSubscription и RemoveSubscription были добавлены в качестве специальной модели отчета, определенной ГОСТ Р МЭК 61850-7-2 (подраздел 14.2).

Блок управления буферизированным отчетом BRCB (BUFFERED-REPORT-CONTROL-BLOCK) обеспечивает гарантию функциональности того, что сервер посылает последовательность событий даже в случае временного нарушения связи. В случае с блоком управления небуферизированным отчетом URCB (UNBUFFERED-REPORT-CONTROL-BLOCK) серверу не нужно буферизовать события в случае временного нарушения связи.

Детали класса REPORT-CONTROL должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2).

Примечание - Модель выдачи отчетов состоит из двух независимых классов: класса блока управления отчетами и класса набора данных. Во-первых, набор данных может быть предопределен (сконфигурирован) или динамически определен сервисом CreateDataSet. Во-вторых, ссылка на набор данных (как атрибут блока управления отчетами) должна быть установлена (также сервисом SetBRCBValues (SetURCBValues). Оба этих этапа объединены в сервисе AddSubscription.

Базовый механизм выдачи отчетов показан на рисунке 2. Буферизированная и небуферизированная выдачи отчетов начинаются с конфигурации блока управления отчетами. Выдача отчетов начинается с установки активного атрибута блока управления буферизированными отчетами в позицию TRUE; установка атрибута в позицию FALSE останавливает выдачу отчетов. Методы выдачи отчетов просты и обеспечивают эффективный способ непосредственной передачи изменений.

Рисунок 6 — Концепция блока управления буферизированным отчетом

9.8.2 Сервис AddSubscription

Клиент должен использовать сервис AddSubscription для запроса сервера:

3. для начала наблюдения и немедленной выдачи отчета по величинам. Наборы данных DATA-SETs, созданные, используя сервисы AddSubscription, подчиняются правилам модели DATA-SET.

После обработки сервиса AddSubscription, сервер должен дать один единичный главный запрос, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2) для синхронизации отображения процесса клиентом с текущим отображением процесса сервером.

Сервис AddSubscription должен быть определен так, как показано в таблице 10.

Таблица 10

Сервис AddSubscription

Название параметра	Описание
Запрос
RCBRef	ReportControlBlockObjectReference Параметр RCBRef должен определить ссылку объекта ObjectReference блока управления отчетами, которая будет выбрана
RCBType	тип блока управления отчетами Параметр RCBType должен определить выбор типа блока управления отчетами, URCB или BRCB
ReportIdentifier [0..1]	ReportIdentifier Параметр ReportIdentifier должен содержать значение для соответствующего атрибута RptIDBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
ReportEnable [0..1]	ReportEnable Параметр ReportEnable должен содержать значение для соответствующего атрибута RptEnaBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2). Для URCB должно быть всегда по умолчанию выставлено в положение TRUE
DataSetReference	DataSetReference Параметр DataSetReference должен использоваться для создания DATA-SET в том случае, если DATA-SET не существует, иначе он обращается к существующему DATA-SET, который должен использоваться для выдачи отчетов. Параметр DataSetReference должен использоваться для установки величины соответствующего атрибута DatSetBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
OptionalFields [0..1]	OptionalFields Параметр OptionalFields должен содержать значение для соответствующего атрибута OptFldsBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
BufferTime [0..1]	BufferTime Параметр BufferTime должен содержать значение для соответствующего атрибута BufTmBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
TriggerOptions [0..1]	TriggerOptions Параметр TriggerOptions должен содержать значение для соответствующего атрибута TrgOpBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
IntegrityPeriod [0..1]	IntegrityPeriod Параметр IntegrityPeriod должен содержать значение для соответствующего атрибута IntgPdBRCB/URCB, на который ссылаются, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.2)
DSMemberRef [0..n]	Элемент набора данных ObjectReference Параметр DSMemberRef должен определять FCD или FCDA данных DATA так, как указано в ГОСТ Р МЭК 61850-7-2 (раздел 11)
Response+	Параметр Response+ указывает, что запрос сервиса завершился успешно. Если некоторые из FCD, на которые ссылаются, не будут доступны клиенту, то сервис завершился неудачно
Response-	Параметр Response- указывает, что запрос сервиса завершился неудачно
ServiceError	Должно вернуться соответствующее сообщение об ошибке ServiceError

9.8.3 Сервис RemoveSubscription

Клиент должен использовать сервис RemoveSubscription для запроса сервера на отключение соответствующего блока управления отчетами и подачи команды на удаление набора данных DATA-SET, на который ссылается его атрибут DataSet. При удалении набора данных DATA-SET должны быть применены те же самые правила сервиса DeleteDataSet.

Сервис RemoveSubscription должен быть определен так, как показано в таблице 11.

Таблица 11

Название параметра	Описание
Запрос
RCBRef	ReportControlBlockObjectReference Параметр RCBRef должен определить ссылку объекта ObjectReference блока управления отчетами, которая будет выбрана и отключена. Набор данных DATA-SET, на который ссылается этот блок управления отчетами, должен быть удален
Response+	Параметр Response+ указывает, что запрос сервиса завершился успешно
Response-	Параметр Response- указывает, что запрос сервиса завершился неудачно
ServiceError	Должно вернуться соответствующее сообщение об ошибке ServiceError

9.9 Сервисы блока управления журналом и классы журнала

Управление журналом LOG-CONTROL обеспечивает механизм занесения значений данных в журнал по заданному критерию (например, при изменении величины, качества информации, при обновлении счетчика или периодически). Поведение LOG-CONTROL обусловлено значениями его атрибутов (например, активность/неактивность регистрации). LOG-CONTROL ссылается на экземпляры класса DATA-SET.

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

Таблица 12
Журнал LOG и управление журналом LOG-CONTROL
Сервисы блока управления журналом LOGControlBlock	О/Н
GetLCBValues	Н
SetLCBValues	Н
Сервисы для журналов LOGs
GetLogStatusValues	Н
QueryLogByTime <*> Н QueryLogAfter <*> Н <*> Сервис должен обеспечить — как специализация LOG, как определено ГОСТ Р МЭК 61850-7-2 (подраздел 14.3), — параметр фильтра, для выбора одних или более FCD или FCDA данных DATA, которые будут запрошены.

Н — необязательный к исполнению.

Детали класса LOG-CONTROL и класса LOG должны быть такими, как определено в ГОСТ Р МЭК 61850-7-2 (подраздел 14.3).

DataFilter, в соответствии с таблицей 13 должен быть добавлен к запросу QueryLogByTime и запросу QueryLogAfter.

Таблица 13

Data filter

DataFilter [0..n]	datafilterObjectReference Параметр DataFilter должен определять FCD или FCDA данных DATA. Если параметр фильтра данных не включен [0] тогда никакая фильтрация данных не применяется. Для выбора данных DATA используются только параметр RangeStartTime совместно с параметром RangeStopTime или входные параметры.

9.10 Сервисы класса control

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

Модель CONTROL обеспечивает сервисы, представленные в таблице 14.

Таблица 14

CONTROL

Сервисы	О/Н
Select	Н
SelectWithValue	Н
Cancel	Н
Operate	О
CommandTermination	Н
TimeActivatedOperate	Н
Примечание — В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

Детали класса CONTROL должны быть такими, как определено ГОСТ Р МЭК 61850-7-2 (раздел 17).

Приложение А (обязательное)

ПРИМЕРЫ СЕРВИСОВ ВЫДАЧИ ОТЧЕТОВ И РЕГИСТРАЦИИ

А.1 Пример выдачи отчетов

Рисунок А.1 — Отображение моделей информации в наборах

В данном примере в отчет вносятся только те значения, которые изменились с момента последнего отчета об этих данных. Каждое изменение величины будет инициировать запуск нового отчета, в который будут внесены новые величины. Как только измененные значения отправляются в отчете, показания значений этих данных вносятся в так называемую «включенную битовую строку». Эта битовая строка содержит столько же битов, сколько содержит элементов набор данных DataSet. Значение первого элемента изменилось, и поэтому первый бит был установлен в положение TRUE. Получатель может определить из позиции в битовой строке, что значение было получено от данных «WindPowerPlant12/WGEN.W.phsA.cVal.mag.f».

Полный идентификатор объекта «WindPowerPlant12/WGEN.W.phsA.cVal.mag.f» может быть передан (опционально), однако это не обязательно.

Отчет опционально может содержать параметры:

• Идентификатор отчета (RpdID) — задается клиентом вручную;
• Порядковый номер — для выявления утерянных частей;
• Подпорядковый номер — если значения не вмещаются в один отчет;
• Ссылка DataSet — «MyDS»;
• Условие выдачи отчета (код условия) — изменение данных, качества и т.д.

А.2 Пример регистрации

Пример регистрации показан на рисунке А.2.

Рисунок А.2 — Основы регистрации (пример)

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

• текущего значения (например, значения с плавающей запятой).

• NewEntryTime (метка времени самого нового события),
• OldEntry (идентификатор самого старого события),
• NewEntry (идентификатор самого нового события).

Эти атрибуты могут быть прочитаны.

Сервис запроса журнала QueryLog позволяет найти записи журнала в некотором интервале времени (между временем 1 и временем 2) или по метке времени и id записи, после которых должны быть возвращены данные (id записи обязателен, т.к. в журнале может содержаться множество записей при одной и той же метке времени).

(обязательное)

Сервисы	О/Н	Сервис, применяемый с FC
Associate	О	-
Release	Н	-
Abort	Н	-
GetServerDirectory	Н	-
GetLogicalDeviceDirectory	Н	-
GetLogicalNodeDirectory	Н	-
GetDataValues	О	CF, DC, ST, MX, SP, EX
SetDataValues	О	CF, SP
GetDataDirectory	Н	CF, DC, ST, MX, SP, CO, EX
GetDataDefinition	Н	CF, DC, ST, MX, SP, CO, EX
GetDataSetValues	О	-
SetDataSetValues	Н	-
CreateDataSet	Н	DataSetReference не имеет связанных FC, но составляющие ее элементы могут быть любого FC
DeleteDataSet	Н	-
GetDataSetDirectory	Н	-
Report	Н	Отчет может включать элементы любого FC См. примечание 1
GetBRCBValues	Н	BR
SetBRCBValues	Н	BR
GetURCBValues	Н	RP
SetURCBValues	Н	RP
AddSubscriptiona	Н	RP, BR
RemoveSubscriptiona	Н	RP, BR
GetLCBValues	Н	LG
SetLCBValues	Н	LG
GetLogStatusValues	Н	LG
QueryLogByTimea	Н	LogEntry может включать элементы любого FC См. замечание 2
QueryLogAftera	Н	LogEntry может включать элементы любого FC См. замечание 2
Select	Н	CO
SelectWithValue	Н	CO
Cancel	Н	CO
Operate	О	CO
CommandTermination	Н	CO
TimeActivatedOperate	Н	CO
Примечания 1 Лишь изменения в величине элементов, определенные в международной практике в [[3]](#p100725), с TrgOp «dchg», «qchg», «dupd» будут создавать вносимые в отчет события. 2 Лишь изменения в величине элементов, определенные в международной практике в [[3]](#p100725), с TrgOp «dchg», «qchg», «dupd» будут создавать вносимые в журнал события. 3 В настоящей таблице использованы следующие обозначения: О — обязательный к исполнению; Н — необязательный к исполнению.

(Справочное)

Требования к автоматизации ветроэнергетической установки похожи, но не точно, на требования к системам автоматизации подстанций. Следствием этих различий является то, что необходимость в некоторых классах ACSI, определенных в ГОСТ Р МЭК 61850-7-2 и предусматривающих вполне конкретное функциональное назначение, отпадает в группе стандартов ГОСТ Р 54418.25.

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

• Substitution (замещение);
• Файлы: В группе стандартов ГОСТ Р 54418.25 не рассмотрено как происходит обмен файлами, однако при возникновении необходимости это будет сделано.

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

• SGCB: Блок управления группой настроек (SettingGroupControlBlock). Все настройки системы будут использовать функциональное ограничение FC. Это означает отсутствие различных групп настроек, предварительно сконфигурированных в сервере;
• GoCB: Блок управления общими объектно-ориентированными событиями на подстанции (GOOSEControlBlock). Блок управления событиями высокого приоритета между защитным устройством в подстанции;
• GsCB: Блок управления общим событием состояния (GSSEControlBlock). Блок управления событиями высокого приоритета между защитным устройством в подстанции;
• MSVCB: Блок многоадресного контроля выборочных значений (MulticastSampledValuesControlBlock);
• USVCB: Блок одноадресного контроля выборочных значений (UnicastSampledValuesControlBlock);

МЭК 61850-7-2 допускает наличие только одного журнала LOG в каждом логическом устройстве LogicalDevice. Это ограничение было изменено в настоящем стандарте таким образом, что журналы LOGs будут привязаны к логическим узлам LogicalNodes так, что более чем один экземпляр может быть создан и привязан к соответствующему ему логическому узлу LogicalNode.

ACSI, определенный в ГОСТ Р МЭК 61850-7-2 (рисунок 3), описывает взаимосвязь между различными элементами, составляющими ACSI в области автоматизации подстанции. Рисунок В.1 описывает взаимосвязь в настоящем стандарте.

Рисунок В.1 — Концептуальная модель сервиса ACSI

БИБЛИОГРАФИЯ

[1]	МЭК 61850-8-1:2004	Сети и системы связи на подстанциях. Часть 8. Специфическое отображение сервиса связи (SCSM) — Описание передачи данных по протоколу MMS (ИСО/МЭК 9506 — Часть 1 и Часть 2) и по протоколу ИСО/МЭК 8802-3
[2]	МЭК 61400-25-4:2008	Установки ветроэнергетические. Часть 25-4. Коммуникации для текущего контроля и управления ветровыми электростанциями. Отображение совокупности параметров в процессах передачи информации
[3]	МЭК 61400-25-2:2006	Установки ветроэнергетические. Часть 25-2. Коммуникации для текущего контроля и управления ветровыми электростанциями. Информационные модели

---