ГОСТ Р ИСО 16100-4-2010 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 4. Методы аттестационных испытаний, критерии и отчеты

ГОСТ Р ИСО 16100-4-2010

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

Системы промышленной автоматизации и интеграция

ПРОФИЛИРОВАНИЕ ВОЗМОЖНОСТИ ИНТЕРОПЕРАБЕЛЬНОСТИ ПРОМЫШЛЕННЫХ ПРОГРАММНЫХ СРЕДСТВ

Часть 4

Методы аттестационных испытаний, критерии и отчеты

Industrial automation systems and integration. Manufacturing software capability profiling for interoperability. Part 4. Conformance test methods, criteria and reports Interface

ОКС 25.040.40

Дата введения 2011-09-01

Предисловие

1 ПОДГОТОВЛЕН Научно-техническим центром "ИНТЕК" на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

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

4 Настоящий стандарт идентичен международному стандарту ИСО 16100-4:2006* "Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 4. Методы аттестационных испытаний, критерии и отчеты" (ISO 16100-4:2006 "Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 4: Conformance test methods, criteria and reports Interface", IDT).

________________

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

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

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

6 ИЗДАНИЕ (март 2020 г.) с Поправкой (ИУС 2-2015)

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

Введение

Разработка комплекса стандартов ИСО 16100 обусловлена необходимостью решения следующих проблем, связанных с:

a) постоянно увеличивающейся базой решений, зависящих от поставщиков;

b) трудностями, возникающими у пользователей при применении стандартов;

c) необходимостью перехода к модульным наборам инструментальных средств интеграции системы;

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

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

Настоящий стандарт разработан Техническим комитетом ИСО/ТК 184 "Системы промышленной автоматизации и интеграция", Подкомитетом ПК 5 "Архитектура, коммуникации и структуры интеграции".

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

- часть 1. Структура;

- часть 2. Методология профилирования;

- часть 3. Службы интерфейса, протоколы и шаблоны возможностей;

- часть 4. Методы аттестационных испытаний, критерии и отчеты;

- часть 5. Методология согласования конфигураций профилей с помощью многоцелевых структур классов.

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

Настоящий стандарт устанавливает метод испытаний, ассоциированные тестовые критерии и формат заявления, предназначенные для проведения оценки и указания степени соответствия испытуемого объекта (UUT) требованиям, установленным в других стандартах комплекса ИСО 16100.

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

Настоящий стандарт распространяется на:

- аспекты соответствия, предназначенные для установления соответствия испытуемого объекта требованиям комплекса стандартов ИСО 16100;

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

- описание аспектов, включаемых в заявление о соответствии;

- набор правил, необходимых для выбора действительных и недействительных комбинаций аспектов при их объединении.

Настоящий стандарт не распространяется на:

- вопросы, относящиеся к меткам или этикеткам соответствия, сертификатам соответствия или декларациям производителей или поставщиков о соответствии;

- дату реализации или распределение обязанностей между сторонами, использующими комплекс стандартов ИСО 16100;

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

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

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

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

ISO 16100-1:2002, Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 1: Framework (Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 1. Структура)

________________

Действует ГОСТ ISO 16100-1:2009.

ISO 16100-2:2003, Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 2: Profiling methodology (Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования)

ISO 16100-3:2005, Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 3: Interface services, protocols and capability templates (Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 3. Службы интерфейса, протоколы и шаблоны возможностей)

REC-xml-20000814, Extensible Markup Language (XML) 1.0 Ed. 2 W3C Recommendation (Рекомендация W3C 1.0. Издание 2. Расширяемый язык XML)

REC-xmlschema-1-20010502, XML Schema Part 1: Structures (Схема языка XML. Часть 1. Структуры)

REC-xmlschema-2-20010502, XML Schema Part 2: Datatypes (Схема языка XML. Часть 2. Типы данных)

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

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

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

[ИСО 10303-31:1994, статья 3.2.1]

3.2 абстрактный тестовый комплект (abstract test suit): Набор контрольных примеров.

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

