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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настоящий стандарт не распространяется на:

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

- таблицу соответствия, в которой даны ссылки на услуги типа 1, указанные и определенные в ИСО 16100-3;

- дополнительные услуги, необходимые для управления этими шаблонами в базе данных или в эквивалентном ему хранилище информационных объектов.

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

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

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

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

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

В настоящем стандарте применены следующие термины с соответствующими определениями:

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

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

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

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

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

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

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

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

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

В настоящем стандарте используются следующие сокращения:

CCS - структура класса параметров (CCS-структура);

CSI - заключение о соответствии для внедрения реализации;

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

MDM - производственная модель (MDM-модель);

MES - управление производственными операциями;

MSU - модуль производственной программы (MSU-модуль);

UML - унифицированный язык моделирования;

XML - расширяемый язык разметки.

Рисунок 1 иллюстрирует принцип согласования конфигураций параметров с помощью многопараметрических структур классов.

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

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

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

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

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

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

c) выбор шаблона параметров для каждого идентифицированного класса параметров;

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

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

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

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

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

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

d) с использованием программы согласования конфигураций типа 2 (см. ИСО 16100-3) сравнение набора требуемых конфигураций параметров с имеющимся набором конфигураций MSU-модуля для нахождения уже существующих MSU-модулей, которые соответствуют набору требуемых конфигураций параметров;

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

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

g) комбинирование набора многократно используемых MSU-модулей [см. перечисление e)] с любым набором разработанных MSU-модулей [см. перечисление f)] для удовлетворения требований, предъявляемых к новой производственной прикладной программе.

Рисунок 2 иллюстрирует вариант реализации принципа разработки новой производственной прикладной программы (см. рисунок 1).

На рисунке 3 схематически изображены MDD-данные, MDM-модель, CCS-структура, класс параметров и их взаимосвязи с другими производственными элементами.

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

Рисунок 4 иллюстрирует пример построения структуры MDM-модели с несколькими источниками MDD-данных. Процесс, после которого следует формирование MDM-модели для формирования MDD-данных, рассмотрен в приложении A.

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

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

b) о производственных процессах (например, об операциях, направлениях работ);

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

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

Как видно из рисунка 5, каждый массив MDD-данных в какой-либо области производства состоит из атрибутов и набора связей с другими MDD-данными в той же области, использующий класс отношений. Взаимосвязь атрибутов типов ограничений и связей в классе отношений устанавливает область допустимых связей между MDD-данными в какой-либо MDM-модели. Разработчик MDM-модели должен предоставлять такое описательное наименование MDD-данным, обмениваемым между производственными функциями или между производственными видами деятельности, чтобы MDD-данные были уникальными в рассматриваемой области производства.

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

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

На рисунке 6 изображены две CCS-структуры, преобразованные из соответствующих деревьев производственных операций. Структуры CCS#1 и CCS#2 различаются между собой, все же имея несколько идентичных классов параметров, которые могут выявляться, если конфигурация параметров, соответствующая классу параметров, описывается с помощью MDD-данных, взятых из одной и той же MDM-модели.

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

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

a) шаблон CCS-структуры;

b) шаблон возможностей;

c) шаблон MDM-модели;

d) шаблон MDD-данных.

6.2.1 Концептуальная структура

CCS-шаблон как минимум должен содержать следующие элементы:

a) наименование разработчика CCS-структуры;

b) идентификационные данные на CCS-структуру;

c) идентификационные данные на каждый класс параметров;

d) идентификационные данные на родительский узел для каждого класса параметров (корневой узел не имеет номера в идентификационных данных на родительский узел).

Идентификационные данные на дочерний узел для каждого мандатного класса.

На рисунке 7 приведена концептуальная структура CCS-шаблона.

6.2.2 Формальная структура

6.3.1 Концептуальная структура

Шаблон конфигурации параметров согласно ИСО 16100-2:2003 (подраздел 6.3) и ИСО 16100-3:2005 (пункт 7.2.2) должен содержать общую часть, а согласно ИСО 16100-2:2003 (подраздел 6.3) - также и специальную часть, в которой как минимум должны содержаться элементы, указанные в ИСО 16100-2, вместе со следующими дополнительными элементами:

a) справочное наименование MDM-модели;

b) формат описания MDD-данных (например, перечень MDD-объектов);

c) описание MDD-данных (например, доступ к MDD-объектам, регламентированный по времени).

На рисунке 8 приведена концептуальная структура шаблона конфигурации параметров.

6.3.2 Формальная структура

Провайдер или пользователь MSU-модуля должен описывать шаблоны конфигурации параметров с помощью XML-схем. Формальная структура подобных шаблонов должна быть такова:

6.4.1 Концептуальная структура

Шаблон MDM-модели должен содержать базовую часть, а также дополнительную часть. Базовая часть должна включать следующие элементы:

a) наименование MDM-модели;

b) наименование отраслевого словаря-справочника.

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

