allgosts.ru25. МАШИНОСТРОЕНИЕ25.040. Промышленные автоматизированные системы

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

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

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

>

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

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


ГОСТ Р исо 16100-6— 2014


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

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

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

Часть 6

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

ISO 16100-6:2011

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

(IDT))

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

Москва Стандартинформ 2015


Предисловие

  • 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»).

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

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

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

© Стандартинформ, 2015

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

и

Содержание

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

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

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

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

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

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

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

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

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

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

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

    • 6.3 Группа CCSI

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

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

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

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

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

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

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

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

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

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

Приложение А (справочное) Модель возможностей, содержащая объекты данных MDD

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

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

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

Приложение Е (справочное) Отображение библиотеки деталей PLIB на объекты данных MDD

Приложение F (справочное) Отображение открытого словаря OTD на объекты данных MDD

Приложение G (справочное) Процедура сопоставления двух профилей

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

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

in

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРОФИЛИРОВАНИЕ ВОЗМОЖНОСТИ ИНТЕРОПЕРАБЕЛЬНОСТИ ПРОМЫШЛЕННЫХ ПРОГРАММНЫХ СРЕДСТВ Часть 6

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

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

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

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 systemsand integration — Manufacturing software capability profiling for interoperability — Part 2: Profiling methodology)

ИСО 16100-3 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 3. Службы интерфейса, протоколы и шаблоны возможностей (IS016100-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. Методология профилирования сопоставления с помощью множественных структур класса возможностей (IS016100-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 — 8 настоящем стандарте шаблон класса возможностей идентичен шаблону профиля возможностей (см. ИСО 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 или открытому словарю ОТО в ИСО 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 IS013584);

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.

Dictionary Import Service Interface

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

Importing Service Provider

Поставщик службы импорта

Data Store Mechanism

Механизм хранения данных

Extended Service Provider

Поставщик расширенных сервисов

CPTI Group, includes CPI Group Type 3

Группа CPTI. включает группу CPI типа 3

CPI Group Type 2 service

Сервисная группа СР! типа 2

CPI Group Type 1 service

Сервисная группа CPI типа 1

CCSI Group

Группа CCSI

Extended Matcher Group

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

other, e g. MDM Interface and MDD Interface

Прочие, те. интерфейс модели MDM и интерфейс объекта данных MDD

Repository

Архив

Capability Profiles

Профили возможностей

Capability Templates

Шаблоны профилей возможностей

CCSs

Объекты CCS

MDMs

Объекты модели MDM

MDDs

Объекты данных MDD

Basic Service Provider

Поставщик базовых сервисов

CPI Group Type 1 service

Сервисная группа СР! типа 1

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

Dictionary Import Service ()-Interface


Importing Service Provider


Data Store Mechanism


•Capability Profiles -Capability Templates -CCSs

-MOMS

-MDDs

v--- ---'


Repository


СРТ1 Group, includes CPI Group Type 3


Extended

Service q cpi Group Type 2 service

Provider X

---(J Cpi Group Type 1 service


О CCSI Group

*0 Extended Matcher Group

*0 others, e.g. MDM Interface and MDD Interface


Basic Service Provider


CPI Group Type 1 service


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

Примечание


  • 2 — Элементы рисунка, выделенные жирным шрифтом, предметно рассматриваются в

настоящем стандарте.

Примечание


Примечание

Serv/ceAccessPo/nt


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

  • 4 — Точка доступа ESI в настоящем стандарте представляется как объект

    Примечание


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


    5 — Сервисная группа CPI Типа 1, кратко описанная в ИС0 16100-3:2005, раздел 5.4, вклю


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MDD Parts libraries



Identifier ICO Class name lIRDIfordassl

  • • Attribute #1 IRDI for

attribute #1

  • • Attribute #2 IRDI for

attribute #2

I

MDD

Объект MDD

MDD Name

Имя объекта MDD

Reference MDM Name

Ссылочное имя модели MDM

List of attributes

Слисок атрибутов

Attnbute #1

Атрибут 1

Parts libraries

Библиотека деталей

Identifier: ICO

Идентификатор ICD

Class name

Имя класса

IRDI for class

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

IROI for attribute #1

Международный зарегистрированный идентификатор данных для атрибута 1

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

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

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

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

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

  • - «dictionaryjd» (идентификатор словаря),

  • - «parent» (родитель),

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

  • - «version» (версия)

  • - «revision» (пересмотр).

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

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

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

  • 6.1 Службы СРТ1 группы

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

Группа 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_ пате»;

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

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

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

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

  • 4) «Event_Ordered_MDD_objects» (объекты MDD в порядке поступления):

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

Каодое значение, внесенное или модифицированное для атрибутов «идентификатор» (в разделе

  • 6.1.2.2 а), имени области «domain_name» в разделе 6.1.2.2 Ь) и «название» в разделе 6.1.2.2 d). должно быть уникальным.

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

  • 6.1.2.3 Служба createTemplate

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

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

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

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

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

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

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

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

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

  • a) пользовательшаблонаинициируетслужбугедие$<Ех1$т/лдге/пр/згеобъекта5егу/се^ссе£5Яо/лт в котором параметром службы requestExistingTemplate является идентификатор шаблона;

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

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

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

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

Template User

Пользователь шаблона

Extended Service Provider

Поставщик расширенных сервисов

Create a new capability profile template based on the formal structure

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

requestBlankTemplateO

requestBlankTemplate ()

returnBlankTemplate(biank template, creation error

retumBlankTemplate (заготовка шаблона, ошибка создания)

processFilledTemplate(template ID)

processFilledTemplate (идентификатор шаблона)

returnProcessmgResult(ID check error, storage error)

returnProcessingResult (ошибка проверки идентификатора, ошибка хранения)

Create a new capability profle template based on an existing capability template

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

requestExetmgTempiate(tempiate ID)

requestExistingTemplate (идентификатор шаблона)

returnExistingTemplate(existing template, processing error)

RetumExistingTemplate (существующий шаблон, ошибка обработки)

processModifiedTemplate (template ID)

processModifiedTemplate (идентификатор шаблона)

returnProcessingResult (ID check error, storage error)

returnProcessingResult (ошибка проверки идентификатора, ошибка хранения)

Template User


Extended Service Provider


Create a new capability profile template based on the formal structure


requestBlankTemplateO ----------------------------------------► returnBlankTemplatetblank template,creation error) ◄----------------------------------------

process F///edTemp/ate(template ID) ---------------------------------------►

retumProcessingResuf^lD check error,storage error)


Create a new capability profile template based on an existing capability tem₽,ate J-i reqi/estEx/stingTemp/ateftemplate ID)


>

reftjmEx/stfr?g7empfefe(existing template,processing error)


Д| processMod/fledTemp/ate(template ID) J-.

retumProcessingResutt(\D check error.storage error)


◄-----------------------------------------

77


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

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

Рисунок 3 — Служба create Template

  • 6.1.3 Служба accessTemplate

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

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

а)лользовательшаблонаинициируетслужбугедие£1Ех15й'лдТетр/а{еобъекта£егк/сеАссе££Ро/пГ. в котором параметром службу requestExistingTemplate является идентификатор шаблона;

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

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

Template User


Extended Service Provider

requestExistingTemplate(iemp\aie ID)


Access a capability template


--------------------------------------►

retomEwstfngTemp/atefexisting template.processing error)

Template User

Пользователь шаблона

Extended Service Provider

Поставщик расширенных сервисов

Access a capability template

Получение доступа к шаблону возможностей

requestExistingTemplate (template ID)

requestExistingTemplate (идентификатор шаблона)

retumExistingTemplate (existing template, processing error)

retumExistingTemplate (существующий шаблон, ошибка обработки)

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

  • 6.1.4 Служба modifyTemplate

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

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

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

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

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

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

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

Template User


Extended Service Provider


Modify an existing template

L requestExistingTemplate(ierr\p\ate ID)


-------------------------------------------►

retumExistingTemplate(exi$6ng template,processing error)

◄--------------------------------------

I


pm<xssModife<fremplate(template ID)


-------------------------------►

retumProcessingResult(iD check error,storage error)

T


Template User

Пользователь шаблона

Extended Service Provider

Поставщик расширенных сервисов

Modify an existing template

Модификация существующего шаблона

requestExetingTemptate (template ID)

requesfExtstingTemplate (идентификатор шаблона)

returnExistingTemplate (existing template, processing error)

returnExis tingTemplate (существующий шаблон, ошибка обработки)

processModrfiedTemplate (template ID)

processModlfledTemplate (идентификатор шаблона)

returnProcessingResuR (ID checks error, strorage error)

retumProcessingResult(ошибка проверки идентификатора, ошибка хранения)

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

  • 6.1.5 Служба validateTemplate

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

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

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

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

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

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

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

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

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

Template User


Extended Service Provider

Validate an unregistered template


requestUnregi$teredTemplate(templa№ ID)

-------------------------------------------►

retumUnregistere<fTemplate(unreg\s\ered template,processing error)

◄---------------------------------------------

testTemplateQ

