ГОСТ Р МЭК 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).
|
Information provider | Провайдер информации |
Information user | Пользователь информации |
GET equipment | Оборудование для получения информации |
Application identification area | Область идентификации приложений |
Data area | Область данных |
Verb=GET | Действие = получить |
Noun=Equipment | Объект = оборудование |
ID = "ABC" | Идентификатор = АВС |
GET | Получать |
Local processing | Локальная обработка |
SHOW equipment | Оборудование для показа |
Application identification area | Область идентификации приложения |
Data area | Область данных |
Verb = SHOW | Действие = показать |
Noun = Equipment | Объект = оборудование |
ID = "ABC" | Идентификатор = ABC |
Description = "Simple equipment" | Описание = простое оборудование |
Equipment property | Свойство оборудования |
ID = "Throughput" | Идентификатор = throughput (выработка) |
Value = "200" | Значение = 200 |
Value unit of measure = "PPM" | Значение единицы измерения = деталей в минуту |
Description = "Throughput as parts per minute" | Описание = выработка, измеряемая числом деталей в минуту |
SHOW | Показать |
Рисунок 1 - Типовой обмен сообщениями в групповой операции
4.3 Структура сообщений
4.3.1 Общая структура
Каждое сообщение должно содержать всю информацию, необходимую для идентификации источника сообщения и типа сообщения. В сообщении имеются две основные области (рисунок 2): Область идентификации приложения и Область данных. Внутри Области данных должны быть Область действия и Область объекта.
|
Data message | Сообщение данных |
Application identification area | Область идентификации приложения |
Data area | Область данных |
Verb area | Область действия |
Noun area | Область объекта |
Initiating verbs: GET, change, cancel, process, sync | Инициирующие действия: получить, изменить, отменить, обработать, синхронизировать |
Responding verbs: SHOW, confirm, acknowledge, respond | Ответные действия: показать, подтвердить правильность, подтвердить прием, ответить |
Objects defined in the IEC 62264-1, Clause 7 object models | Объекты, определенные моделями объектов в соответствии с МЭК 62264-1, раздел 7 |
Рисунок 2 - Типовой обмениваемый набор данных
4.3.2 Область идентификации приложения
Область идентификации приложения должна содержать информацию, которую получающее приложение использует для обработки сообщений. Область идентификации приложения используется для установления уровня связи приложения, например указания требуемого подтверждения обработки сообщения. Данная информация обычно включает электронный адрес отправителя, указание требования подтверждения, дату и время создания сообщения. Область идентификации приложения может также включать другую информацию, необходимую для идентификации и аутентификации сообщения. На рисунке 3 показан типовой расклад для области идентификации приложения.
Примечание - См. спецификацию OAGIS 9.0 (спецификация интеграции открытой группы приложений) для формата области идентификации приложения. Модель обмена данными, определенная в настоящем стандарте, соответствует спецификации OAGIS. Поэтому практическая реализация OAGIS, использующая объекты МЭК 62264-1 и МЭК 62264-2, может соответствовать настоящему стандарту.
|
Data message | Сообщение данных |
Application identification area | Область идентификации приложения |
Sender | Отправитель |
Identifies the sender of the message | Идентифицирует отправителя сообщения |
Logical ID | Логический идентификатор |
Identifies the return address of the sender | Идентифицирует обратный адрес отправителя |
Confirmation | Подтверждение |
Defines the confirmation option | Определяет вариант подтверждения |
Other sender information | Информация о другом отправителе |
Creation date | Дата создания |
Defines the creation date/time of the message | Определяет дату и время создания сообщения |
Other application identification information | Прочая информация об идентификации приложения |
Data area | Область данных |
Рисунок 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 с установленным групповым символом. Провайдер информации возвращает перечень объектов, согласованный со спецификацией групповых символов.