ГОСТ Р МЭК 62264-5-2012

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

ИНТЕГРАЦИЯ СИСТЕМ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ

Часть 5

Операции "бизнес-производство"

Enterprise-control system integration. Part 5. Business to manufacturing transactions

ОКС 25.040.99
         35.100     

         35.200

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

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту МЭК 62264-5:2011* "Интеграция систем управления предприятием. Часть 5. Операции "бизнес-производство" (IEC 62264-5:2011 "Enterprise-control system integration - Part 5: Business to manufacturing transactions", IDT).

________________

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

           

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

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

6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.

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

Введение

Настоящий стандарт основан на использовании абстрактной модели комплекса международных стандартов МЭК 62264, первоначально установленной в частях МЭК 62264-1 и МЭК 62264-2 и объединенной со служебным словарем операций для определения транзакционной модели с целью информационного обмена. Настоящий стандарт не ограничивает использование транзакционных моделей/протоколов, основанных на стандартах, отличных от МЭК 62264, и не признает их недействительными. Транзакции происходят на всех уровнях функционирования предприятия, а также между предприятиями-партнерами и относятся как к обязательным, так и к фактическим операциям. Но основное внимание в настоящем стандарте уделяется интерфейсу между коммерческими и промышленными системами.

Настоящий стандарт определяет комплекс транзакций "бизнес-производство" и "производство-бизнес", которые применяются для объектов, используемых в процессе обмена между Уровнем 4 и Уровнем 3, как определено объектной моделью МЭК 62264-1 и МЭК 62264-2. Информация о моделях также представлена в настоящем стандарте, что позволяет более явным образом описать транзакции и предоставить дополнительную информацию о требуемом порядке обработки транзакций.

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

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

Настоящий стандарт устанавливает групповые операции (транзакции) в терминах обмена информацией между приложениями, выполняющими рыночные и производственные действия, ассоциированные с Уровнями 3 и 4. Обмен информацией обеспечивают операции сбора информации, ее считывания, передачи и хранения для поддержки интеграции системы управления предприятием. Настоящий стандарт соответствует моделям и терминологии, установленным в МЭК 62264-1, а также атрибутам объектов моделей, установленных в МЭК 62264-2. Настоящий стандарт также определяет транзакции, устанавливающие порядок обмена объектами, определенными в МЭК 62264-1, МЭК 62264-2 и в настоящем стандарте. Другие применения моделей транзакций в настоящем стандарте не рассматриваются.

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

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

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

           

IEC 62264-1:2003, Enterprise-control system integration - Part 1: Models and terminology (Интеграция системы управления предприятием. Часть 1. Модели и терминология)

________________

Заменен на IEC 62264-1:2013.

IEC 62264-2:2004, Enterprise-control system integration - Part 2: Object model attributes (Интеграция системы управления предприятием. Часть 2. Атрибуты модели объекта)

________________

Заменен на IEC 62264-2:2013.

IEC 62264-3:2007, Enterprise-control system integration - Part 3: Activity models of manufacturing operations management (Интеграция системы управления предприятием. Часть 3. Модели действий руководства производственными операциями)

________________

Заменен на IEC 62264-3:2016.

           

     3 Термины, определения и аббревиатуры

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

В настоящем стандарте применены термины и определения, приведенные в МЭК 62264-1, МЭК 62264-2 и МЭК 62264-3. В ряде случаев в настоящем стандарте в определения внесены очевидные изменения.

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

3.1.2 идентификатор ID (identifier ID): Информация, необходимая для идентификации объекта или его свойства.

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

3.1.4 объект (существительное) именная конструкция (noun): Одна из двух частей содержимого сообщения, определяющая один или несколько объектов в соответствии с моделями объектов МЭК 62264-1 и МЭК 62264-2.

3.1.5 транзакция, групповая операция (transaction): Последовательность связанных сообщений, которыми обмениваются приложения, выполняющие действия Уровня 3 и Уровня 4.

3.1.6 действие; глагол (verb): Одна из двух частей содержимого сообщения, определяющая выполняемое действие или ответ на запрос.

3.1.7 шаблон (метасимвол) (wildcard): Информация, идентифицирующая набор объектов или свойства ряда объектов.

     3.2 Аббревиатуры
     

OAGIS - Стандарт на интерфейс группы открытых приложений (Open Applications Group Interface Standard);

SYNC - Синхронизированные данные (Synchronized data).

     4 Сообщения и действия транзакций

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

Данный раздел определяет общий набор групповых операций (транзакций), сообщений и действий, используемых между приложениями Уровня 4 и Уровня 3 при обмене данными, определенными в моделях объектов МЭК 62264-1 (раздел 7) и МЭК 62264-2.

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

Сообщения должны содержать как область действия, так и область объекта. Информация, передаваемая сообщением, должна содержаться в области объекта сообщения. Действия, ассоциированные с информацией, должны быть описаны в области действия.

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

Существуют три различные модели транзакций.

a) Модель "PULL (извлечение информации по запросу)" используется, когда пользователь данных запрашивает эти данные у провайдера данных.

b) Модель "PUSH (подача запроса, т.е. принудительная доставка данных)" используется, когда провайдер данных запрашивает действие (обработка, изменение или завершение) с данными у другого пользователя.

c) Модель "PUBLISH (публикация)" используется, когда собственник данных публикует их для пользователей (подписчиков) данных.

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

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

     4.2 Модели транзакций
     

Существуют три класса действий: составление ответа на запрос, выполнение транзакции и синхронизация данных. Эти классы определяют три различных модели транзакций.

a) Модель "PULL" применяется, когда пользователь данных запрашивает информацию у провайдера информации.

Данная модель используется для составления ответа на запрос.

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

Приложения пользователя информации отправляют сообщения GET.

1) Запросы на информацию отправляются с помощью сообщений GET.

2) Сообщение GET описывает область применения запрашиваемой информации.

3) Сообщение SHOW возвращает информацию.

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

Приложения получателя фиксируют сообщения PROCESS (обработка), CHANGE (изменение) или CANCEL (отмена).

Приложения отправителя направляют сообщения PROCESS, CHANGE и CANCEL.

1) Новая информация доставляется получателю с помощью сообщений PROCESS. Ответы могут быть возвращены отправителю через сообщение ACKNOWLEDGE (подтверждение приема).

2) Изменения информации направляются получателю с помощью сообщений CHANGE. Ответы могут быть возвращены отправителю через сообщение RESPOND (ответ).

3) Уведомление об удалении информации направляется получателю сообщением CANCEL.

c) Модель "PUBLISH" используется, когда провайдер данных публикует их для пользователей (подписчиков) данных. Эта модель используется для синхронизации данных.

Приложения подписчика получают сообщения SYNC.

Приложения издателя отправляют сообщения SYNC.