c) наименование MDD-данных - для каждого массива MDD-данных в MDM-модели;

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

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

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

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

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

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

На рисунке 9 приведена концептуальная структура шаблона MDM-модели.

6.4.2 Формальная структура

6.5.1 Концептуальная структура

Шаблон MDD-данных должен содержать базовую часть, а также дополнительную часть. Базовая часть должна включать следующие элементы:

a) наименование MDD-данных;

b) справочное наименование MDM-модели;

c) тип MDD-данных.

Примечание - Тип MDD-данных может использоваться для различения производственных ресурсов и функций или же элементов производственной информации, представляемой MDD-данными;

d) наименование атрибута - для каждого атрибута, содержащегося в MDD-данных;

e) тип атрибута - для каждого атрибута, содержащегося в MDD-данных.

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

6.5.2 Формальная структура

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

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

Процесс согласования конфигураций параметров с использованием программы согласования конфигураций типа 2 начинается с извлечения идентификационных данных (IDs) о словаре-справочнике классов параметров из введенных конфигураций параметров с последующим сравнением их идентификационных данных. В случае, когда они одинаковы, программа согласования должна выполнять процедуру, предусмотренную ИСО 16100-2 для программы согласования конфигураций типа 1; в противном случае программа согласования должна извлекать ссылочные идентификационные данные о MDM-моделях из введенных конфигураций параметров. Если идентификационные данные о MDM-моделях различаются, то программа согласования конфигураций типа 2 выдаст сообщение о том, что сравнение введенных конфигураций не может быть выполнено; в противном случае программа согласования конфигураций будет извлекать форматы определения параметров из введенных конфигураций и сравнивать эти форматы. Если эти форматы различаются, то MDD-данные в определениях форматов будут преобразовываться в единый формат с помощью внешних по отношению к программе согласования конфигураций типа 2 средств (программ); в противном случае никакого преобразования форматов не потребуется. После этих операций программа согласования конфигураций выдаст сообщение об уровне согласования требуемой конфигурации с конфигурацией параметров MSU-модуля.

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

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

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

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

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

К настоящей части ИСО 16100 применима методология определения соответствия, указанная в стандарте ИСО 16100-4. В данный раздел введены CSI, определенные в ИСО 16100-4:2006 (пункт 6.1.3), для шаблона CCS-структуры (см. таблицу 1), для шаблона MDM-модели (см. таблицу 3) и для шаблона MDD-данных (см. таблицу 4). Кроме того, в этот раздел введены CSI для элементов шаблона конфигураций параметров (см. таблицу 2), не указанные в ИСО 16100-4. Пункты соответствия, приведенные в данном разделе, определены в ИСО 16100-4:2006 (таблица 5).

Для ссылки на однозначно идентифицируемый и уникальный номер MDM-модели в конфигурации ее разработчик должен использовать шаблон, указанный в 6.4.2, и зарегистрировать MDM-модель в базе данных (см. таблицу 3).

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

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

B.1 Пример производственной модели

На рисунке B.1 приведен пример MDM-модели в сфере управления производственными операциями (MES) <1>.

--------------------------------

<1> Система организации производства (MES) согласно МЭК 62264-3 является частью системы управления производственными процессами.

Смысл MDD-элементов, изображенных на рисунке B.1, таков:

a) элемент - общий термин, относящийся к исходным материалам, деталям, продуктам незавершенного производства [см. ниже перечисление f)], веществам [см. ниже перечисление e)] и готовым изделиям [см. ниже перечисление g)];

b) элемент качества - наименование атрибута, измеряемого при приемке изделия;

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

d) показатель качества - фактическое значение характеристики, измеренное при приемке изделия;

e) материал - элемент [см. выше перечисление a)], проходящий через производственную операцию;

f) незавершенная продукция (полуфабрикаты) - изделия [см. выше перечисление a)], изготовление которых было начато, но не завершено в процессе производства;

g) готовая продукция - изделия [см. выше перечисление a)], изготовление которых было завершено в процессе производства;

h) способ производства - набор рабочих характеристик, закрепляемых рабочим методом [см. ниже перечисление i)];

i) рабочая процедура - процедура, обеспечивающая производство готовых изделий [см. выше перечисление g)] или продукции незавершенного производства [см. выше перечисление f)];

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

k) процесс - упорядоченный список рабочих процедур [см. выше перечисление i)], применяемых для изготовления изделия;

l) запас - остаточное количество изделий на данный момент времени;

m) складское помещение - место, используемое для хранения изделий;

n) торговое помещение - место, где находится готовая продукция;

o) инженерные коммуникации - например, для подачи воды, воздуха, электричества, топлива;

p) оборудование - общий термин, относящийся к станкам, инструментам и подручным средствам работника;

q) фактически используемое оборудование - оборудование [см. выше перечисление p)], используемое в процессе производства;

r) инструмент - присоединяемое или отсоединяемое устройство, используемое совместно с оборудованием, например металлическая пресс-форма;