retumTestResu/t(test result,match status^

Template User

Пользователь шаблона

Extended Service Provider

Поставщик расширенных сервисов

Validate an unregistered template

Валидация незарегистрированного шаблона

requestUnregrsteredTemplate (template ID)

nquestUnregisteredTemplate (идентификатор шаблона)

returnllnregisteredTemplate (unregistered template, processing error)

returnUnregisteredTemplate (незарегистрированный шаблон, ошибка обработки)

testTemplate

tes(Template{}

returnTestResult(test result, match status)

returnTestResult (результат испытаний, статус сопоставления)

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

  • 6.1.6 Служба deleteTemplate

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

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

  • a) пользовательшаблонаинициируетслужбугедие£{Ехг5й'лдТетр/агеобъекта5ел</сеАссе££Ро7лТ в котором параметром службу requestExistingTemplate является идентификатор шаблона;

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

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

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

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

Template User


Extended Service Provider


Delete an existing capability template

J, reguestExZ$£rngTemp/ate(template ID)

-------------------------------------------►

retumEx/st/ng7emp/ate(existing template,processing error)


removeTemplateQ


I

----------------------►

retumRemoveResutt(remGva\ error)

Template User

Пользователь шаблона

Extended Service Provider

Поставщик расширенных сервисов

Delete an existing capability template

Стирание существующего шаблона возможностей

requestExistingTemplate (template ID)

requestExistingTempiate (идентификатор шаблона)

returnExistingTemplate (existing template, processing error)

returnExistingTemplate (существующий шаблон, ошибка обработки)

removeTemplate ()

remove Template^

returnRemoveResult (removal error)

returnRemoveResult (ошибка удаления)

Рисунок 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 и службу retumProcessingResult. Служба createProfile включает нижеследующие шаги:

  • a) пользовательпрофиляинициируетслужбугедие5^£х/5&лдТетр/а/еобъекта5егу/сеАссе55Ро/лЛ в котором параметром службу requestExistingTemplate является идентификатор шаблона;

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

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

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

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

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

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

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

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

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

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

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

Profile User


Extended Service Provider


Create a new capability profile based on an existing capability profile template


reque$tExistingTemplate{temp\ate ID)

----------------------------------------► retumExi$tingTemplate(existing template,processing error)

processF/7/edProfffe(profite ID)


----------------------------------►

retumProcessingResult(\D check error,storage error)

Create a new capability profile based on an existing capability profile


I reque$tExistingProfile(profi\e ID)


------------------------------------►

ratumExistingProfile(e*jstir\g profile,processing error)

T processA4od/fiedProfife(profile ID)


1

> retumProcessingResuit(\D check error,storage error)

Template User

Пользователь профиля

Extended Service Provider

Поставщик расширенных сервисов

Create a new capability profile based on an extsbng capability profile template

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

requestExstingTemplate (template ID)

requestExistingTemplate (идентификатор шаблона)

returnExistngTemplate (existing template, processing error)

returnExistingTemplate (существующий шаблон, ошибка обработки)

processFiltedProfile (profile ID)

processFilledProfile (идентификатор профиля)

returnProcessingResult(ID check error, storage error)

refurnProcess/ngResu/t (ошибка проверки идентификатора, ошибка хранения)

Create a new capability profile based on an existing capability profile

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

requestExistingProfile (profile ID)

requestExistingProfUe (идентификатор профиля)

returnExistingProfie (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

processModifiedProfile (profile ID)

processModifiedProfile (идентификатор профиля)

returnProcessingResult(ID check error, storage error)

retumProcessingResult (ошибка проверки идентификатора, ошибка хранения)

Примечание 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.

Profile User


Access a profile via ESI I


Extended Service Provider

requestExistingProfile(profile ID)


---------------------------------►

retumExistingProfile(existing profile,processing error)


Access a profile via MSU

1 requestExistingProfileO


retumExistingProfilefexisting profile,processing error]

Template User

Пользователь профиля

Extended Service Provider

Поставщик расширенных сервисов

Access a profile via ESI

Получение доступа к профилю ESI

requestExistingProfle (profile ID)

requestExistingProftte (идентификатор профиля)

returnExistingProfie (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

Access a profile via MSU

Получение доступа к профилю MSU

MSU

Блок программных средств организа^и производства

requestExistingProfile ()

requestExistingProfile ()

returnExistingProfile (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

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

  • 6.2.4 Служба modifyProfile

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

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

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

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

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

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

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

  • 62.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.

processModifiedProfile(profile ID)

retumProcessingResult(ID check error,storage error)

Template User

Пользователь профили

Extended Service Provider

Поставщик расширенных сервисов

Modify an existing profile via ESI

Модификация расширенного профиля через ESI

requestExistingProfle (profile ID)

requestExistingProfile (идентификатор профиля)

returnExistingProfie (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

processModrfiedProfie (profle ID)

processModifiedProfile (идентификатор профиля)

returnProcessingResult (ID check error, storage error)

returnProcessingResult (ошибка проверки идентификатора, ошибка хранения)

Modify an existing profile via MSU

Модификация существующего профиля через MSU

MSU

MSU=Bno< программных средств организации производства

requestExetingProfie (profile ID)

requestExistingProfile (идентификатор профиля)

returnExistingProfie (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

processModifiedProfile (profile ID)

processModifiedProfile (идентификатор профиля)

returnProcessingResult (ID check error, storage error)

returnProcessingResult (ошибка проверки идентификатора, ошибка хранения)

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

  • 6.2.5 Служба validateProfile

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

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

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

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

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

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

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

testProfHeQ

--------------------------►

retumTestResuft(test result,match status)

Template User

Пользователь профиля

Extended Service Provider

Поставщик расширенных сервисов

Validate an existing profile

Валидация существующего профиля

requestExistingProfite (profile ID)

requestExistingProfile (идентификатор профиля)

returnExtsbngProfte (existing profile, processing error)

returnExistingProfile (существующий профиль, ошибка обработки)

testProfile ()

testProfile ()

returnTestResuit (test result, match status)

returnTestResuit (результат испытаний, статус сопоставления)

Рисунок 11 — Служба validateProfite

  • 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 приведена диаграмма последовательности обязательных шагов процедуры стирания профиля, основанной на использовании идентификатора профиля.

Profile User


Extended Service Provider

Delete an existing capability profile


requestExistingProfHe(pmfi\e ID)


]◄-------------

T removeProfifeQ


retumExistingProfileieMsUng profile,processing errorf


I

--------------------►

retumRemoveResuit(remcva\ error)


т

Template User

Пользователь профиля

Extended Service Provider

Поставщик расширенных сервисов

Delete an existing capability profile

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

requestExetingProfie (profile ID)

requestExIstingProflle (идентификатор профиля)

returnExistingProfiie (existing profile, processing error)

ntumExistingProfile (существующий профиль, ошибка обработки)

returnRemoveResult (removal error)

returnRemoveResuft (ошибка удаления)

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

  • 6.3 Группа CCSI

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

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

а) создание 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. службу retumBlankCCS, службу processFilledCCS и службу returnProcessingResutt

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

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

  • b) поставщик сервисов инициирует службу retumBlankCCS объекта ServiceAccessPoint. в котором параметрами службы retumBlankCCS являются заготовка 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. службу retumExistingCCS. службу processModifiedCCS и службу returnProcessingResult. Служба createCCS включает нижеследующие шаги:

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

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

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

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

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

processFilledCCS(CCS ID) J

retumProcessingResuit(\D check error,storage error)

....... 1

Create a new CCS based on an existing CCS

requestExistingCCS(CCS ID)

retumExistingCCS(ex\stong CCS,processing error)

processModrf)edCCS(CCS ID)

L

p

retumProcessingResutt(\D check error,storage error)

CCS User

Попнзпяатрпклтругтуры CCS

Extended Service Provider

Поставщик расширенных сервисов

Create a nem CCS based on the formal CCS structure

Создание новой CCS на основе формальной структуры CCS

request BlankCCSO

requestBlankCCS 0

returnBlankCCS(Nank CCS, creation error)

retumBlankCCS (заготовка CCS, ошибка создания)

processFibedCCS (CCS ID)

processFilliedCCS (идентификатор CCS)

returnProcessingResult(ID check error, storage error)

returnProcessIngResult (ошибка проверки идентификатора, ошибка хранения)

Create a new CCS based on an existing CCS

Создание новой CCS на основе существующей CCS

requestExistingCCS(CCS ID)

requestExistingCCS (идентификатор CCS)

returnExistingCCS(existing CCS, processing error)

returnExistingCCS (существующая CCS, ошибка обработки)

processModtfiedCCS(CCS ID)

processModiffedCCS (идентификатор CCS)

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

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

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

  • 6.3.3 Служба accessCCS

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

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

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

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

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


Extended Service Provider


Access a CCS


I roquestExistingCCS(CCS ID)


------------------------------►

retumExistingCCS(existing CCS.processing error)

T

CCS User

Пользователь структуры CCS

Extended Service Provider

Поставщик расширенных сервисов

Access a CCS

Получение доступа к CCS

requestExtstingCCSfCCS ID)

requestExistingCCS (идентификатор CCS)

returnExisbngCCS(existing CCS, processing error)

retumExistingCCS (существующая CCS. ошибка обработки)

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

  • 6.3.4 Служба modifyCCS

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

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

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

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

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

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

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


Extended Service Provider

Modify an existing CCS

L requestExistingCCS(CCS ID)


--------------------------------►

retumExistingCCS(exiSting CCS,processing error)

-LprocessModifiedCCS(CCS ID)


I

>

retumProcessingResutt(lD check error,storage error)

T

CCS User

Пользователь структуры CCS

Extended Service Provider

Поставщик расширенных сервисов

Modify an existing CCS

Модификация существующей CCS

requestExtstingCCS(CCS ID)

requestExistingCCS (идентификатор CCS)

returnExisbngCCStexKting CCS. processing error)

retumExistingCCS (существующая CCS. ошибка обработки)

processModrfiedCCS(CCS ID)

processModifiedCCS (идентификатор CCS)

returnProcessingResult(ID check error, storage error)

returnProcessingResult (ошибка проверки идентификатора, ошибка хранения)

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

  • 6.3.5 Служба validateCCS

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

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

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

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

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

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

На рИГ.уНКА 16 НА ЯЗЫКА IJMI ПрИВАДАМД ДИАГРАММА ПОСПАДОЯАТАПЬНПСТИ ПбяЗАТАПННЫХ ШАГОВ ПрО-цедуры проверки соответствия существующей CCS с помощью идентификатора CCS.

CCS User


Extended Service Provider

Validate an existing CCS

requestExistlngCCS(CCS ID)

-------------------------------------------►

retumExistingCCS(existir\g CCS,processing error)

◄--------------------------------------

testCCSQ --------------------------------------► retumTostRc3ult(tost result,match statue)

CCS User

Пользователь CCS

Extended Service Provider

Поставщик расширенных сервисов

Validate an existing CCS

Валидация существующей CCS

requestExistingCCS(CCS ID)

requestExistingCCS (идентификатор CCS)

returnExistingCCSfexisting CCS. processing error)

retumExistingCCS (существующая CCS. ошибка обработки)

testCCS()

testCCS 0

returnTestResultftest result, error status)

retumTestResult (результат испытаний, ошибка статуса)

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

  • 6.6.6 Служба deleteCCS

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

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

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

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

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

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

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

CCS User

Extended Service Provider

Delete an existing CCS

_ requestExistingCCS{CCS ID)

retumExistingCCS(exis6ng CCS, processing error)

CCS User

Пользователь CCS

Extended Service Provider

Поставщик расширенных сервисов

Delete an existing CCS

Стирание существующей CCS

reque$tExetingCCS(CCS ID)

requestExistingCCS (идентификатор CCS)

returnExistngCCS(ex»sting CCS. processing error)

retumExistingCCS (существующая CCS. ошибка обработки)

removeCCS ()

removeCCS ()

returnRemoveResuR(removal error)

returnRemoveResull (ошибка удаления)

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

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

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

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

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

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

  • 6.4.2 Служба ExtendedMatcher

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

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

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

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

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

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

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

Matcher User


Extended Service Provider

1 raquestPmfile(proftte ID)


Request a profile either from the Data Container or from the MSU

refumProfffefexisting profile,processing error)


“Г


r*-i rogues/Proff/e(profile ID)

refumPTOfi/efexisting profile,processing error)

◄----------------------------

Match the profiles with the л t.

matcher J reqi/estMatch/ngfprofile ID,profile ID)


>

retumMatchingResutt(matching level,matching report)

Matcher User

Пользователь обнаружителя совладели

Extended Service Provider

Поставщик расширенных сервисов

Request a profile either from the Data Container or from the MSU

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

requestProfite(profile ID)

rvquestProfite (идентификатор профиля)

returnProfite(existing profile, processing error)

retumProfHe (существующий профиль, ошибка обработки)

