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

ГОСТ Р ИСО 16100-6-2014

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

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

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

Часть 6

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

Industrial automation systems and integration. Manufacturing software capability profiling for interoperability. Part 6. Interface services and protocols for matching profiles based on multiple capability class structures

ОКС 25.040.01

Дата введения 2016-01-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "НИИ экономики связи и информатики "Интерэкомс" (ООО "НИИ "Интерэкомс") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 16100-6:2011* "Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 6. Службы и протоколы интерфейса для сопоставления профилей, основанных на многоцелевых структурах классов возможностей" (ISO 16100-6:2011 "Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 6: Interface services and protocols for matching profiles based on multiple capability class structures", IDT).

________________

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

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

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

6 ПЕРЕИЗДАНИЕ. Март 2020 г.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настоящий стандарт устанавливает службы и протоколы интерфейса, используемые для метода сопоставления, основанного на многоцелевых структурах классов возможностей. Настоящий стандарт определяет сервисные группы интерфейса шаблона профиля возможностей (CPTI), интерфейса профиля расширенных возможностей (CPI) и расширенную сервисную группу интерфейса обнаружения совпадений, которые являются расширениями сервисов Типа 1, Типа 2 и Типа 3 в соответствии с ИСО 16100-3:2005, раздел 5.4.

Настоящий стандарт определяет сервисную группу интерфейса структуры класса возможностей (CCSI) и дополнительную группу, используемую для создания, регистрации, обеспечения доступа и модификации структуры класса возможностей для ссылочных моделей производственного домена в соответствии с ИСО 16100-5:2009, раздел 6.

Настоящий стандарт устанавливает содержание особой части шаблона профиля возможностей в соответствии с ИСО 16100-5:2009, раздел 7.

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

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

ISO 10303-11, Industrial automation systems and integration - Product data representation and exchange - Part 11: Description methods: The EXPRESS language reference manual (Промышленные системы автоматизации и интеграция. Представление данных продукта и обмен данных. Часть 11. Метод описания. Справочное руководство по языку EXPRESS)

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

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

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

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

ISO 16100-5, Industrial automation systems and integration - Manufacturing software capability profiling for interoperability - Part 5: Methodology for profile matching using multiple capability class structures (Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 5. Методология профилирования сопоставления с помощью множественных структур класса возможностей)

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

В настоящем стандарте применены термины, определенные в ИСО 16100-1, ИСО 16100-2, ИСО 16100-3, ИСО 16100-4 и ИСО 16100-5.

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

Примечание 1 - Роль блока программных средств организации производства (MSU) может быть разной в различных производственных процессах. При этом соответствующий класс возможностей MSU уникально позиционируется в структуре наследования. Он может занимать различные места в структуре агрегации.

Примечание 2 - В настоящем стандарте шаблон класса возможностей идентичен шаблону профиля возможностей (см. ИСО 16100-2:2003, 6.3, требования к шаблонам возможностей).

Примечание 3 - Адаптировано из ИСО 16100-2:2003, определение 3.3.

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

3.2 структура класса возможностей (capability class structure): Иерархия класса возможностей.

Примечание - Настоящая структура предназначена для моделирования иерархий агрегации возможностей в целевых областях, определенных ИСО 16100-1:2009, рисунок 2.

3.3 шаблон структуры класса возможностей (capability class structure template): Схема (логическая структура в базе данных) на расширяемом языке разметки XML, представляющая собой иерархическую структуру классов возможностей.

Примечание - Адаптировано из ИСО 16100-5:2009, определение 3.2.

3.4 шаблон профиля возможностей (capability profile template): Схема профиля возможностей промышленных программных средств организации.

3.5 расширенный служебный интерфейс (extended service interface): Набор служебных точек доступа, определенных в настоящем стандарте для работы с данными производственной области, моделями производственной области, со структурой класса возможностей, профилем возможностей и шаблоном профиля возможностей.

Примечание - Термин "расширенный" относится как к сервису, описанному в настоящем стандарте, так и к "базовому" сервису, определенному в ИСО 16100-3.

3.6 производственные данные (производственная информация) (manufacturing domain data): Класс унифицированного языка моделирования (UML), представляющий информацию относительно производственных ресурсов, производственной деятельности или объектов, взаимодействующих в конкретной области производства.

Примечание - Адаптировано из ИСО 16100-5:2009, определение 3.3.

3.7 шаблон производственных данных (информации) (manufacturing domain data template): Схема (логическая структура в базе данных) на расширяемом языке разметки XML, представляющая собой производственные данные (производственную информацию).

[ИСО 16100-5:2009, определение 3.4]

3.8 производственная модель (manufacturing domain model): Частное представление производственного домена, состоящее из производственных данных и взаимосвязей между ними, соответствующих областям их применения.

[ИСО 16100-5:2009, определение 3.5]

3.9 библиотека деталей (parts library): (производственный) сборник (каталог) описаний деталей.

Примечание - Термин "библиотека деталей" также относится к словарю, например словарю PLIB в ИСО 13584 или открытому словарю OTD в ИСО 22745.

4 Сокращения

BSU - Базовая семантическая единица (Basic Semantic Unit);

CCS - Структура класса возможностей (Capability Class Structure);

CCSI - Интерфейс структуры класса возможностей (Capability Class Structure Interface);

CPI - Интерфейс профиля возможностей (Capability Profile Interface);

CPTI - Интерфейс шаблона профиля возможностей (Capability Profile Template Interface);

CSI - Утверждение соответствия для практической реализации (Conformance Statement for the Implementation);

ESI - Интерфейс расширенных сервисов (Extended Service Interface);

ESP - Поставщик расширенных сервисов (Extended Service Provider);

ICD - Указатель международного кода (International Code Designator);

MDD - Данные производственного домена (Manufacturing Domain Data);

MDM - Модель производственного домена (Manufacturing Domain Model);

MSU - Блок программных средств организации производства (Manufacturing Software Unit);

OTD - Открытый технический словарь (Open Technical Dictionary);

PLIB - Библиотека деталей (в соответствии с ИСО 13584) [Parts Library (as specified in ISO 13584)];

UML - Унифицированный язык моделирования (Unified Modeling Language);

URL - Унифицированный указатель информационного ресурса (Uniform Resource Locator);

URN - Унифицированное имя ресурса (Uniform Resource Name);

XML - Расширяемый язык разметки (eXtensible Markup Language).

5 Службы интерфейса поставщика сервисов

5.1 Наборы служб

Рисунок 1 показывает все сервисы и их соотношения с поставщиками расширенных (базовых) служб, формирующие профили возможностей, шаблоны профиля возможностей, объекты CCS, объекты модели MDM, данные MDD и объекты MDD. Поставщики базовых сервисов работают с группой услуг CPI Типа 1. Поставщики расширенных сервисов работают с услугами CPTI, услугами CPI и услугами CCSI. Кроме того, поставщики расширенных сервисов поддерживают расширенные сервисы обнаружения совпадений и другие сервисные интерфейсы, работающие с моделями MDM и объектами данных MDD.

Рисунок 1 - Наборы служб поставщика расширенных сервисов

Примечание 1 - Настоящий рисунок не соответствует нотации UML. Линии, расположенные между Механизмом хранения данных и Архивом, обозначают существующие правила добавления, удаления и изменения содержания Архива. Линии, расположенные между Механизмом хранения данных и Поставщиком расширенных сервисов, обозначают отображение расширенных сервисов на сервисы хранения данных. Конкретные отображения зависят от практической реализации. В настоящем стандарте они не рассматриваются.

Примечание 2 - Элементы рисунка, выделенные жирным шрифтом, предметно рассматриваются в настоящем стандарте.

Примечание 3 - Содержание Архива хранится в виде XML-файлов.

Примечание 4 - Точка доступа ESI в настоящем стандарте представляется как объект ServiceAccessPoint.