1) Издатель отправляет сообщения SYNC, содержащие новую, измененную или удаленную информацию, подписчику.

2) Подписчик получает сообщения SYNC, содержащие новую, измененную или удаленную информацию.

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

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

1) путем задания параметров конфигурации в приложении;

2) динамически через сетевые соглашения;

3) с помощью некоторого приложения третьей стороны.

Одно приложение может поддерживать одну или несколько моделей транзакций. Рассматриваемое приложение может играть несколько ролей (отправителя, получателя, провайдера и пользователя).

Примечание 1 - Транзакции основаны на допущении, что обмениваемая информация (объект) содержится в сообщении некоторой формы. Точная форма такого сообщения в настоящем стандарте не определяется. Например, сообщения могут быть файлами с разделителями табуляции, файлами в формате XML, сообщениями электронной почты или данными в именованном канале. Точная форма механизма транспортировки, предназначенного для отправки, получения, прослушивания и публикации сообщений, в настоящем стандарте не определяется.

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

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

Рисунок 1 иллюстрирует обмен сообщениями при транзакции, когда сообщение отправляется от пользователя информации с идентификацией объекта (оборудование GET) и когда сообщение возвращается от провайдера информации с информацией об объекте (оборудование SHOW).

     
Рисунок 1 - Типовой обмен сообщениями в групповой операции

     4.3 Структура сообщений
     

4.3.1 Общая структура

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

     
Рисунок 2 - Типовой обмениваемый набор данных

4.3.2 Область идентификации приложения

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

Примечание - См. спецификацию OAGIS 9.0 (спецификация интеграции открытой группы приложений) для формата области идентификации приложения. Модель обмена данными, определенная в настоящем стандарте, соответствует спецификации OAGIS. Поэтому практическая реализация OAGIS, использующая объекты МЭК 62264-1 и МЭК 62264-2, может соответствовать настоящему стандарту.

          

     
Рисунок 3 - Типовой расклад области идентификации приложения

Дата и время должны включать информацию о временном поясе для однозначной идентификации времени. Например, можно использовать координатное универсальное время или расширенный календарный формат ИСО 8601.

4.3.3 Область данных

Область данных в сообщении должна содержать область действия и область объекта.

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

Область объекта содержит один или несколько объектов и ассоциированных элементов. Каждый объект представляет один или несколько объектов в соответствии с моделями объектов, определенными в МЭК 62264-1 и МЭК 62264-2. Объекты, определенные в настоящем стандарте, перечислены в разделе 6.

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

4.3.4 Объекты сообщения

Объекты представляют собой одну или несколько реализаций объектов для моделей объектов, определенных в МЭК 62264-1 и МЭК 62264-2. Данные модели группируются для использования вместе с сообщениями.

Пример - Объект Определение материала - это объединение реализации Определения материала и Свойств определения материала.

4.3.5 Групповой символ

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

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

Примечание 2 - Групповые символы должны использоваться осторожно при соединении с перечнем идентификаторов объектов или идентификаторов свойств. В случае ошибки сообщение о подтверждении может не содержать достаточной информации для установления причины ошибки.

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

a) "*" - указывает нуль или несколько символов, любые символы приемлемы.

Пример 1 - Групповой символ "ABC" согласуется с "ABC", "ABCD", "ABCDEF", "ABC@4!*", но не согласуется с "ABDDEF";

b) "%" - указывает один или несколько символов, любые символы приемлемы.

Пример 2 - Групповой символ "ABC%" согласуется с "ABCD", "ABCDEF", "ABCЛ4Л*\, но не согласуется с "ABC";

с) "?" - указывает нуль или один символ в заданной позиции, любые символы приемлемы.

Пример 3 - Групповой символ "ABC?" согласуется с "АВСХ", "ABCD", "ABC!", "ABC", но не согласуется с "ABCDE" или "ABDC";

d) символ, идущий за "\", - это буквенный символ, а не групповой.

Пример 4 - Идентификатор объекта "ABC" задает идентификатор как "ABC*".

Пример 5 - Идентификатор свойства "\\\\USM 123*" определяет идентификатор свойства как "\\USM 123".

Примечание 4 - Два последовательных обратных символа "\\" интерпретируются как один обратный символ "\".

Рисунок 4 иллюстрирует транзакцию GET/SHOW с установленным групповым символом. Провайдер информации возвращает перечень объектов, согласованный со спецификацией групповых символов.    

     
Рисунок 4 - GET с групповым символом и ответ SHOW

     5 Действия сообщений

     5.1 Действия и модели транзакций
     

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

Таблица 1 - Определенные действия

     
     

     5.2 Действие GET
     

Действие GET используется в сообщении GET. Оно обеспечивает запрос информации об объекте или о перечне объектов.

Ответом на сообщение GET является сообщение SHOW.

     
Рисунок 5 - Транзакция, включающая действия GET и SHOW

Действие GET извлекает один или несколько объектов и каких-либо содержащихся объектов с помощью атрибутов идентификаторов.

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

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

Пример - Действие GET может извлекать сразу несколько объектов, например все из классов персонала.

Примечание - Действие GET с групповым символом имеет очень ограниченную производительность обработки запросов. Групповые операции не предназначены для обеспечения достаточной производительности при составлении отчета на запрос в соответствии с нормальными требованиями базы данных. Если требуется повысить производительность обработки запросов, то групповая операция GET/SHOW может быть использована для создания копий всех данных. Затем эти копии запросов могут быть обработаны локально.

     5.3 Действие SHOW
     

Действие SHOW используется в сообщении SHOW для ответа на сообщение GET.

Рисунок 6 иллюстрирует транзакцию с сообщением GET и последующими сообщениями SHOW и CONFIRM (опция "Confirm Always (подтверждать всегда)" указана в примере с сообщением GET).

     
Рисунок 6 - Транзакции GET и SHOW с опцией "CONFIRM Always"

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

     5.4 Действие PROCESS
     

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

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

Пример 1 - Отправление сообщения PROCESS для Графика производства на сайт указывает, что данный график должен быть обработан.

Пример 2 - Отправление сообщения PROCESS для Оборудования указывает, что новый элемент оборудования должен быть добавлен.

Область действия PROCESS содержит элементы для выбора с одним из дополнительных определений: Never (никогда) или Always (всегда) (таблица 2). Если элемент для выбора не указан, то по умолчанию всегда берется Never.

Таблица 2 - Опции запроса с получением подтверждения о получении

     
     

     5.5 Действие ACKNOWLEDGE
     

Действие ACKNOWLEDGE используется в сообщении ACKNOWLEDGE для подтверждения получения приложением запроса PROCESS. Ответом на сообщение PROCESS является сообщение ACKNOWLEDGE. Сообщение ACKNOWLEDGE может возвращать исходные или модифицированные данные. Рисунок 7 иллюстрирует сообщение PROCESS с ответным сообщением ACKNOWLEDGE.

     
Рисунок 7 - Транзакция PROCESS/ACKNOWLEDGE

