ГОСТ Р ИСО 16100-6-2014. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 6. Службы и протоколы интерфейса для сопоставления профилей, основанных на многоцелевых структурах классов возможностей
Актуально на 01.11.2026.
Как цитировать: "ГОСТ Р ИСО 16100-6-2014. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 6. Службы и протоколы интерфейса для сопоставления профилей, основанных на многоцелевых структурах классов возможностей". ГОСТ Р ИСО 16100-6-2014. https://bukva.ai/docs/protokol-gost-r-iso-16100-6-2014
(утв. и введен в действие Приказом Росстандарта от 26.11.2014 № 1871-ст)
Примечание
Документ введен в действие с 1 января 2016 года.
и метрологии от 26 ноября 2014 г. № 1871-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ
ПРОФИЛИРОВАНИЕ ВОЗМОЖНОСТИ ИНТЕРОПЕРАБЕЛЬНОСТИ ПРОМЫШЛЕННЫХ ПРОГРАММНЫХ СРЕДСТВ
СЛУЖБЫ И ПРОТОКОЛЫ ИНТЕРФЕЙСА ДЛЯ СОПОСТАВЛЕНИЯ ПРОФИЛЕЙ, ОСНОВАННЫХ НА МНОГОЦЕЛЕВЫХ СТРУКТУРАХ КЛАССОВ ВОЗМОЖНОСТЕЙ
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
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
Дата введения 1 января 2016 года
Предисловие
1 ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики „Интерэкомс“ (ООО „НИИ „Интерэкомс“) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4»
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 ноября 2014 г. № 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»).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 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. Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие документы, которые необходимо учитывать при использовании настоящего стандарта. В случае ссылок на документы, у которых указана дата утверждения, необходимо пользоваться только указанной редакцией. В случае, когда дата утверждения не приведена, следует пользоваться последней редакцией ссылочных документов, включая любые поправки и изменения к ним.
ИСО 10303-11 Промышленные системы автоматизации и интеграция. Представление данных продукта и обмен данных. Часть 11. Метод описания: Справочное руководство по языку EXPRESS (ISO 10303-11, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual)
ИСО 16100-1 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 1. Структура (ISO 16100-1, Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 1: Framework)
ИСО 16100-2 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования (ISO 16100-2, Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 2: Profiling methodology)
ИСО 16100-3 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 3. Службы интерфейса, протоколы и шаблоны возможностей (ISO 16100-3, Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 3: Interface services, protocols and capability templates)
ИСО 16100-4 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 4. Методы аттестационных испытаний, критерии и отчеты (ISO 16100-4, Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 4: Conformance test methods, criteria and reports)
ИСО 16100-5 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 5. Методология профилирования сопоставления с помощью множественных структур класса возможностей (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)
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) в архиве объект имеет одно из нижеследующих состояний:
-
состояние хранения: объект сохранен в Архиве после формирования запроса;
-
состояние регистрации: объект зарегистрирован в Архиве после проверки его соответствия установленным требованиям;
-
состояние стирания: объект стерт из Архива после формирования запроса на стирание.
5.2. Набор служб ESI
Основные службы ESI, обеспечиваемые ESP, могут быть взяты из группы CPI Типа 1 (см. ИСО 16100-3) и из четырех сервисных групп, перечисленных ниже и детально описанных в разделе 6. Другие сервисные группы также могут существовать (например, модели MDM, объекты MDD и объекты данных MDD), но они не рассматриваются в настоящем стандарте.
a) Сервисная группа CPTI, включающая группу CPI Типа 3, допускает:
b) Сервисная группа CPI Типа 2 (см. ИСО 16100-3) допускает:
-
создание нового профиля возможностей MSU или профиля возможностей, удовлетворяющего новым требованиям;
-
обеспечение доступа к профилю возможностей MSU или к профилю возможностей, удовлетворяющему заданным требованиям;
-
модификация профиля возможностей MSU или профиля возможностей, удовлетворяющего заданным требованиям;
-
регистрация профиля возможностей, удовлетворяющего заданным требованиям;
-
стирание профиля возможностей, удовлетворяющего заданным требованиям.
c) Сервисная группа CCSI допускает нижеследующие услуги:
d) Расширенная группа обнаружения совпадений допускает:
-
обеспечение доступа к профилю возможностей MSU или профилю возможностей, удовлетворяющему заданным требованиям;
-
сопоставление двух профилей возможностей, при этом каждый ссылается на другую структуру класса возможностей.
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. См. приложение E.
6. Расширенный служебный интерфейс
6.1. Службы CPTI группы
6.1.1 Сценарии, используемые группой услуг CPTI
Группа CPTI использует нижеследующие сценарии шаблона профиля возможностей:
a) создать шаблон профиля возможностей для особой структуры класса либо путем частичного заполнения характеристической формальной структуры шаблона профиля возможностей, либо путем модификации существующего шаблона профиля возможностей с новым идентификатором ID шаблона профиля возможностей, используя объекты MDD в модели MDM, а затем получить шаблон профиля возможностей от поставщика сервисов;
b) запросить шаблон профиля возможностей из архива с помощью идентификатора ID шаблона профиля возможностей, а затем получить шаблон профиля возможностей от поставщика сервисов;
c) модифицировать шаблон профиля возможностей в соответствии либо с требованиями пользователя, либо с результатами проверки соответствия, а затем получить модифицированный шаблон профиля возможностей от поставщика сервисов;
d) испытать шаблон профиля возможностей в сравнении с критериями соответствия шаблона профиля возможностей, данными в ИСО 16100-5:2009, раздел 8, а затем получить положительный отклик, отрицательный отклик или отклик уровня сопоставления от поставщика сервисов;
e) зарегистрировать испытанный шаблон профиля возможностей в архиве и получить статус «зарегистрирован» от поставщика сервисов;
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» с одним из четырех нижеследующих значений:
-
«Time_Ordered_MDD_objects» (объекты MDD, упорядоченные по времени);
-
«Event_Ordered_MDD_objects» (объекты MDD в порядке поступления);
d) атрибуты «название» и «производственная деятельность» в элементе названия объекта «MDD_name».
Каждое значение, внесенное или модифицированное для атрибутов «идентификатор» (в разделе 6.1.2.2 a), имени области «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 включает нижеследующие шаги:
a) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службы requestExistingTemplate является идентификатор шаблона;
b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;
c) пользователь шаблона модифицирует существующий шаблон, а затем инициирует службу processModifiedTemplate объекта ServiceAccessPoint, в котором параметром службы processModifiedTemplate является идентификатор шаблона;
d) поставщик сервисов проверяет уникальность идентификатора шаблона, а затем инициирует службу returnProcessingResult объекта ServiceAccessPoint, в котором параметрами услуги returnProcessingResult являются ошибка проверки идентификатора и ошибка хранения.
На рисунке 3 (ниже пунктирной линии) на языке UML показана диаграмма последовательности, являющаяся обязательным шагом создания шаблона путем модификации существующего шаблона.
<pre class="legal-pre"> ┌────────────────┐ ┌────────────────┐
│ Template User │ │Extended Service│
│ │ │ Provider │
└───────┬────────┘ └────────┬───────┘
Create a new│ │
capability │ │
profile │ │
template ┌┴┐requestBlankTemplate() ┌┴┐
based on │ │──────────────────────────────────────────────────────────>│ │
the formal │ │ returnBlankTemplate(blank template, creation error)│ │
structure │ │<──────────────────────────────────────────────────────────│ │
└┬┘ └┬┘
│ │
┌┴┐process FilledTemplate(template ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─
<pre class="legal-pre">Create a new│ │
capability │ │
profile │ │
template │ │
based on │ │
an existing┌┴┐requestExistingTemplate(template ID) ┌┴┐</pre>
capability │ │──────────────────────────────────────────────────────────>│ │
template │ │returnExistingTemplate(existing template, processing error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedTemplate(template ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Примечание 1 — Пунктирная линия разделяет два рассмотренных варианта.
Примечание 2 — Созданию шаблона всегда предшествуют предварительные шаги регистрации и верификации уникального идентификатора шаблона, лежащие вне области применения ИСО 16100.
Рисунок 3 — Служба createTemplate
6.1.3 Служба accessTemplate
Служба accessTemplate, использующая службу requestExistingTemplate и службу returnExistingTemplate, дает возможность пользователю шаблона получить доступ к какому-либо другому существующему шаблону.
Служба accessTemplate включает нижеследующие шаги:
a) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службу requestExistingTemplate является идентификатор шаблона;
b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки.
На рисунке 4 на языке UML показана диаграмма последовательности обязательных шагов процедуры получения доступа к шаблону, основанной на использовании идентификатора шаблона.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Template User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
│ │
Access a ┌┴┐requestExistingTemplate(template ID) ┌┴┐</pre>
capability│ │───────────────────────────────────────────────────────────>│ │
template │ │ returnExistingTemplate(existing template, processing error)│ │
│ │<───────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 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 приведена диаграмма обязательных шагов последовательности процедуры модификации существующего шаблона с помощью идентификатора шаблона.
<pre class="legal-pre"> ┌────────────────┐ ┌────────────────┐
│ Template User │ │Extended Service│
│ │ │ Provider │
└───────┬────────┘ └────────┬───────┘
Modify an │ │
existing │ │
template ┌┴┐requestExistingTemplate(template ID) ┌┴┐</pre>
│ │────────────────────────────────────────────────────────────>│ │
│ │ returnExistingTemplate(existing template, processing error)│ │
│ │<────────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedTemplate(template ID) ┌┴┐</pre>
│ │────────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<────────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 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, раздел B.1.
Испытанный шаблон должен быть зарегистрирован в архиве, если значение параметра результата испытаний службы returnTestResult «положительно» или «полное совпадение» (см. ИСО 16100-5:2009, раздел 7.2). В зависимости от требований пользователя, испытанный шаблон может быть зарегистрирован в архиве, если значение параметра результата испытаний либо «полное обязательное совпадение», либо «некоторое обязательное совпадение» (см. ИСО 16100-5:2009, раздел 7.2). Испытанный шаблон может быть модифицирован снова, чтобы удовлетворять критериям соответствия, если значение параметра результата испытаний отрицательно или «обязательное совпадение отсутствует» (см. ИСО 16100-5:2009, раздел 7.2).
На рисунке 6 на языке UML приведена диаграмма обязательных шагов последовательности проверки соответствия незарегистрированного шаблона, основанной на использовании идентификатора шаблона.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Template User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Validate an │ │
unregistered│ │
template ┌┴┐requestUnregisteredTemplate(template ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────────────>│ │
│ │returnUnregisteredTemplate(unregistered template, processing error)│ │
│ │<──────────────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐testTemplate() ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────────────>│ │
│ │ returnTestResult(test result, match status)│ │
│ │<──────────────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 6 — Служба validateTemplate
6.1.6 Служба deleteTemplate
Служба deleteTemplate, использующая службу requestExistingTemplate, службу returnExistingTemplate, службу removeTemplate и службу returnRemoveResult, дает возможность пользователю шаблона стереть существующий шаблон.
Служба deleteTemplate включает нижеследующие шаги:
a) пользователь шаблона инициирует службу requestExistingTemplate объекта ServiceAccessPoint, в котором параметром службу requestExistingTemplate является идентификатор шаблона;
b) поставщик сервисов инициирует службу returnExistingTemplate объекта ServiceAccessPoint, в котором параметрами службы requestExistingTemplate являются существующий шаблон и ошибка обработки;
c) пользователь шаблона инициирует службу removeTemplate объекта ServiceAccessPoint, в котором отсутствуют параметры, ассоциированные со службой removeTemplate;
d) поставщик сервисов инициирует службу returnRemoveResult объекта ServiceAccessPoint, в котором параметром службы returnRemoveResult является ошибка удаления.
На рисунке 7 на языке UML приведена диаграмма обязательных шагов последовательности стирания шаблона, основанная на использовании идентификатор шаблона.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Template User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Delete an │ │
existing │ │
capability┌┴┐requestExistingTemplate(template ID) ┌┴┐
template │ │───────────────────────────────────────────────────────────>│ │</pre>
│ │ returnExistingTemplate(existing template, processing error)│ │
│ │<───────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐removeTemplate() ┌┴┐</pre>
│ │───────────────────────────────────────────────────────────>│ │
│ │ returnRemoveResult(removal error)│ │
│ │<───────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 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 включает нижеследующие шаги:
a) пользователь профиля инициирует службу 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 приведена диаграмма последовательности создания нового профиля из существующего профиля.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Profile User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Create a new│ │
capability │ │
profile │ │
based on │ │
an existing┌┴┐requestExistingTemplate(template ID) ┌┴┐</pre>
capability │ │──────────────────────────────────────────────────────────>│ │
<pre class="legal-pre">profile │ │returnExistingTemplate(existing template, processing error)│ │
template │ │<──────────────────────────────────────────────────────────│ │
└┬┘ └┬┘
│ │
┌┴┐processFilledProfile(profile ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<──────────────────────────────────────────────────────────│ │
└┬┘ └┬┘
─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─
<pre class="legal-pre">Create a new│ │
capability │ │
profile │ │
based on │ │
an existing┌┴┐requestExistingProfile(profile ID) ┌┴┐</pre>
capability │ │──────────────────────────────────────────────────────────>│ │
profile │ │ returnExistingProfile(existing profile, processing error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedProfile(profile ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Примечание 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.
<pre class="legal-pre"> ┌────────────────┐ ┌────────────────┐
│ Profile User │ │Extended Service│
│ │ │ Provider │
└───────┬────────┘ └────────┬───────┘
Access │ │
a profile│ │
via ESI ┌┴┐requestExistingProfile(profile ID) ┌┴┐</pre>
│ │─────────────────────────────────────────────────────────────────>│ │
│ │ returnExistingProfile(existing profile, processing error)│ │
│ │<─────────────────────────────────────────────────────────────────│ │
└┬┘ └┬┘
─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │─ ─ ─ ─
<pre class="legal-pre">Access │ ┌──────────────┐ │
a profile│ │ MSU │ │
via MSU │ └───────┬──────┘ │
┌┴┐requestExistingProfile() ┌┴┐ │</pre>
│ │────────────────────────────────────────────────────────>│ │
│ │returnExistingProfile(existing profile, processing error)│ │
│ │<────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 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.
<pre class="legal-pre"> ┌────────────────┐ ┌────────────────┐
│ Profile User │ │Extended Service│
│ │ │ Provider │
└───────┬────────┘ └────────┬───────┘
Modify │ │
an existing│ │
profile ┌┴┐requestExistingProfile(profile ID) ┌┴┐
via ESI │ │────────────────────────────────────────────────────────────────>│ │
│ │ returnExistingProfile(existing profile, processing error)│ │</pre>
│ │<────────────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedProfile(profile ID) ┌┴┐</pre>
│ │────────────────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<────────────────────────────────────────────────────────────────│ │
└┬┘ └┬┘
─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─
<pre class="legal-pre">Modify │ ┌────────────┐ │
an existing│ │ MSU │ │
profile │ └──────┬─────┘ │
via MSU ┌┴┐requestExistingProfile(profile ID) ┌┴┐ │
│ │────────────────────────────────────────────────────────>│ │ │
│ │returnExistingProfile(existing profile, processing error)│ │ │
│ │<────────────────────────────────────────────────────────│ │ │
└┬┘ └┬┘ │
│ │ │
┌┴┐processModifiedProfile(profile ID) ┌┴┐ │
│ │────────────────────────────────────────────────────────>│ │ │
│ │ returnProcessingResult(ID check error, storage error)│ │ │
│ │<────────────────────────────────────────────────────────│ │ │
└┬┘ └┬┘ │
│ │ │</pre>
Рисунок 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 приведена диаграмма обязательных шагов последовательности процедуры выполнения проверки соответствия существующего профиля, основанной на использовании идентификатора профиля.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Profile User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Validate │ │
an existing│ │
profile ┌┴┐requestExistingProfile(profile ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnExistingProfile(existing profile, processing error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
│ │
┌┴┐testProfile() ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnTestResult(test result, match status)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 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 приведена диаграмма последовательности обязательных шагов процедуры стирания профиля, основанной на использовании идентификатора профиля.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Profile User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Delete │ │
an existing│ │
capability │ │
profile ┌┴┐requestExistingProfile(profile ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnExistingProfile(existing profile, processing error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
│ │
┌┴┐removeProfile() ┌┴┐</pre>
│ │──────────────────────────────────────────────────────────>│ │
│ │ returnRemoveResult(removal error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 12 — Служба deleteProfile
6.3. Группа CCSI
6.3.1 Сценарии, используемые группой CCSI
Группа CCSI использует нижеследующие сценарии шаблона профиля возможностей:
a) создание CCS (структуры класса возможностей) либо путем заполнения заготовки шаблона CCS, либо путем модификации существующего CCS, а затем получение созданного CCS от поставщика сервисов;
a) получение доступа к CCS в Архиве с помощью идентификатора CCS, а затем получение CCS от поставщика сервисов;
b) модификация CCS в соответствии либо с требованиями пользователя, либо с результатами проверки соответствия, а затем получение модифицированного CCS от поставщика сервисов;
c) испытание CCS на соответствие установленным критериям соответствия CCS и получение либо положительного отклика, либо отрицательного отклика, либо отклика уровня сопоставления от поставщика сервисов;
d) регистрация CCS в Архиве и получение статуса «зарегистрирован» от поставщика сервисов;
e) удаление 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.
<pre class="legal-pre"> ┌───────────────┐ ┌────────────────┐
│ CCS User │ │Extended Service│
│ │ │ Provider │
└───────┬───────┘ └────────┬───────┘
Create a new │ │
CCS based │ │
on the │ │
formal CCS ┌┴┐requestBlankCCS() ┌┴┐
structure │ │─────────────────────────────────────────────────────>│ │
│ │ returnBlankCCS(blank CCS, creation error)│ │</pre>
│ │<─────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processFilledCCS(CCS ID) ┌┴┐</pre>
│ │─────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<─────────────────────────────────────────────────────│ │
└┬┘ └┬┘
─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │─ ─ ─ ─
<pre class="legal-pre">Create a new │ │
CCS based on │ │
an existing ┌┴┐requestExistingCCS(CCS ID) ┌┴┐
CCS │ │─────────────────────────────────────────────────────>│ │
│ │ returnExistingCCS(existing CCS, processing error)│ │</pre>
│ │<─────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedCCS(CCS ID) ┌┴┐</pre>
│ │─────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<─────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Примечание 1 — Пунктирная линия разделяет два варианта создания сущности.
Примечание 2 — Созданию CCS всегда предшествует предварительный шаг регистрации и верификации уникального идентификатора CCS, находящийся вне области применения ИСО 16100.
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.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ CCS User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Access a CCS│ │
│ │
┌┴┐requestExistingCCS(CCS ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnExistingCCS(existing CCS, processing error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
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.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ CCS User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Modify an │ │
existing CCS│ │
┌┴┐requestExistingCCS(CCS ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnExistingCCS(existing CCS, processing error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐processModifiedCCS(CCS ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnProcessingResult(ID check error, storage error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
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.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ CCS User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Validate an │ │
existing CCS│ │
┌┴┐requestExistingCCS(CCS ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnExistingCCS(existing CCS, processing error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐testCCS() ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnTestResult(test result, match status)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 16 — Служба validateCCS
6.6.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.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ CCS User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Delete an │ │
existing CCS│ │
┌┴┐requestExistingCCS(CCS ID) ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnExistingCCS(existing CCS, processing error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │
┌┴┐removeCCS() ┌┴┐</pre>
│ │──────────────────────────────────────────────────────>│ │
│ │ returnRemoveResult(removal error)│ │
│ │<──────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
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 приведена диаграмма последовательности обязательных шагов процедуры запрашивания профиля и сопоставления двух профилей.
<pre class="legal-pre"> ┌─────────────────┐ ┌────────────────┐
│ Matcher User │ │Extended Service│
│ │ │ Provider │
└────────┬────────┘ └────────┬───────┘
Request │ │
a profile │ │
either from │ │
the Data ┌┴┐requestProfile(profile ID) ┌┴┐</pre>
Container or│ │──────────────────────────────────────────────────────────>│ │
from the MSU│ │ returnProfile(existing profile, processing error)│ │
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ ┌────────────┐ └┬┘
│ │ MSU │ │
│ └──────┬─────┘ │
┌┴┐requestProfile(profile ID) ┌┴┐ │
│ │────────────────────────────────────────────────>│ │ │
│ │returnProfile(existing profile, processing error)│ │ │
│ │<────────────────────────────────────────────────│ │ │
└┬┘ └┬┘ │</pre>
─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─│─ ─ ─ ─
<pre class="legal-pre">Match │ │ │
the profiles │ │ │
with the ┌┴┐requestMatching(profile ID, profile ID) ┌┴┐
matcher │ │──────────────────────────────────────────────────────────>│ │
│ │ returnMatchingResult(matching level, matching report)│ │</pre>
│ │<──────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Примечание — Пунктирная линия отделяет запрос профиля от запроса сопоставления.
Рисунок 18 — Служба ExtendedMatcher
6.4.3 Проверка соответствия обнаружителя совпадений
Методология установления соответствия, описанная в ИСО 16100-4, используется в настоящем стандарте. Здесь утверждения соответствия для практической реализации CSI расширяются и используются обнаружителями совпадений профилей возможностей в соответствии со ИСО 16100-4:2006, таблица 9. Таблицы 1 и 2 в настоящем стандарте используются процедурой проверки соответствия. Типы точек соответствия, указанные в таблицах 1 и 2, определены в ИСО 16100-4:2006, таблица 5.
Утверждения соответствия CSI, необходимые для функционирования обнаружителей совпадений
| Точка соответствия и № набора | Описание точки соответствия | Ссылка на спецификацию | Тип точки соответствия a | Абстрактный критерий испытания |
| Index_1 | Получение требуемого профиля возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация требуемого профиля возможностей на соответствие с ИСО 16100-5:2009, таблица 2 |
| Index_2 | Получение профиля возможностей MSU | ИСО 16100-5:2009, раздел 7 | A | Верификация профиля возможностей MSU на соответствие с ИСО 16100-5:2009, таблица 2 |
| Index_3 | Сравнение идентификаторов двух профилей модели MDM | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_3.1 | Извлечение идентификаторов из двух профилей модели MDM | ИСО 16100-5:2009, раздел 7 | A | Верификация идентификаторов словарей |
| Index_3.2 | Сравнение двух идентификаторов модели MDM | ИСО 16100-5:2009, раздел 7 | A | Верификация и показ результатов сравнения |
| Index_3.2.1 | Отчет о результате № 1 и переход к обнаружителю совпадений типа 1 | ИСО 16100-5:2009, раздел 7 | A | Верификация: 1) «Идентификаторы совпадают» 2) «Переход к обнаружителю совпадений типа 1» |
| Index_3.2.2 | Отчет о результате № 2 | ИСО 16100-5:2009, раздел 7 | A | Верификация: «Идентификаторы не совпадают» |
| Index_4 | Сравнение названий двух профилей модели MDM | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_4.1 | Извлечение названий двух профилей модели MDM | ИСО 16100-5:2009, раздел 7 | A | Верификация названий модели MDM |
| Index_4.2 | Сравнение двух названий модели MDM | ИСО 16100-5:2009, раздел 7 | A | Верификация результатов на основе сравнения |
| Index_4.2.1 | Отчет о результате № 1 и завершение сопоставления | ИСО 16100-5:2009, раздел 7 | A | Верификация: 1) «Названия модели MDM не совпадают» 2) «Два профиля относятся к различным моделям MDM» 3) «Нет сопоставления» |
| Index_4.2.2 | Отчет о результате № 2 | ИСО 16100-5:2009, раздел 7 | A | Верификация: «Названия модели MDM совпадают» |
| Index_5 | Сравнение форматов определения возможностей двух профилей | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_5.1 | Извлечение форматов определения возможностей из двух профилей | ИСО 16100-5:2009, раздел 7 | A | Верификация форматов определения возможностей |
| Index_5.2 | Сравнение форматов определения возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результатов на основе сравнения |
| Index_5.2.1 | Отчет о результате № 1 | ИСО 16100-5:2009, раздел 7 | A | Показать отчет № 1: 1) «Форматы определения возможностей не совпадают» 2) «Преобразовать объекты MDD и MDD (определения возможностей) к единому формату определения возможностей» |
| Index_5.2.2 | Отчет о результате № 2 | ИСО 16100-5:2009, раздел 7 | A | Верификация: «Форматы определения возможностей совпадают» |
| Index_6 | Сравнение двух определений возможностей | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_6.1 | Сравнение содержания элемента набора MDD элементов «Set_of_MDD_object» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_6.1.1 | Сравнение атрибутов «название» и «операция» элемента имени MDD «MDD_name» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.2 | Сравнение содержания двух списков объектов «List_of_MDD_object» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_6.2.1 | Сравнение последовательностей элементов «MDD_name» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.2.2 | Сравнение атрибутов «название» и «операция» элемента «MDD_name», находящихся в одинаковых позициях в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.3 | Сравнение содержания двух упорядоченных во времени объектов «Time_Ordered_MDD_objects» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_6.3.1 | Сравнение временной упорядоченности элементов «MDD_name» в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.3.2 | Сравнение атрибутов «название» и «операция» в двух элементах «MDD_name», находящихся в одинаковых позициях в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.4 | Сравнение объектов «Event_Ordered_MDD_object», расположенных в порядке поступления | ИСО 16100-5:2009, раздел 7 | A | - |
| Index_6.4.1 | Сравнение элементов «MDD_name», расположенных в порядке поступления в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| Index_6.4.2 | Сравнение атрибутов «название» и «операция» в двух элементах «MDD_name», находящихся в одинаковых позициях в двух определениях возможностей | ИСО 16100-5:2009, раздел 7 | A | Верификация результата |
| a См. ИСО 16100-4:2006, таблица 5. | ||||
Использование утверждений соответствия CSI в отчетах обнаружителей совпадений
| Точка соответствия и № набора | Описание точки соответствия | Ссылка на спецификацию | Тип точки соответствия a | Абстрактный критерий испытания |
| Index_1 | MatchingLevelReport | ИСО 16100-5:2009, раздел 7.2 | A | Допустимый уровень сопоставления: Полное совпадение Совпадают все обязательные элементы Совпадают некоторые обязательные элементы Обязательные элементы не совпадают |
| Index_2 | DetaitedListReport | ИСО 16100-5:2009, раздел 7.2 | A | Верификация согласованных функций и несогласованных функций |
| Index_3 | CompareMatchingLevel & Detailed Report MatchingLevel | - | - | - |
| Index_3.1 | ForCompleteMatch | - | - | Верификация того, что оба набора функций в двух профилях полностью эквивалентны |
| Index_3.2 | ForAllMandatoryMatch | - | - | Верификация того, что оба набора обязательных функций в двух профилях полностью эквивалентны |
| Index_3.3 | ForSomeMandatoryMatch | - | - | Верификация списка эквивалентных обязательных функций в двух профилях и списка неэквивалентных обязательных функций |
| Index_3.4 | ForNoMandatoryMatch | - | - | Настоящие оба набора функций в двух профилях рассматриваются как полностью неэквивалентные |
| a См. ИСО 16100-4:2006, таблица 5. | ||||
7. Формальное описание протокола расширенных сервисов ESI
7.1. Синтаксис основных сервисов
Синтаксис услуги унифицированного названия ресурса URN, описанный в ИСО 16100-3, используется в настоящем стандарте.
Характеристическое название услуги типа URN начинается с строки «услуга:». Настоящее название услуги типа URN включает тип сервиса и соответствующую точку доступа услуги, в которую не включается разделитель «:», с которого начинается адрес спецификации. Информация об атрибуте рассматриваемой услуги следует за адресом спецификации, закодированным в соответствии с грамматикой универсального имени ресурса URN.
Полное имя URN услуги имеет нижеследующий синтаксис:
Элемент
Элемент
Элемент в строке URN задает путь к поставщику услуг ESI.
Список атрибутов включает знаки «;», разделяющие назначения атрибутов. Назначения атрибутов имеют форму:
В дополнение, для ключевых атрибутов используется форма .
Подробное описание услуг на языке UML во всех диаграммах в Разделе 6 использует формальный синтаксис в соответствии с оставшимися подразделами раздела 7.
7.2. Служебный протокол CPTI группы
7.2.1 Создание шаблона профиля возможностей
7.2.1.1 Создание с помощью формальной структуры
Служба createTemplate генерирует шаблон с помощью формальной структуры. Она включает нижеследующие шаги:
a) служба requestBlankTemplate запрашивает заготовку шаблона и задает тип сервиса:
b) служба returnBlankTemplate получает заготовку шаблона и задает тип сервиса:
- template_content=«the_template_content»
- access_status=«the_access_status»
c) служба processFilledTemplate запрашивает приемлемость заполненного шаблона и задает тип сервиса:
- template_ID=«the_template_id»
d) служба returnProcessingResult получает результат обработки и задает тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.2.1.2 Создание с помощью существующего шаблона
Служба createTemplate также генерирует шаблон с помощью существующего шаблона. Она включает нижеследующие шаги:
a) Служба requestExistingTemplate запрашивает существующий шаблон и задает тип сервиса:
- template_ID=«the_template_id»;
b) Служба returnExistingTemplate получает существующий шаблон и задает тип сервиса:
- template_content=«the_template_content»
- process_status=«the_process_status»
c) Служба processModifiedTemplate запрашивает приемлемость модифицированного шаблона и задает тип сервиса:
- template_ID=«the_template_id»
d) Служба returnProcessingResult получает результат обработки и задает тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.2.2 Доступ к шаблону профиля возможностей
Служба accessTemplate получает доступ к шаблону и включает нижеследующие шаги:
a) служба requestExistingTemplate получает доступ к существующему шаблону и задает тип сервиса:
- template_ID=«the_template_id»;
b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:
- template_content=«the_template_content»
- process_status=«the_process_status»
7.2.3 Модификация шаблона профиля возможностей
Служба modifyTemplate модифицирует шаблон и включает нижеследующие шаги:
a) служба requestExistingTemplate получает доступ к существующему шаблону и задает тип сервиса:
- template_ID=«the_template_id»
b) служба returnExistingTemplate получает запрошенный шаблон и задает тип сервиса:
- template_content=«the_template_content»
- process_status=«the_process_status»
c) служба processModifiedTemplate запрашивает приемлемость модифицированного шаблона и задает тип сервиса:
- template_ID=«the_template_id»
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.2.4 Проверка соответствия шаблона профиля возможностей
Служба validateTemplate обеспечивает испытание шаблона и включает нижеследующие шаги:
a) служба requestUnregisteredTemplate получает доступ к незарегистрированному шаблону и задает тип сервиса:
- template_ID=«the_template_id»
b) служба returnUnregisteredTemplate получает запрошенный шаблон. Тип сервиса:
- template_content=«the_template_content»
- process_status=«the_process_status»
c) служба testTemplate верифицирует незарегистрированный шаблон. Тип сервиса:
d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:
- test_result=«the_test_result»
- test_status=«the_test_status»
7.2.5 Стирание шаблона профиля возможностей
Служба deleteTemplate стирает существующий шаблон и включает нижеследующие шаги:
a) служба requestExistingTemplate получает доступ к существующему шаблону. Тип сервиса:
- template_ID=«the_template_id»
b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:
- template_content=«the_template_content»
- process_status=«the_process_status»
c) служба removeTemplate стирает шаблон профиля возможностей из архива. Тип сервиса:
d) служба returnRemoveResult получает статус удаления. Тип сервиса:
- remove_status=«the_remove_status»
7.3. Служебные протоколы расширенной CPI группы
7.3.1 Создание профиля возможностей
7.3.1.1 Создание с помощью шаблона профиля возможностей
Служба createProfile генерирует новый профиль с помощью шаблона профиля возможностей и включает нижеследующие шаги:
a) служба requestExistingTemplate запрашивает существующий шаблон. Тип сервиса:
- template_ID=«the_template_id»
b) служба returnExistingTemplate получает запрошенный шаблон. Тип сервиса:
- template_content=«the_template_content»
- access_status=«the_access_status»
c) служба processFilledProfile запрашивает приемлемость заполненного профиля. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.3.1.2 Создание с помощью существующего профиля
Служба createProfile также генерирует профиль с помощью существующего профиля и включает нижеследующие шаги:
a) служба requestExistingProfile запрашивает существующий профиль. Тип сервиса:
b) служба returnExistingProfile получает существующий профиль. Тип сервиса:
- profile_content=«the_profile_content»
- process_status=«the_process_status»
c) служба processModifiedProfile запрашивает приемлемость модифицированного профиля. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.3.2 Доступ к профилю возможностей
7.3.2.1 Доступ через расширенный служебный интерфейс ESI
Служба accessProfile получает доступ к профилю через интерфейс ESI и включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content=«the_profile_content»
- process_status=«the_process_status»
7.3.2.2 Доступ через блок программных средств организации производства MSU
Служба accessProfile также получает доступ к профилю через MSU и включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content= «the_profile_content»
- process_status=«the_process_status»
7.3.3 Модификация профиля возможностей
Служба modifyProfile модифицирует профиль и включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content= «the_profile_content»
- process_status=«the_process_status»
c) служба processModifiedProfile запрашивает приемлемость модифицированного профиля. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.3.4 Проверка соответствия профиля возможностей
Служба validateProfile обеспечивает испытание существующего профиля и включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content=«the_profile_content»
- process_status=«the_process_status»
c) служба testProfile верифицирует незарегистрированный профиль. Тип сервиса:
d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:
- test_result=«the_test_result»
- test_status=«the_test_status»
7.3.5 Стирание профиля возможностей
Служба deleteTemplate стирает существующий шаблон и включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content=«the_profile_content»
- process_status=«the_process_status»
c) служба removeProfile удаляет профиль возможностей из архива. Тип сервиса:
d) служба returnRemoveResult получает статус удаления. Тип сервиса:
- remove_status=«the_remove_status»
7.4. Служебные протоколы CCSI группы
7.4.1 Создание структуры класса возможностей
7.4.1.1 Создание с помощью формальной структуры
Служба createCCS генерирует новую структуру CCS с помощью формальной структуры и включает нижеследующие шаги:
a) служба requestBlankCCS запрашивает заготовку CCS. Тип сервиса:
b) служба returnBlankCCS получает заготовку CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- access_status=«the_access_status»
c) служба processFilliedCCS запрашивает приемлемость заполненной структуры CCS. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.4.1.2 Создание с помощью существующей структуры CCS
Служба createCCS также генерирует шаблон с помощью существующей структуры CCS и включает нижеследующие шаги:
a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:
b) служба returnExistingCCS получает существующую CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- process_status=«the_process_status»
c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.4.2 Доступ к структуре класса возможностей
Служба accessCCS получает доступ к структуре CCS и включает нижеследующие шаги:
a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:
b) служба returnExistingCCS получает существующую CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- process_status=«the_process_status»
7.4.3 Модификация структуры класса возможностей
Служба modifyCCS модифицирует структуру CCS и включает нижеследующие шаги:
a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:
b) служба returnExistingCCS получает существующую CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- process_status=«the_process_status»
c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса:
d) служба returnProcessingResult получает результат обработки. Тип сервиса:
- ID_check_error=«ID_check_error»
- storage_error=«storage_error»
7.4.4 Проверка соответствия структуры класса возможностей
Служба validateCCS обеспечивает испытание CCS и включает нижеследующие шаги:
a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:
b) служба returnExistingCCS получает существующую CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- process_status=«the_process_status»
c) служба testCCS верифицирует незарегистрированную CCS. Тип сервиса:
d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса:
- test_result =«the_test_result»
- test_status=«the_test_status»
7.4.5 Стирание структуры класса возможностей
Служба deleteCCS стирает существующий шаблон и включает нижеследующие шаги:
a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса:
b) служба returnExistingCCS получает существующую CCS. Тип сервиса:
- CCS_content=«the_CCS_content»
- process_status=«the_process_status»
c) служба removeCCS удаляет структуру CCS из архива. Тип сервиса:
d) служба returnRemoveResult получает статус удаления. Тип сервиса:
- remove_status=«the_remove_status»
7.5. Служебные протоколы расширенной группы обнаружения совпадений
Служба ExtendedMatcher сопоставляет профиль возможностей блока программ MSU с требуемым профилем, используя обнаружитель совпадений. Услуга включает нижеследующие шаги:
a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса:
b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса:
- profile_content=«the_profile_content»
- process_status=«the_process_status»
c) служба requestMatching сопоставляет два доступных профиля. Тип сервиса:
- profile_ID_1 =«the_profile_id_1»
- profile_ID_2=«the_profile_id_2»
d) служба returnMatchingResult получает результат сопоставления. Тип сервиса:
- matching_level=«the_matching_level»
- matching_report=«the_matching_report»
8. Служба и протокол импорта словаря
8.1. Служба импорта словаря DictionaryImporting
Служба DictionaryImporting использует службу requestImportDictionary, службу returnImportDictionary, службу requestDictionary и службу returnDictionary. Служба дает возможность пользователю импортировать библиотеку деталей в архив и просмотреть содержание архива (см. рисунок 19).
<pre class="legal-pre"> ┌───────────────┐ ┌──────────────┐
│Dictionary User│ │Import Service│
│ │ │ Provider │
└───────┬───────┘ └───────┬──────┘
Request │ │
Dictionary │ │
Importing ┌┴┐requestImportDictionary(dictionary ID) ┌┴┐</pre>
│ │────────────────────────────────────────────────────────>│ │
│ │ returnImportResult(import result, processing error)│ │
│ │<────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
Request │ │
Dictionary┌┴┐requestDictionary(dictionary ID) ┌┴┐
Review │ │────────────────────────────────────────────────────────>│ │
│ │ returnDictionary(existing dictionary, processing error)│ │</pre>
│ │<────────────────────────────────────────────────────────│ │
<pre class="legal-pre"> └┬┘ └┬┘
│ │</pre>
Рисунок 19 — Служба DictionaryImporting
Служба DictionaryImporting включает нижеследующие шаги:
a) пользователь словаря инициирует службу requestImportDictionary объекта ImportServicePoint, в котором параметром сервиса, ассоциированного со службой requestImportDictionary, является идентификатор словаря;
b) поставщик сервисов инициирует службу returnImportResult объекта ImportServicePoint, в котором параметрами службы returnImportResult являются результат импортирования и ошибка обработки;
c) пользователь словаря инициирует службу requestDictionary объекта ImportServicePoint, в котором параметром службы requestDictionary является идентификатор словаря;
d) поставщик сервисов инициирует службу returnDictionary объекта ImportServicePoint, в котором параметрами службы returnDictionary являются существующий словарь и ошибка обработки.
8.2. Протокол импорта словаря DictionaryImporting
Служба DictionaryImporting импортирует словарь в архив и включает нижеследующие шаги:
a) служба requestImportDictionary запрашивает импортирование словаря. Тип сервиса:
- dictionary_ID=«the_dictionary_id»
b) служба returnImportDictionary получает импортированный словарь. Тип сервиса:
- importing_result=«the_importing_result»
- process_status=«the_process_status»
c) служба requestDictionary запрашивает словарь. Тип сервиса:
- dictionary_ID=«the_dictionary_id»
d) служба returnDictionary получает запрошенный словарь. Тип сервиса:
- dictionary_content=«the_dictionary_content»
- process_status=«the_process_status»
МОДЕЛЬ ВОЗМОЖНОСТЕЙ, СОДЕРЖАЩАЯ ОБЪЕКТЫ ДАННЫХ MDD
A.1 Диаграмма модели возможностей
Производственная деятельность включает одну и более операций производственного процесса, ассоциированных с набором производственных функций в соответствии с ИСО 16100-1:2009, раздел 5.3. Для каждой операции можно разработать модель, содержащую объекты данных MDD, в соответствии с ИСО 15745-1.
Имеется однозначное соответствие между элементами дерева приложения и элементами дерева класса возможностей. Модель производственной деятельности отображается на модель класса возможностей, как показано на рисунке A.1.
Рисунок A.1 описывает нижеследующие возможности структуры CCS в терминах объекта данных MDD:
a) операции производственной деятельности;
b) обмен ограничениями (информацией) между операциями;
c) ресурсы, использованные при выполнении операции;
d) соотношения между предшествующей и/или последующей операциями.
Рисунок A.1 — Отображение модели возможностей на модель производственной деятельности с помощью объектов данных MDD
A.2 Синтаксис языка разметки XML для рассматриваемой модели возможностей
Ниже приведен пример синтаксиса языка разметки XML для модели возможностей, представленной в особой части шаблона.
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»>
<xs:element name=«CapabilityProfiling»>
xs:complexType
<xs:sequence maxOccurs=«unbounded»>
<xs:element name=«type»>
xs:complexType
<xs:attribute name=«id» type=«xs:string» use=«required»/>
</xs:complexType>
</xs:element>
<xs:element name=«CapabilityProfile»>
xs:complexType
xs:sequence
<xs:element name=«pkgtype»>
xs:complexType
<xs:attribute name=«version» type=«xs:string» form=«unqualified»/>
</xs:complexType>
</xs:element>
<xs:element name=«Common» type=«CommonPartType»/>
<xs:element name=«Specific» type=«SpecificPartType»/>
</xs:sequence>
<xs:attribute name=«date» type=«xs:string» form=«unqualified»/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name=«CommonPartType»>
</xs:complexType>
<xs:complexType name=«SpecificPartType»>
xs:sequence
<xs:element name=«Reference_MDM_Name»>
xs:complexType
<xs:attribute name=«domain_Name» type=«xs:string» form=«unqualified»/>
</xs:complexType>
</xs:element>
<xs:element. name=«MDD_Description_Format» t.ype=«MDD_Description» />
<xs:complexType name=«MDD_Description»>
xs:sequence
xs:choice
<xs:element name=«Set_of_MDD_Objects»>
xs:complexType
<xs:sequence minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«MDD_Name_action»>
A.3 Соотношения между объектами MDD и соответствующей моделью MDM
На рисунке A.2 сравниваются два дерева производственной деятельности (дерево A и дерево B) с различными структурами CCS. Каждый узел дерева имеет свой собственный класс возможностей и соответствующий шаблон профиля возможностей. Каждый шаблон использует объекты данных MDD для описания своих возможностей. Объекты MDD выбираются из одного множества объектов MDD для рассматриваемой модели MDM, например:
Каждый объект MDD в рассматриваемой модели MDM должен быть определен. Он должен отличаться от других объектов. Уникальный идентификатор объекта MDD — отправная точка его семантического сопоставления.
| Activity tree #Am | Дерево производственной деятельности A |
|---|
Примечание — Метки CC-Am, CC-Am1, CC-Am11 и CC-Am12 обозначают особые части класса возможностей узла производственной деятельности Am, узла Am1, узла Am11 и узла Am12, соответственно. Аналогично, метки CC-Bm, CC-Bm1 и CC-Bm11 обозначают особые части класса возможностей узла производственной деятельности Bm, узла Bm1 и узла Bm11, соответственно. Объекты MDD являются элементами указанных особых частей.
Рисунок A.2 — Соотношение между производственной деятельностью и соответствующими объектами данных MDD
УПРОЩЕННОЕ СОПОСТАВЛЕНИЕ ШАБЛОНОВ ПРОФИЛЕЙ ВОЗМОЖНОСТЕЙ
B.1 Пример шаблона профиля возможностей
Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа A21 («getOperationMethod») по ИСО 16100-5, раздел B.2.
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»>
<xs:element name=«CapabilityProfiling»>
xs:complexType
xs:sequence
<xs:element name=«Template»>
<xs: c.omplexType>
<xs:attribute name=«id» type=«xs:string» use=«required» fixed=«A21»/>
<xs:attribute name=«name» type=«xs:string» use=«required» fixed=«getOperationMethod» />
</xs:complexType>
</xs:element>
<xs:element name=«type»>
xs:complexType
<xs:attribute name=«id» type=«xs:string»/>
</xs:complexType>
</xs:element>
<xs:element name=«CapabilityProfile»>
xs:complexType
xs:sequence
<xs:element name=«pkgtype»>
xs:complexType
<xs:attribute name=«version» type=«xs:string» form=«unqualified»/> </xs:complexType>
</xs:element>
<xs:element name=«Common» type=«CommonPartType»/>
<xs:element. name=«Specific» type= «SpecificPartType»/>
</xs:sequence>
<xs:attribute name=«date» type=«xs:string» form=«unqualified»/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name=«CommonPartType»>
............................... ..
................................. .
</xs:complexType>
<xs:complexType name=«SpecificPartType»>
<xs:sequence»
<xs:element name=«Reference_MDM_Name>*
xs:complexType
<xs:attribute name='domain_Name» type=«xs:string» use=«required» fixed=«MESApplicationDomain»
form=«unqualified»/>
</xs:complexType>
</xs:element>
<xs:element name=«format_name» type=«MDD_Description»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«MDD_Description»>
xs:sequence
<xs:element name=«Set_Of_MDD_Objects»>
xs:complexType
xs:sequence
<xs:element name=«actionI»>
xs:complexType
<xs:sequence maxOccurs=«unbounded»>
<xs:element name=«exchanged_information»>
xs:complexType
<xs:sequence minOccurs=«1» maxOccurs=«1»>
<xs:element name=«information_out»>
xs:complexType
<xs:attribute name=«name» use=«required» type=«xs:string» form=«unqualified»
fixed=«operation_type»/>
</xs:complexType>
</xs:elements </xs:sequences </xs:complexType>
</xs:element>
<xs:element name=«Resources»>
............................... ..
................................. .
</xs:element>
<xs:element name=«Constraints»>
............................... ..
................................. .
</xs:elements </xs:sequences
<xs:attribute name=«name» type=«xs:string» use=«required» fixed=«setOperationType»/>
<xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Set»/>
<xs:attribute name=«status» type=«xs:string» default=«mandatory»/>
</xs:complexType>
</xs:element>
<xs:element name=«action2»> xs:complexType
<xs:sequence maxOccurs=«unbounded»>
<xs:element name=«exchanged_information»>
xs:complexType
<xs:sequence minOccurs=«I» maxOccurs=«I»> <xs:element name=«information_in»>
xs:complexType
<xs:attribute name=«name» type=«xs:string» use=«required» form=«unqualified»
fixed=«operation_method(plan)»/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=«Resources»>
............................... ..
................................. .
</xs:element>
<xs:element name=«Constraints»>
............................... ..
................................. .
</xs:elements </xs:sequence>
<xs:attribute name=«name» type=«xs:string» use=«required» fixed=«getOperationMethod»
form=«unqualified»/>
<xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Get» form=«unqualified»/>
<xs:attribute name=«status» type=«xs:string» default=«optional»/>
</xs:complexTypes </xs:element>
<xs:element name=«action3»>
xs:complexType
<xs:sequence maxOccurs=«unbounded»>
<xs:element name=«exchanged_information»>
xs:complexType
<xs:sequence minOccurs=«1» maxOccurs=«1»> <xs:element name=«information_in»>
xs:complexType
<xs:attribute name=«name» type=«xs:string» use=«required» form=«unqualified»
fixed=«recipe(plan)»/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=«Resources»>
............................... ..
................................. .
</xs:element>
<xs:element name=«Constraints»>
............................... ..
................................. .
</xs:element>
</xs:sequence>
Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа B11 («receiveManufacturingInstruction») по ИСО 16100-5, раздел B.3. <xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»> <xs:element name=«CapabilityProfiling»> <xs: c.omplexType> <xs:sequences <xs:element name=«Template»> <xs:complexTypes <xs:attribute name=«id» type=«xs:string» use=«required» fixed=«BII»/> <xs:attribute name=«name» type=«xs:string» use=«required» fixed=«receiveManufacturingInstruetion» /> </xs:complexType> </xs:element> <xs:element name=«type»> xs:complexType <xs:attribute name=«id» type=«xs:string»/> </xs:complexType> </xs:element> <xs:element name=«CapabilityProfile»> xs:complexType xs:sequence <xs:element name=«pkgtype»> xs:complexType <xs: attribut.e name=«version» type=«xs : string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType»/> <xs:element name=«Specific» type=«SpecificPartType»/> </xs:sequence> <xs:attribute name=«date» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=«CommonPartType»> ............................ ............................ </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«Reference_MDM_Name»> xs:complexType <xs:attribute name=«domain_Name» type=«xs:string» use=«required» fixed=«MESApplicationDomain» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name='format_name» type=«MDD_Description»/> </xs:sequence> </xs:complexType> <xs:complexType name=«MDD_Description»> xs:sequence <xs:element name=«Set_Of_MDD_Objects»> xs:complexType xs:sequence <xs:element name=«actionI»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«exchanged_information»> <xs: COmplexType> <xs:sequence minOccurs=«I» maxOccurs=«I»> <xs:element name=«information_in»> xs:complexType <xs:attribute name=«name» type=«xs:string» use=«required» form=«unqualified» fixed=«product_order(plan)»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Resources»> ... ... </xs:element> <xs:element name=«Constraints»> ... ... </xs:element> </xs:sequence> <xs:attri'bute name=«name» type=«xs:string» use=«required» fixed=«getProductOrder»/> <xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Get»/> <xs:attribute name=«status» type=«xs:string» default=«mandatory»/> </xs:complexType> </xs:element> <xs:element name=«action2»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«exchanged_information»> xs:complexType <xs:sequence minOccurs=«1» maxOccurs=«1»> <xs:element name=«information_in»> xs:complexType <xs:attribute name=«name» type=«xs:string» use=«required» form=«unqualified» fixed=«operating_instruction(plan)»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Resources»> ............................ ............................ </xs:element> <xs:element name=«Constraints»> ............................ ............................ </xs:element> </xs:sequence> <xs:attribute name=«name» type=«xs:string» use=«required» fixed=«getOperatingInstruction» form=«unqualified»/> <xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Get» form=«unqualified»/> <xs:attribute name=«status» type=«xs:string» default=«optional»/> </xs:complexType> </xs:element> <xs:element name=«action3»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«exchanged_information»> xs:complexType <xs:sequence minOccurs=«1» maxOccurs=«I»> <xs:element name=«information_in»> xs:complexType <xs:attribute name=«name» type=«xs:string» use=«required»form=«unqualified» fixed=«item»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Resources»> ........................... ........................... </xs:element> <xs:element name=«Constraints»> ............................. ............................. </xs:element> </xs:sequence> <xs:attribute name=«name» type=«xs:string» use=«required» fixed=«getltem» form=«unqualified»/> <xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Get» form=«unqualified»/> <xs:attribute name=«status» type=«xs:string» default=«mandatory»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«List_of_lower_level»> ..................... ..................... </xs:element> </xs:sequence> </xs:complexType> </xs:schema>
Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа A33 («monitorOperationCondition») по ИСО 16100-5, раздел B.2. <xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»> <xs:element name=«CapabilityProfiling»> xs:complexType xs:sequence <xs:element name=«Template»> xs:complexType <xs:attribute name=«id» type=«xs:string» use=«required» fixed=«A33»/> <xs:attribute name=«name» type=«xs:string» use=«required» fixed=«MonitorOperationCondition» /> </xs:complexType> </xs:element> <xs:element name=«type»> xs:complexType <xs:attribute name=«id» type=«xs:string»/> </xs:complexType> </xs:element> <xs:element name=«CapabilityProfile»> xs:complexType xs:sequence <xs:element name=pkgtype«> xs:complexType <xs:attribute name=»version» type=«xs:string»form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType»/> <xs:element name=«Specific» type=«SpecificPartType»/> </xs:sequence> <xs:attribute name=«date» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=«CommonPartType»> </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«Reference_MDM_Name»> xs:complexType <xs:attribute name=«domain_Name» type=«xs:string» use=«required» fixed=«MESApplicationDomain» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«format_name» type=«MDD_Description»/> </xs: sequenc.e> </xs:complexType> <xs:complexType name=«MDD_Description»> xs:sequence <xs:element name= «Set_Of_MDD_Objects»> <xs: c.omplexType> <xs: sequenc.e> <xs:element name=«actionI»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«exchanged_information»> <xs: c.omplexType> <xs:sequence minOccurs=«I» maxOccurs=«I»> <xs:element name=«information_out»> xs:complexType <xsattribute name=«name» type=«xs:string» use=«required» form=«unqualified» fixed=«actual_equipment»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Resources»> ............................. ............................. </xs:element> <xs:element name=«Constraints»> .............................
*.............................*
*</xs:element>*
*< /xs: sequenc.e>*
*<xs:attribute name="name" type="xs:string" use="required" fixed="setActualEquipment"/>*
*<xs:attribute name="method" type="xs:string" use="required" fixed="Set"/>*
*<xs:attribute name="status" type="xs:string" default="mandatory"/>*
*</xs:complexType>*
*</xs:element>*
*<xs:element name="action2">*
*<xs:complexType>*
*<xs: sequence maxOcc.urs="unbounded">*
*<xs:element name="exchanged_information">*
*<xs:complexType>*
*<xs:sequence minOccurs="I" maxOc.curs="I">*
*<xs:element name="information_in">*
*<xs:complexType>*
*<xs:attribute name="name" type="xs:string" use="reauired" form="unqualified"*
fixed=«state(result)»/>
</xs:complexType>
</xs:element>
</xs: sequenc.e>
</xs:complexType>
</xs:element>
<xs:element name=«Resources»>
.........................
.........................
</xs:element>
<xs:element name=«Constraints»>
.............................
</xs:element>
</xs:sequence>
<xs:attribute name=«name» type=«xs:string» use=«required» fixed=«getState» form=«unqualified»/>
<xs:attribute name=«method» type=«xs:string» use=«required» fixed=«Get» form=«unqualified»/>
<xs:attribute name=«status» type=«xs:string» default=«optional»/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=«List_of_lower_level»>
xs:complexType
<xs:sequence minOccurs=«1» maxOccurs=«4»>
<xs:element name=«subactivity_nameI»>
xs:complexType
B.2 Процедура создания шаблона профиля возможностей
Процедура создания нового шаблона профиля возможностей (с помощью формальной структуры шаблона профиля возможностей) показана на рисунке B.1.
Рисунок B.1 — Процедура создания шаблона профиля возможностей
B.3 Процесс выбора надлежащего шаблона профиля возможностей
Процесс выбора надлежащего шаблона профиля возможностей из архива (в соответствии с требуемым шаблоном) показан на рисунке B.2.
| ECT | Существующий шаблон профиля возможностей |
|---|---|
| Req T | Требуемый шаблон |
| ReqOP | Требуемая операция |
| OP | Операция |
Рисунок B.2 — Процедура выбора шаблона профиля возможностей из Архива
ПРОФИЛИ, ПОЛУЧЕННЫЕ С ПОМОЩЬЮ ШАБЛОНА ПРОФИЛЯ ВОЗМОЖНОСТЕЙ
C.1 Профиль «getOperationMethod»
Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа A21 («getOperationMethod») по ИСО 16100-5:2009, раздел B.2.
Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа B11 («receiveManufacturingInstruction») по ИСО 16100-5:2009, раздел B.3.
<exchanged_information>
<information_out_in>
<information_in name="product_order(plan)" />
</information_out_in>
</exchanged_information>
<Resources />
<Constraints />
</actionI>
<exchanged_information>
<information_out_in>
<information_in name="operat.ing_instruction(plan)" />
</information_out_in>
</exchanged_information>
<Resources />
<Constraints />
</action2>
<exchanged_information>
<information_out_in>
<information_in name="item"/>
</information_out_in>
</exchanged_information>
<Resources />
<Constraints />
</action3>
</Set_Of_MDD_Objects>
<List_of_lower_level />
</format_name>
</Specific>
C.3 Профиль «monitorOperationCondition»
Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа A33 («monitorOperationCondition») в ИСО 16100-5:2009, раздел B.2.
< exchanged_information>
<information_out_in>
<information_out name="actual equipmentI" />
</information_out_in>
</exchanged_information>
<Resources />
<Constraints />
</actionI>
<exchanged_information>
<information_out_in>
<information_in name="stateI" />
</information_out_in>
</exchanged_information>
<Resources />
<Constraints />
</action2>
< / Set_Of_MDD_Objects>
<List_of_lower_level>
<subac.tivity_nameI id="A331" />
<subtemplate_nameI id="A331" />
<subactivity_name2 id="A332" />
<subtempiate_name2 id="A332" />
<subactivity_name3 id="A333" />
<subtemplate_name3 id="A333" />
<subactivity_name4 id="A334" />
<subtemplate_name4 id="A334" />
</List_of_lower_level>
</format_name>
ПРОЦЕДУРА СОЗДАНИЯ СТРУКТУРЫ КЛАССА ВОЗМОЖНОСТЕЙ
Процедура создания структуры класса CCS показана на рисунке D.1.
Рисунок D.1 — Процедура создания структуры класса CCS
ОТОБРАЖЕНИЕ БИБЛИОТЕКИ ДЕТАЛЕЙ PLIB НА ОБЪЕКТЫ ДАННЫХ MDD
Словарь деталей PLIB (представляемый в электронной форме) включает определения описаний семейств деталей (классов PLIB) и атрибутов (определенных как «свойства» в ИСО 13584). Настоящая информация представляется кодом, известным как Базовая семантическая единица (BSU).
К записи BSU добавляются метки мультиязыка. Они поддерживают мультиязычные определения. С помощью указанного механизма, профиль возможностей получает различные названия атрибутов (названия свойств в библиотеке деталей PLIB) и определения. В результате, механизм сопоставления просто оказывается электронным кодом, так как элементы BSU также представляются в электронной форме. Преимущество заключается в том, что данное сравнение проще, чем сравнение элементов BSU и объектов языка XML.
На рисунке E.1 показано соотношение между элементами библиотеки PLIB и объектами данных MDD.
| PLIB dictionary | Библиотека деталей |
|---|---|
| Service Interface | Интерфейс услуг |
| Data definition provider | Поставщик определений данных |
| Data definition register | Реестр определений данных |
Рисунок E.1 — Соотношение между элементами библиотеки PLIB и объектами данных MDD через интерфейс услуг
На рисунке E.2 показаны два объекта MDD из одного словаря PLIB. Указанные объекты MDD имеют одинаковые коды BSU, но их названия различны. Механизм сравнения устанавливает, что указанные объекты MDD одинаковы, так как одинаковы их коды BSU.
Рисунок E.2 — Сравнение объектов MDD, используя идентификаторы понятий PLIB
Процесс создания заданного шаблона профиля возможностей начинается с рассмотрения формальной структуры MDD шаблона, описанной в ИСО 16100-5:2009, раздел 6.5.2. Рассматриваемый MDD шаблон создается после того, как выполнено отображение подмножества объектов MDD (из библиотеки PLIB) на формальную структуру MDD.
Ниже приведен пример применения схемы языка XML для рассматриваемого шаблона MDD.
type=«xs:string» form=«Japanese-Destination-Name»/>
<xs:attribute name="VERSION" type="xs:string"
form=«001» />
<xs:attribute name="REVISION" type="xs:string"
form=«001» /> </xs:complexType> </xs:elements <xs:element name=«Attribute_Type»> xs:complexType <xs:attribute name=«type» type=«xs:string» form=«unqualified»/> </xs: complexType> </xs:elements </xs:sequences <xs:attribute name=«id» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
(справочное)
Открытый технический словарь (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 (обозначение #A1 относится к объекту MDD класса возможностей A1; обозначение #B1 относится к объекту MDD класса возможностей B1), которые ссылаются на один глобальный идентификатор продукта OTD и на одно предпочтительное имя. Два объекта MDD с различными названиями в соответствующих словарях представлены соответствующими терминами OTD в ресурсе OTD с разделенным доступом (например, в сервере). Общий глобальный идентификатор является мостом между индивидуальными словарями для сопоставления объектов MDD.
| IG | Справочник идентификаторов (см. ИСО 22745-2) |
|---|---|
 |
Подмножество объектов MDD, используемое в структуре CCS |
 |
Двусторонний обмен информацией |
Рисунок F.1 — Соотношение между открытым словарем OTD и объектом данных MDD, устанавливаемое интерфейсом услуг
Рисунок F.2 — Сравнение объектов MDD и идентификаторов понятий с помощью открытого технического словаря OTD
Как и в разделе E.2 (по аналогии с формальным шаблоном структуры MDD, описанной в ИСО 16100-5:2009, раздел 6.5.2) рассматриваемый пример шаблона профиля возможностей начинается с создания шаблона MDD, используя подмножество объектов MDD (на базе понятий OTD), выраженных в терминах элементов, определенных в словаре OTD для рассматриваемой модели MDM.
Ниже на языке XML приведена схема рассматриваемого шаблона MDD.
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»>
<xs:element name=«MDD»>
xs:complexType
xs:sequence
<xs:element name=«MDD_Name»>
xs:complexType
<xs:attribute name=«name» type=«xs:string» form=«qualified»
fixed=«process operation»/>
(справочное)
СОПОСТАВЛЕНИЯ ДВУХ ПРОФИЛЕЙ
Комплект услуг расширенной группы обнаружения совпадений может быть использован для сопоставления профилей возможностей с помощью нескольких структур CCS. Целью сопоставления двух профилей является отбор подходящих элементов MSU из архива в соответствии с требуемым профилем возможностей для данного вида производственной деятельности в рассматриваемом производственном приложении.
«Процедура сопоставления профилей возможностей» определена в ИСО 16100-5:2009, рисунок 12. Ниже приведены 5 шагов данной процедуры:
- шаг 5: последовательное сравнение определений возможностей в требуемом профиле возможностей с соответствующими определениями в профиле возможностей MSU.
На каждом шаге, уникальный идентификатор объекта MDD (уникальный внутри одной модели MDM) является начальной точкой семантического сравнения объектов MDD. Рассматриваемая процедура «сравнения определений возможностей» (шаг 5) фокусируется на сравнении описаний «MDD_Description». Процедура сравнения (например, списка объектов «List_of_MDD_Objects») показана на рисунке G.1.
На рисунке G.1 имеются контуры двух видов: наружный контур и внутренний контур. В наружном контуре, контур B используется для сравнения операций в соответствии с установленным порядком требуемого профиля. Порядок установлен для объектов, упорядоченных по времени «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-х контуров типа B. Первый внутренний контур используется для сравнения с двумя элементами 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 до получения желаемого результата. Так как может быть несколько ресурсов в одной операций, то после сравнения каждого ресурса рассматривается название этого ресурса.
Примечание — A, B, C и F — точки соединения процедуры. Точка F указывает неудачное сопоставление.
MDD_Description» для обнаружителей совпадений типа 2
(справочное)
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ
НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ИСО 16100-1 | IDT | ГОСТ Р ИСО 16100-1-2010 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 1. Структура» |
| ИСО 16100-2 | IDT | ГОСТ Р ИСО 16100-2-2010 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования» |
| ИСО 16100-3 | IDT | ГОСТ Р ИСО 16100-3-2010 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 3. Службы интерфейса, протоколы и шаблоны возможностей» |
| ИСО 16100-4 | IDT | ГОСТ Р ИСО 16100-4-2010 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 4. Методы аттестационных испытаний, критерии и отчеты» |
| ИСО 16100-5 | IDT | ГОСТ Р ИСО 16100-5-2011 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 5. Методология согласования конфигураций профилей с помощью многоцелевых структур классов возможностей» |
| Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты. | ||