[ИСО 16100-1:2002, статья 3.3]

Примечание - Это определение отличается от приведенного в ИСО 15531-1 и ИСО/ДИС 19439, где термин "возможность" определен как "качественная способность выполнять заданную деятельность". Общее определение термина "возможность" приведено в МЭК 62264-1.

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

[ИСО 16100-2:2003, статья 3.3]

3.5 профилирование возможности (capability profiling): Выбор набора предложенных сервисов, определенных особым интерфейсом в рамках структуры возможности интероперабельности программных изделий разных поставщиков.

[ИСО 16100-1:2002, статья 3.4]

3.6 соответствие (conformance): Отношение между спецификацией и реальным исполнением, соответствующее следующему правилу: что истинно в спецификации, то является истинным и в реальном исполнении.

Пример - Реализация профиля - это соответствие профиля спецификации шаблона, которая создается по правилам, установленным в комплексе стандартов ИСО 16100.

3.7 точка соответствия (conformance point): Специальное требование, установленное в стандартах комплекса ИСО 16100, используемых в качестве основы для подготовки и проведения испытаний с целью установления соответствия реализации.

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

[ИСО/МЭК 10746-2:1996, статья 15.1]

3.9 испытание на соответствие; оценка соответствия (conformance testing; conformity assessment): Тестирование продукта, отобранного для испытаний, для определения наличия специальных характеристик, установленных в настоящем стандарте, с целью определения, в какой степени этот продукт является реализацией, соответствующей техническим условиям.

[ИСО 10303-31:1994, статья 3.2.22]

3.10 протокол испытания на соответствие (conformance test report): Документ, подготовленный после проведения оценки соответствия, в котором приводят полное описание соответствия испытуемого объекта требованиям стандарта, по которому было проведено испытание, а также подробное описание испытания.

[ИСО 10303-31:1994, статья 3.2.23]

3.11 соответствующая реализация (conforming implementation): Реализация, отвечающая требованиям соответствия, согласующимся с возможностями, изложенными в заявлении о соответствии реализации.

[ИСО 10303-31:1994, статья 3.2.24]

3.12 выполняемое средство испытаний (executable test case): Реализация абстрактной совокупности оценочных (тестовых) данных, зависящих от операционной системы и ассоциированных со значениями параметров и специфических испытательных методов.

3.13 выполняемый испытательный комплект (executable test suit): Набор выполняемых контрольных примеров.

3.14 фальсификационное испытание (falsification testing): Испытательный метод, разработанный для обнаружения ошибок в процессе реализации.

[ИСО 10303-31:1994, статья 3.2.32]

3.15 интерфейс (interface): Абстракция поведения объекта, состоящего из подмножества взаимодействий этого объекта с учетом накладываемых ограничений при их возможном появлении.

[ИСО 16100-3:2005, статья 3.3.3]

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

[ИСО 16100-1:2002, статья 3.12]

Примечание - Единица программного обеспечения может быть смоделирована с помощью языка UML в качестве объекта программного обеспечения.

3.17 механизм обнаружения совпадений (matcher): Метод сравнения предложенного профиля с необходимым профилем возможности интероперабельности.

[ИСО 16100-3:2005, статья 3.1.6]

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

[ИСО 16100-3:2005, статья 3.1.7]

3.19 интероперабельность единицы программного обеспечения производства (MSU interoperability): Способность производственной единицы программного обеспечения поддерживать частное применение спецификации интерфейса при обмене наборами прикладной информации с другой производственной единицей программного обеспечения.

[ИСО 16100-3:2005, статья 3.1.8]

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

[ИСО 16100-2:2003, статья 3.10]

3.21 эталонная структура класса возможности (reference capability class structure): Схема, представляющая иерархию классов возможностей, используемая для профилирования возможности.

[ИСО 16100-3:2005, статья 3.1.11]

3.22 шаблон (template): Схема профиля возможности производственного программного обеспечения.

[ИСО 16100-3:2005, статья 3.1.14]