Примечание 5 - Сервисная группа CPI Типа 1, кратко описанная в ИСО 16100-3:2005, раздел 5.4, включает службу обнаружения совпадений типа 1.

Примечание 6 - Сервисная группа CPI Типа 2, кратко описанная в ИСО 6100-3:2005, раздел 5.4, не включает службу обнаружения совпадений типа 2, являющихся частью Расширенной группы обнаружения совпадений.

Примечание 7 - Сервисная группа CPI Типа 3 кратко описана в ИСО 16100-3:2005, раздел 5.4.

Рассматриваемые службы имеют нижеследующие характеристики:

a) для каждой службы имеется один поставщик и один пользователь: третьей стороны - нет;

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

c) инициирование служб пользователем всегда сопровождается откликом поставщика на предоставляемую службу;

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

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

f) инициализация производится для одной отдельной службы. Инициализация не может быть выполнена для группы служб;

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

h) в архиве объект имеет одно из нижеследующих состояний:

1) состояние хранения: объект сохранен в Архиве после формирования запроса;

2) состояние регистрации: объект зарегистрирован в Архиве после проверки его соответствия установленным требованиям;

3) состояние стирания: объект стерт из Архива после формирования запроса на стирание.

5.2 Набор служб ESI

Основные службы ESI, обеспечиваемые ESP, могут быть взяты из группы CPI Типа 1 (см. ИСО 16100-3) и из четырех сервисных групп, перечисленных ниже и детально описанных в разделе 6. Другие сервисные группы также могут существовать (например, модели MDM, объекты MDD и объекты данных MDD), но они не рассматриваются в настоящем стандарте.

a) Сервисная группа CPTI, включающая группу CPI Типа 3, допускает:

1) создание нового шаблона профиля возможностей;

2) получение доступа к шаблону профиля возможностей;

3) модификация шаблона профиля возможностей;

4) проверку соответствия шаблона профиля возможностей;

5) регистрацию профиля возможностей MSU;

6) стирание профиля возможностей MSU.

b) Сервисная группа CPI Типа 2 (см. ИСО 16100-3) допускает:

1) создание нового профиля возможностей MSU или профиля возможностей, удовлетворяющего новым требованиям;

2) обеспечение доступа к профилю возможностей MSU или к профилю возможностей, удовлетворяющему заданным требованиям;

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

4) проверка соответствия профиля возможностей;

5) регистрация профиля возможностей, удовлетворяющего заданным требованиям;

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

c) Сервисная группа CCSI допускает нижеследующие услуги:

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

2) обеспечение доступа к структуре класса возможностей;

3) модификация структуры класса возможностей;

4) проверка соответствия структуры класса возможностей;

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

6) стирание структуры класса возможностей.

d) Расширенная группа обнаружения совпадений допускает:

1) обеспечение доступа к профилю возможностей MSU или профилю возможностей, удовлетворяющему заданным требованиям;

2) сопоставление двух профилей возможностей, при этом каждый ссылается на другую структуру класса возможностей.

5.3 Служебный интерфейс импорта словаря

5.3.1 Библиотеки деталей, импортированные в Архив

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

5.3.2 Соотношение между библиотеками деталей и объектами MDD

Библиотека деталей, импортированная в Архив, может быть использована как часть объектов MDD при профилировании возможностей. Объекты MDD в модели MDM включают определение производственного процесса. Словарь деталей PLIB и открытый технический словарь OTD включают определения технических терминов: это может быть использовано для профилирования возможностей по аналогии с использованием объектов MDD. Все классы и атрибуты словаря PLIB и словаря OTD могут быть идентифицированы уникальным идентификатором в соответствии с ИСО 29002-5 и ИСО 22745-13. Уникальный идентификатор - это форма международной регистрации идентификатора данных (IRDI) в соответствии с ИСО/МЭК 11179-5. Классы и атрибуты словаря PLIB могут также быть описаны комбинацией некоторого словаря и базовой семантической единице BSU, кодом рассматриваемого класса PLIB и внутренним атрибутом словаря. Базовая семантическая единица BSU, соответствующая атрибуту словаря PLIB - это комбинация кода атрибута и BSU родительского класса. Для словаря OTD нет необходимости ссылаться на BSU родительского класса, так как ИСО 22745 нейтрален по отношению к классификации. Он определяет свойства в OTD независимо от класса. Соотношение между словарем PLIB, словарем OTD и объектом MDD определяется отображением уникального идентификатора на каждый объект MDD и атрибут MDD, как показано на рисунке 2.

Примечание 1 - Настоящий рисунок не соответствует нотации UML.

Примечание 2 - В ИСО 13584 термин "свойство" используется вместо термина "атрибут".

Рисунок 2 - Соотношения между библиотеками деталей и объектами MDD

5.3.3 Отображение элемента PLIB на объект MDD

Элемент "MDD_name" на рисунке 2 должен иметь нижеследующие расширенные атрибуты:

- "dictionary_id" (идентификатор словаря),

- "parent" (родитель),

- "BSU" (Базовая семантическая единица),

- "version" (версия)

- "revision" (пересмотр).

Набор атрибутов "dictionary_id", "parent" и "BSU" может быть использован как идентификатор объекта MDD.

В соответствии с рисунком 2 атрибут объекта MDD относится к атрибутам продуктов словаря PLIB. Объект MDD соответствует элементу словаря PLIB. Атрибуты, принадлежащие одному элементу, ассоциируются с одним объектом MDD. См. приложение Е.

6 Расширенный служебный интерфейс

6.1 Службы CPTI-группы

6.1.1 Сценарии, используемые группой услуг CPTI

Группа CPTI использует нижеследующие сценарии шаблона профиля возможностей:

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

b) запросить шаблон профиля возможностей из архива с помощью идентификатора ID шаблона профиля возможностей, а затем получить шаблон профиля возможностей от поставщика сервисов;

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

d) испытать шаблон профиля возможностей в сравнении с критериями соответствия шаблона профиля возможностей, данными в ИСО 16100-5:2009, раздел 8, а затем получить положительный отклик, отрицательный отклик или отклик уровня сопоставления от поставщика сервисов;

е) зарегистрировать испытанный шаблон профиля возможностей в архиве и получить статус "зарегистрирован" от поставщика сервисов;

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

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

6.1.2.1 Процесс создания

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

a) внесения особых значений определенных атрибутов определенных элементов в характеристическую формальную структуру шаблона профиля возможностей в соответствии с ИСО 16100-5:2009, раздел 6.3;

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

6.1.2.2 Конфигурация шаблона профиля возможностей

Характеристическая формальная структура шаблона профиля возможностей может быть либо частично, либо полностью заполнена в соответствии с требованиями приложения.

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

a) атрибуты "идентификатор" и "название" в элементе "Шаблон профиля возможностей";

b) атрибут имени области "domain_name" в элементе ссылочного имени "Reference_MDM_name";

c) атрибут названия формата "format_name" в элементе описания формата "MDD_Description_format" с одним из четырех нижеследующих значений:

1) "Set_Of_MDD_objects" (набор объектов MDD);

2) "List_Of_MDD_objects" (список объектов MDD);

3) "Time_Ordered_MDD_objects" (объекты MDD, упорядоченные по времени);

4) "Event_Ordered_MDD_objects" (объекты MDD в порядке поступления);

d) атрибуты "название" и "производственная деятельность" в элементе названия объекта "MDD_name".

Каждое значение, внесенное или модифицированное для атрибутов "идентификатор" [в разделе 6.1.2.2 а)], имени области "domain_name" в разделе 6.1.2.2 b) и "название" в разделе 6.1.2.2 d), должно быть уникальным.

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

6.1.2.3 Служба createTemplate

6.1.2.3.1 Шаблон, основанный на характеристической структуре формальной возможности