MSU

Блок программных средств орсанизаьми производства

requestProfite(profile ID)

nquestProfite (идентификатор профиля)

returnProHefexrsting profile, processing error)

retumProfite (существующий профиль, ошибка обработки)

Match the profile with the matcher

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

requestMatchingfproffe ID, profie ID)

raquestMatchmg (идентификатор профиля, идентификатор профиля)

returnMatchmgResult (matching level, matching report)

ritumMatchingResuH (уровень сопоставления, отчет о сопоставлении)

Примечание — Пунктирная линия отделяет запрос профиля от запроса сопоставления Рисунок 18 — Служба ExtendedMatcher

Рисунок 18. лист 2

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

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

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

Точка соответствия и № набора

Описание точки соответствия

Ссылка на спецификацию

Тип точки соответствия3

Абстрактный критерий испытания

lndex_1

Получение требуемого профиля возможностей

ИСО 16100-5 2009, раздел 7

А

Верификация требуемого

профиля возможностей на соответствие с ИСО 16100-5:2009. таблица 2

lndex_2

Получение профиля возможностей MSU

ИСО 16100-5:2009, раздел 7

А

Верификация профиля возможностей MSU на соответствие с ИСО 16100-5:2009, таблица 2

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

Точка соответствия и № набора

Описание точки соответствия

Ссылка на спецификацию

Тип ТОЧКИ соответствия3

Абстрактный критерий испытания

lndex_3

Сравнение идентификаторов двух профилей модели MDM

ИСО 16100-5 2009, раздел 7

А

lndex_3 1

Извлечение идентификаторов из двух профилей модели MDM

ИСО 16100-5 2009, раздел 7

А

Верификация идентификаторов словарей

lndex_3.2

Сравнение двух идентификаторов модели МОМ

ИСО 16100-5:2009, раздел 7

А

Верификация и показ результатов сравнения

lndex_3,2.1

Отчет о результате № 1 и переход к обнаружителю совпадений типа 1

ИСО 16100-5 2009, раздел 7

А

Верификация:

  • 1) «Идентификаторы совпадают»

  • 2) «Переход к обнаружителю совпадений типа 1»

lndex_3,2.2

Отчет о результате N8 2

ИСО 16100-5 2009, раздел 7

А

Верификация: «Идентификаторы не совпадают»

lndex_4

Сравнение названий двух профилей модели MDM

ИСО 16100-5:2009, раздел 7

А

lndex_4.1

Извлечение названий двух профилей модели MDM

ИСО 16100-5:2009, раздел 7

А

Верификация названий модели MDM

lndex_4.2

Сравнение двух названий модели МОМ

ИСО 16100-5:2009, раздел 7

А

Верификация результатов на основе сравнения

lndex_4.2.1

Отчет о результате № 1 и завершение сопоставлени

ИСО 16100-5.2009, раздел 7

А

Верификация

  • 1) «Названия модели MDM не совпадают»

  • 2) «Два профиля относятся к различным моделям MDM»

  • 3) «Нет сопоставления»

lndex_4.2.2

Отчет о результате № 2

ИСО 16100-5:2009, раздел 7

А

Верификация: «Названия модели MDM совпадают»

lndex_5

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

ИСО 16100-5:2009, раздел 7

А

lndex_5.1

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

ИСО 16100-5:2009, раздел 7

А

Верификация форматов

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

lndex_5.2

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

ИСО 16100-5:2009, раздел 7

А

Верификация результатов на основе сравнения

lndex_5.2.1

Отчет о результате N8 1

ИСО 16100-5:2009, раздел 7

А

Показать отчет № 1:

  • 1) «Форматы определения возможностей не совпадают»

  • 2) «Преобразовать объекты MDD и MDD (определения возможностей) к единому формату определения возможностей»

lndex_5.2 2

Отчет о результате № 2

ИСО 16100-5 2009, раздел 7

А

Верификация «Форматы определения возможностей совпадают»

lndex_6

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

ИСО 16100-5:2009. раздел 7

А

lndex_6.1

Сравнение содержания элемента набора MDD элементов «Set_of_MDD_object» в двух определениях возможностей

ИСО 16100-5 2009. раздел 7

А

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

Точка соответствия и № наборе

Описание точки соответствия

Ссылка на спецификацию

Тип ТОЧКИ соответствия3

Абстрактный критерий испытания

lndex_6.11

Сравнение атрибутов «название» и «операция» элемента имени MOD «MDD_ пате» в двух определениях возможностей

ИСО 16100-5 2009, раздел 7

А

Верификация результата

lndex_6.2

Сравнение содержания двух списков объектов «List_of_ MDD_object» в двух определениях возможностей

ИСО 16100-5 2009, раздел 7

А

lndex_6.2.1

Сравнение последовательностей элементов «MDD_ пате» в двух определениях возможностей

ИСО 16100-5:2009, раздел 7

А

Верификация результата

lndex_6 2.2

Сравнение атрибутов «название» и «операция» элемента «MDD_name», находящихся в одинаковых позициях в двух определениях возможностей

ИСО 16100-5 2009, раздел 7

А

Верификация результата

lndex_6.3

Сравнение содержания двух упорядоченных во времени объектов <Time_Ordered_ MDD_objects» в двух определениях возможностей

ИСО 16100-5:2009, раздел 7

А

lndex_6.3.1

Сравнение временной упорядоченности элементов «MDD.name» в двух определениях возможностей

ИСО 16100-5:2009, раздел 7

А

Верификация результата

lndex_6.3.2

Сравнение атрибутов «название» и «операция» в двух элементах «MDD_name», находящихся в одинаковых позициях в двух определениях возможностей

ИСО 16100-5 2009, раздел 7

А

Верификация результата

lndex_6.4

Сравнение объектов

«Event_Ordered_MDD_ object», расположенных в порядке поступления

ИСО 16100-5:2009, раздел 7

А

lndex_6.4.1

Сравнение элементов

«MDD_name», расположенных в порядке поступления о доух определениях ооз можностей

ИС0 16100-5 2009, раздел 7

А

Верификация результата

lndex_6 4 2

Сравнение атрибутов «название» и «операция» в двух элементах «М00_пате», находящихся в одинаковых позициях в двух определениях возможностей

ИСО 16100-5:2009. раздел 7

А

Верификация результата

a См. ИСО 16100-4:2006, таблица 5.

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

Точка соответствия и № набора

Описание точки соответствия

Ссылка на спецификацию

Тип точки соответствия3

Абстрактный критерий испытания

lndex_1

MatchingLevelReport

ИСО 16100-5:2009, раздел 7.2

А

Допустимый уровень сопоставления:

Полное совпадение Совпадают все обязательные элементы

Совладают некоторые обязательные элементы

Обязательные элементы не совпадают

lndex_2

DetartedListReport

ИСО 16100-5:2009. раздел 7.2

А

Вери фи ка ци я согл асова иных функций и несогласованных функций

lndex_3

CompareMatchingLevel & Detailed

Report MatchingLevel

lndex_3.1

ForCompleteMatch

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

lndex_3.2

ForAJIMandatoryMatch

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

lndex_3.3

ForSomeMandatoryMatch

Верификация списка эквивалентных обязательных функций в двух профилях и списка неэквивалентных обязательных функций

lndex_3.4

ForNoMandatoryMatch

Нестоящие оба набора функций а двух профилях рассматриваются как полностью неэквивалентные

a См ИСО 16100-4 2006, таблица 5

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

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

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

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

Полное имя URN услуги имеет нижеследующий синтаксис: «service:<service-type>:<service-access-point>://<address>;<atribute-list>»

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

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

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

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

<atribute-id>=<atribute-value>

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

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

I removeCCSQ

retumRemoveResult(remova\ error)


Г------------------т


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

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

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

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

  • a) служба requestBlankTemplate запрашивает заготовку шаблона и задает тип сервиса: <service-ty pe>="requestBlankTemplate"

  • b) служба retumBlankTemplate получает заготовку шаблона и задает тип сервиса: <service-type>= "retumBlankTemplate" с соответствующими атрибутами:

  • - template_content=”the_template_content"

  • - access_status-*the_access_status"

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

<service-type>="processFilletfremplate'' с соответствующими атрибутами: -template_ID="the_templateJd”

  • d) служба returnProcessingResult получает результат обработки и задает тип сервиса: <service-type>="retumProcessingResutf' с соответствующими атрибутами:

  • - ID_check_error="ID_check_error*’

  • - storage_error="storage_error”

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

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

  • a) Служба requestExistingTemplate запрашивает существующий шаблон и задает тип сервиса: <serv‘ice-type>=“requestExistingTemplate" с соответствующими атрибутами:

  • - template_ID="the_template_id";

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

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

  • - template_content=’’the_template_content"

  • - process_status=’’the_process_status”

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

<service-type>='^processModifie<fTemplate^' с соответствующими атрибутами:

  • - template_ID="the_templateJd”

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

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

  • - ID_check_error="ID_check_error"

  • - storage_error="storage_error”

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

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

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

^ervice-type^'requestExistingTemplate" с соответствующими атрибутами:

  • - template_ID="the_template_id";

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

<service-type>="retumExistingTemplate'' с соответствующими атрибутами: -template_content=’’the_template_content"

  • - process_status="the_process_status”

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

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

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

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

  • - templateJD="the_template_id"

зо

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

<service-type>=,,retwnExistfngTe/np/ateM с соответствующими атрибутами:

  • - template_content=''the_template_content"

  • - process_status=”the_process_status”

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

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

  • - template_ID="the_template_id”

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

<service-type>-'returnProcessingResuir с соответствующими атрибутами:

  • - ID_check_error="ID_check_error"

  • - storage_error=,,storage_error

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

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

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

<service-type>="requestUnregjsterecnen?p/ate" с соответствующими атрибутами:

  • - template_lD="the_templateJd"

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

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

  • - template_content=”the_template_content"

  • - process_status=”the_process_status”

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

<service-type>=”testTemp/ate"

  • d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса: <service-type>="returnTestResu/f с соответствующими атрибутами:

  • - test_result =’*the_test_result”

  • - test_status=”the_test_status”

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

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

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

  • - template_lD="the_templateJd"

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

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

  • - template_content= "the_template_content"

  • - process_status-’the_process_status*’

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

<service-type>="removeTemp/ate"

  • d) служба returnRemoveResult получает статус удаления. Тип сервиса: <3ervice-type>="refL/rnRemoveResu/f с соответствующими атрибутами:

  • - remove_status=“the_remove_status‘’

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

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

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

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

  • a) служба requestExistingTemplate запрашивает существующий шаблон. Тип сервиса: <service~type>-'requestExistingTemplate" с соответствующими атрибутами:

  • - template_JD="the_templateJd“

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

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

  • - template_content="the_template_content"