3.23 испытуемый объект (unit under test): Профиль возможности, шаблон возможности, структура класса возможности или механизм обнаружения совпадений, оцениваемые с целью определения соответствия объекта специфическим характеристикам, изложенным в стандартах комплекса ИСО 16100.

4 Сокращения

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

5 Структура соответствия

5.1 Испытание на соответствие

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

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

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

5.2 Типы испытуемых объектов

Интероперабельность производственного программного обеспечения может быть реализована методом профилирования возможности, приведенным в ИСО 16100-2. Выделяют следующие основные этапы метода профилирования возможности как для MSU, так и для профилирования возможности необходимого действия:

a) создание структуры класса возможностей и ее регистрация в базе данных;

b) поиск структуры класса возможностей в базе данных в соответствии с требованиями производственных прикладных программ;

c) выбор класса возможностей из эталонной структуры в базе данных;

d) создание шаблона возможности и его регистрация в базе данных;

e) поиск шаблона возможности в базе данных, соответствующего классу возможностей;

f) создание профиля возможности путем заполнения каждого поля шаблона и его регистрация в базе данных;

g) приведение в соответствие профиля возможности MSU с необходимым профилем с помощью механизма обнаружения совпадений.

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

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

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

- опорная структура класса возможностей;

- шаблон возможности;

- профиль возможности;

- обнаружитель совпадений профилей возможностей.

5.3 Методология аттестационного испытания

Аттестационное испытание включает в себя этапы, указанные на рисунке 1:

a) подготовка CSI;

b) создание АТС;

c) создание ETC;

d) проведение испытания UUT.

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

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

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

Рисунок 1 - Методология развития аттестационного испытания

Когда испытательный комплект выполняют на конкретном UUT, результаты испытания должны быть объединены с результатами каждого выполняемого средства испытаний, принадлежащего конкретному испытательному комплекту. Результатом испытания для каждого средства испытаний должно быть одно из следующих состояний: либо PASS (пропустить), либо FAIL (не пропускать). Испытуемый объект, не соответствующий испытательным данным, считают не соответствующим абстрактному средству испытаний, который отображает набор точек соответствия и ассоциированные испытательные критерии. Если выполнение, по меньшей мере, одного средства испытаний, принадлежащего выполняемому испытательному комплекту, приводит к результату FAIL, то выполнение испытательного комплекта считают не полностью соответствующим.

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

a) создание CSI - см. таблицу 1;

b) создание АТС - см. таблицу 2;

c) создание ЕТС - см. таблицу 3;

d) тестирование UUT - см. таблицу 4.

Таблица 1 - Входные и выходные данные этапа "Создание CSI"

Таблица 2 - Входные и выходные данные этапа "Создание АТС"

Таблица 3 - Входные и выходные данные этапа "Создание ETC"

Таблица 4 - Входные и выходные данные этапа "Тестирование UUT"

6 Проведение аттестационного испытания

6.1 Этап "Создание CSI"

6.1.1 Заявление о соответствии реализации

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

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

Рисунок 2 - Содержание заявления о соответствии реализации

6.1.2 Типы точек соответствия

Точка соответствия - это требование соответствия, установленное в настоящем стандарте или в конкретной спецификации. В этой точке проводят испытание для определения, соответствует ли реализация определенному набору критериев. Типы точек соответствия приведены в таблице 5.

Таблица 5 - Типы точек соответствия

6.1.3 Схема заявления о соответствии реализации

Заявление о соответствии реализации - это запись, представляемая в виде таблицы, содержащей следующие столбцы:

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

b) номер точки соответствия - уникальный идентификатор для каждой точки соответствия;

c) описание точки соответствия - краткое описание точки соответствия, подвергаемой испытанию;

d) ссылка на спецификацию - раздел, подраздел и обозначение стандарта комплекса ИСО 16100, в котором определена конкретная точка соответствия;

e) тип точки соответствия согласно таблице 5;

f) абстрактные критерии тестирования - описание ожидаемого поведения.

6.2 Этап "Создание АТС"