Служба createTemplate должна позволять пользователю шаблона создавать шаблон, основанный на характеристической структуре формальной возможности. Если создание шаблона основано на структуре формальной возможности, то служба createTemplate использует, как минимум, requestBlankTemplate, returnBlankTemplate, ProcessFilledTemplate и службу returnProcessingResult. Служба createTemplate включает нижеследующие шаги:

a) пользователь шаблона инициирует службу requestBlankTemplate объекта ServiceAccessPoint, в котором нет параметров, ассоциированных с услугой requestBlankTemplate;

b) поставщик сервисов инициирует службу returnBlankTemplate объекта ServiceAccessPoint, в котором параметрами службы returnBlankTemplate являются заготовка шаблона и ошибка создания;

c) пользователь шаблона заполняет заготовку шаблона, используя объекты MDD модели MDM, а затем инициирует службу processFilledTemplate объекта ServiceAccessPoint, в котором параметром processFilledTemplate является идентификатор шаблона;

d) поставщик сервисов проверяет уникальность идентификатора шаблона, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами службы returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

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

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

Служба createTemplate дает возможность пользователю шаблона создать новый шаблон путем модификации существующего шаблона. Если при создании нового шаблона модифицируется существующий шаблон, то служба createTemplate использует как минимум службу requestExistingTemplate, службу returnExistingTemplate, службу processModifiedTemplate и службу returnProcessingResult. Служба createTemplate включает нижеследующие шаги:

а) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;

c) пользователь шаблона модифицирует существующий шаблон, а затем инициирует службу processModifiedTemplate объекта ServiceAccessPoint, в котором параметром службы processModifiedTemplate является идентификатор шаблона;

d) поставщик сервисов проверяет уникальность идентификатора шаблона, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

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

Примечание 1 - Пунктирная линия разделяет два рассмотренных варианта.

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

Рисунок 3 - Служба createTemplate

6.1.3 Служба accessTemplate

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

Служба accessTemplate включает нижеследующие шаги:

а) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки.

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

Рисунок 4 - Служба accessTemplate

6.1.4 Служба modifyTemplate

Служба modifyTemplate, использующая службу requestExistingTemplate, службу returnExistingTemplate, службу processModifiedTemplate и службу returnProcessingResult, дает возможность пользователю шаблона модифицировать существующий шаблон.

Служба modifyTemplate включает нижеследующие шаги:

a) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;

c) пользователь шаблона модифицирует существующий шаблон, а затем инициирует службу processModifiedTemplate объекта ServiceAccessPoint, в котором параметром службы processModifiedTemplate является идентификатор шаблона;

d) поставщик сервисов проверяет уникальность идентификатора шаблона, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами службы returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 5 на языке UML приведена диаграмма обязательных шагов последовательности процедуры модификации существующего шаблона с помощью идентификатора шаблона.

Рисунок 5 - Служба modifyTemplate

6.1.5 Служба validateTemplate

Служба validateTemplate, использующая службу requestUnregisteredTemplate, службу returnUnregisteredTemplate, службу testTemplate, службу returnTestResult, дает возможность пользователю шаблона провести проверку соответствия существующего незарегистрированного шаблона.

Служба validateTemplate включает нижеследующие шаги:

a) пользователь шаблона инициирует службу requestUnregisteredTemplate объекта ServiceAccessPoint, в котором параметром службы requestUnregisteredTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnUnregisteredTemplate объекта ServiceAccessPoint, в котором параметрами службы returnUnregisteredTemplate являются незарегистрированный шаблон и ошибка обработки;

c) пользователь шаблона инициирует службу testTemplate объекта ServiceAccessPoint, в котором нет параметров, ассоциированных со службой testTemplate;

d) поставщик сервисов инициирует службу returnTestResult объекта ServiceAccessPoint, в котором параметрами службы returnTestResult являются результат испытаний и статус сопоставления.

Значение параметра результата испытаний службы returnTestResult может быть положительным, отрицательным или уровнем сопоставления, определенным в ИСО 16100-5:2009, раздел 7.2. Значение параметра статуса сопоставления службы returnTestResult должно быть эквивалентно выходным сообщениям, рассмотренным в ИСО 16100-4:2006, раздел В.1.

Испытанный шаблон должен быть зарегистрирован в архиве, если значение параметра результата испытаний службы returnTestResult "положительно" или "полное совпадение" (см. ИСО 16100-5:2009, раздел 7.2). В зависимости от требований пользователя, испытанный шаблон может быть зарегистрирован в архиве, если значение параметра результата испытаний либо "полное обязательное совпадение", либо "некоторое обязательное совпадение" (см. ИСО 16100-5:2009, раздел 7.2). Испытанный шаблон может быть модифицирован снова, чтобы удовлетворять критериям соответствия, если значение параметра результата испытаний отрицательно или "обязательное совпадение отсутствует" (см. ИСО 16100-5:2009, раздел 7.2).

На рисунке 6 на языке UML приведена диаграмма обязательных шагов последовательности проверки соответствия незарегистрированного шаблона, основанной на использовании идентификатора шаблона.

Рисунок 6 - Служба validateTemplate

6.1.6 Служба deleteTemplate

Служба deleteTemplate, использующая службу requestExistingTemplate, службу returnExistingTemplate, службу removeTemplate и службу returnRemoveResult, дает возможность пользователю шаблона стереть существующий шаблон.

Служба deleteTemplate включает нижеследующие шаги:

а) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;

c) пользователь шаблона инициирует службу removeTemplate объекта ServiceAccessPoint, в котором отсутствуют параметры, ассоциированные со службой removeTemplate;

d) поставщик сервисов инициирует службу returnRemoveResult объекта ServiceAccessPoint, в котором параметром службы returnRemoveResult является ошибка удаления.

На рисунке 7 на языке UML приведена диаграмма обязательных шагов последовательности стирания шаблона, основанная на использовании идентификатор шаблона.

Рисунок 7 - Служба deleteTemplate

6.2 Расширенная CPI-группа

6.2.1 Сценарии, используемые расширенной CPI группой сервисов

Группа сервисов CPI использует нижеследующий сценарий профиля возможностей:

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

b) получение доступа к профилю либо из Архива через интерфейс ESI, либо из MSU путем использования идентификатора профиля возможностей, а затем получение профиля возможностей либо от поставщика сервисов, либо из MSU;

c) модификация профиля возможностей в соответствии либо с требованиями пользователя, либо в соответствии с результатами проверки соответствия, а затем получение модифицированного профиля возможностей либо от поставщика сервисов, либо из MSU;

d) испытание профиля возможностей по его критериям соответствия и получение либо положительного отклика, либо отрицательного отклика, либо отклика уровня сопоставления от поставщика сервисов;

e) регистрация испытанного профиля возможностей в Архиве и получение статуса "зарегистрирован" от поставщика сервисов;

f) стирание профиля возможностей с помощью идентификатора профиля возможностей и получение статуса "стерт" от поставщика сервисов.

6.2.2 Создание профиля возможностей

6.2.2.1 Процесс создания

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

6.2.2.2 Служба createProfile

6.2.2.2.1 Профиль, основанный на шаблоне профиля возможностей

Служба createProfile дает возможность пользователю профиля запросить создание профиля, основанного на использовании шаблона профиля возможностей. Если создание профиля основано на использовании шаблона профиля возможностей, то служба createProfile использует как минимум службу requestExistingTemplate, службу returnExistingTemplate, службу processFilledProfile и службу returnProcessingResult. Служба createProfile включает нижеследующие шаги:

а) пользователь профиля инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;

b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;

c) пользователь профиля заполняет существующий шаблон, используя объект MDD модели MDM, а затем инициирует службу processFilledProfile объекта ServiceAccessPoint, в котором параметром службы processFilledProfile является идентификатор профиля;

d) поставщик сервисов проверяет уникальность идентификатора профиля, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

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

6.2.2.2.2 Профиль, основанный на существующем профиле возможностей