• access_status="the_access_status"

  • c) служба processFilledProfile запрашивает приемлемость заполненного профиля. Тип сервиса: <service-type>=”processFilledProfile” с соответствующими атрибутами:

  • - profi1e_ID="the_profile_id”

  • d) служба returnProcessingResutt получает результат обработки. Тип сервиса: <service-type>-'returnProcessingResuiT с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error”

  • - storage_error=*‘storage_error”

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

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

  • a) служба requestExistingProfile запрашивает существующий профиль. Тип сервиса: <service-type>="request£x/st/ngProft7e" с соответствующими атрибутами:

  • - profile_ID='*the_profile_id’’

  • b) служба returnExistingProfile получает существующий профиль. Тип сервиса: <service-type>="returnExistingProfile’’ с соответствующими атрибутами:

  • - profile_content=’4he_profile_content”

  • - process_status=”the_process_status"

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

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

  • - profile_ID=”the_profile_id”

  • d) служба returnProcessingResutt получает результат обработки. Тип сервиса: <service-type> = “returnProcessingResutT с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error"

  • - storage_error=”storage_error”

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

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

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

  • a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса: <seryice-type>=,,requestExistingProfile" с соответствующими атрибутами:

  • - profile_ID=''the_profile_id"

  • b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса: <service-type>=”returnExistfngProft7e" с соответствующими атрибутами:

  • - profile_content=”the_profile_content”

  • - process_status=”the_process_status”

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

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

  • a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса: <service-type>-’requestExistingProfile"

  • b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса: <service-type>-'returnExistingProfile" с соответствующими атрибутами:

  • - profile_content= ’ЧЬе_ргоЛ1е_соп1епГ’

  • - process_status-‘the_process_status"

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

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

  • a) служба requestExistingProfile получает доступ к существующему профилю. Тип сервиса: <service-type>-'requestExistingProfile" с соответствующими атрибутами:

  • - profile_ID="the_profile_id’’

  • b) служба returnExistingProfile получает запрошенный профиль. Тип сервиса: <service-type>=”returnExistingProfile” с соответствующими атрибутами:

  • - proftle_content= “the_profile_content”

  • - process_status=’1the_process_status”

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

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

  • - profi1e_ID="the_profile_id”

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

<service-type>-'returnProcessingResuir с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error”

  • - storage_error=”storage_error”

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

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

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

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

  • - profile_ID=,,the_profile_id"

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

<seryice^pe>-,,returnExistingProfile" с соответствующими атрибутами:

  • - profile_content="the_profile_content"

  • - process_status=”the_process_status”

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

<service-type>="testProff/eB

  • d) служба returnTestResult получает результат испытаний и статус испытаний. Тип сервиса: <service-type>- 'returnTestResulT с соответствующими атрибутами:

  • - test_result="the_test_result"

  • - test_status-'the_test_status"

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

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

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

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

  • - profile_ID=''the_profile_id”

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

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

  • - profile_content= ”the_profile_content”

  • - process_status=”the_process_status”

  • c) служба removeProfile удаляет профиль возможностей из архива. Тип сервиса: <service-type>=" removeProfile'

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

<service-type>-'returnRemoveResulT с соответствующими атрибутами:

  • - remove_status="the_remove_status“

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

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

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

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

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

<service-type>=" requestBlankCCS"

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

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

  • - CCS_content=’’the_CCS_content"

  • - accessestatus=‘‘the_access_status"

  • c) служба processFilliedCCS запрашивает приемлемость заполненной структуры CCS. Тип сервиса: <service-type>-’processFilliedCCS" с соответствующими атрибутами:

  • - CCS_ID=’’the_CCS_id”

  • d) служба returnProcessingResutt получает результат обработки. Тип сервиса: <service-type>="refurnProcess/ngResu/T с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error”

• storage_error=”storage_error*'

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

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

  • a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса: <service-type>=”requestExistingCCS" с соответствующими атрибутами:

  • - CCS_ID="the_CCS_id'’

  • b) служба retumExistingCCS получает существующую CCS. Тип сервиса: <service-type>~"returnExistingCCS'' с соответствующими атрибутами:

  • - CCS_content="the_CCS_content”

  • - process_status-’the_process_status”

  • c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса: <service-type>="processModtf7edCCS" с соответствующими атрибутами:

  • - CCS_ID=**the_CCS_id"

  • d) служба returnProcessingResuft получает результат обработки. Тип сервиса: <service-type>="retumProcessingResuir с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error*'

  • - storage_error=’’storag e_error”

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

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

  • a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса: <setvice-type>-'requestExistingCCS" с соответствующими атрибутами:

  • - CCS_ID="the_CCS_id"

  • b) служба retumExistingCCS получает существующую CCS. Тип сервиса: <service-type>-'returnExistingCCS" с соответствующими атрибутами:

  • - CCS_content="the_CCS_content"

  • - process_status=”the_process_status"

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

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

  • a) служба requestExistingCCS запрашивает существующую CCS. Тил сервиса: <service-type>~'requestExistingCCSM с соответствующими атрибутами:

  • - CCS_ID="the_CCS_id"

  • b) служба retumExistingCCS получает существующую CCS. Тип сервиса: <service-type>-'returnExistingCCS" с соответствующими атрибутами:

  • - CCS_content=”the_CCS_content"

  • - process_status-’the_process_status"

  • c) служба processModifiedCCS запрашивает приемлемость модифицированной CCS. Тип сервиса: <service-type>=7>rocessModffredCCS*' с соответствующими атрибутами:

  • - CCS_ID="the_CCS_id"

  • d) служба returnProcessingResuft получает результат обработки. Тип сервиса: <service-type>= 'retumProcessingResutr с соответствующими атрибутами:

  • - ID_check_error=”ID_check_error”

  • - storage_error=”storage_error”

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

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

  • a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса: <service-type>-'requestExistingCCS" с соответствующими атрибутами:

  • - CCS_ID="the_CCS_id"

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

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

  • - CCS_content- *the_CCS_content"

  • - process_status=’’the_process_status"

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

<service-type>=,,testCCS"

  • d) служба retumTestResult получает результат испытаний и статус испытаний. Тип сервиса: <service-type>=”retum7estRest//r с соответствующими атрибутами:

  • - test_result ="the_test_result”

  • - test_status="the_test_status"

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

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

  • a) служба requestExistingCCS запрашивает существующую CCS. Тип сервиса: <service-type>="requestExistingCCS" с соответствующими атрибутами:

  • - CCS_ID=**the_CCS_id"

  • b) служба returnExistingCCS получает существующую CCS. Тип сервиса: <service-type>="retumExistingCCS" с соответствующими атрибутами:

  • - CCS_content- *the_CCS_content"

  • - process_status=’’the_process_status"

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

<service-type>=" removeCCS"

  • d) служба returnRemoveResult получает статус удаления. Тип сервиса: <service-type>=’’returnRemoveResu/T с соответствующими атрибутами:

  • - remove_status=”the_remove_status”

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

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

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

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

  • - profile_ID="the_profile_id"

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

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

  • - profile_content=,,the_profile_content”

  • - process_status=’’the_process_status"

  • c) служба requestMatching сопоставляет два доступных профиля. Тип сервиса: <service-type>=,Teqi/estMatch/ngM с соответствующими атрибутами:

  • - profi1e_ID_1 ="the_profile_id_1"

  • - prorile_ID_2=,’the_profite_id_2“

  • d) служба retumMatchingResult получает результат сопоставления. Тип сервиса: <service-type>=~returnMatchingResutr с соответствующими атрибутами:

• matching_level=”the_matching_level”

  • - matching report»’*the matching report”

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

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

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

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

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

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

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

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

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

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

  • a) служба requestimportDictionary запрашивает импортирование словаря. Тип сервиса; <service-type>=”requestfmportDfct/onary* с соответствующими атрибутами;

  • - dictionaryJD-'the-dictionaryJd"

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

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

  • - importing_result=”the_importing_resutt”

  • - process_status=”the_process_status”

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

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

  • - dictionary_ID=’*the_dictionary_id"

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

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

  • - dictionary_content="the_dictionary_content"

  • - process_status=’’the_process_status”

    Dictionary User


    Request Dictionary Review


Import Service Provider

Request Dictionary Importing I requestlmpor^icbonary^diOtionary ID)


T

>

retumlmportResultQmport result,processing error)

-Ц requestDictionary(dKtionary ID)


-------------------------------►

ntumDicbonary(existir\g dictionary,processing error)

Dictionary User

Пользователь словаря

Import Service Provider

Поставщик сервисов импортирования

Request Dictionary importing

Запрос импртирования словаря

requestlmportDistionary(dictionary ID)

requestimportDictionary (идентификатор словаря)

returnlmportResult (import result, processing error)

returnimportingresult (результат импортирования, ошибка обработки)

Request Dictionary Review

Запрос пересмотра словаря

requestDictionary(dictionary ID)

requestDictionary (идентификатор словаря)

returnDict»onary(existing dictionary, processing error)

retumDictionary (существующий словарь, ошибка обработки)

Рисунок 19 — Служба Dictionaryimporting

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

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

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

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

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

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

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

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

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

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

Class Capability

Actions— Performed by methods


Resources—

Support the methods to fulfill the action


Constraints—

In the methods /actions

Information exchanged— between the methods /actions


Relationship—

between MDDs or actions


Г

Action

Name

Method

I

Status Device

Equipment

Toots utility

Material

Secondary material

Human

------

Recipe

Quality requirement

Input data

Output data

Standart time Actual time

Start time End time

Standart cost Actual cost

-------

Predecessor

Successor

•*«*—*—**••


-► Method in the action

> Workpiece / Substance / Item

■> Instruction / Prescription

Order / Control data / Product data / Manufacturing data

Action performance report / Progress state / Product data / Manufacturing data



Class Capability

Возможности класса

Actions—Performed by methods

Операции (выполняются разными методами)

Action

Операция

Name

Название

Method

Метод

Status

Статус

Methods in the action

Метод выполнения операции

Device

Устройство

Equipment

Оборудование

Tools utility

Инструмент для выполнения операции

Material

Материал

Secondary material

Вспомогательный материал

Human

Человек

Resources—Support the methods to fulfill the action

Ресурсы (реализа^я метода выполнения операции)

lAforfcptece / Substance 7 Item

Заготовка/еещество/изделие

Recipe

Рецептура

Instruction / Prescription

Инструк1><я/Предписание

Quality requirement

Требование к качеству

Input data

Входные данные

Order 7 Control data / Product data! Manufacturing data

Приказ/данные управленияданные продукта/ производственные данные

Output data

Выходные данные

Action performance report! Process state / Product data / Manufacturing data

Отчет о выполнении операции/состояние развития/данные родукта/производственные данные

Standard time/Actual time

Стандартное время'фактическое время

Constraints—in the methods / actions

Ограничения (метода/операции)

Information exchanged—between the methods / actions

Обмен информации (между методами/операциями)

Start time/End time

Время начала/время окончания

Standard cost/Actual cost

Стандартные эатраты*фактмческие затраты

Relationship—between MDDs or actions

Соотношения (между объектами данных MDD и операциями)

Predecessor