Для каждого типа UUT используют наборы АТС, созданные на основе CSI специального UUT для его испытания. Каждое АТС должно быть связано с другими элементами аттестационного испытания, указанными на рисунке 3, и включать в себя следующие элементы:

a) тип UUT;

b) идентификатор точки соответствия;

c) идентификатор набора точек соответствия;

d) выходные данные испытания точки соответствия.

Каждое АТС должно иметь собственную цель проверки и определение достоверности поведения определенного испытуемого объекта. Абстрактные совокупности тестовых данных должны быть логически сведены в группы ATG в соответствии с набором CSI. Полный набор групп ATG должен формировать ATS для заданного типа UUT.

Рисунок 3 - Диаграмма класса элементов аттестационного испытания

6.3 Этап "Создание ETC"

Для каждого типа UUT используют набор ETC, созданный на основе абстрактных совокупностей тестовых данных особого UUT с целью создания специализированных АТС, зависящих от платформы реализации. Специализированные факторы платформы могут включать в себя аппаратные и программные средства, коммуникационные сети и языки программирования. Выполняемые ETC должны формировать группы ETG так же, как соответствующий набор АТС образует группу ATG. Полный набор групп ETG должен формировать ETS для заданного типа UUT согласно рисунку 3.

6.4 Этап "Тестирование UUT"

Для каждого типа UUT используют комплект ETS, предназначенный для проведения аттестационного испытания. Тестовые входные данные должны включать в себя UUT, а также дополнительную информацию об испытуемом объекте, необходимую для функционирования каждого ETC, относящегося к конкретному ETS. Тестовые выходные данные должны включать в себя протокол аттестационного испытания, содержащий:

a) заявление об уровне соответствия, содержащее одно из следующих значений:

1) FULL CONFORMANCE (полное соответствие) - в случае, если все типы точек соответствия выдержали ETS;

2) MINIMAL CONFORMANCE (минимальное соответствие) - в случае, если все точки соответствия типов А и С выдержали ETS;

3) NO CONFORMANCE - в случае, если одна из точек соответствия типа А или С не выдержала ETS.

Примечание - Заявление об уровне соответствия может быть недостоверным, если ETS не был получен из АТС должным образом;

b) информацию, которая должна включать в себя перечень точек соответствия, выходные данные каждого ETC и подробные информативные сообщения в случаях MINIMAL CONFORMANCE и NO CONFORMANCE.

7 Соответствие испытуемых объектов

7.1 Соответствие структуры класса возможностей

7.1.1 Опорная структура класса возможностей

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

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

Рисунок 4 - Пример отображения структуры класса возможностей для дерева действий приложения

7.1.2 Заявление о соответствии для реализации

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

Таблица 6 - Заявление о соответствии реализации эталонной структуры класса возможностей

7.2 Соответствие шаблона возможности

7.2.1 Шаблон возможности

Описание структуры класса возможности приведено в 6.2.1 ИСО 16100-2, характеристики шаблона возможности - в разделе 7 ИСО 16100-3. Способ отображения класса возможностей для шаблона возможностей приведен в 6.3 ИСО 16100-2.

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

a) точно сформированной схемой XML;

b) достоверным согласно спецификациям раздела 7 ИСО 16100-3.

7.2.2 Заявление о соответствии реализации шаблона возможности

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

Таблица 7 - Абстрактные совокупности тестовых данных шаблона возможности

7.3 Соответствие профиля возможности

7.3.1 Профиль возможности

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

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

a) точно сформированным документом XML;

b) действительным в соответствии со спецификацией шаблона, приведенной в разделе 7 ИСО 16100-3.

7.3.2 Заявление о соответствии реализации профиля возможности

Абстрактные совокупности тестовых данных профиля возможности типа UUT должны соответствовать требованиям таблицы 8.

Таблица 8 - Заявление о соответствии реализации профиля возможности

7.4 Соответствие профиля возможности механизма обнаружения совпадений

7.4.1 Обнаружитель совпадений типа 1

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