s) данные о вкладываемых ресурсах - наименование MDD-данных в перечне изделий [см. выше перечисление a)] и их количество, которое поступает для выполнения рабочей процедуры [см. выше перечисление i)];

t) данные о произведенной продукции - наименование MDD-данных в перечне изделий [см. выше перечисление a)] и объемов их производства, которое находится на выходе рабочей процедуры [см. выше перечисление i)];

u) данные о потребляемых услугах - наименование MDD-данных в перечне коммунальных услуг и их объема, оказываемых в процессе выполнения рабочей процедуры [см. выше перечисление i)];

v) данные о производственном оборудовании - наименование MDD-данных в перечне фактически используемого оборудования, т.е. оборудования, закрепленного за данным процессом производства [см. выше перечисления p) и q)], его количества и производительности для данного рабочего процесса.

На рисунке B.1 обозначены два стандартных класса параметров - <<plan&result>> и <<history>>, первый из которых иллюстрируется рисунком B.2, а второй - рисунком B.3.

B.2 Пример конфигурации параметров модулей программного обеспечения производства (MSU)

B.2.1 Пример дерева операций для системы организации производства (MES)

На рисунке B.4 приведен пример дерева производственных операций для пакета MES-программ, разработанного его поставщиком. Этот пакет может быть разбит на семь операций, отличающихся моделями управления производственными операциями, путем применения MDM-модели, показанной на рисунке B.1. В свою очередь, каждая из этих семи операций путем анализа также может быть разбита на субоперации. В таблице B.1 перечислены все операции и субоперации (вместе с соответствующими MDD-данными).

B.2.2 Описание на языке XML примера конфигурации параметров MSU-модуля

Нижеприведенное XML-описание относится к конфигурации параметров для субоперации A11 (см. таблицу B.1).

B.3 Пример требуемой конфигурации параметров

B.3.1 Пример дерева операций для запрашиваемой системной спецификации

На рисунке B.5 приведен пример дерева операций для пакета программ управления производственными операциями (MES), который требуется специалисту по системной интеграции. Этот пакет разделен на шесть групп операций, каждая из которых, в свою очередь, для анализа ее функций с помощью MDM-модели (см. рисунок B.1) делится на субоперации. Все указанные операции и субоперации представлены в таблице B.2 вместе со ссылочными MDD-данными и действиями.

B.3.2 Пример запрашиваемого профиля возможностей

Нижеприведенное описание на языке XML показывает конфигурацию параметров для операции B11 (см. таблицу B.2).

B.4 Пример согласования конфигураций, получаемый с помощью программы согласования типа 2

Специалист по системной интеграции сравнивает требуемые ему конфигурации параметров (см., например, рисунок B.3) с имеющимися у MSU-модуля конфигурациями (см., например, рисунок B.2), используя для этого процедуру, описанную в разделе 7. Программа сравнения конфигураций типа 2 сравнивает наименования MDD-данных и действия, связанные с каждой субоперацией. Для каждого согласования субоперации программа согласования типа 2 после этого оценивает ее коэффициент совпадений, т.е. процент наименований MDD-данных и действий в требуемой конфигурации параметров, согласованных с наименованиями MDD-данных и действий в конфигурации параметров MSU-модуля.

Рисунок B.6 и таблица B.3 иллюстрируют процедуру оценки, производимую программой согласования конфигураций типа 2. Так, на рисунке B.6 эта программа согласует операцию B61 с операцией A63, каждая из которых имеет наименование "Заказ продукции (фактический)" и наименование действия "Установка" и рассчитывает коэффициент совпадений как 4 из 5 наименований MDD-данных и действий для операции B61 в требуемой конфигурации параметров, т.е. 80% совпадений. После этого программа согласования рассчитывает коэффициент совпадений для всех операций в требуемой конфигурации параметров, которые были согласованы для операции в конфигурации параметров MSU-модуля, и сформирует сообщение-отчет (см. таблицу B.3), а также рассчитает уровень согласования (см. 7.2) для операций в требуемой конфигурации параметров. При этом она заштрихует те ячейки таблицы отчетных данных, для которых был достигнут уровень "полного обязательного согласования". В примере для операции B61 даже при наличии коэффициента совпадений только 80% четыре наименования MDD-данных и действий были связаны с обязательными функциями, поэтому программа согласования конфигураций заштриховала в таблице B.3 ячейку B61-A63.

При анализе специалистом по системной интеграции таблицы B.3 он по заштрихованным ячейкам таблицы сможет заметить, что семь MSU-модулей достигли уровня "полного обязательного согласования" и возможности многократного применения модуля этим специалистом с выполнением всех его требований, например предъявляемых к пакету B MES (см. таблицу B.3).

На рисунке B.7 приведена блок-схема дерева производственных операций для пакета B управления производственными операциями (MES), которое применимо к используемым MSU-модулям (см. таблицу B.3).

Условные обозначения:

- многократно используемый MSU-модуль;

- новый MSU-модуль