Пример - Отправление сообщения ACKNOWLEDGE для Графика производства, когда сообщение PROCESS для Графика производства получено, соответствующее приложение со стороны рынка подтверждает получение Графика производства и его приемку.

Область действия ACKNOWLEDGE содержит элемент с одним из нижеследующих дополнительных определений: Accepted (принято), Rejected (отклонено) или Modified (модифицировано) (таблица 3).

Таблица 3 - Элементы действия Acknowledge

           

Пример - Рисунок 8 показывает последовательность сообщений, идущих от планирующей системы к исполнительной системе. Исходное сообщение PROCESS с графиком производства получено, и сообщение ACKNOWLEDGE с флажком MODIFIED возвращено с новым предлагаемым графиком. Планирующая система пересматривает график и повторно отправляет его исполнительной системе. Исполнительная система принимает график производства и возвращает сообщение ACKNOWLEDGE с флагом ACCEPTED.

     
Рисунок 8 - Пример действия ACKNOWLEDGE на запрос о переработке

     5.6 Действие CHANGE
     

Действие CHANGE используется в сообщении CHANGE, если отправитель сообщения отправляет запрос на изменение данных. Область объекта содержит новые данные. Рисунок 9 иллюстрирует сообщения CHANGE и RESPOND.

     
Рисунок 9 - Транзакция CHANGE/RESPOND

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

Область действия CHANGE содержит элемент для выбора с одним из нижеследующих дополнительных определений: Never (никогда) или Always (всегда) (таблица 4). Если элемент для выбора не установлен, то по умолчанию принимается Never.

Таблица 4 - Опции действия Respond

     
     

     5.7 Действие CANCEL
     

Действие CANCEL используется в сообщении CANCEL, если отправитель сообщения CANCEL отправляет запрос на отмену данных (рисунок 10).

     
Рисунок 10 - Сообщение CANCEL

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

Примечание - Так как сообщение CANCEL не отправляется собственником данных, то эти данные не обязательно удаляются. Отправитель только указывает, что ему эти данные больше не нужны.

     5.8 Действие CONFIRM
     

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

     
Рисунок 11 - Пример сообщения GET с подтверждением при наличии ошибки

Примечание - Порядок поступления сообщения CONFIRM (или какого-либо другого ответного сообщения) в настоящем стандарте не определяется.

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

Запрос на подтверждение, указанный в области идентификации приложения, приобретает значения, определенные в таблице 5.

Таблица 5 - Опции запроса на подтверждение

           

Сообщение CONFIRM:

a) идентифицирует подтверждаемое инициирующее сообщение;

b) указывает статус переработки сообщения;

c) включает описание ошибки, если статус указывает на ошибку при обработке.

Если ошибка возникает при обработке инициирующего сообщения получающим приложением и отправитель устанавливает атрибут подтверждения на OnError или на Always, то получающее приложение должно создать сообщение CONFIRM. Если опция подтверждения не установлена, то значением по умолчанию будет Confirm Never.

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

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

Дополнительное описание ошибок, кода или текста, ассоциированного с объектами в области объекта (существительного), может содержаться в указанной области (см. Область идентификации приложения) в соответствии с рисунком 12.

     
Рисунок 12 - Сообщение Confirm

     5.9 Действие RESPOND
     

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

Область действия RESPOND содержит элемент с одним из нижеследующих дополнительных определений: Accepted (принято), Rejected (отклонено) или Modified (модифицировано) (таблица 6).

Таблица 6 - Элементы действия Respond

     
     

     5.10 Действие SYNC
     

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

Примечание 1 - Действие SYNC необходимо для синхронизации данных. Оно подразумевает использование синхронизированных или выровненных данных. Оно не рассматривает синхронные связи.

Примечание 2 - Должно быть только одно приложение, отправляющее сообщения SYNC для каких-либо специальных элементов информации.

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

Сообщение SYNC отправляет собственник информации.

Сообщение SYNC должно содержать в области действия один из нижеследующих модификаторов: ADD (добавить), CHANGE (изменить) или DELETE (удалить).

Пример 2 - Данное действие обычно используется, если необходимы большие изменения. Например, если система планирования ресурсами предприятия (ERP; Enterprise Resource Planning) публикует главный элемент нескольких систем управления производством (MES; Manufacturing Execution System) или если механизмы публикации и подписки используются в качестве архитектуры интеграции компании.

     5.11 Действие SYNC ADD
     

Действие SYNC ADD отправляется собственником информации. Оно указывает, что собственник добавил новую информацию, как показано на рисунке 13. Сообщение SYNC ADD включает добавленные реализации объекта и значения всех атрибутов данных объектов. Добавляемые специальные элементы определены в разделе 6.

     
Рисунок 13 - Транзакция SYNC ADD с подтверждением

Пример - Сообщение SYNC ADD (по спецификации результатов проверки качества объекта) указывает на определение новой спецификации этих результатов.

     5.12 Действие SYNC CHANGE
     

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

Пример - Сообщение SYNC CHANGE (с объектом класса материалов) указывает на изменение в классе материалов, на свойство класса материалов, а также на новое значение.

     5.13 Действие SYNC DELETE
     

Действие SYNC DELETE направляется собственником информации. Оно указывает, что провайдер информации удалил информацию, как показано на рисунке 14. Сообщение SYNC DELETE включает удаленные реализации объекта. Специальные удаляемые элементы определены в разделе 6.

     
Рисунок 14 - Транзакция SYNC DELETE без подтверждения

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

     6 Объекты сообщения

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

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

     6.2 Определение содержания сообщения
     

6.2.1 Сервисный профиль транзакции

Содержание сообщения сервисного профиля транзакции возвращает все поддерживаемые комбинации "действие/объект", если каждая комбинация поддерживается как получатель, если она поддерживается как отправитель и если поддерживаются групповые символы. См. разделы 6.12 и 7 для определения объекта и соответствующей информации.

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

6.2.2 Класс персонала

Объект "Класс персонала" содержит следующие объекты в соответствии с МЭК 62264-2:

- класс персонала;

- свойство класса персонала.

6.2.3 Сотрудник

Объект "Сотрудник" содержит следующие объекты в соответствии с МЭК 62264-2:

- сотрудник;

- свойство сотрудника;

- результат квалификационных испытаний.

6.2.4 Спецификация квалификационных испытаний

Объект "Спецификация квалификационных испытаний" содержит следующие объекты в соответствии с МЭК 62264-2:

- спецификация квалификационных испытаний.

6.2.5 Класс оборудования

Объект "Класс оборудования" содержит следующие объекты в соответствии с МЭК 62264-2:

- класс оборудования;

- свойство класса оборудования.