a) допускает использование двух действительных профилей и двух действительных шаблонов;

b) запрашивает только те действительные профили, которые необходимы;

c) формирует отчет об уровне совпадения, описание которого приведено в 6.1.2 ИСО 16100-3.

Аттестационное испытание не должно включать в себя проверку поведения обнаружителя совпадений типа 1.

7.4.2 Заявление соответствия для реализации обнаружителя совпадений профилей возможностей

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

Таблица 9 - Заявление соответствия для реализации обнаружителя совпадений профилей возможностей

Приложение А
(справочное)

Аттестационное испытание профиля возможности

Аттестационное испытание профиля возможности проводят в соответствии с правилом, приведенным в примечании.

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

А.1 Абстрактные совокупности тестовых данных

if (! lndex_1)

output message "Capability Profile should be in XML format"

if (! lndex_2)

output message "The schema component of the header elements should be in conformance with ISO

16100-3:2005, 7.1.2."

else {

if (!lndex_2.1)

output message "XML version and target namespaces should be in conformance with ISO 16100-3:2005,

7.1.2

if (! lndex_2.2)

output message "schema component should be in conformance with ISO 16100-3:2005, 7.1.2."

else {

if (!lndex_2.2.1)

output message "Type should have attribute id"

If (!lndex_2.2.2)

Output message "CapabilityProfile should have components 'PKgtype', 'Common', 'Specific'

and attribute date."

else {

if (!lndex_2.2.2.1)

output message "PKgtype' should have version"

if (! lndex_2.2.2.2)

output message "'Common' should be in 'CommonPartType' and 'Specific' should be in

'SpecificPartType'."

}

}

}

if (! lndex_3)

output message "Common part should exist and be in 'CommonPartType'."

else {

if (!lndex_3.1)

output message "The profile should have profile ID but only one ID should be appeared, either

Requirement ID or MSU_Capability ID and each ID should have the value in "string"

type and "unqualified" form"

if (!lndex_3.2)

output message "Each profile should have at least one element 'ReferenceCapabilityClassStructure'.

The value of ReferenceCapabilityClassStructure should be Complex Type"

else {

lf (!lndex_3.2.1)

output message "The value of id should be in "string" type and "unqualified" form"

lf (!lndex_3.2.2)

output message "The value of name should be in "string" type and "unqualified" form"

lf (!lndex_3.2.3)

output message "The value of version should be in "string" type and "unqualified" form"

lf (!lndex_3.2.4)

output message "The value of uri should be in "string" type and "unqualified" form"

}

if (!Index_3.3)

output message "A Profile should have a TemplatelD, the value should be in "string" type and

"unqualified" form. It should distinguish the start class within a Capability Class

Structure. Typically, the value is NULL if capability profile matching is required for the

full capability class structure."

}

if (Index _3.5) { //lndex_3.5 is type С conformance point

// "It is necessary to fill the value for MSU capability profiling, but it is not necessary for requirement capability

profiling. The value of Version is Complex Type"

lf (!lndex_3.5.1)

output message "The value of major should be in "string" type and "unqualified" form"

lf (!Index_3.5.2)

output message "The value of minor should be in "string" type and "unqualified" form"

}

if (lndex_3.6) { //Index_3.6 is type С conformance point

// "it is not necessary for requirement capability profiling, but. It is necessary to fill the value for MSU

capability profiling. If 'Owner' is empty, it means that the profile is for requirement capability profiling"

lf (!lndex_3.6.1)

output message "The value of name should be in "string" type and "unqualified" form"

lf (! lndex_3.6.2)

output message "The value of street should be in "string" type and "unqualified" form"

lf (!lndex_3.6.3)

output message "The value of city should be in "string" type and "unqualified" form"

lf (!lndex_3.6.4)

output message "The value of zip should be in "string" type and "unqualified" form"

lf (!lndex_3.6.5)

output message "The value of state should be in "string" type and "unqualified" form"

lf (!lndex_3.6.6)

output message "The value of country should be in "string" type and "unqualified" form"

lf (!lndex_3.6.7)

output message "The value of comments should be in "string" type and "unqualified" form"

}