Служба createProfile дает возможность пользователю профиля запросить создание нового профиля путем модификации существующего профиля. При создании нового профиля путем модификации существующего профиля, служба createTemplate использует как минимум службу requestExistingProfile, службу returnExistingProfile, службу processModifiedProfile и службу returnProcessingResult. Служба createProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта ServiceAccessPoint, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта ServiceAccessPoint, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки;

c) пользователь профиля модифицирует существующий профиль, используя объект данных MDD модели MDM, а затем инициирует службу processModifiedProfile объекта ServiceAccessPoint, в котором параметром службы processModifiedProfile является идентификатор профиля;

d) поставщик сервисов проверяет уникальность идентификатора профиля, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 8 (ниже пунктирной линии) на языке UML приведена диаграмма последовательности создания нового профиля из существующего профиля.

Примечание 1 - Пунктирная линия разделяет два варианта создания профиля.

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

Рисунок 8 - Служба createProfile

6.2.3 Служба accessProfile

6.2.3.1 Профиль ESI, отличный от профиля MSU

Служба accessProfile дает возможность пользователю профиля получить доступ к профилю возможностей MSU из профиля ESI, отличного от профиля MSU. Служба accessProfile используеткак минимум службу requestExistingProfile и службу returnExistingProfile. Служба accessProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта ServiceAccessPoint, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта ServiceAccessPoint, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки.

На рисунке 9 (выше пунктирной линии) на языке UML приведена диаграмма последовательности обязательных шагов процедуры получения доступа к профилю, основанной на использовании идентификатора профиля ESI.

6.2.3.2 Профиль из MSU

Служба accessProfile дает возможность пользователю профиля получить доступ к требуемому профилю возможностей MSU. Служба accessProfile использует как минимум службу requestExistingProfile и службу returnExistingProfile. Служба accessProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта MSU, в котором параметры службы requestExistingProfile отсутствуют;

b) поставщик сервисов инициирует службу returnExistingProfile объекта MSU, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки.

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

Рисунок 9 - Служба accessProfile

6.2.4 Служба modifyProfile

6.2.4.1 Профиль, доступный в интерфейсе ESI

Служба modifyProfile использует службу requestExistingProfile, службу returnExistingProfile, службу processModifiedProfile и службу returnProcessingResult. Она дает возможность пользователю профиля модифицировать существующий профиль, доступный в интерфейсе ESI. Служба modifyProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта ServiceAccessPoint, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта ServiceAccessPoint, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки;

c) пользователь профиля модифицирует существующий профиль, используя объект MDD модели MDM, а затем инициирует службу processModifiedProfile объекта ServiceAccessPoint, в котором параметрами службы processModifiedProfile является идентификатор профиля;

d) поставщик сервисов проверяет уникальность идентификатора профиля, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 10 (выше пунктирной линии) на языке UML приведена диаграмма последовательности процедуры модификации профиля с помощью существующего профиля ESI.

6.2.4.2 Профиль, доступный в MSU

Служба modifyProfile использует службу requestExistingProfile, службу returnExistingProfile, службу processModifiedProfile и службу returnProcessingResult. Она дает возможность пользователю профиля модифицировать существующий профиль, доступный в MSU. Служба modifyProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта MSU, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта MSU, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки;

c) пользователь профиля модифицирует существующий профиль, используя объект данных MDD модели MDM, а затем инициирует службу processModifiedProfile объекта MSU, в котором параметром службы processModifiedProfile является идентификатор профиля;

d) поставщик сервисов проверяет уникальность идентификатора профиля, а затем инициирует службу returnProcessingResult объекта MSU, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 10 (ниже пунктирной линии) на языке UML приведена диаграмма последовательности процедуры модификации профиля с помощью существующего профиля через MSU.

Рисунок 10 - Служба modifyProfile

6.2.5 Служба validateProfile

Служба validateProfile использует службу requestExistingProfile, службу returnExistingProfile, службу testProfile и службу returnTestResult. Она дает возможность пользователю профиля провести проверку соответствия существующего профиля.

Служба validateProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта ServiceAccessPoint, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта ServiceAccessPoint, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки;

c) пользователь профиля инициирует службу testProfile объекта ServiceAccessPoint, в котором параметры, ассоциированные со службой testProfile, отсутствуют;

d) поставщик сервисов инициирует службу returnTestResult объекта ServiceAccessPoint, в котором параметрами службы returnTestResult являются результат испытаний и статус сопоставления.

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

Рисунок 11 - Служба validateProfile

6.2.6 Служба deleteProfile

Служба deleteProfile использует службу requestExistingProfile, службу returnExistingProfile, службу removeProfile и службу returnRemoveResult. Она дает возможность пользователю профиля стереть существующий профиль в Архиве посредством ESI.

Служба deleteProfile включает нижеследующие шаги:

a) пользователь профиля инициирует службу requestExistingProfile объекта ServiceAccessPoint, в котором параметром службы requestExistingProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnExistingProfile объекта ServiceAccessPoint, в котором параметрами службы returnExistingProfile являются существующий профиль и ошибка обработки;

c) пользователь профиля инициирует службу removeProfile объекта ServiceAccessPoint, в котором параметры, ассоциированные с службой removeProfile, отсутствуют;

d) поставщик сервисов инициирует службу returnRemoveResult объекта ServiceAccessPoint, в котором параметром службы returnRemoveResult является ошибка удаления.

На рисунке 12 на языке UML приведена диаграмма последовательности обязательных шагов процедуры стирания профиля, основанной на использовании идентификатора профиля.

Рисунок 12 - Служба deleteProfile

6.3 Группа CCSI

6.3.1 Сценарии, используемые группой CCSI

Группа CCSI использует нижеследующие сценарии шаблона профиля возможностей:

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

b) получение доступа к CCS в Архиве с помощью идентификатора CCS, а затем получение CCS от поставщика сервисов;

c) модификация CCS в соответствии либо с требованиями пользователя, либо с результатами проверки соответствия, а затем получение модифицированного CCS от поставщика сервисов;

d) испытание CCS на соответствие установленным критериям соответствия CCS и получение либо положительного отклика, либо отрицательного отклика, либо отклика уровня сопоставления от поставщика сервисов;

e) регистрация CCS в Архиве и получение статуса "зарегистрирован" от поставщика сервисов;

f) удаление CCS с помощью идентификатора идентификатор CCS и получение статуса "удален" от поставщика сервисов.

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

6.3.2.1 Процесс создания

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

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

6.3.2.2 Служба createCCS

6.3.2.2.1 Создание CCS из заготовки шаблона CCS

Служба createCCS дает возможность пользователю CCS создавать новые CCS путем заполнения заготовки шаблона CCS. При создании CCS из заготовки шаблона CCS служба createCCS использует как минимум службу requestBlankCCS, службу returnBlankCCS, службу processFilledCCS и службу returnProcessingResult.

Служба createCCS, предназначенная для создания новой структуры CCS из заготовки шаблона CCS, включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestBlankCCS объекта ServiceAccessPoint, в которой параметры, ассоциированные со службой requestBlankCCS, отсутствуют;

b) поставщик сервисов инициирует службу returnBlankCCS объекта ServiceAccessPoint, в котором параметрами службы returnBlankCCS являются заготовка CCS и ошибка создания;

c) пользователь CCS заполняет заготовку шаблона CCS, используя объекты MDD модели MDM, а затем инициирует службу processFilledCCS объекта ServiceAccessPoint, в котором параметром службы processFilledCCS является идентификатор CCS;

d) поставщик сервисов проверяет уникальность идентификатора CCS, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 13 (выше пунктирной линии) на языке UML приведена диаграмма последовательности обязательных шагов процедуры создания новой CCS из формальной структуры CCS.

6.3.2.2.2 Структура CCS, созданная путем модификации существующей структуры CCS