6.2.6 Оборудование

Объект "Оборудование" содержит следующие объекты в соответствии с МЭК 62264-2:

- оборудование;

- свойство оборудования;

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

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

Объект "Спецификация испытаний производительности оборудования" содержит следующие объекты в соответствии с МЭК 62264-2:

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

6.2.8 Запрос на техническое обслуживание

Объект "Запрос на техническое обслуживание" содержит следующие объекты в соответствии с МЭК 62264-2:

- запрос на техническое обслуживание.

6.2.9 Заказ-наряд на техническое обслуживание

Объект "Заказ-наряд на техническое обслуживание" содержит следующие объекты в соответствии с МЭК 62264-2:

- заказ-наряд на техническое обслуживание.

6.2.10 Ответ по техническому обслуживанию

Объект "Ответ по техническому обслуживанию" содержит следующие объекты в соответствии с МЭК 62264-2:

- ответ по техническому обслуживанию.

6.2.11 Класс материалов

Объект "Класс материалов" содержит следующие объекты в соответствии с МЭК 62264-2:

- класс материалов;

- свойство класса материалов.

6.2.12 Определение материала

Объект "Определение материала" содержит следующие объекты в соответствии с МЭК 62264-2:

- определение материала;

- свойство определяемого материала.

6.2.13 Партия материала

Объект "Партия материала" содержит следующие объекты в соответствии с МЭК 62264-2:

- партия материала;

- свойства партии материалов;

- результат испытаний качества.

6.2.14 Часть партии материалов

Объект "Часть партии материалов" содержит следующие объекты в соответствии с МЭК 62264-2:

- часть партии материалов;

- свойство части партии материалов;

- результат испытаний качества.

Примечание - В МЭК 62264-1 и МЭК 62264-2 части партий материалов не имеют уникальных свойств или результатов испытаний качества. Практическая реализация данной модели должна позволить частям партий материалов иметь свои уникальные свойства и результаты испытаний качества.

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

6.2.15 Спецификация испытаний качества

Объект "Спецификация испытаний качества" содержит следующие объекты в соответствии с МЭК 62264-2:

- спецификация испытаний качества.

6.2.16 Сегмент процесса обработки

Объект "Сегмент процесса обработки" содержит следующие объекты в соответствии с МЭК 62264-2:

- сегмент процесса обработки;

- параметр сегмента обработки;

- спецификация сегмента персонала;

- спецификация сегмента оборудования;

- спецификация сегмента материала;

- зависимость сегмента обработки;

- свойство спецификации сегмента персонала;

- свойство спецификации сегмента оборудования;

- свойство спецификации сегмента материала.

6.2.17 Производственные возможности

Объект "Производственные возможности" содержит следующие объекты в соответствии с МЭК 62264-2:

- производственные возможности;

- возможности персонала;

- производительность оборудования;

- возможности материала;

- производительность сегмента обработки;

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

- свойство производительности оборудования;

- свойство возможностей материала.

6.2.18 Определение продукта

Объект "Определение продукта" содержит следующие объекты в соответствии с МЭК 62264-2:

- определение продукта;

- сегмент продукта;

- зависимость сегмента продукта;

- смета производства;

- параметр продукта;

- спецификация персонала;

- спецификация оборудования;

- спецификация материала;

- свойство спецификации персонала;

- свойство спецификации оборудования;

- свойство спецификации материала.

6.2.19 График производства

Объект "График производства" содержит следующие объекты в соответствии с МЭК 62264-2:

- график производства;

- запрос о состоянии производства;

- требование сегмента;

- запрошенный отклик сегмента;

- параметр производства;

- требование к персоналу;

- требование к оборудованию;

- требование к изготовленному материалу;

- требование к потребленному материалу;

- ожидаемые расходные материалы;

- свойство требования к персоналу;

- свойство требования к оборудованию;

- свойство требования к изготовленному материалу;

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

- свойство ожидаемого расходного материала.

6.2.20 Производственные показатели

Объект "Производственные показатели" содержит следующие объекты в соответствии с МЭК 62264-2:

- производственные показатели;

- ответное сообщение о состоянии производства;

- отклик сегмента;

- данные производства;

- фактический персонал;

- фактическое оборудование;

- фактический изготовленный материал;

- фактический потребленный материал;

- фактический расходный материал;

- свойство фактического персонала;

- свойство фактического оборудования;

- свойство фактически изготовленного материала;

- свойство фактически потребленного материала;

- свойство фактического расходного материала.

     6.3 Модель персонала
     

6.3.1 Элементы модели персонала

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

     
Рисунок 15 - Группировка объектов для модели персонала

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

6.3.2 Действия класса персонала

Все действия должны быть корректными в отношении объекта "Класс персонала".

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

6.3.3 Особенности действия класса персонала

В таблице 7 определены особенности действий, а также использование идентификаторов и значений класса персонала.

Таблица 7 - Особенности действия класса персонала

           

6.3.4 Действия сотрудника

Все действия должны быть корректными для объекта "Сотрудник".

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

6.3.5 Особенности действия сотрудника

Действия для объекта "Сотрудник" определены в таблице 8.

Таблица 8 - Особенности действия Сотрудника

           

6.3.6 Спецификация действий квалификационных испытаний

Все действия должны быть корректными в отношении объекта спецификации квалификационных испытаний.

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

6.3.7 Особенности действий спецификации квалификационных испытаний

Действия, выполняемые в отношении объекта "Спецификации квалификационных испытаний", определены в таблице 9.

Таблица 9 - Особенности действий спецификации квалификационных испытаний

     
     

     6.4 Модель оборудования
     

6.4.1 Элементы модели оборудования

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

     
Рисунок 16 - Группировка объектов для модели оборудования

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

6.4.2 Действия класса оборудования

Все действия должны быть корректны в отношении объекта класса оборудования.

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

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

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

Таблица 10 - Особенности действий класса оборудования

           

6.4.4 Действия оборудования

Все действия должны быть корректны по отношению к объекту "Оборудование".

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

6.4.5 Особенности действий оборудования

Действия, выполняемые по отношению к объектам оборудования, определены в таблице 11.

Таблица 11 - Особенности действий оборудования

           

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

Все действия должны быть корректны по отношению к объекту "Спецификация испытаний производительности оборудования".

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

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

Действия, выполняемые в отношении объекта "Спецификация испытаний производительности оборудования", определены в таблице 12.

Таблица 12 - Особенности действий спецификации испытаний производительности оборудования

     
     

     6.5 Модель технического обслуживания
     

6.5.1 Элементы модели технического обслуживания

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

     
Рисунок 17 - Группировка объектов для рассматриваемой модели технического обслуживания

6.5.2 Действия запроса технического обслуживания

Все действия должны быть корректными в отношении объекта "Запрос технического обслуживания".

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