Предшествующая операция

Successor

Последующая операция

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

А.2 Синтаксис языка разметки ХМ1_дпя рассматриваемой модели возможностей

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

<?xml version="1.0" encoding-'UTF-B"?>

<xs:schema xmlns:xs="http:/Avww.w3.org/2001/XMLSchema'*>

<xs:element name="CapabilityProfiling”>

<xs:complexType>

<xs sequence maxOccurs="unbounded">

«'xsrelement name- 'type"’*

<xs complexType> <xs:attribute name-id" type-'xs stnng" use-’required’7>

</xs:complexType>

</xs:element>

<xs:element name-'CapabilrtyProfile‘,>

<xs complexType>

<xs:sequence>

<xs:element name="pkgtype">

<xs:complexType>

<xs:attnbute name-'version" type="xs:string" form="unqualrfied"/>

</xs:complexType>

</xs:element>

<xs element name="Common" type-'CommonPartType“/> <xs:element name="Specific" type="SpecificPartTypeV>

</xs:sequence>

<xs:attnbute name-'date" type="xs:string" form="unqualified"/>

</xs complexType»

<Zxs: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:stnng" form=”unqualified7>

</xs complexType»

</xR-plerrw»nt>

<xs element name="MDD_Description_Formar 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-'O* maxOccurs="unbounde<r>

<xs:element name=“MDD_Name_actk>n">

<xs attribute name-'name"t.ype=“xs: string” use=” required" fixed^/»<xs:attribute name-’method" type- 'xsstnng” use-'required" fixed-”/» <xs:attribute name=”status" type-'xs: string" default-'"/»

</xs:element>

<xs:element name-‘MDD_Name_exchanged_information"> <xs: complexType»

<xs:sequence minOccurs-'O“ maxOccurs-'unbounded"»

<xs choice^

<xs:element name="information_out">

<xs: complexType»

<xs:attnbute name-'name"type=^s:string"fonm="unqualified7> </xs:complexType> </xs:elemertt>

<xs:element name="mformationjn,'>

<xs:complexType>

<xs:attnbute name-'name"type="xs:string"form="unqualified7> </xs:complexType> </xs:element>

</xs:choice>

</xs:sequence>

</xs:complexType>

</xs:element> // end of exchangedjnfbrmation

<xs : element name="MDD_Name_constraints" >

<xs: complexly pe>

<xs sequence minOccurs="0" maxOccurs=”unbounded">

<xs:element name=”Constraint_name">

<xs:complexType>

<xs:attribute name-'name" type="xs:string"fbrm-'unqualified"/> </xs complexType» </xs:element»

< /xs: sequenc e»

</xs complexType»

</xs:elements //end of constraints

<xs element name="MDD_Name_resources" >

<xs:complexType>

<xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Resource_name"> <xs:complexType>

<xs:attribute name-’name" type=”xs:string’’fbrm=”unqualified" l> </xs:complexType>

</xs element»

</xs:sequence> </xs:complexType>

</xs: element»

// end of resources

</xs:sequence> </xs:complexType> </xs element»

// end of "Set_of_MDD_Objec ts'


<xs: element name="List_of_MDD_Objects">

</xs:element>

<xs:element name="Time_ordered_MDD_Objects **>

</xs: element»

<xs: element name-'Event_ordered_MDD_Objec.ts ’*> </xs:element>

</xse.haicA>

<xs element name=“List_ofJowerJevel *' > <xs:complexType> <xs:sequence minOccurs-'O" maxOccurs=”unbounded”>

<xs : element name-’ Subac.tivity_name“> <xs: c omplexType»

<xs attribute name=“name“ type=”xs string" form-’unqualified"/» </xs:complexType>

</xs: element»

<xs:element name-'subtemplate_name”> <xs:complexType>

<xs attribute name="name” type="xs:string” form-'unqualified"/» </ xs:complexType>

</xs: element»

</xs:sequence> </xs:complexType>

</xs.element>

</xs:sequence> // end for MDD_Descnption </xs:complexType>

<fxs sequenc e> <Acs:comptexType> // end for SpecrficPart </xs:schema>

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

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

MDDiCMDM|iC(1..n]

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

| Activity tree #Am

| Дерево производственной деятельности А

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

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

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

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

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

В.1.1 Пример 1

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

<?xml version-1.0" encoding=,‘UTF-8’,?>

<xs:schema xmlns:xs="htty://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:stnng’7>

</xs:complexType>

</xs:element>

<xs:element name="CapabilityProfile“>

<xs:complexType>

<xs:sequence>

<xs:etement name=”pkgtype”>

<xs:complexType>

<xs:attribute name="version" type="xs string" form="unqualified“/> </xs complexType>

</xs:element>

<xs:element name-’Commcn" type-'CommonPartType7> <xs:element name-’Specific" type= "SpecificPartType7> </xs:sequence>

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

</xs:element>

</xs:sequence>

</xs:comptexType>

</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="MESApplicationDornain" form="unqualified"/>

</xs:complexType>

</xs:element>

<xs:element name- 'format_name" type="MDD_Description7>

</xssequer»ce>

<Zxs:complexType>

<xs:complexType name="MDD_Description">

<xs sequence>

<xs.element name="Set_Of_MDD_Objects">

<xs:complexType>

<xs: sequence»

<xs:element name=”actionr>

<xs complexType»

<xs: sequence maxOccurs="unbounded">

<xs: element name="exchanged_information">

<xs complexType»

<xs:sequence minOccurs="1" maxOccurs="1">

<xs:element name-‘inforrriation_out">

<xs:complexType>

<xs:attribute name="name" use-'required" type="xs:string” form-'unqualified" fixed-'operation_type7>

</xs: complexType»

</xs elements </xs sequences </xs:complexType>

</x«:element>

<xs: element name="Resources“>

</xs:element> <xs: element name="Constraints">

</xs:elements </xs:sequences

<xs attnbute name-'name" type="xs:stringH use=’required" fixed=”setOperationType“/> <xs:attnbute name-'method"type="xs:stnng" use-'required" fixed="Set7> <xs:attribute name="status" type=“xs:string" default="mandatory7> <Zxs:complexType>

</xs:element>

<xs:element name=”action2"> <xs:complexType>

<xs:sequence maxOccurs-'unbounded"»

<x$:element name="cxchanged_informabon‘>

<xs: complexType» <xs:sequence mmOccurs="r maxOccurs=T> <xs:element name="information_in’’> <xs:complexType>

<xs:attribute name="name" type="xs:string" use-'required" form-'unqualified" fixed-'operation_method(plan)7>

</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=7rs:string" use="required" fixed=”getOperationMethod" form-’unquali f ied7>

<xs: attribute name-'method"type="xs:string" use-'required" fixed=“Get" form-'unqualified"/» <xs: attribute name-'status" type=7<s:string" default="optional7>

</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-'informationjn"» <xs:complexType>

<xs:attribute name="name* type="xs:string“ use-’required" form-'unqualified" fixed-' reci pe( p la n )7>

</xs: complexType*

</xs: element*

</x$: sequence*

</xs: complexType*

</xs:element>

<xs element name="Resources">

</xs: element* <xs:element name-'Constraints"*

<ftcs element*

c/xssequenne*

<xs attribute name=“name" type-'xs:string" use="required" fixed=“get.Recipe" form=“unqualified"/> <xs:attribute name-'method" type="xs:string" use=”required" fixed-'Get" fbrm=“unqualified"/> <xs:attnbute name-'status" type-’xs:stnng" default="optional7> <7xs:complexType>

</xs: element*

</xs: sequence*

</xs:complexType>

</xs:element>

<xs:element name="List_of_lowerJever*

</xs:element>

</xs:sequence>

</xs: complexly pe > </xs:schema>

B.1.2 Пример 2

Ниже приведен пример синтаксиса языка разметки XML для шаблона профиля возможностей производственной деятельности типа В11 CreceiveManufacturinglnstruction") по ИСО 16100-5, раздел В 3 <?xml version="1.0" encoding="UTF-8"?>

<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-'В1Г/*

<xs:attnbute name="name" type="xs:string" use-'required" fixed-’receiveManufacturinglnstruetJon"/> </xs complexType*

</xs:element>

<xs element name=“type">

<xs:complexType> <xs:attribute name="id" type=*'xs:string7> </x$: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”/* <Zxs:complexType>

</xs element*

<xs:element name-’Common" type-'CommonPartTypeV* <xs:element name-Specific" type- 'SpedficPartType’7*

</xs:sequence>

<xs:attribute name="date” type-'xs:stnng" form-’unqualified"/> </xs complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="CommonPartType"> <7xs:complexType>

<xs:complexType name=,,SpecificPartType“>

<xs.sequence>

<xs:element name-*Reference_MDM_Name">

<xs complexType>

<xs*attribute namA=''domain_NamA’’ fypa=Hxss1ring" ijfie=Mreqijired" fixed="MFSApplmatwnDomairr form=“unqualified“/>

</xs:complexType>

</xs:element>

<xs:element name- format_name" type=”MDD_Description"/>

</xs:sequence>

</xs:complexType>

<xs:comptexType name-'MDD_Description">

<xs:sequence>

<xs:element name="Set_Of_MDD_Objects">

<xs:complexType>

<xs:sequence>

<xs:element name=”actionr>

<xs complexType>

<xs:sequence maxOccurs="unboundecr>

<xs:element name="exchanged_informabon">

<xs COiiiptexType>

<xs:sequence minOccurs=”r maxOccurs=T>

<xs element name=,’informationjn">

<xs:complexType>

<xs:attribute name^name" type-'xs:string" use="required" form=“unqualified" fixed-'prod uct_order(plan)7>

</xs: complexType>

</xs.element>

</xs:sequence> </xs:complexType> </xs:eiement>

<xs:element name-'Resources“>

</xs:etement> <xs:element name-'Constraints"»

</xs:element>

</xs: sequence»

<xs:attribute name-’name" type-*xs:string" use="require<r fixed="getProductOrdef7> <xs:attribute name="method" type="xs string" use-'required" fixed-'GeT/>

<xs:attribute name-'status" type="xs:string" defautt="mandatory'7>

</xs:complexType>

</xs:element>

<xs:element name="action2">

<xs complexType>

<xs:sequence maxOccurs=”unbounded*'>

<xs:element name="exchanged_informabon">

<xs: complexType»

<xs:sequence minOccurs="r maxOccurs="1“>

<xs:element name="information_in">

<xs:complexType>

<xs.attribute name="name" type="xs:string" use="required" form="unqualified" fixed="operating_instruction(plan)7>

</x$: complexType»

</xs:element>

</xssequence> </xs:complexType> </xs: element» <xs:element name-'Resources“>

</xs: element» <xs:element name="Constraints">

</xs: element»

</xs: sequence»

<xs:attnbute name-'name” type="xs:string" use=”required" fixed="getOperatjnglnstnjction" form=" unq u a I ifi ed"/>

