База ГОСТовallgosts.ru » 27. ЭНЕРГЕТИКА И ТЕПЛОТЕХНИКА » 27.180. Энергетические системы ветровых турбин

ГОСТ Р 54418.25.5-2013 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям

Обозначение: ГОСТ Р 54418.25.5-2013
Наименование: Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям
Статус: Действует

Дата введения: 07/01/2015
Дата отмены: -
Заменен на: -
Код ОКС: 27.180
Скачать PDF: ГОСТ Р 54418.25.5-2013 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям.pdf
Скачать Word:ГОСТ Р 54418.25.5-2013 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям.doc


Текст ГОСТ Р 54418.25.5-2013 Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические. Часть 25-5. Коммуникации для текущего контроля и управления ветровыми электростанциями. Проверка соответствия техническим требованиям



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ


НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ


ГОСТР

54418.25.5-

2013

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

Возобновляемая энергетика. Ветроэнергетика. Установки ветроэнергетические

Часть 25-5

КОММУНИКАЦИИ ДЛЯ ТЕКУЩЕГО КОНТРОЛЯ И УПРАВЛЕНИЯ ВЕТРОВЫМИ ЭЛЕКТРОСТАНЦИЯМИ

Проверка соответствия техническим требованиям

IEC 61400-25-5:2006

Wind turbines — Part 25-5: Communications for monitoring and control of wind

power plants — Conformance testing (MOD)

Издание официальное

Москва

Стандартинфоры

2014

Предисловие

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

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

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

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

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р1.5—2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА

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

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

© Стандартинформ.2014

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

Содержание

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

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

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

4    Сокращения.......................................................

5    введение в проверку на соответствие стандарту................................

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

5.2    Процедуры тестирования на соответствие.................................

5.3    Гарантия качества и тестирование......................................

5.4    Тестирование...................................................

5.5    Отчет о тесте соответствия...........................................

6    Проверка устройства на соответствие стандарту................................

6.1    Общие руководящие принципы........................................

6.2    Стандартные процедуры тестирования...................................

6.3    Процедуры тестирования соответствия...................................

7    Промышленные испытания..............................................

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

7.2    Коммуникационная задержка..........................................

7.3    Синхронизация времени и точность......................................

7.4    Тест на устойчивость...............................................

Приложение А (справочное) Примеры процедуры тестирования.......................

Приложение ДА (обязательное) Сведения о соответствии ссылочных национальных и межгосударственных стандартов международным стандартам, использованным в качестве ссы лочных в примененном международном стандарте

Библиография...................................

Введение

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

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

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

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

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

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

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

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

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

Группа стандартов дает полное описание принципов и моделей, используемых в группе стандартов ГОСТ Р 54418.25.

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

<


Субъект,

например,

SCAOA


Примечание


Г


Внешняя область действия


Клиент


Информационнообменная модель (получение,установка, доклад, регистрация, контроль, публикация, подписание и т.л.) определена в проекте стандарта ГОСТ Р 54418.25.3


Сообщение через типографию коммуникационного профайла

(прочитано, написано, доставлено) определено в проекте стандарта ГОСТ Р 64418.25.4


Г~

Информационная модель ветровой электростанции определена в проекте стандарта ГОСТ Р 64418.25.2



Сервер

Внешняя область действия


Информационно-обменная модель (получение, установка, доклад, регистрация, контроль, публикация, подписание и т.п.) определена в проекте стандарта ГОСТ Р 54418.25.3


Информационная модель ветровой электростанции (скорость ротора, нарушенные статусы, итоговое производство энергии и т.п.) определена в проекте стандарта ГОСТ Р 54418.25.2


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


Компонент ветровой электростанции^ например, ветровая турбина



ГОСТ Р 54418.25.5—2013


ГОСТР 54418.25.5—2013 {МЭК 61400-25-5:2006)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Возобновляемая энергетика. Ветроэнергетика.

Установки ветроэнергетические

Часть 25*5

КОММУНИКАЦИИ ДЛЯ ТЕКУЩЕГО КОНТРОЛЯ И УПРАВЛЕНИЯ ВЕТРОВЫМИ

ЭЛЕКТРОСТАНЦИЯМИ

Проверка соответствия техническим требованиям

Renewable power engineering. Wind power engineering. Wind turbines — Part 25-5; Communications for monitoring and

control of wind power plants — Conformance testing

Дата введения — 2015—07—01

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

Настоящий стандарт устанавливает процедуры испытаний (тестирования), которые должны быть проведены для определения соответствия коммуникационной системы ветровой электростанции (ВЭС) требованиям стандарта.

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

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

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

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

Примечание — Для получения общей картины необходимо использовать другие стандарты группы ГОСТ Р 54418.25.

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

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

ГОСТ Р ИСО/МЭК 9646-1—93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 1. Общие положения

ГОСТ Р 51237—98 Нетрадиционная энергетика. Ветроэнергетика. Термины и определения

ГОСТ РМЭК 61850-7-1—2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 1. Принципы и модели

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

ГОСТ Р МЭК 61850-7-4—2011 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 4. Совместимые классы логических узлов и классы данных

ГОСТ 15971—90 Системы обработки информации. Термины и определения

Издание официальное

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

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

В настоящем стандарте применены термины ло ГОСТ Р 51237. ГОСТ 15971. а также следующие термины с соответствующими определениями:

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

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

3.3    местный приемочный тест (SAT): Проверка данных, контрольных точек и правильной работы устройства и его операционной среды на месте сооружения ВЭУ.

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

3.5    модель реализации соответствующего элемента (MICS): Детализация стандартных элементов модели объекта, поддерживаемых системой или устройством.

3.6    негатив-тест (negative test): Тест для проверки корректного ответа устройства илисистемы.

3.7    проверка образца (type test): Проверка корректного поведения системных компонентов ВЭС с помощью системы тестирования программного обеспечения при условиях, соответствующих техническим.

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

3.8    протокол реализации соответствующего элемента (PICS): Сводка возможностей тестируемой системы.

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

Примечание — PIXIT не подвергается стандартизации.

3.10    системный тест (system test): Проверка работоспособности компонентов и всей ВЭС в различных режимах работы.

Примечание — Системный тест является заключительным этапом разработки системного компонента

ВЭУ.

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

3.12    стандартный тест (routine test): Тест, выполняемый производителем для проверки работоспособности и безопасности устройства.

3.13    тестирующая организация (test facility): Организация, которая может обеспечить соответствующее испытательное оборудование и предоставить обученный штат для тестирования на соответствие стандарту.

Примечание — Тестирование на соответствие стандарту и полученная информация должны соответствовать системе качестве.

3.14    тестовое оборудование (test equipment): Все элементы ВЭС и инструменты, которые моделируют и проверяют ее работу, такие как ветроэнергетическая установка, коммутационная аппаратура. преобразователи, сетевые центры управления или соединенные телекоммуникационные модули на одной стороне, линии связи между системными компонентами ВЭС.

4    Сокращения

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

ACSi — абстрактный коммуникационный интерфейс службы модели:

BRCB — буферизованный отчет блока управления:

OUT — испытываемое устройство;

FAT — заводские испытания;

GI — главный запрос;

HMI — интерфейс человек-машина;

IED — интеллектуальное электронное устройство:

IP — межсетевой интернет-протокол;

LCB — блок контроля регистрации;

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

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

MICS — модель реализации соответствующего элемента;

PICS — протокол реализации соответствующего элемента;

PIXIT — протокол реализации дополнительной информация для тестирования:

RCB — контрольный блок:

RTU — удаленный терминал:

SAT — эксплуатационные испытания;

SCAOA — система диспетчерского контроля и сбора данных;

SCSM — топография конкретного коммуникационного сервиса;

SOE — порядок событий;

SUT — испытуемая система;

ТРАА — две части программы ассоциации;

URCB — небуферизованный отчет блока управления:

UTC — координация времени;

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

5    Введение в проверку на соответствие стандарту

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

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

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

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

5.2    Процедура тестирования на соответствие

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

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

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

•    отсутствие точного критерия оценки полноты (завершенности) тестов. Могут быть проверены многие возможные ситуации во всех нормальныхэксплуатационных режимах, но. возможно, не для всех вероятных случаев отказа:

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

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

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

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

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

5.3 Гарантия качества и тестирование

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

Для того чтобы гарантировать качество во время проверки на соответствие стандарту, система гарантии качества должна быть на месте эксплуатации ВЭУ.

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

5.3.2    План обеспечения качества

5.3.2.1    План обеспечения качества теста на соответствие

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

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

План обеспечения качества теста на соответствие должен содержать:

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

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

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

•    метод управления отклонениями и изменениями на всех этапах испытаний:

•    процедуру подписания и описание предоставляемой для этого документации.

5.3.2.2    Тест и инспекционный план

План обеспечения качества теста на соответствие должен содержать описание теста и инспекционный плач. В этот план должна быть включена следующая информация:

•    что будет осмотрено, протестировано и зарегистрировано:

•    цель инспекции и испытаний;

•    процедуры и стандарты, по которым инспекции, тесты и регистрация будут выполнены;

•    ожидаемые результаты инспекций и тестов;

•    список людей, выполняющих инспекцию, тесты и регистрацию.

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

План обеспечения качества теста на соответствие должен содержать предложения по приостановке. освидетельствованию и наблюдению при выполнении теста и инспекционного плана.

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

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

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

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

5.4 Тестирование

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

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

•    устройство для теста;

•    протокол реализации соответствующего элемента (PICS):

•    протокол реализации дополнительной информация для тестирования (PIXIT):

•    модель реализации соответствующего элемента (MICS);

•    инструкции, детализирующие установку и работу устройства.