6.5.3 Особенности действия запроса технического обслуживания

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

Таблица 13 - Особенности действия запроса технического обслуживания

           

6.5.4 Действия ответа по техническому обслуживанию

Все действия должны быть корректными в отношении объекта "Ответ по техническому обслуживанию".

Примечание - Ответ по техническому обслуживанию дается на запрос технического обслуживания.

6.5.5 Особенности действий ответа по техническому обслуживанию

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

Таблица 14 - Особенности действия ответа по техническому обслуживанию

           

6.5.6 Действия заказ-наряда на техническое обслуживание

Все действия должны быть корректными в отношении объекта "Заказ-наряд на техническое обслуживание".

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

6.5.7 Особенности действия заказ-наряда на техническое обслуживание

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

Таблица 15 - Особенности действий заказ-наряда на техническое обслуживание

     
     

     6.6 Модель материала
     

6.6.1 Элементы модели материала

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

     
Рисунок 18 - Группировка объектов для рассматриваемой модели материала

Пример - Возможные сообщения: Получить Класс материалов, Получить Партию материала, Получить Испытания качества.

6.6.2 Действия класса материалов

Все действия должны быть корректными в отношении объекта "Класс материалов".

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

6.6.3 Особенности действий класса материалов

Действия, выполняемые в отношении объектов "Класса материалов", определены в таблице 16.

Таблица 16 - Особенности действий классов материалов

           

6.6.4 Действия по определению материала

Все действия должны быть корректными в отношении объекта "Определение материала".

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

6.6.5 Особенности действий по определению материала     

Действия, выполняемые в отношении объекта "Определение материала", определены в таблице 17.

Таблица 17 - Особенности действий по определению материала

           

6.6.6 Действия партии материалов

Все действия должны быть корректными в отношении объекта "Партия материалов".

6.6.7 Особенности действий партии материалов

Действия, выполняемые в отношении объекта "Партия материалов", определены в таблице 18.

Таблица 18 - Особенности действий партии материалов

           

6.6.8 Действия части партии материалов

Все действия должны быть корректными в отношении объекта "Части партии материалов".

6.6.9 Особенности действий части партии материалов

Действия, выполняемые в отношении части партии материалов, определены в таблице 19.

Таблица 19 - Особенности действий части партии материалов

           

6.6.10 Действия спецификации испытаний качества

Все действия должны быть корректными в отношении объекта "Спецификации испытаний качества".

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

6.6.11 Особенности действий спецификации испытаний качества

Действия, выполняемые в отношении объекта "Спецификации испытаний качества", определены в таблице 20.

Таблица 20 - Особенности действий испытаний качества

     
     

     6.7 Модель сегмента процесса обработки
     

6.7.1 Элементы модели сегмента процесса обработки

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

     
Рисунок 19 - Группировка объектов для модели сегмента процесса обработки

6.7.2 Действия сегмента процесса обработки

Все действия должны быть корректными в отношении объекта "Сегмент процесса обработки". Группировка объектов для сегмента процесса обработки показана на рисунке 19.

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

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

6.7.3 Особенности действий сегмента процесса обработки

Действия, выполняемые в отношении объекта "Сегмент процесса обработки", определены в таблице 21.

Таблица 21 - Особенности действий сегмента процесса обработки

     
     

     6.8 Модель производственных возможностей
     

6.8.1 Элементы модели производственных возможностей

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

     
Рисунок 20 - Группировка объектов для модели производственных возможностей

6.8.2 Действия производственных возможностей

Все действия должны быть корректными в отношении объекта "Производственные возможности".

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

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

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

6.8.3 Особенности действий производственных возможностей

Действия, выполняемые в отношении объекта "Производственные возможности", определены в таблице 22.

Таблица 22 - Особенности действий производственных возможностей

Таблица 23 - Определения элементов производственных возможностей для сообщений GET и сообщений без идентификатора

     6.9 Модель определения продукта
     

6.9.1 Элементы модели определения продукта

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

     
Рисунок 21 - Группировка объектов для модели определения продукта

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

6.9.2 Действия определения продукта

Все действия должны быть корректными в отношении объекта "Определение продукта".

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

6.9.3 Особенности действий определения продукта

Действия, выполняемые в отношении объекта "Определение продукта", определены в таблице 24.

Таблица 24 - Особенности действий определения продукта

     
     

     6.10 Модель графика производства
     

6.10.1 Элементы модели графика производства

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

Рисунок 22 - Группировка объектов модели графика производства, лист 1

     

     
Рисунок 22, лист 2

6.10.2 Действия графика производства

Все действия должны быть корректными в отношении объекта "График производства".

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

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

6.10.3 Особенности действий графика производства

Действия, выполняемые в отношении объекта "График производства", определены в таблице 25.

Таблица 25 - Особенности действий графика производства

           

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

Таблица 26 - Определения элементов графика производства для сообщений GET и сообщений без идентификатора

     
     

     6.11 Модель производственных показателей
     

6.11.1 Элементы модели производственных показателей

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

     
Рисунок 23 - Группировка объектов модели производственных показателей

6.11.2 Действия производственных показателей

Все действия должны быть корректными в отношении объекта "Производственные показатели".

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

Примечание 2 - Производственные показатели - это временной кадр состояния производства.

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

6.11.3 Особенности действий производственных показателей

Действия, выполняемые в отношении объекта "Производственные показатели", определены в таблице 27.

Таблица 27 - Особенности действий производственных показателей

Таблица 28 - Определения производственных показателей для сообщений GET и сообщений без идентификатора

     
     

     6.12 Профиль транзакции
     

Профиль транзакции содержит определение действия и комбинации объектов, поддерживаемых приложением. Профиль транзакции устанавливает метод запроса приложениями других приложений, чтобы определить комбинацию "действие - объект", которую он поддерживает. Профиль транзакции - это элемент, ассоциированный с объектом. Приложения, поддерживающие настоящий стандарт, должны также поддерживать использование действий GET и SHOW с соответствующими профилями транзакций. Объекты, предназначенные для обмена профилями транзакций, указаны точками на рисунке 24.

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

     
Рисунок 24 - Модель профиля транзакции

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

Таблица 29 - Атрибуты поддерживаемого действия

           

Действие GET должно быть корректным в отношении объекта профиля транзакции. В таблицу 30 сведены особенности действий профиля транзакции.

Таблица 30 - Особенности действий профиля транзакции

     
     

     7 Завершенность, соответствие по существу и соответствие форме

     7.1 Завершенность
     

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

     7.2 Соответствие по существу
     

Любая оценка степени соответствия спецификации определяется:

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

b) использованием протокола для каждой поддерживаемой транзакции;

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

В случае частичного соответствия области несоответствия должны быть явно идентифицированы.

     7.3 Соответствие по форме
     