Служба createCCS дает возможность пользователю CCS создавать новые структуры CCS путем модификации существующих CCS. При создании новых CCS путем модификации существующих CCS служба createCCS использует как минимум службу requestExistingCCS, службу returnExistingCCS, службу processModifiedCCS и службу returnProcessingResult. Служба createCCS включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestExistingCCS объекта ServiceAccessPoint, в котором параметром службы requestExistingCCS является идентификатор CCS;

b) поставщик сервисов инициирует службу returnExistingCCS объекта ServiceAccessPoint, в котором параметрами службы returnExistingCCS являются существующая CCS и ошибка обработки;

c) пользователь CCS модифицирует существующую CCS, а затем инициирует службу processModifiedCCS объекта ServiceAccessPoint, в котором параметром службы processModifiedCCS является идентификатор CCS;

d) поставщик сервисов проверяет уникальность идентификатора CCS, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 13 (ниже пунктирной линии) на языке UML приведена диаграмма последовательности обязательных шагов процедуры создания новой структуры CCS из существующей структуры CCS.

Примечание 1 - Пунктирная линия разделяет два варианта создания сущности.

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

Рисунок 13 - Служба createCCS

6.3.3 Служба accessCCS

Служба accessCCS использует службу requestExistingCCS и службу returnExistingCCS. Она дает возможность пользователю CCS получить доступ к существующей CCS.

Служба accessCCS включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestExistingCCS объекта ServiceAccessPoint, в котором параметром службы requestExistingCCS является идентификатор CCS;

b) поставщик сервисов инициирует службу returnExistingCCS объекта ServiceAccessPoint, в котором параметрами службы returnExistingCCS являются существующая CCS и ошибка обработки.

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

Рисунок 14 - Служба accessCCS

6.3.4 Служба modifyCCS

Служба modifyCCS использует службу requestExistingCCS, службу returnExistingCCS, службу processModifiedCCS и службу returnProcessingResult. Она дает возможность пользователю CCS модифицировать существующую CCS.

Служба modifyCCS включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestExistingCCS объекта ServiceAccessPoint, в котором параметром службы requestExistingCCS является идентификатор CCS;

b) поставщик сервисов инициирует службу returnExistingCCS объекта ServiceAccessPoint, в котором параметрами службы returnExistingCCS являются существующая CCS и ошибка обработки;

c) пользователь CCS модифицирует существующую CCS, а затем инициирует службу processModifiedCCS объекта ServiceAccessPoint, в котором параметром службы processModifiedCCS является идентификатор CCS;

d) поставщик сервисов проверяет уникальность идентификатора CCS, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.

На рисунке 15 на языке UML приведена диаграмма последовательности обязательных шагов процедуры модификации существующей CCS на основе идентификатора CCS.

Рисунок 15 - Служба modifyCCS

6.3.5 Служба validateCCS

Служба validateCCS использует службу requestExistingCCS, службу returnExistingCCS, службу testCCS и службу returnTestResult. Она дает возможность пользователю CCS провести проверку соответствия существующей CCS.

Служба validateCCS включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestExistingCCS объекта ServiceAccessPoint, в котором параметром службы requestExistingCCS является идентификатор CCS;

b) поставщик сервисов инициирует службу returnExistingCCS объекта ServiceAccessPoint, в котором параметрами службы returnExistingCCS являются существующая CCS и ошибка обработки;

c) пользователь CCS инициирует службу testCCS объекта ServiceAccessPoint, в котором параметры, ассоциированные с услугой testCCS, отсутствуют;

d) поставщик сервисов инициирует службу returnTestResult объекта ServiceAccessPoint, в котором параметрами услуги returnTestResult являются результат испытаний и ошибка статуса.

На рисунке 16 на языке UML приведена диаграмма последовательности обязательных шагов процедуры проверки соответствия существующей CCS с помощью идентификатора CCS.

Рисунок 16 - Служба validateCCS

6.3.6 Служба deleteCCS

Служба deleteCCS использует службу requestExistingCCS, службу returnExistingCCS, службу removeCCS и службу returnRemoveResult. Она дает возможность пользователю CCS стереть существующую CCS.

Служба deleteCCS включает нижеследующие шаги:

a) пользователь CCS инициирует службу requestExistingCCS объекта ServiceAccessPoint, в котором параметром службы requestExistingCCS является идентификатор CCS;

b) поставщик сервисов инициирует службу returnExistingCCS объекта ServiceAccessPoint, в котором параметрами службы returnExistingCCS являются существующая CCS и ошибка обработки;

c) пользователь CCS инициирует службу removeCCS объекта ServiceAccessPoint, в котором параметры, ассоциированные со службой removeCCS, отсутствуют;

d) поставщик сервисов инициирует службу returnRemoveResult объекта ServiceAccessPoint, в котором параметром службы returnRemoveResult является ошибка удаления.

На рисунке 17 на языке UML приведена диаграмма последовательности обязательных шагов процедуры стирания CCS с помощью идентификатора CCS.

Рисунок 17 - Служба deleteCCS

6.4 Расширенная группа обнаружения совпадений

6.4.1 Сценарии, используемые расширенной группой обнаружителей совпадений

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

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

b) сопоставление двух профилей возможностей (существующего профиля возможностей MSU и требуемого профиля возможностей) и получение результата сопоставления, включающего уровень сопоставления (см. ИСО 16100-5:2009, раздел 7.2) и отчет о согласованных и несогласованных функциях от поставщика сервисов.

6.4.2 Служба ExtendedMatcher

Служба ExtendedMatcher использует службу requestProfile, службу returnProfile, службу requestMatching и службу returnMatchingResult. Она дает возможность пользователю запросить профиль либо из архива, либо из MSU (блока программных средств организации производства) и сопоставить профиль возможностей MSU с требуемым профилем возможностей, используя рассматриваемый обнаружитель совпадений.

Служба ExtendedMatcher включает нижеследующие шаги:

a) пользователь обнаружителя совпадений инициирует службу requestProfile объекта ServiceAccessPoint или объекта MSU, в котором параметром службы requestProfile является идентификатор профиля;

b) поставщик сервисов инициирует службу returnProfile объекта ServiceAccessPoint или объекта MSU, в котором параметрами службы returnProfile являются существующий профиль и ошибка обработки;

c) пользователь обнаружителя совпадений инициирует службу requestMatching объекта ServiceAccessPoint, в котором имеются два параметра идентификатора профиля;

d) поставщик сервисов инициирует службу returnMatchingResult объекта ServiceAccessPoint, в котором параметрами службы returnMatchingResult являются уровень сопоставления (см. ИСО 16100-5:2009, раздел 7.2) и отчет о сопоставлении (отчет о согласованных и несогласованных функциях).

На рисунке 18 на языке UML приведена диаграмма последовательности обязательных шагов процедуры запрашивания профиля и сопоставления двух профилей.

Примечание - Пунктирная линия отделяет запрос профиля от запроса сопоставления.

Рисунок 18 - Служба ExtendedMatcher

6.4.3 Проверка соответствия обнаружителя совпадений

Методология установления соответствия, описанная в ИСО 16100-4, используется в настоящем стандарте. Здесь утверждения соответствия для практической реализации CSI расширяются и используются обнаружителями совпадений профилей возможностей в соответствии с ИСО 16100-4:2006, таблица 9. Таблицы 1 и 2 в настоящем стандарте используются процедурой проверки соответствия. Типы точек соответствия, указанные в таблицах 1 и 2, определены в ИСО 16100-4:2006, таблица 5.

Таблица 1 - Утверждения соответствия CSI, необходимые для функционирования обнаружителей совпадений

Таблица 2 - Использование утверждений соответствия CSI в отчетах обнаружителей совпадений

7 Формальное описание протокола расширенных сервисов ESI

7.1 Синтаксис основных сервисов

Синтаксис услуги унифицированного названия ресурса URN, описанный в ИСО 16100-3, используется в настоящем стандарте.