Требования для проверки на соответствие стандарту попадают в две категории:

а)    статические требования соответствия (определяют требования реализации);

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

Статические и динамические требования соответствия должны бытьолределены ePICS. PICScny-жит трем целям:

1)    выбор соответствующего набора тестов;

2)    гарантирование того, что тесты, соответствующие требованию соответствия, выполняются;

3)    обеспечение основы для анализа статического соответствия.

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

В дополнение к PICS должен быть обеспечен документ PIXIT. Процесс оценки соответствия показан на рисунке 2.

Рисунок 2 — Концептуальный процесс оценки соответствий

5.4.2 Тестирование устройства

Отдельное устройство должно быть протестировано отдельным тестовым устройством.

Особые тесты соответствия устройства содержат при необходимости положительное и отрицательное тестирование следующего:

- контроль документации и версии управления устройства:

•    тест файла конфигурации устройства в зависимости от устройства, относящегося к модели:

•    тест связи реализуется в зависимости от применяемого SCSM:

•    тест реализованных служб ACSI в зависимости от определения ACSI;

•    тест дополнительных расширений устройства согласно правилам данного стандарта.

5.5 Отчет о тесте соответствия

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

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

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

•    имя и адрес поставщика:

•    имя и адрес инициатора теста соответствия качества (если они отличаются от имени и адреса поставщика);

•    название протестированного устройства;

•    все виды протестированного устройства (аппаратные средства, встроенное микропрограммное обеспечение, и т. д.);

•    имя и адрес тестирующего учреждения;

•    дата выпуска тестового отчета;

•    имя и подпись тестера;

•    уникальный номер ссылки;

•    список объектов тестирования, необходимых для проверки соответствия качества;

•    комментарии и проблемы;

•    комплект документации для каждого объекта тестирования, включающий в себя:

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

•    ссылка на раздел и абзац стандарта группы стандартов ГОСТ Р 54418.25;

•    уникальный идентификатор на тестовое изделие;

•    результат испытаний: тест пройден, не пройден, неокончательный, результат неприменимый;

•    сравнение полученного результата испытаний сожидаемым результатом.

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

Документация о тесте на соответствие должна быть предоставлена инициатору.

6 Проверка устройства на соответствие стандарту

6.1    Общие руководящие принципы

6.1.1    Тестовая методика

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

Динамическое поведение должно быть протестировано должным образом при использовании четко определенных тестовых данных.

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

Воздействие коммуникационного метода (клиент-сервер. FTP/IP и т. д.), используемого устройством при тестировании, необходимо рассмотреть должным образом в процедурах тестирования. Проверка функциональных приложений не является частью теста соответствия, даже если усовершенствованные инструменты могут предложить такой анализ.

6.1.2    Архитектура системы тестирования

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

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

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

•    тестовую конфигурацию аппаратных средств системы тестирования:

•    тестовую конфигурацию программного обеспечения системы тестирования:

-    тестовое моделирование, фоновое средство моделироеания илиустройстео синхронизации времени.

6.2 Стандартные процедуры тестирования

6.2.1    Контроль документации и управление версиями устройства

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

-    PICS:

-    управление версиями;

•    документация поставщика.

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

•    синхронизация времени;

•    добавление меток времени;

-    потеря связи.

6.3 Процедуры тестирования соответствия

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

Настоящий подпункт описывает требования процедуры тестирования, тестовую структуру, объекты (что должно быть протестировано), формат и несколько примеров процедур тестирования (как это должно быть протестировано).

6.3.2 Требования к процедуре тестирования

Процедура тестирования должна удовлетворять следующим требования:

•    совокупность тестовых данных должна описывать объекты тестирования: процедура тестировав ния описывает как исполнитель тестирования или система тестирования должны выполнить тест;

•    совокупность тестовых данных должна включать в себя ссылочный документ;

•    результаты испытаний должны быть воспроизводимыми:

•    проведение тестирования должно быть в достаточной степени автоматизировано, человеческое вмешательство должно быть минимизировано;

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

•    проверка поведения устройства на задержку потерянного, дублированного и неиспорченного пакетов;

•    конфигурация, реализация, риски работы;

•    несоответствие именам, параметрам, настройкам или типам данных;

•    превышение определенных пределов, диапазонов или времени;

•    вынужденные ситуации для тестирования отрицательных ответов;

•    проверка всех (управление) стационарных путей коммуникаций агрегата;

•    вызов одновременных операций управления от многократных клиентов:

•    тесты ACSI сосредотачиваются на прикладном уровне (отображение);

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

•    тест включает в себя тестирование версий, моделей данных и конфигурационного файла и использует серийную терминологию ГОСТ Р ИСО/МЭК 9646-1.

Процедуры тестирования должны быть обрисованы так. как это показано на рисунке 4. В таком формате документа процедура тестирования может также быть использована в качестве тестового отчета. Несколько примеров процедуры тестирования приведены е приложении А.

Ссылка на тест <ACSI modeixP/NJp/eJxnunber*


6.3.3    Структура теста

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

а)    документация и версии управления (настоящий стандарт);

б)    модельданных(см.(2));

в)    отображение моделей ACSI и служб (см. (3]); соответствующие подпункты, определяющие абстрактные объекты, приведены в скобках:

•    объединение применений (6.3.4.5);

•    сервер, логическое устройство, логический узел, модель информации (6.3.4.6):

•    набор данных (6.3.4.3);

•    отчетность (6.3.4.7);

•    эапись(6.3.4.9);

•    контроль(6.3.4.10);

-    время и синхронизация времени (6.3.4.11).

6.3.4    Тестовые данные для тестирования сервера

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

В настоящем стандарте определены абстрактные варианты теста (см. 6.3.4.5— 6.3.4.12). Абстрактные варианты теста должны использоваться для определения конкретных вариантов теста и его запуска.

Примечания

1    Тестирование методом черного ящика объектов зависит от среды системы тестирования, то есть, главным образом, от языка сценария тестирования. Конкретные объекты должны быть обеспечены тестовыми средствами, согласованными с участниками рынка.

2    Для тестов сервера может потребоваться генератор базовой нагрузки. Определение базовой нвгрузки выходит за рамки группы стандартов ГОСТ Р 54418.25.