Любая оценка степени соответствия приложения определяется:

a) установленной документацией на транзакцию (см. таблицы 7-28);

b) установленной документацией на правила транзакций.

При частичном соответствии области несоответствия должны быть явно идентифицированы.

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

Таблица 31 - Поддерживаемые комбинации "действие - объект"

           

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

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

Пример - Таблица 32 представляет собой пример, когда поставщик, предлагающий поддержку, занимается обменом информации о материале. Рассматриваемое приложение может действовать как пользователь (провайдер) данных для транзакций PULL и PUSH, но только как пользователь (подписчик) для групповой операции PUBLISH.

Таблица 32 - Пример соответствия поставщика формальным требованиям

     

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

Примеры моделей транзакций и рыночных сценариев

A.1 Координирующие действия

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

На рисунке А.1 приняты следующие допущения для рыночных операций:

a) информация об определении главного продукта содержится на Уровне 4 приложения PLM (Управление жизненным циклом продукта);

b) Уровень 3 (Управление определением производства) получает текущую информацию о технологических маршрутах и технологических особенностях от приложения PLM с помощью транзакций "Получить определение производства/Показать определение производства";

c) информация об основном оборудовании содержится на Уровне 4 приложения Управления активами;

d) Уровень 3 (Управление производственными ресурсами) получает информацию об оборудовании от приложения Управления активами с помощью групповых операций "Получить оборудование/Показать оборудование";

e) приложение Уровня 4 управляет работой по Планированию производства и Анализу производственных мощностей;

f) управление производственными ресурсами Уровня 3 отвечает за информацию о производственных возможностях;

g) управление производственными ресурсами Уровня 3 проталкивает информацию о производственных возможностях на Уровень 4 для приложений Планирования производства и Анализа производственных мощностей;

h) приложение Планирования производства и Анализа производственных мощностей передает с Уровня 4 информацию о графике производства на Уровень 3 для Детального планирования с использованием транзакций и составления Технологических карт производства;

i) приложение "Отслеживание производства" передает с Уровня 3 информацию о производственных показателях (изготовленные материалы, использованные ресурсы и т.п.) для Планирования производства и Анализа производственных мощностей с использованием транзакций для текущих Производственных показателей, а также передает информацию о части партии материалов на Уровень 4 в приложение Управление запасами с помощью транзакций, использующих части партий технологических материалов.

     
Рисунок А.1 - Координация планирования и выполнения технологических операций

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

А.2 Сценарии использования

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

Приложение ERP (Планирование ресурсов предприятия) представляет типовую рыночную систему Уровня 4 в указанных сценариях. Приложение MOM (Управление производственными операциями) представляет типовую производственную систему Уровня 3. Стрелки отслеживают передачу сообщений между указанными приложениями.

А.3 График производства и производственные показатели

А.3.1 Модель Push

Рисунок А.2 иллюстрирует модель Push, основанную на нижеследующих допущениях сценария:

a) приложение ERP передает готовые графики производства в приложение MOM для последующей обработки;

b) по окончании работы приложение MOM передает производственные показатели в приложение ERP для последующей обработки.

________________

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

Рисунок А.2 - Модель Push: график производства и производственные показатели

А.3.2 Модель Pull

Рисунок А.3 иллюстрирует модель Pull, основанную на следующих допущениях сценария:

a) приложение MOM запрашивает графики производства у приложения ERP по расписанию;

b) приложение ERP запрашивает производственные показатели у приложения MOM по расписанию.

________________

Сообщение GET с производственными показателями идентифицирует график производства Производственные показатели/Идентификатор графика производства.

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

Рисунок А.3 - Модель Pull: график производства и производственные показатели

А.3.3 Модель Publish

На рисунке А.4 приведена модель Publish, основанная на нижеследующих допущениях сценария:

a) приложение MOM подписывается на графики производства;

b) приложение ERP подписывается на производственные показатели;

c) приложение ERP публикует графики производства;

d) приложение MOM публикует исходные производственные показатели с помощью сообщения SYNC ADD;

e) приложение MOM публикует последующие производственные показатели (для построения графика производства) с помощью сообщения SYNC CHANGE.

________________

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

Рисунок А.4 - Модель Publish: график производства и производственные показатели

А.4 Изменения графика производства

А.4.1 Модель Push

Рисунок А.5 иллюстрирует модель Push, основанную на нижеследующих допущениях сценария:

a) приложение ERP направляет график производства приложению MOM для обработки;

b) приложение MOM направляет производственные показатели приложению ERP для обработки;

c) приложение ERP вносит изменения в график производства и отправляет его приложению MOM для обработки.

________________

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

Рисунок А.5 - Модель Push: изменение графика производства

А.4.2 Модель Publish

Рисунок А.6 иллюстрирует модель Publish, основанную на нижеследующих допущениях сценария:

a) приложение MOM подписывается на графики производства;

b) приложение ERP подписывается на производственные показатели;

c) приложение ERP публикует графики производства;

d) приложение MOM публикует исходные производственные показатели с помощью сообщения SYNC ADD;

e) приложение ERP изменяет графики производства и повторно публикует их с помощью сообщения SYNC CHANGE;

f) приложение MOM публикует последующие производственные показатели для построения графика с помощью сообщения SYNC CHANGE.

________________

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

           

Рисунок А.6 - Модель Publish: изменение графика производства

А.5 Отмена графика производства

А.5.1 Модель Push

Рисунок А.7 иллюстрирует модель Push, основанную на нижеследующих допущениях сценария:

a) приложение ERP направляет график производства приложению MOM для обработки;

b) приложение ERP отменяет график перед фактическим запуском производства и отправляет сообщение CANCEL с отменой графика приложению MOM.

     
Рисунок А.7 - Модель Push: отмена графика производства

А.5.2 Модель Push and Pull

Рисунок А.8 иллюстрирует модель Push and Pull, основанную на нижеследующих допущениях сценария:

a) приложение MOM запрашивает график производства у приложения ERP;

b) приложение ERP отменяет график перед фактическим запуском производства и отправляет сообщение CANCEL об отмене графика приложению MOM.

     
Рисунок А.8 - Модель Push and Pull: отмена графика

А.6 Ежедневные производственные показатели

А.6.1 Модель Push

Рисунок А.9 иллюстрирует модель Push, основанную на нижеследующих допущениях сценария:

a) приложение MOM отправляет ежедневные производственные показатели приложению ERP;

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

     
Рисунок А.9 - Модель Push: ежедневные производственные показатели

А.6.2 Модель Pull

Рисунок А.10 иллюстрирует модель Pull, основанную на нижеследующем допущении сценария:

- приложение ERP запрашивает производственные показатели у приложения MOM по ежедневному графику.

     
Рисунок А.10 - Модель Pull: ежедневные производственные показатели

А.6.3 Модель Publish