if (Index _3.7) { // Index_3.7 is type С conformance point

lf (!lndex_3.7.1)

output message "The value of ComputingFacilities type should be in "string" type and "unqualified" form"

lf (!lndex_3.7.2)

output message "The value of Processor type should be in "string" type and "unqualified" form"

lf (!lndex_3.7.3)

output message "The value of OperatingSystem type should be in "string" type and "unqualified" form"

lf (!lndex_3.7.4)

output message "The value of Language type should be in "string" type and "unqualified" form"

if (lndex_3.7.5) {

lf (!lndex_3.7.5.1)

output message "The value of Memory size should be in "string" type and "unqualified" form"

lf (!lndex_3.7.5.2)

output message "The value of Memory unit should be in "string" type and "unqualified" form"

}

If (Index _3.7.6) {

lf (! lndex_3.7.6.1)

output message "The value of DiskSpace size should be in "string" type and "unqualified" form"

lf (! lndex_3.7.6.2)

output message "The value of DiskSpace unit should be in "string" type and "unqualified" form"

}

}

if (Index _3.9) { //Index_3.9 is type D conformance point

lf (! lndex_3.9.1)

output message "The value of ElapsedTime should be in "string" type and "unqualified" form"

lf (! lndex_3.9.2)

output message "The value of TransactionPerUnitTime should be in "string" type and "unqualified" form"

}

if (lndex_3.11) { //Index _3.11 is type D conformance point

lf (! lndex_3.11.1)

output message "The value of UsageHistory should be in "string" type and "unqualified" form"

lf (! lndex_3.11.2)

output message "The value of Shipments number should be in "string" type and "unqualified" form"

lf (! lndex_3.11.3)

output message "The value of IntendedSafetyIntegrity level should be in "string" type and "unqualified" form"

lf (! lndex_3.11.4)

output message "The value of Certification no1 should be in "string" type and "unqualified" form"

}

if (lndex_3.13) { //lndex_3.13 is type D conformance point

lf (! lndex_3.13.1)

output message "The value of SupportPolicy index should be in "string" type and "unqualified" form"

}

if (lndex_3.15 exists) { //lndex_3.15 is type D conformance point

lf (! lndex_3.15.1)

output message "The value of PriceData invest should be in "string" type and "unqualified" form"

lf (! lndex_3.15.2)

output message "The value of PriceData annualSupport should be in "string" type and "unqualified" form"

lf (! lndex_3.15.3)

output message "The value of PriceData unit should be in "string" type and "unqualified" form"

}

}

Шаблон является схемой соответствующего профиля (см. 7.1.2 ИСО 16100-3 или пример, приведенный ниже). Эту информацию следует использовать при аттестационном испытании профиля возможности.

<CapabilityProfiling xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="C:\...\ISO16100-General.xsd">

A.2 Структура испытания

Этапы и последовательность проведения испытания указаны на рисунке А.1.

А.3 Формат протокола аттестационного испытания

Рекомендуется использовать следующий формат протокола аттестационного испытания (см. 6.4):

a) Проверка достоверности формата XML:

- имя испытуемого объекта: {имя профиля};

- результат проверки достоверности формата XML: {PASS или FAIL};

- формат ошибки при ее возникновении: {NO ERROR или описание и точное место ошибки};

- предполагаемый вариант исправления ошибки: {NO CORRECTION NEEDED или описание исправленной ошибки}.

b) Проверка достоверности точки соответствия:

- имя испытуемого объекта: {имя профиля};

- результат проверки достоверности точки соответствия: {PASS или FAIL};

- возникновение ошибки: {NO ERROR или описание и точное место ошибки};

- предполагаемый вариант исправления ошибки: {NO CORRECTION NEEDED или описание исправленной ошибки}.

Рисунок А.1 - Испытание UUT профиля возможности

Приложение В
(справочное)