Характеристическое название услуги типа URN начинается с строки "услуга:". Настоящее название услуги типа URN включает тип сервиса и соответствующую точку доступа услуги, в которую не включается разделитель ":", с которого начинается адрес спецификации. Информация об атрибуте рассматриваемой услуги следует за адресом спецификации, закодированным в соответствии с грамматикой универсального имени ресурса URN.

Полное имя URN услуги имеет нижеследующий синтаксис:

"service:<service-type>:<service-access-point>://<address>;<atribute-list>"

Элемент <service-type> в строке URN представляет характеристическую услугу, идентифицированную в разделе 5.1.

Элемент <service-access-type> в строке URN представляет собой точку доступа сервисные группы ESI. Данные сервисные группы идентифицированы в разделе 5.2.

Элемент <address> в строке URN задает путь к поставщику услуг ESI.

Список атрибутов включает знаки ";", разделяющие назначения атрибутов. Назначения атрибутов имеют форму:

<atribute-id>=<atribute-value>

В дополнение для ключевых атрибутов используется форма <atribute-id>.

Подробное описание услуг на языке UML во всех диаграммах в Разделе 6 использует формальный синтаксис в соответствии с оставшимися подразделами раздела 7.

7.2 Служебный протокол CPTI-группы

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

7.2.1.1 Создание с помощью формальной структуры

Служба createTemplate генерирует шаблон с помощью формальной структуры. Она включает нижеследующие шаги:

a) служба requestBlankTemplate запрашивает заготовку шаблона и задает тип сервиса:

<service-type>="requestBlankTemplate"

b) служба returnBlankTemplate получает заготовку шаблона и задает тип сервиса:

<service-type>="returnBlankTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- access_status="the_access_status"

c) служба processFilledTemplate запрашивает приемлемость заполненного шаблона и задает тип сервиса:

<service-type>="processFilledTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

d) служба returnProcessingResult получает результат обработки и задает тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.2.1.2 Создание с помощью существующего шаблона

Служба createTemplate также генерирует шаблон с помощью существующего шаблона. Она включает нижеследующие шаги:

a) Служба requestExistingTemplate запрашивает существующий шаблон и задает тип сервиса:

<service-type>="requestExistingTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

b) Служба returnExistingTemplate получает существующий шаблон и задает тип сервиса:

<service-type>="returnExistingTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- process_status="the_process_status"

c) Служба processModifiedTemplate запрашивает приемлемость модифицированного шаблона и задает тип сервиса:

<service-type>="processModifiedTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

d) Служба returnProcessingResult получает результат обработки и задает тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.2.2 Доступ к шаблону профиля возможностей

Служба accessTemplate получает доступ к шаблону и включает нижеследующие шаги:

a) служба requestExistingTemplate получает доступ к существующему шаблону и задает тип сервиса:

<service-type>="requestExistingTemplate" с соответствующими атрибутами:

- template_ID="the_template_id";

b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:

<service-type>="returnExistingTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- process_status="the_process_status"

7.2.3 Модификация шаблона профиля возможностей

Служба modifyTemplate модифицирует шаблон и включает нижеследующие шаги:

а) служба requestExistingTemplate получает доступ к существующему шаблону и задает тип сервиса:

<service-type>="requestExistingTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

b) служба returnExistingTemplate получает запрошенный шаблон и задает тип сервиса:

<service-type>="returnExistingTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- process_status="the_process_status"

c) служба processModifiedTemplate запрашивает приемлемость модифицированного шаблона и задает тип сервиса:

<service-type>="processModifiedTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.2.4 Проверка соответствия шаблона профиля возможностей

Служба validateTemplate обеспечивает испытание шаблона и включает нижеследующие шаги:

a) служба requestUnregisteredTemplate получает доступ к незарегистрированному шаблону и задает тип сервиса:

<service-type>="requestUnregisteredTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

b) служба returnUnregisteredTemplate получает запрошенный шаблон. Тип сервиса:

<service-type>="returnUnregisteredTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- process_status="the_process_status"

c) служба testTemplate верифицирует незарегистрированный шаблон. Тип сервиса:

<service-type>="testTemplate"

d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:

<service-type>="returnTestResult" с соответствующими атрибутами:

- test_result ="the_test_result"

- test_status="the_test_status"

7.2.5 Стирание шаблона профиля возможностей

Служба deleteTemplate стирает существующий шаблон и включает нижеследующие шаги:

a) служба requestExistingTemplate получает доступ к существующему шаблону. Тип сервиса:

<service-type>="requestExistingTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:

<service-type>="returnExistingTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- process_status="the_process_status"

c) служба removeTemplate стирает шаблон профиля возможностей из архива. Тип сервиса:

<service-type>="removeTemplate"

d) служба returnRemoveResult получает статус удаления. Тип сервиса:

<service-type>="returnRemoveResult" с соответствующими атрибутами:

- remove_status="the_remove_status"

7.3 Служебные протоколы расширенной CPI-группы

7.3.1 Создание профиля возможностей

7.3.1.1 Создание с помощью шаблона профиля возможностей

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

a) служба requestExistingTemplate запрашивает существующий шаблон. Тип сервиса:

<service-type>="requestExistingTemplate" с соответствующими атрибутами:

- template_ID="the_template_id"

b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:

<service-type>="returnExistingTemplate" с соответствующими атрибутами:

- template_content="the_template_content"

- access_status="the_access_status"

c) служба processFilledProfile запрашивает приемлемость заполненного профиля. Тип сервиса:

<service-type>="processFilledProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.3.1.2 Создание с помощью существующего профиля

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

a) служба requestExistingProfile запрашивает существующий профиль. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает существующий профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

c) служба processModifiedProfile запрашивает приемлемость модифицированного профиля. Тип сервиса:

<service-type>="processModifiedProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.3.2 Доступ к профилю возможностей

7.3.2.1 Доступ через расширенный служебный интерфейс ESI

Служба accessProfile получает доступ к профилю через интерфейс ESI и включает нижеследующие шаги:

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

7.3.2.2 Доступ через блок программных средств организации производства MSU

Служба accessProfile также получает доступ к профилю через MSU и включает нижеследующие шаги:

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

7.3.3 Модификация профиля возможностей

Служба modifyProfile модифицирует профиль и включает нижеследующие шаги:

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

c) служба processModifiedProfile запрашивает приемлемость модифицированного профиля. Тип сервиса:

<service-type>="processModifiedProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.3.4 Проверка соответствия профиля возможностей

Служба validateProfile обеспечивает испытание существующего профиля и включает нижеследующие шаги:

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

c) служба testProfile верифицирует незарегистрированный профиль. Тип сервиса:

<service-type>="testProfile"

d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:

<service-type>="returnTestResult" с соответствующими атрибутами:

- test_result="the_test_result"

- test_status="the_test_status"

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

Служба deleteTemplate стирает существующий шаблон и включает нижеследующие шаги:

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

c) служба removeProfile удаляет профиль возможностей из архива. Тип сервиса:

<service-type>="removeProfile"

d) служба returnRemoveResult получает статус удаления. Тип сервиса:

<service-type>="returnRemoveResult" с соответствующими атрибутами:

- remove_status="the_remove_status"

7.4 Служебные протоколы CCSI-группы

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

7.4.1.1 Создание с помощью формальной структуры

Служба createCCS генерирует новую структуру CCS с помощью формальной структуры и включает нижеследующие шаги:

a) служба requestBlankCCS запрашивает заготовку CCS. Тип сервиса:

<service-type>="requestBlankCCS"

b) служба returnBlankCCS получает заготовку CCS. Тип сервиса:

<service-type>="returnBlankCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- access_status="the_access_status"

c) служба processFilliedCCS запрашивает приемлемость заполненной структуры CCS. Тип сервиса:

<service-type>="processFilliedCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.4.1.2 Создание с помощью существующей структуры CCS

Служба createCCS также генерирует шаблон с помощью существующей структуры CCS и включает нижеследующие шаги:

a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:

<service-type>="requestExistingCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

b) служба returnExistingCCS получает существующую CCS. Тип сервиса:

<service-type>="returnExistingCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- process_status="the_process_status"

c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса:

<service-type>="processModifiedCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.4.2 Доступ к структуре класса возможностей

Служба accessCCS получает доступ к структуре CCS и включает нижеследующие шаги:

a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:

<service-type>="requestExistingCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

b) служба returnExistingCCS получает существующую CCS. Тип сервиса:

<service-type>="returnExistingCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- process_status="the_process_status"

7.4.3 Модификация структуры класса возможностей

Служба modifyCCS модифицирует структуру CCS и включает нижеследующие шаги:

a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:

<service-type>="requestExistingCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

b) служба returnExistingCCS получает существующую CCS. Тип сервиса:

<service-type>="returnExistingCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- process_status="the_process_status"

c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса:

<service-type>="processModifiedCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

d) служба returnProcessingResult получает результат обработки. Тип сервиса:

<service-type>="returnProcessingResult" с соответствующими атрибутами:

- ID_check_error="ID_check_error"

- storage_error="storage_error"

7.4.4 Проверка соответствия структуры класса возможностей

Служба validateCCS обеспечивает испытание CCS и включает нижеследующие шаги:

a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:

<service-type>="requestExistingCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

b) служба returnExistingCCS получает существующую CCS. Тип сервиса:

<service-type>="returnExistingCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- process_status="the_process_status"

c) служба testCCS верифицирует незарегистрированную CCS. Тип сервиса:

<service-type>="testCCS"

d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:

<service-type>="returnTestResult" с соответствующими атрибутами:

- test_result ="the_test_result"

- test_status="the_test_status"

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

Служба deleteCCS стирает существующий шаблон и включает нижеследующие шаги:

a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:

<service-type>="requestExistingCCS" с соответствующими атрибутами:

- CCS_ID="the_CCS_id"

b) служба returnExistingCCS получает существующую CCS. Тип сервиса:

<service-type>="returnExistingCCS" с соответствующими атрибутами:

- CCS_content="the_CCS_content"

- process_status="the_process_status"

c) служба removeCCS удаляет структуру CCS из архива. Тип сервиса:

<service-type>="removeCCS"

d) служба returnRemoveResult получает статус удаления. Тип сервиса:

<service-type>="returnRemoveResult" с соответствующими атрибутами:

- remove_status="the_remove_status"

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

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

a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:

<service-type>="requestExistingProfile" с соответствующими атрибутами:

- profile_ID="the_profile_id"

b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:

<service-type>="returnExistingProfile" с соответствующими атрибутами:

- profile_content="the_profile_content"

- process_status="the_process_status"

c) служба requestMatching сопоставляет два доступных профиля. Тип сервиса:

<service-type>="requestMatching" с соответствующими атрибутами:

- profile_ID_1="the_profile_id_1"

- profile_ID_2="the_profile_id_2"

d) служба returnMatchingResult получает результат сопоставления. Тип сервиса:

<service-type>="returnMatchingResult" с соответствующими атрибутами:

- matching_level="the_matching_level"

- matching_report="the_matching_report"

8 Служба и протокол импорта словаря

8.1 Служба импорта словаря Dictionarylmporting

Служба Dictionarylmporting использует службу requestlmportDictionary, службу returnlmportDictionary, службу requestDictionary и службу returnDictionary. Служба дает возможность пользователю импортировать библиотеку деталей в архив и просмотреть содержание архива (см. рисунок 19).

Служба Dictionarylmporting включает нижеследующие шаги:

а) пользователь словаря инициирует службу requestlmportDictionary объекта ImportServicePoint, в котором параметром сервиса, ассоциированного со службой requestlmportDictionary, является идентификатор словаря;

b) поставщик сервисов инициирует службу returnlmportResult объекта ImportServicePoint, в котором параметрами службы returnlmportResult являются результат импортирования и ошибка обработки;

c) пользователь словаря инициирует службу requestDictionary объекта ImportServicePoint, в котором параметром службы requestDictionary является идентификатор словаря;

d) поставщик сервисов инициирует службу returnDictionary объекта ImportServicePoint, в котором параметрами службы returnDictionary являются существующий словарь и ошибка обработки.

8.2 Протокол импорта словаря Dictionarylmporting

Служба Dictionarylmporting импортирует словарь в архив и включает нижеследующие шаги:

a) служба requestImportDictionary запрашивает импортирование словаря. Тип сервиса:

<service-type>="requestlmportDictionary" с соответствующими атрибутами:

- dictionary_ID="the_dictionary_id"

b) служба returnlmportDictionary получает импортированный словарь. Тип сервиса:

<service-type>="returnlmportingresult" с соответствующими атрибутами:

- importing_result="the_importing_result"

- process_status="the_process_status"

c) служба requestDictionary запрашивает словарь. Тип сервиса:

<service-type>="requestDictionary" с соответствующими атрибутами:

- dictionary_ID="the_dictionary_id"

d) служба returnDictionary получает запрошенный словарь. Тип сервиса:

<service-type>="returnDictionary" с соответствующими атрибутами:

- dictionary_content="the_dictionary_content"

- process_status="the_process_status"

Рисунок 19 - Служба Dictionarylmporting

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

Модель возможностей, содержащая объекты данных MDD

А.1 Диаграмма модели возможностей

Производственная деятельность включает одну и более операций производственного процесса, ассоциированных с набором производственных функций в соответствии с ИСО 16100-1:2009, раздел 5.3. Для каждой операции можно разработать модель, содержащую объекты данных MDD, в соответствии с ИСО 15745-1.

Имеется однозначное соответствие между элементами дерева приложения и элементами дерева класса возможностей. Модель производственной деятельности отображается на модель класса возможностей, как показано на рисунке А.1.

Рисунок А.1 описывает нижеследующие возможности структуры CCS в терминах объекта данных MDD:

a) операции производственной деятельности;

b) обмен ограничениями (информацией) между операциями;

c) ресурсы, использованные при выполнении операции;

d) соотношения между предшествующей и/или последующей операциями.

Рисунок А.1, лист 1 - Отображение модели возможностей на модель производственной деятельности с помощью объектов данных MDD

Рисунок А.1, лист 2

А.2 Синтаксис языка разметки XML для рассматриваемой модели возможностей

Ниже приведен пример синтаксиса языка разметки XML для модели возможностей, представленной в особой части шаблона.

А.3 Соотношения между объектами MDD и соответствующей моделью MDM

На рисунке А.2 сравниваются два дерева производственной деятельности (дерево А и дерево В) с различными структурами CCS. Каждый узел дерева имеет свой собственный класс возможностей и соответствующий шаблон профиля возможностей. Каждый шаблон использует объекты данных MDD для описания своих возможностей. Объекты MDD выбираются из одного множества объектов MDD для рассматриваемой модели MDM, например:

MDDi MDM|i [1..n]

Каждый объект MDD в рассматриваемой модели MDM должен быть определен. Он должен отличаться от других объектов. Уникальный идентификатор объекта MDD - отправная точка его семантического сопоставления.

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

Рисунок А.2 - Соотношение между производственной деятельностью и соответствующими объектами данных MDD

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

Упрощенное сопоставление шаблонов профилей возможностей

В.1 Пример шаблона профиля возможностей