<xs:attnbute name-’method"type="xs:string" use=“required“ fixed="Get"form="unqualifie(f7> <xs:attribute name-'status*' type="xs:string" default="optronal"/> </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-T»

<xs:element name=*,information_in">

<x$: complexTу pe>

<xs:attnbute name-'name” type="xs:string" use=”require(Tft>rm="unqualified“ fixed=”rtem’7> </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:attnbute name-'name" type=**xs:string“ use="required" fixed="getltem" form=”unqualified7> <xs: attribute name-'method"type="xs:string" use-'required" fixed="Get" form-'unqualified"/» <xs:attnbute name="status" type=^s:stnng” defautt="mandatory’7>

</xs complexType»

</xs: element»

</xs:sequence>

</xs:complexType>

</xs:element>

<xs element name="List_of_lower_lever>

</xs:element> </xs:sequence> </xs: complexType» </xs: schema»

В.1.3 Пример 3

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

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

<xs:schema xmlns:xs-'http7/wwww3 org/2001/XMLSchema“>

<xs:eiement name=”CapabilityProfiling">

<xs:ccmplexType>

<xs.sequence»

<xs:element name=’’Template">

<xs:complexType>

<xs:attribute name=”id" type=^s:string” use=”requirecf fixed="A337>

<xs:attribute name^name" type-*xs string" use-'required" fixed-’MonitorOperationCondfticn" /> <7ks:complexType>

</xs:element>

<xs:element name="type“>

<xs:complexType> <xs:attnbute name="id“ type-*xs:string7> </xs:compiexType>

</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-'Specrfic" type-'SpecificPartType"/> </xs:sequence>

<xs:attribute name=**date" type="xs:stnng" form=’'unqualrfied'7> </ks:complexType>

</xs: element»

</xs sequence»

</xs:complexType>

</xs:element>

<xs: complexType name-'CommonPartType"»

</xs:complexType>

<xs complexType name-'SpedficPartType"»

<xs:sequence>

<xs element name=“Reference_MDM_Name">

<xs:complexType> <xs:attribute name="domain_NameM type="xs:string" use-'required" fixed-'MESApplicationDomain" form="unqualified7>

</xs: complexType»

</xs element»

<xs:element name="format_name" type="MDD_Description"/>

</xs: sequenc e»

</xs:comp1exType>

<xs: complexType name="MDD_DescnptK>n">

<xs sequence»

<xs: element name= "Set_Of_MDD_Obj ects">

<xs: c.omplexType»

<xs: sequenc e»

<xs:element name=,,actionr>

<xs:complexType>

<xs:sequence maxOccurs-’unbounded*’» <xs:element name-'exchanged_information"> <xs: c.omplexType» <xs:sequence minOccurs=T maxOccurs-T» <xs:element name="information_our>

<xs:complexType>

<xsattribute name="name" type-'xs:string" use-'required" form-'unqualrfied'

fixed="actual_equipment'7>

</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:attnbute name-'name" type="xs:string" use="required" fixed="setActualEquipment7> <xs:attribute name-'method'’ type="xs:string" use="required" fixed="Set7>

<xs:attnbute name-’status" type- xs:stnng" defautt="mandatory’7> </xs complexType» </xs:element>

<xs:element name="actionZ*>

<xs:complexType>

<xs: sequence maxOcc.urs-'unbounded"» <xs:element name="exchanged_informatjon"> <xs:complexType> <xs:sequence minOccurs=T maxOccurs=T> <xs: element name="informationjn"> <xs:complexType>

<xs attribute name="name' types“xs string" use-'reauired" form="unqualified“ fixed-' statef resu It )7>

</xs: complexType»

</xs:element>

</xs: sequenc e» </ks:complexType>

</xs: element»

<xs:element name="Resources">

<Zxs: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:stnng" use="required" fixed="Get" form="unqualified"/> <xs attribute name-' status" type="xs:string" default-'optionar/»

</xs:complexType>

</xs element»

</xs:sequence>

</xs:complexType»

</xs:element>

<xs:element name="List_of_k>werJever'>

<xs:complexType>

<xs:sequence minOccurs=“1" max0ccurs="4">

<xs element name="subactivity_namer>

<xs:complexType>

<xs attribute name- 'id" type- *xs:string" use-' required" fixed-'A331" form="unqualified"> </xs:complexType> </xs:element>

<xs:element name="subtemplate_namer>

<xs:complexType>

<xs:attribute name-’id" type-’xs string" use="required” fixed-'АЗЗГ form=“unqualified,7> </xs: complexType» </xs element»

<xs:element name="subactrvity_name2">

<xs:complexType>

<xs:attribute name-’id” type=”xsstring” use-’required” fixed=“A332" form=”unqualified"/> </xs: complexType» <7xs :element >

<xs:element name="subtemplate_name2">

<xs:complexType>

<xs:attribute name-’id” type-’xs:string" use-’required" fixed-’A332” form="unqualified7> </xs: complexType» </xs element»

<xs element name=’4ijhacfrvity_name3'’>

<xs:complexType>

<xs:attribute name-’id” type-’xs:string" use-’required" fixed-'A333”form="unqualrfied"/> </xs: complexType» </xs element»

<xs:element name="subtemplate_name3">

<xs:complexType>

<xs:attribute name-’id" type-’xs:string" use-’required” fixed-'A333” form="unqualified7> </xs: complexType» </xs: elements

<xs:element name="subactivTty_name4’’>

<xs:complexType>

<xs:attribute name-’id” type-’xs:string" use-’required” fixed-’A334” form="unqualified"/> </xs complexType» </xs: element»

<xs:element name=”subtemplat.e_name4">

<xs.complexType>

<xs:attnbute name-’id” type-’xs:string" use-’required” fixed-'A334” form="unqualrfied"/> <Acs complexType» </xs: element»

</xs:sequence>

</xs: complexType»

</xs:element>

</xs sequence»

</xs:complexType>

</xs:schema>

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

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

Start

Начало

load a bank capability profiling template (*.xsd)

Загрузка заготовки шаблона профилировался возможности

MDD Dictionary of MDM

Словарь объектов MDD для модели MDM

specify the elements or attributes in the blank template using MDDs from the dictionary

Задание элементов (атрибутов) заготовки шаблона, используя объекты MOD из словаря

Modify

Модифицировать

mod ify/a dd/delete

МодифицироватЫдобавить/стереть

Delete

Стирание

load the selected MDDs

Загрузка выбранных объектов MDD

select the MDDs to be deleted

Выбрать объекты MDD для стирания

modify the selected element or attribute

Модифицировать выбранный элемент (атрибут)

add a new element or attnbute

Добавить новый элемент (атрибут)

delete the selected element or attribute

Стереть выбранный элемент (атрибут)

generate a capability profiling template

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

End

Конец

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

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

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