Рисунок А.11 иллюстрирует модель Publish, основанную на нижеследующих допущениях сценария:

a) приложение ERP подписывается на ежедневные производственные показатели от приложения MOM;

b) приложение MOM ежедневно публикует производственные показатели;

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

     
Рисунок А.11 - Модель Publish: ежедневный график производства

А.7 График производства, основанный на производственных возможностях

А.7.1 Модель Push and Pull

Рисунок А.12 иллюстрирует модель Push and Pull, основанную на нижеследующих допущениях сценария:

a) приложение ERP запрашивает производственные возможности на планируемый период;

b) приложение MOM сообщает производственные возможности приложению ERP;

c) приложение ERP отправляет график производства приложению MOM для обработки;

d) приложение MOM отправляет производственные показатели приложению ERP, отражая частичное выполнение работы;

e) приложение MOM отправляет производственные показатели приложению ERP, отражая завершение работы.

     
Рисунок А.12 - Модель Push and Pull: производственные возможности и график производства

А.7.2 Модель Publish and Push

Рисунок 13 иллюстрирует модель Publish and Push, основанную на нижеследующих допущениях сценария:

a) приложение ERP подписывается на производственные возможности;

b) приложение MOM подписывается на график производства;

c) приложение MOM публикует производственные возможности по установленному графику, например один раз в два дня;

d) приложение ERP генерирует график производства и публикует его;

e) приложение MOM направляет производственные показатели приложению ERP, отражая частичное выполнение работ;

f) приложение MOM направляет производственные показатели приложению ERP, отражая частичное выполнение работ;

g) приложение MOM направляет производственные показатели приложению ERP, отражая завершение работ.

________________

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

Рисунок А.13 - Модель Publish and Push: производственные возможности и график производства

А.8 Изменение графика производства

А.8.1 Модель Push and Pull

Рисунок А.14 иллюстрирует модель Push and Pull, основанную на нижеследующих допущениях сценария:

a) приложение ERP направляет график производства приложению MOM для обработки;

b) приложение MOM направляет производственные показатели приложению ERP для обработки;

c) приложение ERP запрашивает производственные возможности у приложения MOM;

d) приложение MOM сообщает производственные возможности приложению ERP;

e) приложение ERP вносит изменения в график производства и отправляет его приложению MOM для обработки;

f) приложение MOM направляет производственные показатели приложению ERP, отражая частичное выполнение работ;

g) приложение MOM направляет производственные показатели приложению ERP, отражая завершение работ.

     
Рисунок А.14 - Модель Push and Pull: изменение графика

А.8.2 Модель Publish

Рисунок А.15 иллюстрирует модель Publish и изменения графика производства вследствие изменения производственных возможностей:

a) приложение MOM подписывается на график производства;

b) приложение ERP подписывается на производственные показатели;

c) приложение ERP публикует график производства;

d) приложение MOM публикует исходные производственные показатели с помощью сообщения SYNC ADD;

e) приложение ERP изменяет график производства, составленный по исходным показателям и опубликованный повторно с помощью сообщения SYNC CHANGE;

f) приложение MOM публикует последующие производственные показатели для графика производства с помощью сообщения SYNC CHANGE.

________________

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

Рисунок А.15 - Модель Publish: изменение графика производства вследствие изменения производственных возможностей

А.9 Измененное количество материала

А.9.1 Модель Push

Рисунок А.16 иллюстрирует модель Push, основанную на нижеследующих допущениях сценария:

a) расходные материалы поступают в цех и учитываются приложением ERP;

b) приложение ERP отправляет информацию о партии материалов приложению MOM для обработки;

c) приложение MOM отправляет информацию о количественных изменениях партии материалов приложению ERP по мере потребления материалов;

d) приложение ERP отправляет сообщение CANCEL, если партия материалов стала недоступной.

     
Рисунок A.16 - Модель Push: добавление партии материалов, количественное изменение партии материалов

А.9.2 Модель Publish and Push

Рисунок A.17 иллюстрирует модель Publish and Push, основанную на нижеследующих допущениях сценария:

a) приложение ERP публикует информацию о партии материалов; приложение MOM на нее подписывается;

b) приложение MOM отправляет информацию о количественных изменениях партии материалов приложению ERP;

c) приложение ERP отправляет сообщение SYNC DELETE, если данная партия материалов становится недоступной.

     
Рисунок А.17 - Модель Publish and Push: количественные изменения партии материалов

А.9.3 Модель Push and Pull

Рисунок A.18 иллюстрирует модель Push and Pull, основанную на нижеследующих допущениях сценария:

a) приложение MOM периодически запрашивает информацию о новых партиях материалов у приложения ERP;

b) приложение ERP сообщает информацию о новых партиях материалов; в одном сообщении SHOW может быть информация о нескольких партиях материалов;

c) приложение MOM передает информацию о количественных изменениях партии материалов приложению ERP.

     
Рисунок А.18 - Модель Push and Pull: количественные изменения партии материалов

     

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

Вопросы и ответы по использованию транзакций

B.1 Различные идентификаторы

Вопрос:

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

Ответ:

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

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

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

B.2 Тип транзакции

Вопрос:

Рассматриваемые транзакции относятся к базам данных или к сообщениям?

Ответ:

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

B.3 Откат (возвращение предыдущего состояния)

Вопрос:

Как работать с откатами?

Ответ:

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

B.4 CONFIRM (подтверждение)

Вопрос:

Почему следует использовать режим CONFIRM для сообщения SYNC?

Ответ:

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

Данный режим следует использовать с осторожностью, так как:

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

b) если предварительная подписка не оформлена, то издатель не может знать, что клиент не подтвердил сообщение SYNC;

c) даже если издатель видит, что клиент неправильно обработал сообщение SYNC (либо отправил сообщение CONFIRM с ошибкой или вообще ничего не отправил), то он уже ничего сделать не может.

B.5 Двухфазный контроль за завершением транзакций

Вопрос:

Как выполняется двухфазный контроль за завершением транзакций?

Ответ:

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

B.6 Подтверждение сообщений GET

Вопрос:

Зачем нужно подтверждение сообщения GET, если сообщение SHOW и так является стандартным ответом?

Ответ:

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

B.7 Механизм запроса

Вопрос:

Почему настоящий стандарт не поддерживает общий механизм запроса сообщениями GET?

Ответ:

Определения транзакций не предназначены для формирования полного механизма запросов удаленных данных (например, в форматах доступа SQL или XML), а только механизма обеспечения доступа к данным для слабо связанных систем с различными внутренними структурами хранения данных. Если наличие полного механизма запросов необходимо, то рассматриваемые транзакции могут быть использованы для создания локальных баз данных. Могут быть использованы также локальные механизмы запроса.

B.8 Простые объекты

Вопрос:

Как определяются простые объекты (nouns)?