В.1.1 Пример 1

Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа А21 ("getOperationMethod) по ИСО 16100-5, раздел В.2.

В.1.2 Пример 2

Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа В11 ("receiveManufacturinglnstruction") по ИСО 16100-5, раздел В.3.

В.1.3 Пример 3

Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа А33 ("monitorOperationCondition") по ИСО 16100-5, раздел В.2.

В.2 Процедура создания шаблона профиля возможностей

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

Рисунок В.1 - Процедура создания шаблона профиля возможностей

В.3 Процесс выбора надлежащего шаблона профиля возможностей

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

Рисунок В.2, лист 1 - Процедура выбора шаблона профиля возможностей из Архива

Рисунок В.2, лист 2

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

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

С.1 Профиль "getOperationMethod"

Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа А21 ("getOperationMethod") по ИСО 16100-5:2009, раздел В.2.

С.2 Профиль "receiveManufacturinglnstruction"

Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа В11 ("receiveManufacturinglnstruction") по ИСО 16100-5:2009, раздел В.3.

С.3 Профиль "monitorOperationCondition"

Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа А33 ("monitorOperationCondition") в ИСО 16100-5:2009, раздел В.2.

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

Процедура создания структуры класса возможностей

Процедура создания структуры класса CCS показана на рисунке D.1.

Рисунок D.1, лист 1 - Процедура создания структуры класса CCS

Рисунок D.1, лист 2

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

Отображение библиотеки деталей PLIB на объекты данных MDD

Е.1 Преимущества отображения

Словарь деталей PLIB (представляемый в электронной форме) включает определения описаний семейств деталей (классов PLIB) и атрибутов (определенных как "свойства" в ИСО 13584). Настоящая информация представляется кодом, известным как Базовая семантическая единица (BSU).

К записи BSU добавляются метки мульти-языка. Они поддерживают мульти-язычные определения. С помощью указанного механизма, профиль возможностей получает различные названия атрибутов (названия свойств в библиотеке деталей PLIB) и определения. В результате механизм сопоставления просто оказывается электронным кодом, так как элементы BSU также представляются в электронной форме. Преимущество заключается в том, что данное сравнение проще, чем сравнение элементов BSU и объектов языка XML.

На рисунке Е.1 показано соотношение между элементами библиотеки PLIB и объектами данных MDD.

Рисунок Е.1 - Соотношение между элементами библиотеки PLIB и объектами данных MDD через интерфейс услуг

На рисунке Е.2 показаны два объекта MDD из одного словаря PLIB. Указанные объекты MDD имеют одинаковые коды BSU, но их названия различны. Механизм сравнения устанавливает, что указанные объекты MDD одинаковы, так как одинаковы их коды BSU.

Рисунок Е.2 - Сравнение объектов MDD, используя идентификаторы понятий PLIB

Е.2 Пример отображения

Процесс создания заданного шаблона профиля возможностей начинается с рассмотрения формальной структуры MDD шаблона, описанной в ИСО 16100-5:2009, раздел 6.5.2. Рассматриваемый MDD шаблон создается после того, как выполнено отображение подмножества объектов MDD (из библиотеки PLIB) на формальную структуру MDD.

Ниже приведен пример применения схемы языка XML для рассматриваемого шаблона MDD.

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

Отображение открытого словаря OTD на объекты данных MDD

F.1 Преимущества отображения

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

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

Соответствующее ИСО 16100 описание MDD, содержащее информацию о производственной деятельности, ресурсах, возможностях программного обеспечения и соотношениях между объектами MDD, может быть закодировано как описание продукта, соответствующего ИСО 22745, с помощью понятий словаря OTD. Возможности MSU или возможности, определяемые приложением, также могут быть выражены в терминах объектов MDD с помощью словаря OTD. Описание продукта, удовлетворяющее требованиям ИСО 22745, может быть связано с эквивалентными описаниями продукта, данными как в ИСО 22745, так и в других стандартах (например, ИСО 13584).

Для сопоставления двух объектов MDD (с помощью понятий словаря OTD) производится сравнение однозначных идентификаторов понятий. Если два различных идентификатора понятий OTD представляют одно и то же понятие, то настоящий факт следует отразить в словаре OTD как соотношение эквивалентности понятий. Указанные идентификаторы либо указываются явно среди объектов MDD, либо выделяются с помощью накладываемых связей.

Рисунок F.1 дает соотношение между объектами MDD и открытым словарем OTD.

Рисунок F.2 показывает два объекта MDD (обозначение #А1 относится к объекту MDD класса возможностей А1; обозначение #В1 относится к объекту MDD класса возможностей В1), которые ссылаются на один глобальный идентификатор продукта OTD и на одно предпочтительное имя. Два объекта MDD с различными названиями в соответствующих словарях представлены соответствующими терминами OTD в ресурсе OTD с разделенным доступом (например, в сервере). Общий глобальный идентификатор является мостом между индивидуальными словарями для сопоставления объектов MDD.

IG Справочник идентификаторов (см. ИСО 22745-2)

Подмножество объектов MDD, используемое в структуре CCS

Двусторонний обмен информацией

Рисунок F.1 - Соотношение между открытым словарем OTD и объектом данных MDD, устанавливаемое интерфейсом услуг

Рисунок F.2 - Сравнение объектов MDD и идентификаторов понятий с помощью открытого технического словаря OTD

F.2 Пример отображения

Как и в разделе Е.2 (по аналогии с формальным шаблоном структуры MDD, описанной в ИСО 16100-5:2009, раздел 6.5.2) рассматриваемый пример шаблона профиля возможностей начинается с создания шаблона MDD, используя подмножество объектов MDD (на базе понятий OTD), выраженных в терминах элементов, определенных в словаре OTD для рассматриваемой модели MDM.

Ниже на языке XML приведена схема рассматриваемого шаблона MDD.

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

Процедура сопоставления двух профилей

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

"Процедура сопоставления профилей возможностей" определена в ИСО 16100-5:2009, рисунок 12. Ниже приведены 5 шагов данной процедуры:

- шаг 1: сравнение двух словарных идентификаторов двух профилей;

- шаг 2: сравнение названий двух моделей MDM;

- шаг 3: сравнение двух форматов определений;

- шаг 4: преобразование объектов MDD в соответствующие определения;

- шаг 5: последовательное сравнение определений возможностей в требуемом профиле возможностей с соответствующими определениями в профиле возможностей MSU.

На каждом шаге, уникальный идентификатор объекта MDD (уникальный внутри одной модели MDM) является начальной точкой семантического сравнения объектов MDD. Рассматривамая процедура "сравнения определений возможностей" (шаг 5) фокусируется на сравнении описаний "MDD_Description". Процедура сравнения (например, списка объектов "List_of_MDD_Objects") показана на рисунке G.1.

На рисунке G.1 имеются контуры двух видов: наружный контур и внутренний контур. В наружном контуре, контур В используется для сравнения операций в соответствии с установленным порядком требуемого профиля. Порядок установлен для объектов, упорядоченных по времени "Time_Order_Of_MDD_object", и объектов, расположенных в порядке поступления "Event_Order_Of_MDD_object". Элементы "производственной деятельности" упорядочены по времени для объектов "Time_Order_Of_MDD_objects" описания "MDD_Description". Аналогично, элементы "производственной деятельности" упорядочены в порядке поступления для объектов "Event_Order_Of_MDD_object" описания "MDD_Description". Сравнение элементов "производственной деятельности" выполяется строго в установленном порядке. Исключением являются объекты "Set_Of_MDD_objects", где каждый элемент производственной деятельности в требуемом профиле последовательно сравнивается со всеми элементами производственной деятельности в профиле MSU до достижения желаемого результата.

Внутренний контур фактически состоит из 4-х контуров типа В. Первый внутренний контур используется для сравнения с двумя элементами MDD_name_action из двух индивидуальных профилей. В соответствии с формальной структурой, показанной на рисунке 2, после сравнений двух элементов производственной деятельности рассматриваются соответствующие названия, методы и статусы.

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

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

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

Рисунок G.1, лист 1 - Процедура сравнения описаний "comparison MDD_Description" для обнаружителей совпадений типа 2

Примечание - А, В, С и F - точки соединения процедуры. Точка F указывает неудачное сопоставление.

Рисунок G.1, лист 2

Рисунок G.1, лист 3

Рисунок G.1, лист 4

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

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

Таблица ДА.1

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

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

и сверен по:

, 2020