( Start

Start

Начало

Get the particular required template ReqT

Получение требуемого шаблона

For each existing capability template ECT in the data container

Для каждого существующего шаблона возможностей в контейнере данных

For each action ReqOP in ReqT

Для каждой операции (требуемая операция в требуемом шаблоне)

Get one action OP in ECT

Выбрать одну операцию в существующем шаблоне

Compare ReqOP in ReqT with OP in ECT

Сравнить требуемую операцию в требуемом шаблоне с имеющейся операцией в существующем шаблоне

Same?

Одинаковы ли операции?

Yes

Да

по

Нет

Get next action OP in ECT

Перейти к следующей операции в существующем шаблоне

All OP in ECT checked?

Все ли операции существующего шаблона проверены?

Get next action ReqOP in ReqT

Перейти к следующей требуемой операции в требуемом шаблоне

All ReqOP in ReqT checked?

Все ли требуемые операции в требуемом шаблоне проверены?

Generate one ECT matching report

Создание отчета о результатах сопоставления с существующим шаблоном

Get next ECT in the data container

Перейти к следующему существующему шаблону в контейнере данных

All ECT in the data container checked?

Все ли существующие шаблоны в контейнере данных проверены?

Generate al matching reports

Создание отчета о результатах сопоставления

End

Конец

Обозначения на схеме

ЕСТ Существующий шаблон профиля возможностей Req Т Требуемый шаблон

ReqOP Требуемая операция

ОР Операция

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

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

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

С.1 Профиль “getOperationMethod”

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

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

«Capabilityprofiling xmlns:xsi=http://www.w3.org/2001/XHLSchema-instance xsi:noNamespaceSchemaLocation=”D:\

newDB\MonitorOperationCondition.xsd"> «Template id-'A2r name-'getOperat»onl>lethod" /> <t.ype id=”MSU profile” /> «CapabilityProfile*

«pkgtype version="1.1 Г />

<Common>

<MSU_Capabi1 ity >

<ID*getOperationMethod«/lD>

</MSU_Capabi 1 ity >

«ReferenceCapabilityClassStruct.ure id="MESTreeA"/> <Capabilit.y_Class_Name name="get,OperationMethod” /> <Reference_Capability_Class_Structure JMame name-'MESTreeA” /> «/Common* <Specific> <Reference_MDM_Name domain_Name="MESApplicationDomain" t> <format_name>

<Set_Of_MDD_Objects>

<action1 name-'setOperationType" method=”Set' status="mandatory”>

«exchangedjnformabon*

<information_out_in>

<information_out name="operatjonjype7>

< / information_out_in>

</exchanged_information>

«Resources/*

«Constraints/*

«/actionl*

<action2 name-'getOperationMethod" method-'Get" status-'optional "> <exchanged_information> <information_out_in>

«informationjn name-'operation_method(plan)" f> «/informa tion_outjn> </exchanged_information>

«Resources />

«Constraints />

</action2>

<action3 name-'get-Recipe” method=”Gef' status-' optional" > <exchanged_information> <information_out_in>

«informationjn name-'recipe(plan)*’ />

«/informa tion_out_in>

«/exchangedjnformation*

«Resources />

«Constraints f>

</action3>

«/Set_Of_MDD_Objects>

<List_of_lower_level />

</fo rmat_na me*

«/Specific*

«/CapabilityProfile*

«/Capabi 1 ityProfi 1 ing*

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

Ниже приведен пример синтаксиса языка разметки XML для профиля производственной деятельности типа

В11 freceiveManufacturinglnstruction") по ИСО 16100*5 2009, раздел В 3

<‘>xml version^! 0" encoding=”utf-8“ ?>

<Capabi1ityProfi1ing xmlnsxsi =http://www. w3.org/2001/XMLSchema-instance xsrnoNamespaceSchemaLocation^DAnewDBVMonitorOperabonCondrtion.xscr»

«Template id="Bir name="receiveManufacturinglnstnjction" t>

«type id="MSU profile” />

«CapabilityProfile»

«pkgtype version-*1.1. Г />

<Common>

<MSU_Capabi1 i ty>

<ID>receiveManufactunnglnstruction«/ID>

</MSU_Capabi1i ty>

«ReferenceCapabilityClassStructure id- ’MESTreeB" f>

«Capabilit y_Class_Name name-'recerveManufacturinglnstruetion" /> <Reference_Capability_Class_Structure_Name name="MESTreeB" /> </Common>

«Specific»

<Reference_MDM_Name domain_Name="MESApplicationDomain” t>

<format_name>

<Set_Of_MDD_Objects>

«actionl name-'getProductOrder” method-'Get” status-'mandatory”»

«exchangedjnformation»

<information_out_in>

<information_in name="product_order(planf />

</information_outJn> «/exchangedjnformation» «Resources />

«Constraints />

«/actionl»

<action2 name-'getOperatinglnstruction” method-'GeT status=”optionar>

«exchangedjnformation»

<information_out_in>

«informationjn name-’operat.ingjnstructionfplan)" />

</information_outJn>

«/exchangedjnformation»

«Resources />

«Constraints />

</action2>

<action3 name-'get Item" method-'Get” status=” optional”»

«exchangedjnformation» <information_out_in>

«informationjn name="item7>

</information_outJn>

«/exchanged Jnformation» «Resources />

«Constraints />

</action3>

</Set_Of_MDD_Objects>

<Lrst_of_lower_level /»

</format_name>

«/Specific»

«/Capabi 1 fty Profile»

«/Capabi 1 ity Profi 1 ing>

С.3 Профиль NmonitorOperationConditionN

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

<?xml version-’ 1.0" encoding-’ut.f-8" ?> «Capabilityprofiling xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi noNamespaceSchemaLocation="D: \newDB\MonitorOperationCondition.xsd" > «Template id- 'A33~ name="MonitorOperationCondrtionH />

«type id-'MSU profile" !>

<CapabilityProfile> «pkgtype version=H1.1. Г /> <Common> <MSU_Capabi1 i ty> <ID>MSUMoni torOperationCondi tion«/XD>

< / KISU_Capabi1 ity> «ReferenceCapabilityClassStructure id="MESTreeA" /> <Capability_Class_Name name-'MonitorOperationCondition" f> <Reference_Capabilrty_Class_Stnjcture_Name name-’MESTreeA"/> </Common>

«Specifio <Reference_MDM_Name domain_Name- ’MESApplicationDomain" f> <format_name>

<Set_Of_M DD_Objects>

«actioni name="setMonitorCondition" method-’Set" status="mandatory">

  • < exchangedjnformation>

<information_outjn> <information_out name="actual equipmentl" /> «/informa tjon_out_in>

«/exctianged_information>

«Resources /> «Constraints t> </actionl> <action2 name="getMonitorConditjon'' method-'GeC st.atus="opt ional" > <exchangedjnformation> <information_out_in> <infomiation_in name=*'stater f> </inft>rmabon_out_in>

</exciianged_information>

«Resources l> «Constraints l> </action2>

  • < / Set_Of_MDD_Objects> <List_of_k>wer_level> <subac.tivity_namel id="A331" /> <subtemplate_namel id=“A33T'/> <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> </Specific> </CapabilityProfi1e> «/Capabil ityProfil in g>

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

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

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

start

•CCSs

• The formal structure of a CCS


_

Search for a suitable CCS in data container

нпо one?

Modify?

yes

For each node to be modified



К

Load a blank CCS based on the formal structure

4

Specify the nodes needed according to the application on the blank CCS

2


Select a suitable capability template from the data container


  • • Capability templates

  • • Formal structure of capability template


Finished?

Obtain a particular application-oriented CCS


For each node to be added

-4

  • • Select a suitable capability template from the data container, or

  • • Generate a particular capability template based on blank template

I



start

Начало

Seach for a suitable CCS in data container

Поиск необходимой структуры в контейнере данных

-CCSs

♦ The formal structure of a CCS

  • - структуры CCS

  • - формальная структура CCS

Find one?

Удалось ли найти?

yes

Да

no

Нет

Load a blank CCS based on the formal structure

Загрузка заготовки CCS. основанной на использовании формальной структуры

Modify?

Модифицировать7

Specify the nodes needed according to the application on the blank CCS

Указание узлов, соответствующих приложению заготовки CCS

For each node to be modified

Для каждого модифицируемого узла

Select a suitable capability template from the data container

Выбор подходящего шаблона возможностей из контейнера данных

- Capabikty templates

• Formal structure of capability template

  • - шаблоны возможностей

  • - формальная структура шаблона возможностей

For each node to be added

Для каждого добавляемого узла

* Select a suitable capability template from the data container, or - Generate a particular capaMrty template based on blank template

  • * выбор подходящего шаблона возможностей из котейнера данных

  • * создание особого шаблона возможностей на основе заготовки

Finished?

Закончить работу?

Obtain a particular application-oriented CCS

Получение особой структуры CCS для рассматриваемого приложения

end

Конец

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

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

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

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

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

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

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

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

PLIB dictionary

0

п

Se/v/ce Interface

Data definition provider

Data definition register


ACCS XI ' • 7


S X (MDM X) Ч х***- " *


MDDs

ч...


CCSX2


PLIB dictionary

Библиотека деталей

Service Interface

Интерфейс услуг

Data definition provider

Поставщик определений данных

Data definition register

Реестр определений данных

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

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

identifiers to be matched

PLIB dictionary

Словарь деталей

Properties

Свойства

Preferred name = Repeat time

Предпочтительное имя = время повторения

Name - Iteration

Имя - Итерация

Name = Count

Имя = Счет

Provide definition

Получение определения

Identifiers to be matched

Сопоставляемые идентификаторы

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

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

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

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

<?xml version=* 1.0" encoding- 'UTF-8"?>

<xs : schema xmlns :xs="http: //wwww3.оra/2001 /ХМLSchema">

<xs:element name-'MDD">

<xs:complexType>

<xs:sequence>

<xs:element name-’MDD_Name">

<xs:complexType>

<xs:attribute name-’name" type='*xs: string" form="process ordef/>

<xs:attribute name="DICTIOIS!ARY_ID" type= "xs: string" form=" 9999/IS016100-XXX"/>

<xs:attnoute name="PARENT" type- xs:string" ronrF"Fl6l00002E’7> <xs:attnbute name-’BSU" type="xs:stnng" form="F16100001C7> <xs attribute name="PREFERRED_NAME" language="en" type="xs:string" form="process order7>

<xs attribute name-VERSION" type='*xs string" form="001"/> <xs:attribute name-’REVISION" type-*xs:string" form=,,00r /> </xs:complexType>

</xs:element>

<xs: element name= "Reference_MDM_Name">

<xs:complexType> <xs:attribute name-’name" type=”xs:string” form="unqualified'7> </xs:complexType> </xs:element>

<xs:element name=’’List_Of_Attributes">

<xs:complexType>

<xs:sequence minOccurs- '0" maxOccurs-'unboundecf'»

<xs:element name-'Attribute*'»

<xs:complexType>

<xs:sequence>

<xsetement narne='*Attribute_Narr>e“>

<xs: complexType» <xs:attnbute name-'name" type="xs:stnng" fofm=*'Source"/>

<xs:attribute name-'DICTIONARYJD" type="xs:string" form="9999fl SO16100-XXX"/»

<xs:attribute name-'PARENT” type="xs: string” form="F161000017>

<xs:attribute name-'BSU" type="xs: string" form="A1610000017»

<xs attribute name="PREFERRED_NAME" language="en" type-’xs string" fnrm="Snume"/>

<xs:attribute name-'PREFERRED_NAME“ language="ja“ type=**xs:string" form-'Japanese-Source-Name"/»

<xs:attnbute name- "VERSION" type-*xs:stnng" form="001" />

<xs:attribute name-'REVISION" type="xs:string" form="001" />

</xs:complexTypes

</xs:element>

<xs:element name="Attribute_Type'*>

<xs:complexType>

<xs: attribute name-type" type="xs string" form="unqualified7>

</xs:complexTypes

</xs:etement»

</xs:sequence>

<xs.attribute name-'id” type-'xs string" fom>="unqualtfied7> </xs:complexType>

</xs element»

<xs:element name-‘Attribute’*»

<xs:complexType>

<xs:sequence>

<xs:element name="Attnbute_Name">

<xs: complexType»

<xs:attribute name="name" type="xs string” form="Dest>nation7>

<xs:attribute name="DICTIONARY_lD" type="xs:string” form="9999/l S016100-ХХХ7»

<xs:attribute name="PARENT" type="xs:string" form="F161000017>

<xs: attribute name=“BSU" type="xs string" form="A1610000027»

<xs:attribute name=”PREFERRED_NAME“ language="en" type-*xs:string'* form-*Destination7>

<xs attribute name="PR.EFERRED_NAME" language= ** ja type='*xs string" form="Japanese-Destination-Name7>

<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-’xsstring" form=" u nq ua I ifi ed7>

</xs: complexType»


</xs:elements

</xs:sequences

<xs:attribute name="id" type-'xsstring" form="unqualifiecT/> </xs:complexType>

</xs: element»

</xs:sequence>

</xs: complexType>

</xs: element»

</xs:sequence>

</xs:complexType>

</xs: element»

</xs:schema>

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

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

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

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

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

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

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

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

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


NATO Codificatior .System


MDM Owner X


web service interface


«Data search provider

• Data mapping provider



web service interface


MDDs in

provide

MDM Owner Y

gesx^


  • • Data definiti provider

  • • Data definition register


MDDs in IGX


• Data search



Industry Associations

NATO Codification System

Система кодификации НАТО

Bridge

Мост

MDM Owner X

Собственник модели X

MDDs in IG X

Объекты данных MDD в справочнике идентификаторов X

web service interface

Интерфейс сетевых услуг

Data search provider

Провайдер поиска данных

Data mapping provider

Провайдер отображения данных

Data definition provider

Поставщик определений данных

Data definition register

Реестр определений данных

OTD

Открытый технический словарь

Industry Associations

Промышленные ассоциации

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

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

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

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

MDD #A1 in MDM п

Item

Identifier = 0161-1-01-014159 Preferred name = EYE BOLT Link URL = http://www.AAA/ XX_Dic

Link URL = http://www.BBB/ YY_Dic


Provide OTD item information


Name - bolt

from URL = http://www.AAA/ <-XXDic

Identifier = 0161-1-014)14159 Preferred name = EYE BOLT


MDD#B1 in MDM n


Name = screw bolt

Link URL = http://www.BBB/ < -YY_Dic

identifier 0161-1-01-014159 <-

Preferred name = EYE BOLT


Defined originally in XX Die


Identifers to be matched


Defined originally in YY Die


*

OTD

Открытый технический словарь

Item

Изделие

Identifier

Идентификатор

Preferred name = EYE BOLT

Предпочтительное имя = рым-болт

Link URL =

Рабочий язык ресурса -

MDD#A1 in MDM n

Объект MOD класса А1 в модели МОМ

Name = bolt

Имя = болт

Provide OTD item information

Доставляет информацию об изделии из словаря ОТО

from URL

На языке ресурса

Name = screw bolt

Имя = болт с головкой

Defined originally in XX Die

Изначально определен в словаре XX

XX Dic

Словарь XX

Identifiers to be matched

Сопоставляемые идентификаторы

Defined originally in YY Dic

Изначально определен в словаре YY

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

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

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

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

<?xml version-'1 СТ encoding="UTF-B"?>

<xs:schcma xmlns:xo“”http://www.w3.org/2001/XMLSchcma’’> <xs:element name=”MDD'’>

<xs:complexType>

<xs sequence>

<xs:element name="MDD_Name">

<xs:complexType>

<xs:attnbute name-’name" type-*xs:stnng" form=“qualifiecT fixed-'process operation‘7>

<xsrattribute name-'Globalltemldentrfier type=“xs:string“ form=“qualified“ fixed="process_MDM_IGxxx7>

<xs:attribute name-'GloballtemCategory- type="xs:string- form=MqualifiecT fixed-' process_MDM_IGxxx "/>

<xs:attribute name-'Trtie" type="xs:string" form=-qualified" fixed="process_MDM IGxxx "/>

<xsrattribute name-'Definition- type=“xs:stnng- form="qualified" fixed=“process_MDM IGxxx “/>

<xs:attribute name-'DateAdded" type="xs:string" form=”qualified" fixed="process_MDM_lGxxx 7>

<xs:attribute name-’SecretariatReference’’ type=“xs:string" form="qualified" fixed-’process_MDM_IGxxx7> </xs:complexType> </xs:element> <xs element name-‘Reference_MDM_Name“> <xs:complexType>

<xs:attribute name-’name" type- *xs:string" form="unqualified"/> </xs:complexType>

</xs:element>

<x$:element name-‘List_Of_Attributes">

<xs:complexType>” <xs:sequence minOccurs-'O" maxOccurs-'unbounded”* <xs:element name-'Attribute"*

<xs:complexType> <xs:sequence> <xs:element name="Attribute_Name">

<xs: complexType*

<xs: attribute name=“AttributeTitle” typers: string" form=”qualified" fixed=" process_MDM_IGxxx 7>

<xs:attnbute name="AttributeDefinition’’ type="xs:stnnq" form="qualified“ fixed=" process_MDM IGxxx"/> </xs:complexType> </xs element* <xs:element name="Attribute_Type"> <xs:complexType> <xs:attribute name-’GlobalAttributeCategory" type="xs:string" form=‘'qualrfied" nxed="process_MDM_IGxxx"/>

<xs: attribute name-’AttributeDateAdded" type="xs: string" form="qualrfied" fixed-'process MDM_IGxxx”/>

<xs:attribute name-’AttnbuteSecretariatReTerence" type='xs:string' form='qualified" fixed=" process_HDM_IGxxx”/* </xs:complexType> </xs: element* </xs:sequence> <xs attribute name-’GlobalAttributeXdentifier” type="xs:strinq" form="qualified" fixed="process_MDM_IGxxx"/> </xs:complexType> </xs:element> </xs sequence* </xs:complexType> </xs:element> </xs sequence* </xs:complexType> </xsielement> </xs:schema>

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

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

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

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

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

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

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

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

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

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

На рисунке G.1 имеются контуры двух видов наружный контур и внутренний контур. В наружном контуре, контур В используется для сравнения операций в соответствии с установленным порядком требуемого профиля. Порядок установлен для объектов, упорядоченных по времени 'Time_Order_Of_MDD_objecf, и объектов, расположенных в порядке поступления “Event_Order_Of_MDD_objecf Элементы «производственной деятельности» упорядочены по времени для объектов <Time_Order_Of_MDD_objects» описания «MDD_Description» Аналогично. элементы «производственной деятельности» упорядочены в порядке поступления для объектов «Event_ Order_Of_MDD_object» описания <MDD__Description». Сравнение элементов «производственной деятельности» выполяется строго в установленном порядке. Исключением являются объекты «Set_Of_MDD_objects». где каждый элемент производственной деятельности в требуемом профиле последовательно сравнивается со всеми элементами производственной деятельности в профиле MSU до достижения желаемого результата.

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

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

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

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

См. ниже продолжение

start

Начало

Step 1

Шаг 1

extract the frst «action» element in the action list from the

Извлечь а отдельности зле мент первой операции списка

required profile and the first «action» element in the action list

операций из требуемого профиля и элемент первой операции

from the MSU profile separately

списка операций из профиля MSU

Obtain elements?

Получены ли элементы?

no

Нет

yes

Да

Compare

Сравнить

- name;

- имя

- method;

- метод

• status

• статус

Compare the two «action» elements

Сравнение элементов двух операций

Same actions?

Одинаковы ли операции?

Step 2

Шаг 2

Extract one «exchanged information» element from the required profile and an MSU profile in the actions separately

Извлечь в отдельности в каждой операции один элемент «обмена информации» из требуемого профиля и один элемент «обмена информации» из профиля MSU

Compare.

Сравнить

- in or out;

- ВХОД или выход

- name

- имя

Compare the two «exchanged_information» elements

Сравнение указанных выше двух элементов «обмена информации»

Same elements?

Одинаковы ли эти элементы?

Extract the next «exchanged information» element from the

Извлечь в отдельности в каждой операции следующий

required profile and from an MSU profile in the actions separately

элемент «обмена информафш» из требуемого профиля и один элемент «обмена информации» из профиля MSU

More elements?

Рассматривать ли другие элементы?

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

Step 3



См ниже продолжение

Step3

ШагЗ

Extract one «Constraints» element from the requred profile and an MSU profile in the actions separately

Извлечь в отдельности для каждой операции элемент «ограничения» из требуемого профиля и один соответствующий элемент из профиля MSU

Compare: - name

Сравнить. * имя

Compare the two «constraints» elements

Сравнение указанных двух элементов «ограничения»

Same elements?

Одинаковы ли эти элементы?

Extract separately next «constraints» element from the required profile and an MSU profile in the actions

Извлечь в отдельности для каждой операции следующие элементы «ограничения» из требуемого профиля и элементы из профиля MSU

Obtain constraints'7

Получены ли ограничения'7

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

Slap 4

Шаг 4

Extract separately one «resources» element from the required profile and an MSU profile in the actions

Извлечь в отдельности для каждой операции элемент «ресурсы» из требуемого профиля и элемент «ресурсы» из профиля MSU

Compare:

♦ name

Сравнить

• имя

Compare the two «resources» elements

Сравнение двух указанных элементов «ресурсы»

Same elements?

Одинаковы ли элементы?

Extract separately next «resources* element from the requred profile and an MSU profile in the actions

Извлечь в отдельности для каждой операции следующий элемент «ресурсы» из требуемого профиля и соответствующий элемент из профиля MSU

More resources?

Рассматривать ли ресурсы далее?

All actions compared?

Все ли операции прошли сравнение?

yes matched

Сопоставление закончено

End

Конец

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

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

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

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

Таблица ДА 1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

ИСО 16100-1

IDT

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

ИСО 1G100-2

IDT

ГОСТ Р ИСО 1С100-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 - идентичные стандарты.

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

(1)ИСО/МЭК 11179-5:2005

Информационные технологии. Реестры метаданных (MDR). Часть 5. Принципы присвоения имен и идентификации

(ISO/IEC 11179-5:2005)

(Information technology - Metadata registries (MDR) — Part 5: Naming and identification principles)

[2] ИСО 13584-24:2003

Системы промышленной автоматизации и интеграция. Библиотека данных на детали. Часть 24. Логический ресурс. Логическая модель библиотеки поставщика

(ISO 13584-24:2003)

(Industrial automation systems and integration - Parts library - Part 24: Logical resource: Logical model of supplier library)

[31 ИСО 13584-26:2000

Системы промышленной автоматизации и интеграция. Библиотека данных на детали. Часть 26. Логический ресурс: идентификация поставщика информации

(ISO 13584-26:2000)

(Industrial automation systems and integration - Parts library - Part 26: Logical resource: Information supplier identification)

[4] ИСО 13584-42:2010

Системы промышленной автоматизации и интеграция. Библиотека данных на детали. Часть 42. Методология описания: методология структурирования групп деталей

(ISO 13584-42:2010)

(Industrial automation systems and integration - Parts library - Part 42: Description methodology: Methodology for structuring parts families)

[5] ИСО 15745-1:2003

Системы промышленной автоматизации и интеграция. Прикладная среда интегрирования открытых систем. Часть 1. Общее эталонное описание

(ISO 15745-1:2003)

(Industrial automation systems and integration - Open systems application integration framework - Part 1: Generic reference description)

[6] ИСО/МЭК 19501:2005

Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 14 9

(ISO/IEC 19501:2005)

(Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2)

[7] ИСО 22745-1:2010

Промышленные автоматизированные системы и интеграция. Открытые технические словари и их применение к основным данным. Часть 1. Обзор и основные принципы

(ISO 22745-1:2010)

(Industrial automation systems and integration -Open technical dictionaries and their application to master data - Part 1: Overview and fundamental principles)

[8] ИСО 22745-2:2010

Промышленные автоматизированные системы и интеграция. Открытые технические словари и их применение к основным данным. Часть 2. Словарь

(ISO 22745-2:2010)

(Industrial automation systems and integration -Open technical dictionaries and their application to master data - Part 2: Vocabulary)

[9] ИСО 22745-13:2010

Промышленные автоматизированные системы и интеграция. Открытые технические словари и их применение к основным данным. Часть 13. Идентификация понятий и терминологии

(ISO 22745-13:2010)

(Industrial automation systems and integration -Open technical dictionaries and their application to master data - Part 13: Identification of concepts and terminology)

[10] ИСОЯС 22745-35:2010

Промышленные автоматизированные системы и интеграция. Открытые технические словари и их применение к основным данным. Часть 35. Запрос характеристических данных

(ISOHS 22745-35:2010)

(Industrial automation systems and integration - Open technical dictionaries and their application to master data - Part 35: Query for characteristic data)

[11] ИСО/ТС 29002-5:2009

Промышленные автоматические системы и интеграция. Обмен характеристическими данными. Часть 5. Схема идентификации (Industrial automation systems and integration - Exchange of characteristic

(ISOaS 29002-5:2009)

data - Part 5: Identification scheme)

[12] RFC 2276. Architectural Principles of Uniform Resource Name Resolution. IETF (Internet Engineering Task Force), ed. K. Soilins. 1998

УДК 658.52.011.56:006.354 ОКС 25.040.01 Т58

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

Редактор В.М. Никифорова Технический редактор А Б Заварзина Корректор В.Г. Смолин Компьютерная верстка Д Е. Першин

Сдано в набор 24 09 2015 Подписано в печать 8.10.2015. Формат 60x841/8. Гарнитура Ариал. Усп. леч. л. 8.84 Уч-изд л. 8.00. Тираж 30 экз Зак. 3416.

Набрано 8 ООО «Академиздат». www.academizdat.com lenin@academizdat.ru

Издано и отпечатано во

, 123995 Москва. Гранатный пер., 4.

info@gostjnfo.ru