Ответ:

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

B.9 Ответ CONFIRM

Вопрос:

Возможно ли получение ответа CONFIRM по каждому действию?

Ответ:

Ответ CONFIRM допускается по любому сообщению. Однако он не рекомендуется для действий SYNC. Ответ CONFIRM может быть получен по сообщениям PROCESS и CHANGE. Это особые ответные сообщения типов ACKNOWLEDGE и RESPOND, содержащие модифицированные данные. Отметим, что сообщение CONFIRM может содержать любую информацию об ошибках.

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

Шаблон действия

C.1 Шаблон

В таблицах C.1-C.11 приведены общие шаблоны для создания правил определения требований к действиям в отношении указанных объектов. Те же общие шаблоны могут быть применены к другим (простым) объектам, не рассмотренным в настоящем стандарте. Указанные в них спецификации лежат вне области применения настоящего стандарта.

C.2 Особенности действий GET

Существует общий шаблон действий GET, где объекты (один или несколько) включены вместе с идентификатором первичного объекта, идентификатором ассоциированного свойства и/или значением свойства, определенным в таблицах C.1-C.3. Специальные правила формирования действий GET для указанных объектов описаны в соответствующем разделе настоящего стандарта. Если объекты включают другие ассоциированные элементы (например, предельные значения параметров), то особенности действий также описаны в соответствующем разделе настоящего стандарта.

Таблица C.1 - Сообщения GET с идентификатором объекта

Таблица C.2 - Сообщение GET с групповым символом в идентификаторе объекта

Таблица С.3 - Сообщение GET без идентификатора объекта

           

С.3 Особенности действий сообщения PROCESS

Общий шаблон действий сообщения PROCESS с указанным идентификатором объекта определен в таблице С.4.

Таблица С.4 - Сообщение PROCESS с идентификатором объекта

           

Общий шаблон действий в отношении сообщения PROCESS, не содержащего идентификатора объекта, определен в таблице C.5.

Таблица C.5 - Сообщение PROCESS без идентификатора объекта

          

C.4 Действия для сообщения CHANGE

Общий шаблон действий в отношении сообщения CHANGE с указанным идентификатором объекта определен в таблице C.6.

Таблица C.6 - Сообщение CHANGE с идентификатором объекта

           

Общий шаблон действий в отношении сообщения CHANGE, когда идентификатор объекта является групповым символом, определен в таблице C.7.

Таблица C.7 - Сообщение CHANGE с идентификатором объекта, являющимся групповым символом

           

C.5 Действия сообщения CANCEL

Общий шаблон действий в отношении сообщения CANCEL с указанным идентификатором объекта определен в таблице C.8.

Таблица C.8 - Сообщение CANCEL с идентификатором объекта

           

Общий шаблон действий в отношении сообщения CHANGE, когда идентификатор объекта является групповым символом, определен в таблице С.9.

Таблица С.9 - Сообщение CANCEL с групповым символом, содержащимся в идентификаторе объекта

           

C.6 Действия для сообщения SYNC

Общий шаблон действий в отношении сообщения SYNC с указанным идентификатором объекта определен в таблице C.10. Сообщение SYNC может иметь тип SYNC ADD и содержать новую информацию, тип SYNC CHANGE для изменения имеющейся информации, а также тип SYNC DELETE для удаления информации.

Таблица C.10 - Сообщение SYNC с идентификатором объекта

           

Общий шаблон действий в отношении сообщения SYNC, когда идентификатор объекта содержит спецификацию группового символа, определен в таблице C.11.

Таблица C.11 - Сообщение SYNC с групповым символом в идентификаторе объекта

     

          

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

Общие правила идентификации объектов модели

D.1 Шаблоны

Данное приложение описывает общий шаблон для определения объектов, основанных на использовании UML (Универсальный язык моделирования) моделей в соответствии с ИСО/МЭК 19501.

Тот же общий шаблон может быть применен к другим существительным и/или объектам, не определенным в настоящем стандарте. Данные спецификации в настоящем стандарте не рассматриваются.

D.2 Иерархическая модель объекта

Модель объекта с иерархической структурой имеет один "верхний" объект, составленный из других объектов. Примеры иерархических моделей объектов: Сегмент процесса обработки, Определения продукта, График производства, Производственные показатели.

Если верхний уровень объекта является составным, а дочерние объекты только рассматриваются в контексте объекта верхнего уровня, то ИМЕННАЯ КОНСТРУКЦИЯ (объект) идентифицируется с данным объектом верхнего уровня. Если дочерние объекты также являются составными, то они включаются как ИМЕННАЯ КОНСТРУКЦИЯ (объект) верхнего уровня.

Имя СУЩЕСТВИТЕЛЬНОГО (объекта) такое же, как и имя объекта верхнего уровня.

Данное правило основано на допущении, что обмен дочерними объектами не будет эффективным из-за необходимости иметь контекст родительского объекта. Например, обмен просто Требований к сегменту без контекста Запроса о состоянии производства и контекста Графика производства не дает достаточной информации об обработке указанных Требований к сегменту.

Рисунок D.1 иллюстрирует составные отношения внутри Графика производства. Так как все объекты данной модели входят в составную иерархию, за исключением ассоциаций объектов в других моделях (обработки или сегмента продукта), то имеется только одна ИМЕННАЯ КОНСТРУКЦИЯ (объект), определенная для данной модели.

Рисунок D.1 - Модель объекта с составными отношениями, лист 1

     

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

D.3 Неиерархическая модель объекта

Модели объектов, не имеющие иерархической структуры, обычно имеют несколько определений модельных конструкций. Примеры неиерархических моделей объектов: Персонал, Материал, Оборудование.

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

Если дочерний объект (например, Часть партии материалов) имеет достаточный контекст для раздельного обмена, то дочерний объект также определяется как именная конструкция.

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

Имя модельной конструкции совпадает с именем объекта.

Рисунок D.2 иллюстрирует случай, когда в модели объекта нет составных соотношений. Ее ожидаемое рыночное использование - обмен отдельных объектов.

     
Рисунок D.2 - Модель объекта с несоставными отношениями

Рисунок D.3 иллюстрирует случай, когда в модели объекта имеются и составные отношения, и ассоциированные объекты. В данной ситуации именная конструкция определяется как для каждого простого объекта, так и для составного объекта, включающего несколько объектов в определенном составном отношении. Так, пять отдельных существительных (noun) определяются для Классов материалов, Определений материалов, Партий материалов, Частей партий материалов и Спецификаций испытаний качества. Ассоциированные объекты (например, Результаты испытаний качества) размещаются в существительных Партии материалов и существительных Части партии материалов, основанных на ожидаемом характере использования рассматриваемого объекта.

     
Рисунок D.3 - Пример использования нескольких составных объектов

     

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

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

Таблица ДА.1