6.3.4.2    Документация и обзор процедуры тестирования версии системы управления Проверьте, htoPICS производителя. MICS и документация PIXIT и аппаратные и программные версии соответствуют DUT (см. (1J).

6.3.4.3    Объекты модели дднных Модель тестирования данных должна:

•    проверять присутствие обязательных объектов для каждого LN (присутствие — «М», отсутствие — «О»);

•    проверять отсутствие условно присутствующих ложных объектов;

-    проверять тип данных всех объектов для каждого LN;

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

Результат испытаний — список ссылок на объект с типом данных, классом общих данных, типом атрибута данных и индикация присутствия МО ([2]).

Расширения данных модели должны быть проверены согласно стандартизированным правилам расширения, включая использование пространств имен. Специфичные для производителя расширения модели данных должны быть задокументированы. Для 3ToroMICS должен включать есебя определения логических узлов, классы общих данных и атрибуты данных в формате, как в [2].

Отображение модели данных должно быть проверено:

> подлине имени и объектного расширения;

-    по организации функциональных компонентов;

•    по именованию управляющих блоков и журналов.

6.3.4.4    Отображение моделей ACSI и объектов служб

Тестовые позиции должны быть сгруппированы етаблицыидолжныотражатьследующие службы:

•    ассоциация приложения (Ass);

-    сервер, логическое устройство, логический узел, данные и модель атрибута данных (Srv);

-    отчет модели управления (Rpt);

-    регистр модели управления (Log);

•    модель управления (Cti);

-    время и модель синхронизации времени (Тм).

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

•    положительный — проверка нормальных условий, обычно приводящих кответу «+»;

•    отрицательный — проверка аварийных условий, обычно приводящих кответу «-».

Ю

Объект обязателен еслучае. когда применимая модель ACSI и служба ACSI поддерживаются OUT. Это определяется в PICS согласно ГОСТ Р МЭК 61850*7*2 (приложение А).

6.3.4.5 Ассоциация приложения

6.3.4.5.1 Положительный

Таблица 1

вариант

Описание варианта испытания

S.AS81

Ассоциация и релиз ТРАА (ГОСТ Р МЭК 61850*7*2 (подраздел 7.4)

S_Ass2

Ассоциация и клиентское аварийное прекращение работы ТРАА (ГОСТ Р МЭК 61850-7-2 (подраздел 7.4)

S.A883

Ассоциация с максимальным количеством клиентов одновременно (PIXIT)

6.3.4.5.2 Отрицательный

Таблица 2

вариант

Описание варианта испытания

S_A8S N1

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

S.A88 N2

Проверить, что с неправильными параметрами ассоциации на сервере или в клиенте происходит сбой ассоциации (ГОСТ Р МЭК 61850-7-2 (подраздел 7.4) PIXIT)

S_A88 N3

Установить максимум «плюс 1* ассоциации, проверить, что прошлая ассоциация устранена

S_A83 N4

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

S.A88 N5

Прервать и восстановить электропитание. OUT должен принять запрос ассоциации, когда будет готов

6.3.4.6 Сервер, логическое устройство, логический узел, данные и модель атрибута данных

6.3.4.6.1 Положительный

Таблица 3

Вариант

Описание варианта испытания

S_Srv 1

Запросить GetServerOirectory (логическое устройство) и проверить ответ (ГОСТ Р МЭК 61850-7*2 (пункт 6.2.2)

S_Srv 2

Для каждого ответа GetServerOirectory (логическое устройство) запросить GetlogicalDeviceDlrectory и проверить ответ (ГОСТ Р МЭК 61850-7*2 (пункт 8.2.1)

S_Srv3

Для каждого ответа GetLogicaiOevtceDirectory запустить GetLogealNodeDirectory (данные) и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 9.2.2)

S_Srv 4

Для каждого ответа GetLogicaiNodeDlrectory (данные) запросить:

•    GetOataOlrectory и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.4);

•    GetDataOefinltlon и проверить ответ ГОСТ Р МЭК 61850-7-2 (пункт 10.4.5);

•    GetOataValuee и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.2)

S_Srv5

Запустить один запрос GetOataValues с максимальным количеством значений данных и проверить ответ

S_Srv 6

Для каждого объекта данных с разрешением записи провести запрос SetOataValues и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.2)

S_Srv 7

Запустить один запрос SetOataValues с максимальным количеством значений и проверить ответ

6.3.4.6.2 Отрицательный

Таблице 4

Вариан!

Описание варианта испытания

S_Srv N1

Запросить информационные службы с неправильными параметрами (неизвестный объект, несоответствие случая, неправильное логическое устройство или неправильный логический узел) и проверить ответ — ошибка спужбы:

•    ServerOirectory (логическое устройство) (ГОСТ Р МЭК 61850-7-2 (пункт 6.2.2):

•    GetLogtcaOeviceOrectory (ГОСТ Р МЭК 61850-7-2 (пункт 8.2.1):

•    GetLogteaNodeDirectory (данные) (ГОСТ Р МЭК 61850-7-2 (пункт 9.2.2):

•    OetAltDataValuee (ГОСТ Р МЭК 61650-7-2 (пункт 9.2.3);

•    GetDataValues (ГОСТ Р МЭК 61650-7-2 (пункт 10.4.2):

- SetDataValues (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.3);

•    GetOataDirectory (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.4);

•    GetDataDefinmon (ГОСТ Р МЭК 61650-7-2 (пункт 10.4.5)

S_Srv N2

Запросить SetDataValues из перечисленных значений данных из диапазона и проверить ответ — ошибка службы (ГОСТ Р МЭК 61650-7-2 (пункт 10.4.2)

S.Srv N3

Запросить SetOateVaiues о несоответствии значения данных (например, интервап холостого хода) и проверьте ответ — ошибка службы (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.2)

S.Srv N4

Запросите SetDataValues на значения данных только для чтения и проверьте ответ — ошибка службы (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.2))

6.3.4.7 Модель набора данных

6.3.4.7.1 Положительный

Таблица 5

Вариант

Описание варианта испытания

S_Ds1

Запросить GetLogicalNodeOrectory (логическое устройство) и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 9.2.2). Для каждого ответа проблемы:

•    запросить GetDataSetValues и проверить ответ (ГОСТ Р МЭК 61650-7-2 (пункт 11.3.2);

•    запросить GetOataSelDIreclory и проверить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.6)

S_Ds2

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

S_Da3

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

S_De4

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

S_De5

Создать и уделить неустойчивый набор данных, создайте набор данных снова с тем же самым именем, имеющим одно дополнительное значение двнных/перенастроенным элементам, и проверить элементы

S_De6

Создать неустойчивый набор данных, запустить/прервать ассоциацию, связаться снова и проверить, что набор данных был удален (ГОСТ Р МЭК 61850-7-2 (подраздел 11.1}

S_Ds7

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

S_Ds8

Создать и уделить стабильный набор данных и проверить, что каждый набор данных может создаваться обычно: повторить процесс создания и удаления однажды

S_De9

Создать и удалить неустойчивый набор данных и проверить, что каждый нвбор данных может создаваться обычно: повторите процесс создания и уделения однажды

S_Os10

Проверить SetOataSetValues/GetDataSetVaiues с GetDataValues и SetDataVaiues

6.3.4.7.2 Отрицательный

Таблица 6

вариант

Описание варианта испытания

S.D8N1

Запросить следующие службы набора данных с неправильными параметрами (неизвестный объект, несоответствие случая, неправильное логическое устройство или неправильный логический узел), и проверить ответ— ошибка службы:

•    GetDataSetValuee (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.2);

•    SetDetaSetValues (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.3у.

•    CreateDataSet (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.4):

•    OeleteOataSet (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.S):

•    GetOataSetDIrectory (ГОСТ Р МЭК 61850-7-2 (пункт 11.3.6)

S_DeN2

Создать стабильный набор данных с тем же самым именем дважды и проверить ответ — ошибка службы

S_DeN3

Создать неустойчивый набор данных с тем же самым именем дважды и проверить ответ — ошибка службы

S_DsN4

Создать больше чем максимум стабильный набор данных и проверить ответ — ошибка службы

S_OeN5

Создать больше чем максимум неустойчивый набор данных и проверить ответ — ошибка службы

S_DeN6

Создать стабильный набор данных с больше чем максимальным количеством элемен-тоа и проверить ответ — ошибка службы

S_DeN7

Создать неустойчивый нвбор данных с больше чем максимальным количеством элементов и проверить ответ — ошибха службы

S_DeN8

Создать стабильный набор денных с неизвестными элементами и проверить ответ — ошибка службы

S_DeN9

Создать неустойчивый набор данных с неизвестными элементами и проверить ответ — ошибка службы

S_DsN10

Уделить неудвляемый (предопределенный) набор данных и проверить ответ — ошибка службы

S_OsN11

Удалить стабильный набор данных дважды и проверить ответ — ошибка службы

S_OsN12

Удалить неустойчивый набор данных дважды и проверить ответ — ошибка службы

S_OsN13

Удалить набор данных, на который ссылается (отчет) класс управления, и проверить ответ — ошибке службы

6.3.4.8 Создание отчетов о модели

6.3.4.8.1 Положительный

Таблица 7

Вариант

Описание варианта испытания

S_Rpt1

Запросить GetLogicelNodeOirectory (BRCB) и проверить ответ. Запросить, чтобы GetBRCBValue8 0Tee48n BRCB

S_Rpl2

Запросить GetLog»celNodeOirectory (URCB) и проверить ответ. Запросить, чтобы GetURCBValuee отвечал URCB's

S_Rpt3

Запросить AddSubscrlptton к проверить ответ «*» сообщение (ГОСТ Р 54416.25.3 (пункт 9.8.2). Запросить GetxRCSValues всех отвечающих LN

S_Rpt4

Запросить RemoveSubscnption и проверить ответ «♦» сообщение (ГОСТ Р 54416.25.3 (пункт 9.8.3)

Продолжение таблицы 7

Вариан!

Описание варианта испытания

S_Rpt5

Проверить создание отчетов дополнительных попей URCB. Создать конфигура-иию/разрешить URC8 со всеми полезными дополнительными полевыми комбинация-ми. порядковым номером, разовым отчетом — штампом, причиной добавления, именем набора данных, ссылкой данных, буферным переполнением, и/или entrylO (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.2.1 >. вынужденный/иниииированный отчет и проверьте, что доклады содержат включенные дополнительные поля (ГОСТР МЭК 61850-7-1 (пункт 14.3.1)

S_Rpt6

Проверить создание отчетов дополнительных полей BRCB (см. RptS)

S_Rpt7

Проверить создание отчетов дополнительных попей установки xRCBAddSubscnption (ГОСТ Р 54418.25.3 (таблица 10. пункт 9.8.2) (дополнительные поля см. а отчете 4)

S_Rpt8

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

•    на целостности:

•    на обновлении (dupd);

•    на обновлении и целостности:

- на изменении данных (dchg):

•    на данные и качественное изменение:

•    на данные и качественное изменение с периодом целостности:

•    на данные и качественное изменение с периодом целостности и 8ufTime (отчеты целостности должны быть пвредвны сразу);

•    проверить законность ReaaonCode (ГОСТ Р МЭК 616S0-7-2 (подпункт 14.2.3.2.2.9):

•    проверить, что при правильном соблюдении условий запуска, сгенерирован только один отчет (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.3.2);

•    проверить, что отчеты отправляются только, когда RptEna устанавливается в True (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.5), когда создание отчетов останавливается и никакие отчеты не должны передаваться

S_Rpt9

Проверить условия запуска BRCB (см. Rpt8)

S.RptlO

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

S_Rpt11

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

•    SeqNum (неизмененный);

•    SubSeqNum (0 для первого отчете, увеличение, переполнение):

•    MoreSeqmentsFollow;

•    TlmeOfEntry (неизмененный. поскольку SeqNum не изменяется) (ГОСТ Р МЭК 61850-7-2 (подпункт 14 2.3.2.2.9)

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

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

S_Rpt12

Проверка конфигурации (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.7);

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

•    удаление элемента набора данных:

•    переупорядочение элементов в наборе данных.

•    ConfRev никогда не должен быть 0 (нуль);

Окончание таблицы 7

Вариант

Описание варианта испытания

• проверить, что после перезапуске сервера значение ConfRev остается неизменным (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.7);

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

S_Rpt13

время буферизации (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.9))

•    проверить это в случае, если второе внутреннее уведомление о том же самом элементе DATA-SET произошло до истечения BufTIm (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.9)

•сервер будет для информации о статусе вести себя так. как будто виГГип истек, и сразу отправляет отчет, перезапустите таймер со значением BufTim и обработайте второе уведомление;

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

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

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

•    проверить, что значение 0 в течение буферного времени указывает, что буферный атрибут времени не используется (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.9);

•    проверьте, что значение BufTm может содержать, по крайней мере, значение 3600000 (эквивалент одному часу в миллисекундах)

S_Rpt14

буферизованное создание отчетов (BRCB), режим работы машины (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.S. рисунок 20):

•    проверить, что события буферизуются после создания ассоциации:

•    проверить, что создание отчетов отключается после исчезновения ассоциации: •проверить, что отчеты, не полученные во время ассоциации, теперь получаются в правильном порядке (SOE) (ГОСТ Р МЭК 618S0-7-2 (пункт 14.2.1). ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.5);

•    сделайте тоже самое, но теперь установите PurgeBufe True прежде, чем включить создание отчетов. Не сохраненные буферизованные отчеты должны быть отправлены (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.14);

•    проверить, что все буферизованные события отправляются прежде, чем целостность или отчет общего запроса могут быть отправлены (см. ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.3.3), ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.3.4);

•проверить, что после изменения DatSet буфер отчета очищается (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.2.5):

•    силовое переполнение буфера, буферное переполнение OpiFkte должно быть установлено в первом отчете, который отправляется с событиями, произошедшими после переполнения (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.2.8)

6.3.4.8.2 Отрицательный

Таблица 8

Вариант

Описание варианта испытания

S_RptN1

Запросить GetxRCBValues с неправильными параметрами и проверьте ответ - ошибка службы (ГОСТ Р МЭК 61650-7-2 (подпункт 14.2.3.3.2)

S_RplN2

Сконфигурировать создание отчетов, но не устанавливать одну из опций запуска (dcfig. qchg, dupd. целостность). При включении одной из них передается только один отчет (GI). Никакие отчеты не должны быть отправлены, пока генерируются события (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.3.2.2.9)

S_RptN3

Установленный период целостности 0 в TrgOps означает целостность, но не приведет ни к каким отчетам, хотя и будет отправлен (ГОСТ Р МЭК 618S0-7-2 (подпункт 14.2.2.12)

Окончание таблицы 8

Вариант

Описание варианта испытания

S_RptN4

Неправильная конфигурация URCB: сконфигурировать когда включено, сконфигурировать ConfRev и SqNum и сконфигурировать с неизвестным набором данных

S_RptN5

Неправильная конфигурация BRCB: сконфигурировать когда включено, сконфигурировать ConfRev и SqNum и сконфигурировать с неизвестным набором данных

S_RptN6

Недоступное использование URCB и потерянной ассоциации. Сконфигурировать URC8. установить атрибут Resv и включить его. Проверьте, что другой клиент не может установить атрибут URCB (ГОСТ Р МЭК 61850-7-2 (подпункт 14.2.4.5)

S_RptN7

Недоступное использование 8RC6 и потерянной ассоциации. Сконфигурировать BRCB и включить его. Проверить, что другой клиент не может установить атрибут BRCB (ГОСТ Р МЭК 61850-7-2 (пункт 14.2.1)

S_RptN8

Сконфигурировать неподдерживаемые опции URC8 (PIXIT). Сконфигурировать неподдерживаемые условия запуска, дополнительные поля и связанные параметры

S_RptN9

Сконфигурировать неподдерживаемые опции BRCB (PIXIT). Сконфигурировать неподдерживаемые условия запуска, дополнительные поля и связанные параметры

S_RptN10

Запросить AddSubscription с неправильными параметрами и проверить ответ — ошибки службы (ГОСТ Р 54418.25.3 (пункт 9.8.2)

S_RptN11

Запросить Remove Subscription с неправильными параметрами и проверить ответ — ошибки службы (ГОСТ Р 54418.25.3 (пункт 9.8.3)

6.3.4.9 Модельжурнала

6.3.4.9.1 Положительный

Таблице 9

Вариант

Описание варианта испытания

S_Log1

Запросить GetLogicalNodeDirectory (журнал) и проверьте ответ «+•

S_Log2

Запросить GetLogicelNodeOirectory (LCB) и проверьте ответ

S_log3

Запросить GetLCBValuee с функциональными ограничителями LG из LCB

S_Log4

Запросить SetLCBValues с функциональным ограничительным LG. когда LCB отключается

S_Log5

Проверить, что сконфигурированные LOG» показывают OUT со ссылочным LOname/LNname. LG.Logname

S_log6

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

S_Log7

Проверить, что LogEna от отключения до включения или от включения до отключения должен сделать запись в журнал

S_Log8

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

- на целостности:

•    на обновлении (dupd);

•    на обновлении с целостностью:

•    на изменении данных (dchg);

•    на качественном изменении (qchg):

•    на данные и качественном изменении;

•    на данные и качество, изменяемые с периодом

S_Log9

Запросить QueryLogByTlme и проверьте ответ в**

S_Log10

Запросить QueryLogByEntry и проверьте ответ «♦*

S.Logll

Запросить GetLogStalueVaiue» и проверьте ответ ««а. проверить, что записи указывают на самую старую/новейшую Ю/время запись, доступную в журнале

6.3.4.9.2 Отрицательный

Таблица 10

Вариант

Описание еарианта испытания

S_LogN1

Запросить после служб записи с неправильными параметрами (из записей диапазона или не существующего набора данных. LC8 или журнала) и проверьте ответ — ошибка службы:

•    GetLC8Values (ГОСТ Р МЭК 61850-7-2 (подпункт 14.3.2.5):

•    SetLCBValuea (ГОСТ Р МЭК 61850-7-2 (подпункт 14.3.2.6):

•    QueryLogByTime (ГОСТ Р МЭК 61850-7-2 (подпункт 14.3.5.2):

•    QueryLogByEntry (ГОСТ Р МЭК 61850-7-2 (подпункт 14.3.5.3);

•    GetLogStatusVatues (ГОСТ Р МЭК 61850-7-2 (подпункт 14.3.5.4}

S_LogN2

Запросить SeiLCBValues с функциональным ограничительным LG. когда LCB включается. и проверьте ответ — ошибка службы

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

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

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

1)    прямое управление с нормальной безопасностью:

2)    SBO-управление с нормальной безопасностью:

3)    прямое управление с улучшенной безопасностью;

4)    SBO-управление с улучшенной безопасностью.

6.3.4.10.2    Положительный

Таблица 11

Вариант

Описание еарианта испытания

s_cm

вызвать и проварить каждый путь в режиме работы машины управления для нескольких объектов управления с режимами управления:

а)    прямой с нормальной безопасностью (ГОСТ Р МЭК 61850-7-2 (пункт 17.2.1):

б)    ЗВО-улраеление с нормальной безопасностью (работают однажды/многие) (ГОСТ Р МЭК 61850-7-2 (пункт 17.2.2);

в)    прямой с улучшенной безопасностью (ГОСТ Р МЭК 61850-7-2 (пункт 17.3.2);

д) SBO-управление с улучшенной безопасностью (работают однажды/многие) (ГОСТ Р МЭК 61850-7-2 (пункт 17.3.3)

Сравните стационарные варианты тестирования машины для каждого режима управления

S_Ctl2

Проверить, что команды с набором тестового режима обрабатываются согласно (2) или ГОСТ Р МЭК 61850-7-4 и PIXIT

S.C113

выбрать все объекты управления SBO и отменить их в противоположном порядке

S.CtM

Время действия вторым улучшенным объектом управления безопасностью перед временем активации первого объекта управления

S_CU5

Изменить модель управления, используя онлайновые службы

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

Таблица 12

Вариант

Описание варианта испытания

S_DOns1

ЧастьОрегКед (teslok) reap ♦. Выполнить корректный запрос действий

S_DOna2

ЧвстьОрегЯед (lestok) reap *.

Клиент запрашивает TimOper. приводящий к «testnotok»

Окончание таблицы 12

Вариант

Описание варианта испытания

S_OOns3

ЧастьОрегИед [testnotok] rasp

Клиент запрашивает TimOper. приводящий к «testnotok»

S_DOns4

ЧастьТнпОрегЯед [testok] * TimerExpired (teetok) reap *.

Отправить запрос TlmeActivatedOperate. таким образом удостоверяясь, что устройство генерирует «testok». Проверить, что результаты WeitForActionTime в таймере истекли «testok»

S_DOns5

Часть TimOperReq [testok) • TimerExpired [testnotok] resp ♦.

Отправить запрос TlmeActivatedOperate. таким образом удостоверяясь, что устройство генерирует «testok». Проверить, что результаты WanForActionTIme в таймере истекли «testnotok»

Следующая таблица содержит статические варианты тестирования машины для «SBO с нормаль* ной безопасностью» в ГОСТ Р МЭК 61850*7*2 (рисунок 32). возвращающие устройство в состояние готовности или невыбраиный режим.

Таблице 13

Вариант

Описание варианта испытания

S_SBOns1

Часть 1. SelectReq (test not ok) resp

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

S_SBOns2

MacTbSelectReq (test ok| resp ♦;

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

•    клиент запрашивает отмену:

•    клиент ожидает тайм-аута:

•    клиент запрашивает TimOper. приводящий к «testnotok».

•    клиент запрашивает Орег. приводящий к «testnotok»:

•    клиентские запросы работают единовременно корректно

S_SBOns3

MacTbSelectReq (test ok] resp ♦ и TimOperReq (test ok] resp *:

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

•    проверить, что результаты WeitForActionTime в таймере истекли Ktestnotok».

•    проверить, что результаты WeitForActionTime в таймере истекли «testok. workonce»

S_SBOns4

Часть SelectReq (testok) resp ♦ и OperReq (testok. OPERATEMANY) resp ♦:

Выбрать устройство, правильно используя выбор. Проверить, что отправка корректного управления многими запрашивается, возвратив устройство в состояние готовности

S.SBOnsS

Часть SelectReq (testok) resp + и TimOperReq (testok) resp ♦ и TimerExpired (testok. OPERATEMANY) resp ♦ :

Выбрать устройство, правильно используя выбор. Отправить корректировку TlmeActivatedOperate. которую многие запрашивают. После того, как таймер истек, проверить. что устройство возвращается в состояние готовности

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

Таблица 14

вариант

Описание варианта испытания

S.DOesI

4acTbTimOperReq [testnot ok) resp *:

Отправить запрос управления TimeActlvated. таким образом удостоверяясь, что устройство генерирует «testnotok*

Окончание таблицы 14

Вариант

Описание варианта испытания

S_D0632

ЧвстьОрегЯед (testnot ok| reap

Отправить запрос управления, таким образом удостоверяясь, что устройство генерирует «testnotok*.

S_DOee3

MacTbTimOperReq (teetok) reap +: отправьте корректированный запрос управления TimeActivated. Проверьте, что каждый из этих путей возвратит устройство в состояние готовности:

•    клиент ожидает тайм-вута («testnotok».);

•    клиент запрашивает корректную отмену

Часть TimOperReq (tealok) reap + и Таймер истек (teetok) reap ♦:

Отправить корректированный запрос управления TimeActivated. Проверьте, что результаты WaitForActionTime в таймере истекли «teetok». После того, как таймер истек, проверьте, что все приведенные пути возвратят устройство в состояние готовности:

•    вывод устройства перемещается в его новое состояние, приводящее к новому состоянию CmdTermreq ♦;

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

•вызвать вывод устройства так. чтобы вывод достиг «between* состояния, приводящее к промежуточному состоянию CmdTermreq -.

S_DOes5

MacTbOperReq (teetok) reap ♦:

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

•    вывод устройства перемещается а его новое состояние, приводящее к новому состоянию CmdTermreq +;

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

•    вызвать вывод устройства так. что вывод достиг «between* состояния, приводящее к промежуточному состоянию CmdTermreq -.

Следующая таблица содержит статические варианты тестирования машины для «SBO с улучшен* ной безопасностью» (см. ГОСТ Р МЭК 61850-7-2 (рисунок 34). возвращающие устройство в состояние готовности или невыбранный режим.

Таблица 15

Вариант

Описание еарианта испытания

S_SBOea1

Часть 1 (возвращающая к выбору режима):

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

S_SBOes2

Часть 2+3a/b/c/d (возвращающая к выбору режима):

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

•    клиент запрашивает отмену (За);

•    клиент ожидает тайм-аута (ЗЬ);

•    клиент запрашивает TtmOper. приводящий к «teatnotok* (Зс);

•    клиентские запросы управления, получающиеся в «teatnotok* (3d)

S_SBOes3

Часть 2+4+8afb/c (возвращающая к выбору режима):

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

•    выполнить корректно запрос OPERATEONCE (8а):

•    выполнить корректно запрос OPERATEONCE и вызвать вывод устройства так. чтобы вывод сохранил свое старое состояние (8Ь);

•    выполните корректно запрос OPERATEONCE и вызовите вывод устройства так. чтобы вывод достиг состояния Kbetween* (8с)

S_SB03s4

Часть 2+5*6 (возвращающая к выбору режима):

выбрать устройство. прввильно используя SelVal. Отправить запрос TimeActivatedOperate, таким образом удостоверясь. что устройство генерирует «teetok». Смоделировать такую ситуацию, чтобы результаты WaitForActionTime в таймере достигнули Kteetnotok»

Окончание таблицы 15

Вариант

Описание варианта испытания

S.SBOesS

Часть 2*5+7«8а/Ь/с (возвращающая к выбору режима):

Выбрать устройство, правильно используя SelVal. Отправить корректный запрос TimeActivatedOperate. Проверить, что результаты WaltForAcnonTime в таймере достигли «testok*. После того, как таймер сработал, проверьте, что каждый из этих путей возвратит устройство к выбору режима.

•    выполнить корректно запрос OPERATEONCE (6а):

•    выполнить корректно запрос OPERATEONCE и вызвать вывод устройства так. чтобы вывод сохранил свое старое состояние (8Ь);

•    выполнить корректно запрос OPERATEONCE и вызвать вывод устройства так. чтобы вывод достиг состояния «between* (8с)

S_SBOes6

Часть 2«4+9в/Ь/с (возвращающая к Состоянию Готовности):

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

•    выполнить корректно запрос OPERATEMANY (9а):

•    выполнить корректно запрос OPERATEMANY и вызвать вывод устройства так. чтобы вывод сохранил свое старое состояние (9Ь):

•    выполнить корректно запрос OPERATEMANY и вызвать вывод устройства так. чтобы вывод достиг состояния «between* (9с)

S_SBOes7

Часть 2*5«7*9а/Ь/с (возвращающие в состояние готовности):

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

•    выполнить корректно запрос OPERATEMANY (9а):

•    выполнить корректно запрос OPERATEMANY и вызвать вывод устройства так. чтобы вывод сохранил свое старое состояние (9b);

•    выполнить корректно запрос OPERATEMANY и вызвать вывод устройства так. чтобы вывод достиг состояния «between* (9с)

в.3.4.10.3 Отрицательный

Таблице 16

Вариаи!

Описание варианта испытания

S_CtlN1

Работает (без выбора) для SBO-управления объекта и проверяет ответ и AddCause (ГОСТ Р МОК 61850-7-2 (пункт 17.2.2)

S_CtlN2

Выбрать дважды (второй выбор должен привести к сбою) и проверить ответ и AddCause (ГОСТ Р МЭК 61850-7-2 (пункт 17.2.2)

S_CtlN3

Рабочее значение будет тем же самым, что и фактическое значение (Оп-Оп или Off-Off). Проверить ответ и AddCause (ГОСТ Р МЭК 61850-7-2 (пункт 17.2.2)

S_CtlN4

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

S_CtlN5

Выбрать неизвестное управление, возражают и проверяют ответ и AddCause (ГОСТ Р МЭК 61850-7-2 (пункт 17.2.2)

S_CtlN6

Проверить ситуации для установления определенных применимых значений AddCause (ГОСТ Р МЭК 61850-7-2 (подпункт 17.5.2.6}

S_CtIN7

Выбор прямого управления за контролем объекта

S_CdN6

Управляйте прямым контролем объекта дважды от двух клиентов

S_Ct!N9

Управляйте с различным значением. Проверить, что SelectWIthValue является объектом управления SBOes

6.3.4.11 Время и модель синхронизации времени

6.3.4.11.1 Положительный

Таблица 17

Вариант

Описание варианта испытания

S_Tm1

Проварить, что OUT поддерживает синхронизацию времени SCSM

S_Tm2

Проверить, что точность отметки времени отчета/записи соответствует качеству метки времени сервера

6.3.4.11.2 Отрицательный

Таблица 18

Вариант

Описание варианта испытания

S_TmN1

Проверить, что потеря связи при синхронизации времени обнаруживается после установленного периоде

S_TmN2

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

6.3.4.12 Тест комбинации

6.3.4.12.1 Положительный

Таблица 19

Вариант

Описание варианта испытания

S_Comb1

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

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

•    разрешить сообщения:

-    разрешить регистрирование.

-    разрешить синхронизацию времени:

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

•    запустить запросы всех запросов поддержки и контролируйте серверы. Как только один запрос выполняется, запустить новый запрос. Продолжать в течение 10 минут:

•    запросить логический сервер, логический узел и GetOataVatuee-сервис:

•    запросить GetOataSetValue-сервис:

-    запросить GetxRCSValue-cepBHc:

-    запросить QueryLog-сервис:

•    выбрать и управлять объектами управления

6.3.5 Прецеденты для тестирования клиента

6.3.5.1    Ассоциация приложения

6.3.5.1.1    Положительный

Таблица 20

Вариант

Описание варианта испытания

С_Авв1

Ассоциировать и вынудить клиента/оа для выпуска ТРАА (ГОСТ Р МЭК 61850-7-2 (подраздел 7.4)

С_Авв2

вынудить клиента/ое связаться с максимальным количеством серверов одновременно (P1XIT)

6.3.5.1.2 Отрицательный

Таблице 21

вариант

Описание варианта испытания

C.AesNI

Ассоциация и сервер отвечают отрицательно из-за AccessPomlRelerence

C_AeeN2

Ассоциация и сервер отвечают отрицательно из-за AutheniicationParameter

C_AeeN3

Ассоциация и сервер выпускают ТРАА (ГОСТ Р МЭК 61650-7-2 (подраздел 7.4). OUT должен попытаться восстановить ассоциацию после периода настройки (PIXIT)

C_AeeN4

Ассоциация и аварийное прекращение работы сервера ТРАА (ГОСТ Р МЭК 61850-7-2 (подраздел 7.4). OUT должен попытаться восстановить ассоциацию после периода настройки (Р1ХГГ)

C_AeeN5

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

C_AeeN6

Прервать и восстановить электропитание. OUT допжен установить настройки ассоциации. когда все будет готово (PIXIT)


6.3.5.2 Сервер, логическое устройство, логический узел и модель данных

6.3.5.2.1 Положительный

Таблице 22

Примечения

1    Autodescriptton означает, что есть способ настроить клиента, чтобы обновить изображение модели одного из серверов, которое следует передать с использованием служб ACSI.

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


Варнан!

Описание варианта испытания

C_Srv1

Если клиент реализует Autodescriptton (см. примечание 1). вынудите клиента запустить Autodescriptton и проверьте, что клиент звпрвшивает GetServerOirectory (LOGICALDEVICE) ко всем логическим устройствам на сконфигурированных серверах (см. примечание 2}

C_Srv2

Если клиент реализует Autodescription, для каждого GetServerOirectory (LOGICALDEVICE) ответа. проверьте. что клиент запрашивает GetLogicalOeviceOlrectory

C_Srv3

Если клиент KlmplementsAutodescription». для каждой проблемы ответа GetLogicalOeviceOlrectory. проверьте, что клиент запрашивает GetLoglcalNodeOirectory (DATA) запрос

C_Srv4

Если клиент «implementsAutodescnption». для каждого GetLoglcalNodeOirectory (DATA) ответ, проверьте, что клиент выпускает по крайней мере одну из следующих служб:

•    запросить GetOataDirectory и проварить ответ (ГОСТ Р МЭК 61850-7-2 (пункт 10.4.4)};

•    запросить GetDataOefinition и проверить ответ (ГОСТ РМЭК 61650-7-2 (пункт 10.4.5)}

C_Srv5

Проверить, что после запуска клиент в состоянии обновить его представление сконфигурированных серверов (PIXIT)

C_Srv6

Для каждого объекта DATA с разрешением записи выпустить запрос SetOataValues и проверить ответ (ГОСТ Р МЭК 61650- 7-2 (пункт 10.4.2))

C.Srv

Звпросить SetOataValues всех различных основных типов и проверить службы

C_Srv7

Запросить GetAIIDateValues на каждое функциональное ограничение и проверку, если клиент обновляет ее модель (ГОСТ Р МЭК 61650-7-2 (пункт 9.2.3))

6.3.5.2.2 Отрицательный

Таблица 23

Вариант

Описание варианта испытания

C_SrvN1

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

•    GetServerDIrectory (LOGICAL DEVICE):

•    GetLogicalDeviceDIrectory;

•    GetLogicalNodeDirectory (DATA):

•    GetDeiaDirectory;

•GelDataOeflnltlon

C_SrvN2

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

•    сервер не дает ответа:

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицательный:

•    ответ идет с неправильным типом

C_SrvN3

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

•    сервер не дает ответа.

•    ответ прибывает позже, чем максимально позволенная задержка,

•    ответ отрицательный.

•    ответ идет с неправильным типом:

•    значение вне диапазона зтих данных

C_SrvN5

Если клиент обнвруживает/уведомляет изменения в атрибуте «Quality», необходимо использовать SERVERSIMULATOR для вызова различных значений в качестве изме-ренных/неизмененных значений, контролируемых клиентом. Необходимо также проверить поведение, описанное в PIXIT

C_SrvN6

Если клиент обнаруживает/уведомлявт изменения метки времени в атрибуте «TimeQuality». необходимо использовать SERVERSIMULATOR для вызова различных значений в TimeQualrty измеренных'кеизмененных значений, контролируемых клиентом. Необходимо также проверить поведение, описанное в PIXIT

6.3.5.3 Модель DataSet

6.3.5.3.1 Положительный

Таблица 24

Вариант

Описание варианта испытания

С_Ов1

Если клиент реализует Autodescription, вынудить его запустить Autodescnptlon. Проверить. что оно запрашивает GetLoglcalNodeDIrectory (DATASET) всех LOGICALNODES не сконфигурированном сервере

C_Ds2

Если клиент реализует Autodescription. вынудить его запустить Autodescnptlon. Проверить. что оно запрашивает GetDetaSetDirectory всего OataSete сервера

C_Ds3

Проверьте, что GetDataSetVatues обновляет информационную модель клиента

C_Ds4

Если клиент конфигурирует наборы данных динамически после запуска, проверьте, что клиент отправляет службы CreateDataSet согласно конфигурации (PIXIT)

C_Ds5

Запросите службу DeleteDataSet и проверьте, что клиент отправляет запрос должным образом и в состоянии обработать ответ сервера

6.3.5.3.2 Отрицательный

Таблице 25

вариант

Описание варианта испытания

C_DSN1

Если клиент реализует Autodescnption. вынудить его запустить Autodescription и проверить. что клиент все еще связывается с другими серверами по запросу следующих служб без ответа/звдержки положитвлького/отрицвтельного ответа:

•    GetLogiceWodeDirectory (DATASET);

•    GetDataSetDIrectory

C_DsN2

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

•    CreateDataSet:

•    DeieteDataSet

C_DsN3

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

•    сервер не дает ответа:

•    ответ прибывает позже, чем максимально позволенная задержка:

C_DsN3

•    ответ отрицательный.

•    ответ идет с болыив/мвньше элементами, чем ожидаемый:

•    ответ идет с различными типами элементов

C_DsN4

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

•    сервер не дает ответа.

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицательный:

•    ответ идет с больше/мвньше элементами, чем число элементов в DataSet

C.D9N5

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

C_DsN6

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

6.3.5.4 Соэданиеотчбтовомодели

6.3.5.4.1 Положительный

Таблице 26

вариант

Описание варианта испытания

C_Rpt1

Если клиент реализует Autodeecription. принудить его запустить Autodescnption и проверку. если оно запрашивает GetLogicalNodeDirectory (URCB) все логические узлы всех сконфигурированных серверов

C_Rpt2

Если клиент реализует ветоописание. принудить его запустить Autodescnption и проверку. если оно запрашивает GetLogicalNodeDirectory (BRC8) всех логических узлов всех сконфигурированных серверов

C_Rpt3

Если клиент не буферизовал параметры ReportControlBlock после использования запуска SetURCBValues, проверить, что GetURCBVakues/SetURC8Values отправляются вместе с сконфигурированными значениями

C_Rpt4

Если клиент буферизовал параметры ReportControlBlock после использования запуска SetBRCBValues. проверить, что GetBRCBValues/SetBRCBValues отправляются вместе с сконфигурированными значениями

C_Rpt5

Если клиент конфигурирует параметры ReportControlBlock сервера после запуска AddSubscnption. проверить, что служба AddSuPecnptlon была отправлена как конфигурирующаяся

Продолжение таблицы 26

Вариант

Описание варианта испытания

C_Rpt6

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

C_Rpt7

Проверить, что клиент в состоянии обработать отчеты с различными дополнительными полями, вынудить клиент конфигурировать/разрешить URCB со всеми полезными дополнительными полевыми комбинациями: последовательность (число, отметка времени отчета, причина включения, имя набора данных, ссылка данных} и/или entrylO (ГОСТ РМЭК 61850-7-2 (подпункт 14.2.3.2.2.1), вынудили/инициироевли отчет и проверяют. что клиент в состоянии обработать отчеты и обновляет его модель данных

C_Rpl8

Проверить, что клиент в состоянии обработать отчеты с различными дополнительными полями установки xRCBAddSubscriptton (ГОСТ Р 54418.25.3 (пункт 9.8.2, таблица 10)

C_Rpt9

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

•    на целостности:

•    на обновлении (dupd):

•    на обновлении с целостностью;

•    на изменении данных (dchg):

•    на данных и качественном изменении:

•    на данных и качественном изменении с периодом целостности;

•    на данных и качественном изменении с периодом целостности и BufTlme (отчеты целостности должны быть переданы сразу)

C_Rpt10

Проверить, что клиент в состоянии обработать отчеты, которые сегментируются

C_Rpt11

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

6.3.5.4.2 Отрицательный

Таблица 27

Вариант

Описание варианта испытания

C.RptNI

Если клиент реализует Autodescription. вынудить клиента запустить Autodeacnption. Проверить, что клиент все еще связывается с другими серверами, когда запрашивает GeiLoglcalNodeDIrectory (URCB) и GetLogicaiNodeDIrectory (BRCB) без ответа/задержки лоложительного/отрицательного ответа

C_RptN2

Проверить, что клиент все еще работает должным образом, когда это запрашивает GetURCeValues/GetBRC8Values а следующей ситуации:

•    сервер не дает ответа;

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицательный:

•    ответ идет с неправильным типом:

•    значение испытывает недостаток допустимого диапазона для данных

C_RptN3

Проверить, что клиент все еще работает должным образом, когда запрашивает SetURCBValuee/SelBRCBValues в следующей ситуации:

•    сервер не дает ответа:

•    ответ прибывает позже, чем максимально позволенная задержка.

•    ответ отрицателен

C_RptN4

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

•    сервер не дает ответа;

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицателен

C_RptN5

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

•    сервер не дает ответа;

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицателен

Окончание таблицы 27

Вариант

Описание варианта испытания

C_RptN6

Отчет с неподдерживаемого OptFIde. Проверить, что клиент не вышел иэ строя, если получает отчет с несконфигурироевнным или неподдерживаемым OptFtds

C_RptN7

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

C_RptN8

Неожиданные отчеты:

•    отчеты с IntgPd. установленный в 0;

•    отчеты QI не требуются;

•    отчеты получены от ReponControlBlock. который не был включен

C.RptNS

Плохие отчеты формата:

•    отчет с неизвестным DataSet.

•    отчет с неправильными ссылками DATA;

•    отчет с неправильными типами DATA; Проверить поведение, описанное в PIXIT

C_RptN10

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

C_RplN11

ConfRev. Проверить, обнаруживает ли DUT изменение в атрибуте ConfRev управляющего блока отчета

C_RptN12

SqNum. Проверить, что DUT показывает ошибку, если получвет отчет не по порядку

C_RplN13

Целостность. Проверить, что OUT показывает ошибку, если активирует целостность в сервере и никакие отчеты целостности не отсылаются назад

6.3.5.5 Модель журнала

6.3.5.5.1 Положительный

Таблице 28

Вариант

Описание варианта испытания

C_Log1

Если клиент реализует Autodescnptlon. вынудить его запустить Autodescrlpbon и проверить. запрашиваются ли GetLogicalNodeDirectory (LOO) все логические узлы всех сконфигурированных серверов

C_Log2

Если клиент реализует Autodescnptlon. вынудить его запустить Autodescrlpbon и проверить. запрашиваются ли GetLogicalNodeDirectory (LCB) все логические узлы всех сконфигурированных серверов

C_Log3

Если клиент реализует Autodescnptlon. вынудить его запустить Autodescrlpbon и проверить, запрашивается ли GeLogStatusVaiues всех LOG, найденных с GetLogicalNodeDirectory (LCB) службы

C_Log4

Если клиент реализует автоописание, вынудить его запустить автоописание и проверить. запрашивается ли GeLCBVatues всех LCB. найденных с GetLogicalNodeDirectory (LCB)

C_Log5

Если клиент конфигурирует параметры LogControlBlock сервера после использования запуска SetLCBValues. проверить, что GetLCBValuesrSetLCBValues отправляются со сконфигурированными значениями

C_Log6

Вынудить клиента включить регистрацию по крайней мере одного LOG-cepeepa и проверить. что он отправил запрос правильно

C_Log7

вынудить клиента к OueryLogByTime и проверить, что DUT обновляет свою базу данных с полученными записями LOG

C_Log6

Вынудить клиенте к QueryLogByEntry и проверить, что DUT обновляет свою базу данных с полученными записями LOG

6.3.5.5.2 Отрицательный

Таблица 29

Вариант

Описание варианта испытания

C_LogN1

Если клиент реализует Autodeacnption. вынудите клиента эвлустить Autodescnption и проверить, что он асе еще связывается с другими серверами при запросе OetLoglcalNodeOlrectory (LCB) и GetLogealNodeDirectory (LOG) без ответа/эвдержки положительного ответа/отрицателького ответа

C_LogN2

Проверить, что клиент все еще работает должным образом при запросе GetLCBValuee/GetLogStalueVaiues в следующей ситуации:

•    сервер не дает ответа;

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицателен.

•    ответ идет с неправильного типа:

•    значение испытывает недостаток допустимого диапазона для отих данных

C_LogN3

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

•    сервер не дает ответа:

•    ответ прибывает позже, чем максимально позволенная задержка:

•    ответ отрицательный

C_LogN4

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

•    OataRef не существует в модели;

•    DateValue не имеет ожидаемого типа

C_LogN5

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

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

6.3.5.6.1    Общие прецеденты

6.3.5.6.1.1    Положительные

Таблица 30

Вариант

Описание варианта испытания

С_СИ1

Проверить, в состоянии ли клиент установить поле TEST а командах PIXIT

C_CU2

Проверить, в состоянии ли клиент установить CHECK (SYNHRO-CHECK или INTERLOCK-CHECKbite) в командах PIXIT

С_СМЗ

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

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

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

1)    прямое управлениес нормальной безопасностью;

2)    SBO управляют с нормальной безопасностью;

3)    прямое управлениес улучшенной безопасностью;

4)    SBO управляют с улучшенной безопасностью.

6.3.5.6.3    Прямое управление с нормальной безопасностью

6.3.5.6.3.1 Положительный

Таблица 31

Вариант

Описание варианта испытания

С_ООпв1

OperReq (тест хорошо) геер *

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

Окончание таблицы 31

Вариант

Описание варианта испытания

C_DOns2

OperReq [тает нехорошо] rasp -

Клиент запрашивает Орег. приводящий к «testnotok*. Проварить, что клиент понимает отказавшую работу

C_DOns3

TimOperReq [test not ok] rasp -

Клиент запрашивает, чтобы TimOper. приводящий к «testnotok». выполнил неправильный запрос TlmOperate и проверил, что клиент понимает отказавшую работу. Неправильным запросом TimOperate может быть:

•    неправильное время работы:

•    неправильный ctlVal:

•    неправильный инициатор {PIXIT);

•    неправильный тест или проверка (PIXIT)

С_00пв4

TimOperReq [test ok) + TimerExpIred [test ok] resp ♦

Отправляет запрос TimeActivatedOperate. таким образом удостоверяясь, что устройство генерирует «testok*. Проверить, что результаты WaitForActionTime в таймере истекли «testok» и что клиент понимает, что работа выполнялась успешно

С.ООпвб

TimOperReq [test ok) ♦ TimerExpIred [test not ok) resp -

Отправляет запрос TlmeAcbvatedOperate. таким образом удостоверяясь, что устройство генерирует «testok». Ситуация с силой, что результаты WaitForActionTime в таймере истекли «testnotok». Проверить, что клиент понимает отказавшую работу

6.3.5.6.3.2 Отрицательные

Таблице 32

вариант

Описание варианта испытания

C_DOnsN1

Неправильное управление. Проверить, что клиент обнаруживает следующие ситуации: - работа без ответа;

• работе с задержанным ответом

C_DOnsN2

Неправильная команда TlmedActlvatedOperate. При проверке клиент обнаруживает следующие ситуации:

- TlmedActlvatedOperate без ответа:

•    TlmedActlvatedOperate с задержанным ответом:

•    Т imedActlvated с положительным первым ответом и отсутствием второго ответа после WaitForActionTime;

•    ТImedActlvated с отрицательными первым и вторым ответами, положительным ответом после WaitForActionTime;

•    ТimedActlvated с отрицательными первым и вторым ответами, отрицательным ответом после WaitForActionTime

6.3.5.6.4 SBO управляют с нормальной безопасностью

6.3.5.6.4.1 Положительный

Таблица 33

Вариант

Описание варианта испытания

C_S80ns1

SelectReq [testnotok] resp -:

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

C_S80ns2

SelectReq [testok)resp ♦:

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

C_S80ns3

OperReq [teetok] resp ♦ выбранного объекта:

Выполняет корректное управление запросом. Проверить, что клиент понимает, что работа успешно выполнялась

Окончание твбпииы 33

Вариант

Описание варианта испытания

C_SBOns4

OperReq (testnotokj reap — выбранного объекта:

выполняет некорректное управление запросом Проверить, что клиент понимает отказ работы

C_SBOns5

TimOperRe<) (teetok) reap ♦ выбранного объекта:

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

C_SBOns6

TimOperReq (teetok) reap — выбранного объекта:

выполняют неправильный запрос TimOperate. Проверить, что клиент понимает, что работа перестала выполняться

6.3.5.6.4.2 Отрицательный

Таблица 34

Вариант

Описание варианта испытания

C_S80naN1

Неправильная SELECT.

Проверьте, что клиент обнаруживает следующие ситуации:

•    SELECT без ответа:

•    SELECT с задержкой ответа

C_SBOneN2

Неправильная OPERATE выбранного объекта Проверьте, что клиент обнаруживает следующие ситуации:

•    OPERATE без ответа:

•    OPERATE с задержкой ответа

C_S80nsN3

Неправильная TimedActivatedOperate выбранного объекта.

При проверке клиент обнаруживает следующие ситуации:

•    TimedActivatedOperate без ответа:

•    TimedActivatedOperate с задержанным ответом.

•    TimedActivated с положительным первым ответом и отсутствием второго ответа после WaitForActlonTlme;

•    TimedActivated с отрицательными первым и вторым ответами, положительным ответом после WaitForAcbonTime:

•    TimedActivated с отрицательным первым и вторым ответвми. отрицательным ответом после WaitForActlonTlme

6.3.5.6.5 Прямое управление с улучшенной безопасностью

6.3.5.6.5.1 Положительный

Таблица 3S

Вариант

Описание варианта испытания

C_DOes1

TimOperReq (teetnotok) resp -:

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

C_OOes2

OperReq (teetnotok) resp

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

С.ООевЗ

TlmOperReq (teetok) resp +:

•    передайте TimeActlvated корректный управляющий запрос:

•    проверить, что клиент понимает запрос работы, которая успешно закончена: •проверить, что клиент замечает работу, успешно законченную, когда она получает CommendTemrination ♦;

•    проверить, что клиент замечает работу, не успешно законченную, когда она получает CommandTermlnation -

Окончание таблицы 35

Вариант

Описание варианта испытания

С_00вв4

OperReq (testok) rasp +:

•    передать корректный управляющий запрос Time Activated:

•    проверить, что клиент понимает запрос работы, которая успешно закончена:

•    проверить, что кпиент замечает работу, успешно законченную, когда она получает CommandTermination +.

•    проверить, что клиент замечает рвботу. не успешно законченную, когда она получает CommandTermination -

6.3.5.6.5.2 Отрицательный

Таблице 36

вариант

Описание варианта испытания

C_DOesN1

Неправильное OPERATE

Проверить, что кпиент обнаруживает следующие ситуации.

•    OPERATE без ответа;

•    OPERATE с задержанным ответом

C_DOesN2

Неправильная проверка TimedActivatedOperate.

Проверить, что клиент обнаруживает следующие ситуации:

•    TimedActivatedOperate без ответа;

•    TimedActivatedOperate с задержанным ответом:

•    Т imedActlvated с положительным первым ответом и отсутствием второго ответа после WaitForActionTime;

•    ТImedActlvated с отрицательным первым и вторым ответами, положительным ответом после WaitForActionTime:

•    ТimedActlvated с отрицательным первым и вторым ответами, отрицательным ответом после WaitForActionTime

C_DOesN3

OperReq (teetok] resp + 6e3CommandTermmation.

Проверить, что клиент показывает ошибку, когда после положительного OPERATE, ото не принимает никакого CommandTermination

C_DOesN4

TlmedActivatedOpereteReq (teetok) resp * без CommandTermination.

Проверить, что клиент показывает ошибку, когда после положительного TimedActivatedOperate не принимается никакого CommandTermination

6.3.5.6.6 SBO управляют с улучшенной безопасностью

6.3.5.6.6.1 Положительный

Таблица 37

вариант

Описание варианта испытания

C.SSOeel

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

C_S80es2

Права доступа SelectWithvalue. Выбрвть использование устройства SelVal с правами доступа. Проверить, что кпиент выполняет порядок управления после получения доступа к управляемому объекту

C_S80es3

OperReq (teetok) resp ♦ выбранного объекта.

Выполнить корректное управление запросом. Проверить, что клиент понимает, что работа успешно выполнялась и обнаруживает CommandTermination с результатом порядка.

C_S80es4

OperReq (testnotok) resp — выбранного объекта.

Выполнить неправильное управление запросом. Проверить, что клиент понимает, что работа перестала работать

Окончание твбпииы 37

Вариант

Описание варианта испытания

C_SBOes5

TimOperReq (teatokj reap + выбранного объекта

выполнить корректный запрос TimOperate. Проверить, что клиент понимает, что работе успешно выполнена после WeitForActionTime и проверить результат CommandTermination

C_SBOes6

TimOperReq (teatokj reap — выбранного объекта.

выполнить некорректный запрос TimOperate. Проверить, что клиент понимает отказ работы

6.3.5.6.6.2 Отрицательный

Таблица 38

Вариант

Описание варианта испытания

C_S80eaNl

Неправильный SelectWtthVaiue.

Проверить, что клиент обнаруживает следующие ситуации:

•    SetectWithValue без ответа:

•    SetectWithValue с задержанным ответом

C_S80eaN2

Неправильное Управление выбранным объектом. Проверить, что клиент обнаруживает следующие ситуации:

•    Работа без ответа:

•    Работа с задержкой ответа

C_S80eaN3

Неправильно выбранный объект TimedActivatedOperate.

Проверить, что клиент обнаруживает следующие ситуации:

•    TimedActivatedOperate без ответа:

•    TimedActivatedOperate с задержанным ответом.

•    TimedAcbvated с положительным первым ответом и отсутствие второго ответа после WeitForActionTime.

•    TimedActrveted с отрицательным первым и вторым ответами, положительным ответом после WeitForActionTime.

•    TimedActivated с отрицательным первым и вторым ответами, отрицательным ответом после WeitForActionTime

C_S80esN4

Работать без выбранного объекта CommandTermination. Проверить, что клиент показывает ошибку, когда после положительного OPERATE не предпринимается CommandTermination

C_S80eaN5

выполнить TimedActivatedOperate выбранного объекта без CommandTermination. Проверить. что клиент показывает ошибку, когда после положительного TimedActivatedOperate не предпринимается CommandTermination

6.3.5.7 Время и модель синхронизации времени

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

6.3.6 Критерии допустимости

Цель состоит в том. чтобы показать все тестируемые требования при указанных фоновых загрузках.

Критерии оценки тестирования OUT включают:

•    определенные расчетные характеристики, которые будут проверены:

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

Для результата испытаний согласно группе стандартов ИСО/МЭК 9646 всегда есть три варианта:

•    пройдено (решение) — тестовое решение, когда наблюдаемый результат, на котором тестовая цель прецедента фокусируется, свидетельствует о соответствии требованию(ям)соответствия. и когда никакое недопустимое тестовое событие не может быть обнаружено:

•    провалено (решение) — тестовый приговор, когда любой наблюдаемый результат, на котором фокусируется тестовая цель прецедента, демонстрирует несоответствие относительно, по крайней мере одного из требований(я) соответствия, или содержит, по крайней мере, одно недопустимое тесто» вое событие относительно соответствующей спецификации(й);

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

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

7 Промышленные испытания

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

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

7.2    Коммуникационная задержка

7.2.1    Время передачи

Коммуникационные требования времени передачи идентифицируются как существенная метрика производительности. Время передачи — время, требуемое процессу для передачи от передающего физического устройства до логики процесса приемного устройства. Время передачи определяется с точки зрения трех интервалов: fa — время, необходимое передающему устройству для передачи значения процесса: tb — время, необходимое для сети, чтобы передать сообщение: и /с — время, необходимое для приемного устройства, чтобы распознать логику процесса.

Интервал tb является сетевой инфраструктурой и не является атрибутом устройства. С точки зрения тестирования устройства только выводные и входные задержки могут быть измерены. fa и tc оцениваются от измеренных задержек:

•    измеренная выходная задержка равна сумме значений оцененного входного времени обработки и оцененного fe;

•    измеренная входная задержка равна сумме значений выходного времени обработки и оцененного tb.

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

Предполагаемое входное время обработки устройства ВЭС — время, требуемое для входного сигнала для создания благоприятных условий (например, выход на открытое место, выборка и т. д.).

Предполагаемое выходное время обработки устройства ВЭС — время, требуемое для активации выходного сигнала (например, связь с задержками, частотой развертки ввода-вывода и т. д.).

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

7.2.2    Методология

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

-    сообщение о выходной задержке;

-    запись выходной задержки:

•    управление выходной задержкой.

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

Рисунок 5— Тестирование производительности (принцип черного квадрата)

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

7.3 Синхронизация времени и точность

7.3.1 Введение в тест синхронизации времени

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

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

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

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

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

7.3.2 Синхронизация времени тестирует методологию

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

Рисунок 6 — Синхронизация времени и точность проверки установки

7.3.2.1    Время из внешнего источника

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

7.3.2.2    Время из протокола синхронизации времени

Второе измерение точности устройства ВЭУ производят, используя протокол синхронизации времени с ведущей функцией времени в системе тестирования. Необходимо сгенерировать ряд из 1000 событий и вычислить среднее стандартное отклонение от среднего значения по разнице между временем события и полученными отметками времени. Генерация последовательности событий должна быть скоординирована с протоколом синхронизации времени. После того, как устройство запрашивает синхронизацию с ведущим устройством времени, сразу должна начаться последовательность события. Если синхронизация требуется во время выполнения последовательности, то она прерывается и обмен протокола синхронизации завершается.

7.3.3 Критерий тестирования

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

Применение — Искажения, вызванные сетевым компонентом (коммутатор), как правило, незначительны.

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

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

Примечание — Искажения независимы от синхронизации времени.

7.4 Тест на устойчивость

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

Приложение А (справочное)


Примеры процедуры тестирования


А.1 Пример 1

RptPI

GetLog»celNodeOirectory(BRCB) и GetBRCSValues

Пройдено

Провалено

Неокончательно

Ожидаемые оезультаты

1)    DUT отправляет GelLogtcalNodeDifectory(BRCB) response *

2)    OUT отправляет CetBRCBValues response *

Описание теста

1)    Дпя каждого логического узла клиент запрашивает GetLog«alNodeDlrectory(8RCB)

2)    Для каждого BRC8 клиент запрашивает GelBRCBValues ()

А.2 Пример 2

RptP2

GetLogicalNodeOlrectory(URCB) и GetURCBValues

Пройдено

Провалено

Неокончательно

ГОСТ Р МЭК 61850-7-2 (пункт 9.2.2 и подпункт 14 2.5.3) стандарт [1] (пункты 12.3.1 и 17.2.4)


Ожидаемые результаты

3)    OUT отправил GetLogicalNodeDlrectory(URCB) response ♦

4)    OUT отправил Get8RCBValues response ♦

Описание теста

3)    Для каждого логического узла клиент запрашивает GetLogicelNodeOirectory(URCB)

4)    Для каждого 8RC8 клиент запрашивает GetURCBVatues (}

Комментарии


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

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

международном стандарте

Таблице ДА.1

Обозначение ссылочного национального, мсжгосударстааиного стандарта

Степень соот ее тс таи я

Обозначение и наименование ссылочного международного стандарта

ГОСТ Р ИСО/МЭК 9646-1—93

ют

ИСО/МЭК 9646.1991 «Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 1. Общие положения»

ГОСТ Р МЭК 61850-7-1—2009

ют

МЭК 61850-7-1:2003 «Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздал 1. Принципы и модели*

ГОСТ Р МЭК 61650-7-2—2009

ют

МЭК 618S0-7-2:2009 «Сети и системы связи на подстанциях. Часть 7. Базовая структуре связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI)*

ГОСТ Р МЭК 61650-7-4—2011

ют

МЭК 61850-7-4:2003 «Сети и системы связи иа подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 4. Совместимые классы логических узлов и классы денных»

Примечание—8 настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

• ЮТ — идентичные стандарты.

Библиография

(1) МЭК 61850-8-1:2011

Сети и системы связи не подстанциях. Честь 8-1. Специфическое отображение сервиса связи (SCSM)—схемы отображения на MMS (ИСО 9506-1 и ИСО 9506-2) и на ИСО/МЭК 8802-3

(2} МЭК 61400-25-4:2008

Турбины ветровые. Часть 25-4. Коммуникации для мониторинга и контроля ветровых станций. Маршрутизация к коммуникационному профилю

(3} МЭК 61400-25*2:2008

Турбины ветровые. Часть 25-2. Коммуникации для текущего контроля и управления ветровыми злектроствнциями. Информационные модели

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

Турбины ветровые. Часть 25-3. Коммуникации для текущего контроля и управления ветровыми злектроствнциями. Модели информационного обмена

УДК 621.311.24:006.354    ОКС 27.180

Ключевые слова: нетрадиционная энергетика, ветроэнергетика, системы контроля, коммуникационные системы зв

Редактор ЕА. Черепко Технический реаахюр В Н. Прусакова Корректор М.В. Бучиая Компьютерная верстка Ю в. Деиония ой

Сдано о набор 30.09.2014. Подписано а печать 14.11.2014. Формат 60 > 84у£. Гарнитура Ариал. Уел. печ. л. 5.12. Уч.чтм. л. 5.00. Тирах 41 экэ. Зак. 4661

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ». 123995 Москва. Гранатный лер.. 4. www.90slinto.1u    <