Аттестационное испытание механизма обнаружения совпадений типа 1

Аттестационное испытание обнаружителя совпадений типа 1 проводят в соответствии с правилом, приведенным в примечании.

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

В.1 Абстрактная совокупность тестовых данных

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

// accept the required profile

if (! lndex_1) // Validate whether the profile is in XML format

output message "Any Capability profile should be in XML format"

if (!lndex_2)

output message "Both Required Capability Profile and MSU's Capability Profile should be in conformance

with the Capability Profile."

// search for MSU profile according to Reference capability class ID and the Template ID

if (! Find the profile according to Reference capability class ID and the Template ID)

output message "Cannot find the msu profile to match"

if (! msu profile is accessible)

output message "the msu profile is not accessible"

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

If (! lndex_3)

// validate if the report has 4 items: the MSU profile ID; required profile ID; the matching level and the detail list

output message "The MatchingLevel and a detail list report should be in the result report."

else {

If (MatchingLevel =="Complete Match") && (DetailListReport does not include any mandatory match or optional match)

output message "the matching level is invalid."

if (MatchingLevel =="AII Mandatory") && (DetailListReport does not include all mandatory match)

output message "the matching level is invalid."

if (MatchingLevel =="Some_Mandatory") && (DetailListReport does not include any mandatory match)

output message "the matching level is invalid."

if (MatchingLevel =="No_Mandatory") && (DetailListReport includes at least one mandatory match)

output message "the matching level is invalid."

}

Абстрактные совокупности тестовых данных, соответствующих заявлениям реализации обнаружителя совпадений типа 1 для проверки соответствия MatchingLevel детализированному списку, должны быть следующими:

counterAllFail = 0, counterAIIPass = 0,

while (Review the detail list of the matching report) // for mandatory point counting

{

if (mandatory point XX is no match) {

output message "Mandatory point XX does not match"

counterAIIFail = countertAIIFail + 1

}

else

countertAIIPass = counterAIIPass + 1

}

if ((counterAIIFail == 0) && (MatchingLevel ! = AII_Mandatory match) && (MatchingLevel ! = Complete match))

output message "The matching level is not in accordance with the detail list"

else if ((counterAIIPass == 0) && (MatchingLevel == Some_Mandatory match))

output message "The matching level is not in accordance with the detail list"

else if ((counterAIIPass == 0) && (MatchingLevel ! = No_Mandatory match)

output message "The matching level is not in accordance with the detail list"

B.2 Контрольная схема заявления о совпадении профилей возможностей

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

<?xml version="1.0" encoding="utf-8"?>

<!--lnline XSD schema-->

<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">

<xs:element name="MatchingReport">

<xs:complexType>

<xs:sequence>

<xs:element name="reqirement_capability_profilelD">

<xs:complexType>

<xs:sequence>

<xs:element name="ID" type="xs:string"/>

</xs:sequence>

<xs:attribute name="Validated" type="xs:string"/>

//this reqirement_capability_profile has been validated

<xs:attribute name="HasMSU" type="xs:string"/>

//MSU with the required ID has been found

</xs:complexType>

</xs:element>

<xs:element name="capability_msu_profilelD" type="xs:string"/>

<xs:element name="the_matching_level">

<xs:complexType>

<xs:choice>

<xs:element name="Complete_Match"/>

<xs:element name="AII_Mandatory_Match"/>

<xs:element name="Some_Mandatory_Match"/>

<xs:element name="No_Mandatory_Match"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="the_matching_comment" type="xs:string"/>

</xs:sequence>

<xs:attribute name="date" type="xs:string"/>

</xs:complexType>

</xs:element>

</xs:schema>

В.3 Пример блок-схемы аттестационного испытания для заявления о совпадении

Рисунок В.1 - Пример блок-схемы аттестационного испытания для заявления о совпадении

В.4 Аттестационное испытание для заявления о совпадении

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

Рисунок В.2 - Этап "Испытание UUT" для заявления о совпадении

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

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

Электронный текст документа

и сверен по:

, 2020