ГОСТ Р 57136-2016/ISO/TR 18161:2013. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Подход к интеграции приложений с использованием моделирования требований к обмену информацией и профилирования функциональных возможностей программного обеспечения

(утв. и введен в действие Приказом Росстандарта от 10.10.2016 № 1355-ст)

ОКС 25.040.01

Дата введения 1 июня 2017 года

Предисловие

1 ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики „Интерэкомс“ (ООО „НИИ „Интерэкомс“) на основе собственного перевода на русский язык англоязычной версии международного документа, указанного в пункте 4»

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

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

4 Настоящий стандарт идентичен международному документу ISO/TR 18161:2013 «Системы промышленной автоматизации и интеграция. Подход к интеграции приложений с использованием моделирования требований к обмену информацией и профилирования функциональных возможностей программного обеспечения» (ISO/TR 18161:2013 «Automation systems and integration. Applications integration approach using information exchange requirements modelling and software capability profiling», IDT).

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

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

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

Введение

Инициатива разработки комплекса международных стандартов ИСО 16100 принадлежит специалистам из промышленности и экономической сферы, в частности, по причинам:

a) растущей базы зависящих от производителя решений;

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

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

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

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

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

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

В настоящем стандарте приведен пример процесса моделирования насоса с программным управлением (приложение A), подробно описаны шаблоны профилирования единиц производственного программного обеспечения (приложение B) и приведены профили функциональных возможностей прикладных программных модулей (приложение C). Информация, которой обмениваются между единицами производственного программного обеспечения, используемым насосом с программным управлением, основана на методологии ИСО 18435 (приложение D).

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

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

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

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

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

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

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

ISO 18435 2, Industrial automation systems and integration — Diagnostics, capability assessment and maintenance applications integration — Part 2: Descriptions and definitions of application domain matrix elements (Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 2. Описания и определения элементов матрицы домена приложения).

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

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

В настоящем стандарте используются термины, определенные в ИСО 16100-3, ИСО 16100-5, ИСО 18435-2, а также следующие термины с соответствующими определениями:

3.1 элемент матрицы домена приложения; ADME-элемент (application domain matrix element): Элемент матрицы домена приложения, предназначенный для обмена информацией между приложениями.

[ИСО 18435-2:2012, статья 3.2]

3.2 элемент матрицы взаимодействия приложений; элемент матрицы обмена данными между приложениями; AIME-элемент (application interaction matrix element): Элемент в матрице обмена данными между приложениями, предназначенный для обозначения функциональных возможностей существующих ресурсов поддерживать обмен информацией.

[ИСО 18435-2:2012, статья 3.4]

3.3 профиль интероперабельности приложений; AIP-профиль (application interoperability profile): Единственная спецификация, позволяющая сопоставлять группу профилей (конфигураций параметров) — производственных параметров, конфигурации параметров обмена информацией и ресурсами, а также других AIP-профилей, которые являются частями основных спецификаций и которые сами по себе могут считаться профилями.

Примечание — Группа профилей может состоять из профиля (профилей) процесса, профиля (профилей) обмена информацией, профиля (профилей) ресурсов, а иногда — и из AIP-профилей.

[ИСО 18435-2:2012, статья 3.5]

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

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

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

[ИСО 16100-5:2009, статья 3.1]

3.5 структура класса функциональных возможностей; структура класса возможностей; CCS-структура (capability class structure): Иерархия классов функциональных возможностей.

3.6 шаблон для профилирования функциональных возможностей; шаблон функциональных возможностей; шаблон (capability profiling template; capability template; template): Структура профиля функциональных возможностей промышленного программного обеспечения.

Примечание — Данный вид шаблона может быть заполнен частично.

[ИСО 16100-3:2005, статья 3.1.14]

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

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

[ИСО 16100-5:2009, статья 3.5]

4 Сокращения

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

ADID — диаграмма интеграции домена приложения (Application Domain Integration Diagram);

ADME — элемент матрицы домена приложения (Application Domain Matrix Element);

AIF — интеграционная среда приложений (Application Integration Framework);

AIME — элемент матрицы взаимодействия приложений (Application Interaction Matrix Element);

AIP — профиль интероперабельности приложений (Application Interoperability Profile);

CCS — структура класса функциональных возможностей (Capability Class Structure);

IG — руководство по идентификации (Identification Guide);

MDD — данные производственного домена (Manufacturing Domain Data);

MDM — модель производственного домена (Manufacturing Domain Model);

MSU — единица производственного программного обеспечения (Manufacturing Software Unit);

OTD — открытый технический словарь (Open Technical Dictionary);

PID — пропорционально-интегрально-дифференциальное регулирование (ПИД); Пропорционально-интегро-дифференцирующий (ПИД) регулятор (Proportional Integral Derivative);

PLC — программируемый логический контроллер (Programmable Logic Controller);

UML — унифицированный язык моделирования (Unified Modelling Language);

VFD — частотно-регулируемый привод (Variable Frequency Drive);

XML — расширяемый язык разметки (eXtensible Markup Language).

5 Моделирование требований к интероперабельности приложений

5.1 Интеграционная среда приложений ИСО 15745 и ИСО 18435

Интеграционная среда приложений (AIF-среда), в соответствии с ИСО 15745 1, устанавливает основу для интеграции архитектуры системы автоматического управления и контроля в рамках архитектуры производственных приложений.

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

Integrated Manufacturing Application — интегрированное производственное приложение; spans — SPANS-протокол передачи сигналов; Domain from ADID — домен из ADID-диаграммы; Manufacturing Process — производственный процесс; Manufacturing Activity — производственная деятельность; Manufacturing Information Exchange — обмен производственной информацией; Application Interaction Matrix Element — AIME-элемент; Interaction Requirements — требования к взаимодействию; Manufacturing Resource — производственные ресурсы; Manufacturing Software Unit — MSU-модуль; Equipment — оборудование; Other Resource Types — другие виды ресурсов

Рисунок 1 — Модель интеграции приложений

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

Категории для рассматриваемых доменов приложений перечислены в ИСО 18435-1 и представлены в виде диаграммы интеграции доменов приложений (ADID-диаграммы).

5.2 Элементы обмена информацией ИСО 18435

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

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

В ИСО 18435-2 приведены подробные определения AIME- и ADME-структур, их взаимосвязей, а также описаны общие процедуры формирования AIME- и ADME-элементов.

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

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

Integrated Application X — интегрированное приложение X; Integrated Application Y — интегрированное приложение Y; Resources — ресурсы; Process — процесс; Information Exchange — обмен информацией; Activities — работы

Целью ADME-элемента является описание требований к интероперабельности и интеграции, предъявляемых данными приложениями. Общая концепция ADME-элемента состоит в моделировании обмена информацией между приложениями с помощью профиля интероперабельности приложений (AIP-профиля), описанного в ИСО 15745-1. ADME-элемент поддерживает обмен информацией между приложениями, основываясь при этом на идентифицированных в AIME-элементах функциональных возможностях. Полный набор AIME-элементов, определяющих требования к обмену информацией для реализации интероперабельности двух приложений, содержится в ADME-элементе.

5.3 Контекст требований к обмену информацией

Информационный контекст необходимо устанавливать с использованием рассматриваемого домена приложений в соответствии с ИСО 18435-1.

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

Контекст обмена информацией может быть получен из структуры работ и класса функциональных возможностей (CCS-структуры), показанной на рисунке 3. В разделе A.2 приведен пример CCS-структуры для приложения, относящегося к насосу с программным управлением. В соответствии с методологией ИСО 16100 каждый класс функциональных возможностей обладает собственным шаблоном. Примеры шаблонов функциональных возможностей для указанного насоса приведены в приложении B.

Integrated Manufacturing Application — интегрированное производственное приложение; Activity 1 (MSU 1) — рабочая операция 1 (MSU 1); Activity 2 (MSU 2) — рабочая операция 2 (MSU 2); Sub Activity 1 (MSU 11) — субоперация 1 (MSU 11); Sub Activity 2 (MSU 12) — субоперация 2 (MSU 12); Resource 1 (MSU 111) — ресурс 1 (MSU 111); Resource 2 (MSU 112) — ресурс 2 (MSU 112); Capability Class — класс функциональных возможностей; Profile Template = Concrete class for profile — шаблон профиля = конкретный класс для профиля; Profile Template — шаблон профиля; Profile — профиль; Class — класс; Instance — экземпляр класса

Рисунок 3 — Древо работ в приложении

5.4 Содержание требований к обмену информацией

5.4.1 Требования к профилю функциональных возможностей приложения

Информация, которой обмениваются между собой MSU-модули, определяет содержание (контент) для ADME-структуры в соответствии с описанием MDD-данных.

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

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

Capability — функциональные возможности; Actions Performed by methods — работы, выполняемые данными методами; Resources Support the methods to fulfill the action — ресурсы, необходимые для поддержки методов и выполнения работ; Constraints in the methods/actions — ограничения в методах/работах; Information exchanged between the methods/actions — информация, которой обмениваются в рамках методов/работ; Relationship between MDDs or actions — взаимосвязь между MDD-данными или работами; Action — работы (операции); Name — наименование; Method — методы; Status — статус; Device — устройства; Equipment — оборудование; Tools utility — технологическая оснастка; Material — основные материалы; Secondary material — вторичные материалы; Human — персонал; Recipe — наборы команд; Quality requirement — требования к качеству; Input data — входные (исходные) данные; Output data — выходные данные; Standard time — стандартное время; Action time — фактическое время; Start time — время начала; End time — время окончания; Standard cost — стандартные затраты; Action cost — фактические затраты; Predecessor — предшествующие; Successor — последующие; Methods in the action — методы, используемые в работе; Work piece/Substance/Item — заготовки/вещества/компоненты; Instruction/prescription — инструкции/предписания; Order/Control data/product data/Manufacturing data — заказы/контрольная информация/информация о продукции/производственная информация; Action performance report/Progress state/product data/Manufacturing data — отчеты о показателях работы/состояние выполнения заказа/информация о продукции/производственная информация; MDDs — MDD-данные

Рисунок 4 — Частная функциональная модель, представляемая с помощью MDD-данных

Информационные элементы, предназначенные для выполнения функций контроля работы оборудования и устройств, например насоса и частотно-регулируемого электропривода (рисунок A.1), обычно обрабатываются в MSU-модулях (в приведенном примере они не рассматриваются).

5.4.2 MDD-данные, используемые в контенте ADME-элемента

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

5.5 Передача данных при обмене информацией

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

5.6 ADME-элемент приложения насоса с программным управлением

Сегменты контекста, контента и передачи данных, указанные в 5.3, 5.4 и 5.5, формируют ADME-элемент, выражающий требования к обмену информацией и поддерживающий интероперабельность приложений, связанных с управлением и диагностикой состояния насоса с программным управлением (в рамках интегрированного приложения).

6 Подходы к решению вопросов интероперабельности насоса с программным управлением

6.1 Информационная модель насоса с программным управлением

Среда проектирования активов содержит большой объем ресурсов по обработке информации и управлению, например, насосом в некоторых технологических процессах. Комплекс международных стандартов ИСО 15926 позволяет упростить интеграцию информации об активах для поддержания работ в рамках их жизненного цикла и процессов на производственных предприятиях. В ИСО 15926 представлены модели и библиотеки классов, а также шаблоны для представления жизненного цикла информации о технических установках и их компонентах. На рисунке 5 приведена информационная модель насоса, построенная в соответствии с ИСО 15926.

Equipment — оборудование; Rotating Equipment — вращающееся оборудование; Pump — насос; Mechanical Equipment — механическое устройство; Impeller — ротор насоса; Electrical Equipment — электрические компоненты; Induction Motor — индукционный двигатель; VFD — VFD-привод; Instrumentation and Control Equipment — средства КИПиА (контрольно-измерительные приборы и автоматика); PLC — PLC-контроллер; Transmitter — датчик; Property — свойства; Flow Transmitter — датчик расхода; Capacity — расход; Electrical Flow Transmitter — электрический датчик расхода; Scale — единица измерения; gpm — галлон/мин; Pump Object Information Model — объектная информационная модель насоса; Individual Pump — отдельный насос; Pump — насос; It whole of — в целом; Has aspect — имеет аспект; Capacity — производительность; Is quantified as — количественно измеряется как; Has scale — имеет единицы измерений; Discharge rate — расход; Is connected to — соединен с; Electrical Flow Transmitter — электрический датчик расхода; VFD — VFD-привод; Induction Motor — индукционный двигатель

Рисунок 5 — Модель насоса, построенная в соответствии с ИСО 15926

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

6.2 Устранение неоднозначности терминов и определений с помощью открытого технического словаря

Строго определенные методы установления взаимосвязей между терминами и определениями, общими для среды проектирования и производства, в настоящий момент отсутствуют. Многие термины и определения, связанные с активами, которые используют в контекстах проектирования и производства, зачастую бывают неоднозначными или даже несовместимыми, поскольку их интерпретация или смысл зависят от конкретного контекста. Открытый технический словарь (OTD), основанный на комплексе международных стандартов ИСО 22745, позволяет устранять неоднозначность или несовместимость этих терминов и определений. Преимущества комплекса международных стандартов ИСО 8000 (качество данных) могут быть реализованы с помощью ИСО 22745 путем определения требований к информации в сообщениях, содержащих эталонные данные (master data), которыми обмениваются организации; а также специальных требований к синтаксису, семантическому кодированию и переносимости (возможности переноса) данных.

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

В ИСО 22745 также содержатся рекомендации по использованию руководств по идентификации (IG-руководств), которые представляют собой набор правил описания конкретного класса элементов, отвечающих требованиям получателя данных. IG-руководство определяется с помощью XML-схемы. Если все элементы включены в описание, то это IG-руководство облегчает автоматизированный анализ качества данных из-за возможности четкого понимания того, что требуемые данные были получены без их предварительного анализа человеком. Использование IG-руководств для формирования эталонных данных в каталогах продукции может служить примером применения идентификаторов понятий при построении профилей обмена информацией между приложениями (т.е. AIME- и ADME-элементов).

Идентификаторы понятий, используемые в сегментах контекста, контента и передачи данных в AIME- и ADME-элементах, обеспечивают ссылку на зарегистрированные в OTD-словаре понятия, с указанием стандартов, в которых определены объекты обмена информацией. Эти идентификаторы также используют для их занесения в профили функциональных возможностей и шаблоны, необходимые для интеграции приложений.

Примечание 1 — ИСО 29002 определяет принципы увязки идентификаторов понятий из OTD-словаря в соответствии с ИСО 22745 с другими системами идентификаторов понятий. Определения идентификаторов объектов, содержащиеся в МЭК 61987 (перечень свойств устройств, классификации), ИСО 13584 (библиотека деталей) и ИСО 15926, можно выражать в терминах идентификатора понятий согласно ИСО 22745. Использование других идентификаторов понятий и детали установления их соответствия выходят за рамки настоящего стандарта.

Примечание 2 — Для обеспечения большей удобочитаемости идентификаторы понятий в XML-примерах не используются.

6.3 Интеграция приложений с использованием ИСО 18435

В комплексе международных стандартов ИСО 18435 определены условия, при которых, как ожидается, с точки зрения набора профилей интероперабельности будут выполняться приложения и которым они будут удовлетворять. Например, если приложение для диагностики требует потока информации от приложения для управления насосом с целью оценки общего состояния активов, то эти два приложения для обмена конкретной информацией должны иметь совместимые профили. Цель ADME-элемента состоит в описании требований к обмену информацией между приложениями. Для каждого приложения используемые для обмена информацией интерфейсы описывают с использованием AIME-элемента, который детализирует функциональные возможности ресурсов, которые будут отвечать требованиям к обмену информацией и поддерживать интероперабельность двух приложений. Набор AIME-элементов представляет собой профили интерфейсов, поддерживаемые приложениями и соответствующими ресурсами; эти AIME-элементы содержат ADME-элемент.

7 Формирование AIME- и ADME-элементов приложения для насоса с программным управлением

7.1 Общие сведения

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

7.2 AIME-элемент приложения для управления насосом

Приложение для управления насосом состоит из двух отдельных приложений с соответствующими MSU-модулями, одного для пропорционально-интегрально-дифференциального регулирования (PID) и другого — для сбора данных с датчиков. AIME-элементы, полученные при PID-регулировании и сборе данных, формируют один ADME-элемент (который в настоящем стандарте не рассматривается). Сразу же после интеграции двух упомянутых приложений один результирующий AIME-элемент может быть сформирован путем дублирования сегментов контекста и передачи данных, содержащихся в ADME-элементе. Символические наименования в элементах матрицы в AIME- и ADME-элементах заменяются на идентификаторы понятий, уже зарегистрированные в эталонном OTD-словаре. Рисунок 5 иллюстрирует использование идентификаторов понятий в AIME-элементе. В левой части рисунка 6 показан сегмент передачи данных AIME-элемента без идентификаторов понятий, а в правой части этого рисунка то же, но с идентификаторами понятий.

<Conveyance_Section> ... Diagnostics Example <informationType name=«FlowRateRequestType» type=«tFlowRateReq»> Flow Rate Request <informationType name=«FlowRateResponseType» type=«tFlowRateRes»> Flow Rate Response ... <channelType name=«DiagnosticsChannel» type=«ISO15745_ENet_CommNet_Profile» Ethernet/IP ISO15745-2 Profile ...	<Conveyance_Section> ... Diagnostics Example <informationType name=«FlowRateRequestType» type=«0161-1#01-080761#1»> Flow Rate Request <informationType name=«FlowRateResponseType» <type=«0161-1#01-018902#1»> Flow Rate Response ... <channelType name=«DiagnosticsChannel» type=«0161-1#01-1074537#1»> Ethernet/IP ISO15745-2 Profile ...

Рисунок 6 — Идентификаторы понятий в AIME-элементе

В разделе D.2 приведен AIME-элемент для приложения, связанного с управлением насосом.

7.3 AIME-элемент приложения для диагностики состояния насоса

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

В разделе D.3 приведен AIME-элемент приложения для диагностики состояния насоса.

7.4 ADME-элемент интегрированного приложения насоса с программным управлением

Элементы всех сегментов ADME-элемента для интегрированного приложения получают из AIME-элементов, связанных с управлением и диагностикой состояния насоса, а также из информационных элементов, содержащихся в профилях функциональных возможностей соответствующих MSU-модулей. Все остальные символические наименования в ADME-элементах заменяются на идентификаторы понятий, уже зарегистрированные в эталонном OTD-словаре. Эти идентификаторы, используемые в элементах матрицы, следует выбирать из IG-руководства с целью уточнения допустимых сочетаний данных, которые можно анализировать для определения их соответствия требованиям к интероперабельности, предъявляемым к интегрированному приложению для насоса с программным управлением.

В разделе D.4 приведен AIME-элемент интегрированного приложения для насоса с программным управлением.

8 Общие процедуры, необходимые для достижения интеграции приложений

Процедура моделирования интероперабельности приложений заключается в:

a) определении соответствующего домена (доменов) по ADID-диаграмме (ИСО 18435) и идентификации соответствующих приложений для обмена информацией, например, доменов управления и диагностики состояния;

b) профилировании требований к обмену информацией между приложениями, основанному на методологии профилирования (ИСО 15745);

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

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

e) восстановлении или формировании CCS-структуры для требований к приложению. CCS-структуры выражают с помощью идентификаторов понятий, зарегистрированных в OTD-словаре (ИСО 22745);

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

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

h) если требования к интероперабельности приложений предусмотрены ИСО 16100, то профили функциональных возможностей:

1) отвечают требованиям к функциональным возможностям, указанным в ИСО 16100 и вносятся в соответствующие сегменты контекста AIME- и ADME-элементов;

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

3) отвечают требованиям к функциональным возможностям, указанным в ИСО 16100 и вносятся в соответствующие сегменты контента AIME- и ADME-элементов.

i) если требования к интероперабельности приложений предусмотрены ИСО 18435, то ADME-элементы:

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

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

3) пересматривается и соответственно осуществляется обновление ADME- и AIME-элементов.

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

МОДЕЛИРОВАНИЕ ПРИЛОЖЕНИЙ НАСОСА С ПРОГРАММНЫМ УПРАВЛЕНИЕМ

A.1 Приложение для насоса с программным управлением

Информационная модель интегрированной системы управления насосом с программным управлением, представленная в настоящем Приложении, является развитием стандартной модели насоса (согласно ИСО 15926), рисунок 5. Блок-схема системы насоса с программным управлением в качестве примера приведена ниже, на рисунке A.1.

PLC1 Pump control — PLC1-контроллер управления насосом; PLC2 Pump Diagnostics — PLC2-контроллер диагностики состояния насоса; MSU1 (Data Acq.) — MSU1-модуль (сбор данных); MSU2 (Diagnostics) — MSU2-модуль диагностики; MSU3 (Speed/PID) — MSU3-модуль (регулировка скорости/PID); Information Exchange — обмен информацией; Input Module — входной модуль; Comm. Module — модуль связи; Flow Sensor — датчик расхода; Pressure Sensor — датчик давления; Temperature Sensor — датчик температуры; VFD — частотно-регулируемый электропривод; Pump — насос; Motor — двигатель

Рисунок A.1 — Блок-схема системы насоса с программным управлением

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

- сбора данных с датчиков, например, расхода, давления и температуры;

- управления насосом, например, для регулировки скорости его вращения и пропорционально-интегрально-дифференциального регулирования (PID) расхода и давления.

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

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

Далее приведены потоки данных, проходящие через указанное приложение:

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

b) необходимые данные с датчиков посылаются в приложение для диагностики состояния насоса в целях выполнения диагностики;

c) диагностика состояния насоса, например, выявление кавитации, проводится с помощью MSU2-модуля в соответствующем приложении;

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

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

A.2 CCS-структура интегрированного приложения для насоса с программным управлением

В нижеприведенном XML-примере представлена CCS-структура интегрированного приложения для насоса с программным управлением.

<CapabilityClassStructure xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:noName spaceSchemaLocation=«C:\SmartPump1108\SmartPumpCCS.xsd»> <CCS_Creator_Name name=«WG4_WG7» /> <CCS_ID id=«SmartPumpCCS» /> <CCS_Root_Node_ID id=«IntSmartPump» /> <Capability_Class> <Capability_Class_ID id=«IntSmartPump» /> <Parent_Node_ID id=«NONE» /> <Child_Node_ID> <Capability_Class> <Capability_Class_ID id=«SmatPumpControl_PLC1» /> <Parent_Node_ID id=«IntSmartPump» /> <Child_Node_ID> <Capability_Class> <Capability_Class_ID id=«MSU1» /> <Parent_Node_ID id=«SmartPumpControl_PLC1» /> </Capability_Class> </Child_Node_ID> <Child_Node_ID> <Capability_Class> <Capability_Class_ID id=«MSU3» /> <Parent_Node_ID id=«SmartPumpControl_PLC1» /> </Capability_Class> </Child_Node_ID> </Capability_Class> </Child_Node_ID> <Child_Node_ID> <Capability_Class> <Capability_Class_ID id=''SmartPumpDiagnostics_PLC2_MSU2» /> <Parent_Node_ID id=«IntSmartPump» /> </Capability_Class> </Child_Node_ID> </Capability_Class>

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

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

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

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

<xs:schema xmlns:xs=«http://www.w3.org/2 001/XMLSchema»> <xs:element name=«CapabilityProfiling»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«Template»> xs:complexType <xs:attribute fixed=«SmartPumpControl_PLC1_MSU_1» form=«unqualified» name=«id» type=«xs:string» /> <xs:attribute fixed=«SmartPumpDaq» name=«name» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«Type»> xs:complexType <xs:attribute fixed=«MSU_profile» name=«id» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«CapabilityProfile»> xs:complexType xs:sequence <xs:element name=«Pkgtype»> xs:complexType <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType» /> <xs:element name=«Specific» type=«SpecificPartType» /> </xs:sequence> <xs:attribute form=«unqualified» name=«date» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=«CommonPartType»> xs:sequence <xs:element name=«MSU_Capability»>
xs:complexType xs:sequence <xs:element fixed=«SmartPumpDaqMSU1» name=«ID» type=«xs:string» /> xs:sequence </xs:complexType> </xs:element> <xs:sequence maxOccurs=«unbounded»> <xs:element name=«ReferenceCapabilityClassStructure»> xs:complexType <xs:attribute fixed=«SP_MSU1» form=«unqualified» name=«id» type=«xs:string» /> <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> <xs:attribute form=«unqualified» name=«url» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> <xs:element name=«Capability_Class_Name»> xs:complexType <xs:attribute fixed=«SmartPumpDaq» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Reference_Capability_Class_Structure_Name»> xs:complexType <xs:attribute fixed=«SmartPump_Daq» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Version»> xs:complexType <xs:attribute form=«unqualified» name=«major» type=«xs:string» /> <xs:attribute form=«unqualified» name=«minor» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Owner»> xs:complexType xs:sequence
<xs:element minOccurs=«0» name=«Name» type=«xs:string» /> <xs:element minOccurs=«0» name=«Street» type=«xs:string» /> <xs:element minOccurs=«0» name=«City» type=«xs:string» /> <xs:element minOccurs=«0» name=«Zip» type=«xs:string» /> <xs:element minOccurs=«0» name=«State» type=«xs:string» /> <xs:element minOccurs=«0» name=«Country» type=«xs:string» /> <xs:element minOccurs=«0» name=«Comment» type=«xs:string»/> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«ComputingFacilities»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Processor»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«OperatingSystem»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Language»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Memory»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» /> <xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«DiskSpace»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» />
<xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«ReferenceDictionaryName»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfProfileAttributes»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfMethods''> xs:complexType <xs:attribute form=»unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfResources»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfConstraints»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfExtensions»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element>
<xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfLowerLevels»> xs:complexType <xs:attribute form=«unqualified» name=''number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfSubtemplatesAtNextLowerLevel»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«Reference_MDM_Name»> xs:complexType <xs:attribute form=«unqualified» name=«domain_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description_Format»> xs:complexType <xs:attribute form=«unqualified» name=«format_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description»> xs:complexType xs:sequence xs:choice <xs:element name=«Set_Of_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«MDD_Name»> xs:complexType xs:sequence <xs:element name=«MDD_Information_Exchange»> xs:complexType <xs:sequence maxOccurs=«unbounded»>
xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_in»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_out»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_inout»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«MDD_Constraints»> xs:complexType
xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Constraint_name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute name=«property» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«MDD_Resources»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Resource_name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«action» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«List_Of_MDD_Objects»> xs:complexType
<xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«action» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Time_Ordered_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Time_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string»/> <xs:attribute form=«unqualified» name=«action» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
</xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Event_Ordered_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Event_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=''MDD_Name«> xs:complexType <xs:attribute form=»unqualified» name=«name» type=«xs:string»/> <xs:attribute form=«unqualified» name=«action»type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name»type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
</xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Attributes» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Methods» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Resources» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=''List_Of_CC_Constraints» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=''List_Of_CC_Extensions» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Lower_Levels» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Subtemplates» /> </xs:sequence> </xs:complexType> </xs:schema>

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

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

<xs:schema xmlns:xs=«http://www.w3.org/2001/XIVILSchema»> <xs:element name=«CapabilityProfiling»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«Template»> xs:complexType <xs:attribute fixed=«SmartPumpDiag_PLC2_MSU2» form=«unqualified» name=«id» type=«xs:string» /> <xs:attribute fixed=«SmartPumpDiagnose» name=«name» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«Type»> xs:complexType <xs:attribute fixed=«MSU_profile» name=«id» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«CapabilityProfile»> xs:complexType xs:sequence <xs:element name=«Pkgtype»> xs:complexType <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType» /> <xs:element name=«Specific» type=«SpecificPartType» /> </xs:sequence> <xs:attribute form=«unqualified» name=«date» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=''CommonPartType«> xs:sequence <xs:element name=»MSU_Capability«> xs:complexType»
xs:sequence <xs:element fixed=«SmartPumpDiagnoseMSU2» name=«ID» type=«xs:string» /> </xs:sequence> </xs:complexType> </xs:element> <xs:sequence maxOccurs=«unbounded»> <xs:element name=«ReferenceCapabilityClassStructure»> xs:complexType <xs:attribute fixed=«SP_MSU2» form=«unqualified» name=«id» type=«xs:string» /> <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> <xs:attribute form=«unqualified» name=«url» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> <xs:element name=«Capability_Class_Name»> xs:complexType <xs:attribute fixed=«SmartPumpDiagnose» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Reference_Capability_Class_Structure_Name»> xs:complexType <xs:attribute fixed=«SmartPump_Diag» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Version»> xs:complexType <xs:attribute form=«unqualified» name=«major» type=«xs:string» /> <xs:attribute form=«unqualified» name=«minor» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Owner»> xs:complexType xs:sequence <xs:element minOccurs=«0» name=«Name» type=«xs:string» /> <xs:element minOccurs=«0» name=«Street» type=«xs:string» /> <xs:element minOccurs=«0» name=«City» type=«xs:string» />
<xs:element minOccurs=«0» name=«Zip» type=«xs:string» /> <xs:element minOccurs=«0» name=«State» type=«xs:string» /> <xs:element minOccurs=«0» name=«Country» type=«xs:string» /> <xs:element minOccurs=«0» name=«Comment» type=«xs:string» /> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«ComputingFacilities»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Processor»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«OperatingSystem»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Language»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Memory»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» /> <xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«DiskSpace»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» /> <xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element>
</xs:sequence> <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«ReferenceDictionaryName»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfProfileAttributes»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfMethods»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfResources»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfConstraints»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfExtensions»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfLowerLevels»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType>
</xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfSubtemplatesAtNextLowerLevel»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«Reference_MDM_Name»> xs:complexType <xs:attribute form=«unqualified» name=«domain_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description_Format»> xs:complexType <xs:attribute form=«unqualified» name=«format_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description»> xs:complexType xs:sequence xs:choice <xs:element name=«Set_Of_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«MDD_Name»> xs:complexType xs:sequence <xs:element name=«MDD_Information_Exchange»> xs:complexType <xs:sequence maxOccurs=«unbounded»> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_in»>
xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_out»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_inout»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required „/> </xs:complexType> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=“MDD_Constraints»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Constraint_name»>
xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute name=«property» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«MDD_Resources»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Resource_name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute form=«unqualified» name=«name» type=«xs:string»use=«required» /> <xs:attribute form=«unqualified» name=«action» type=«xs:string»use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«List_Of_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string»use=«required» /> <xs:attribute form=«unqualified» name=«action» type=«xs:string»use=«required» />
</xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Time_Ordered_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Time_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string'/> <xs:attribute form=»unqualified» name=«action»type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Event_Ordered_MDD_Objects»> xs:complexType
<xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Event_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string'/> <xs:attribute form=»unqualified» name=«action»type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=''unbounded» name=«List_Of_CC_Attributes» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Methods» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Resources» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Constraints»/> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Extensions» />
<xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Lower_Levels»/> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Subtemplates» /> </xs:sequence> </xs:complexType> </xs:schema>

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

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

<xs:schema xmlns:xs=«http://www.w3.org/2 001/XMLSchema»> <xs:element name=«CapabilityProfiling»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«Template»> xs:complexType <xs:attribute fixed=«SmartPumpControl_PLC1_MSU3» name=«id» type=«xs:string» /> <xs:attribute fixed=«SmartPumpControl» name=«name» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«Type»> xs:complexType <xs:attribute fixed=«MSU_profile» name=«id» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> <xs:element name=«CapabilityProfile»> xs:complexType xs:sequence <xs:element name=«Pkgtype»> xs:complexType <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType» /> <xs:element name=«Specific» type=«SpecificPartType» /> </xs:sequence> <xs:attribute form=«unqualified» name=«date» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=«CommonPartType»> xs:sequence <xs:element name=«MSU_Capability»> xs:complexType
xs:sequence <xs:element fixed=«SmartPmupControlMSU3» name=«ID» type=«xs:string» /> </xs:sequence> </xs:complexType> </xs:element> <xs:sequence maxOccurs=«unbounded»> <xs:element name=«ReferenceCapabilityClassStructure»> xs:complexType <xs:attribute fixed=«SP_MSU3» form=«unqualified» name=«id» type=«xs:string» /> <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> <xs:attribute form=«unqualified» name=«version» type=«xs:string» /> <xs:attribute form=«unqualified» name=«url» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> <xs:element name=«Capability_Class_Name»> xs:complexType <xs:attribute fixed=«SmartPumpControl» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Reference_Capability_Class_Structure_Name»> xs:complexType <xs:attribute fixed=«SmartPump_Control» form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Version»> xs:complexType <xs:attribute form=«unqualified» name=«major» type=«xs:string» /> <xs:attribute form=«unqualified» name=«minor» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«Owner»> xs:complexType xs:sequence <xs:element minOccurs=«0» name=«Name» type=«xs:string» /> <xs:element minOccurs=«0» name=«Street» type=«xs:string» /> <xs:element minOccurs=«0» name=«City» type=«xs:string» />
<xs:element minOccurs=«0» name=«Zip» type=«xs:string» /> <xs:element minOccurs=«0» name=«State» type=«xs:string» /> <xs:element minOccurs=«0» name=«Country» type=«xs:string» /> <xs:element minOccurs=«0» name=«Comment» type=«xs:string» /> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«ComputingFacilities»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Processor»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«OperatingSystem»> xs:complexType <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Language»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Memory»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» /> <xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«DiskSpace»> xs:complexType <xs:attribute form=«unqualified» name=«size» type=«xs:string» /> <xs:attribute form=«unqualified» name=«unit» type=«xs:string» /> </xs:complexType> </xs:element>
</xs:sequence> <xs:attribute form=«unqualified» name=«type» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«ReferenceDictionaryName»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfProfileAttributes»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfMethods»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfResources»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfConstraints»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfExtensions»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfLowerLevels»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» />
</xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«NumberOfSubtemplatesAtNextLowerLevel»> xs:complexType <xs:attribute form=«unqualified» name=«number» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«Reference_MDM_Name»> xs:complexType <xs:attribute form=«unqualified» name=«domain_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description_Format»> xs:complexType <xs:attribute form=«unqualified» name=«format_name» type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Description»> xs:complexType xs:sequence xs:choice <xs:element name=«Set_Of_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=''unbounded«> <xs:element name=»MDD_Name«> xs:complexType xs:sequence <xs:element name=»MDD_Information_Exchange«> xs:complexType <xs:sequence maxOccurs=»unbounded«> xs:sequence <xs:element minOccurs=»0» maxOccurs=«unbounded» name=«information_in»>
xs:complexType <xs:attribute form=«unqualified» name=«name»type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value»type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_out»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«information_inout»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» use=«required» /> <xs:attribute form=«unqualified» name=«value» type=''xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«MDD_Constraints»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Constraint_name»>
xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string'' use=''required» /> <xs:attribute name=«property» type=«xs:string» use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«MDD_Resources»> xs:complexType xs:sequence <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«Resource_name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute form=«unqualified» name=«name» type=«xs:string»use=«required» /> <xs:attribute form=«unqualified» name=«action» type=«xs:string»use=«required» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«List_Of_MDD_Objects''> xs:complexType <xs:sequence minOccurs=»0» maxOccurs=«unbounded»> <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string»use=«required» />
<xs:attribute form=«unqualified» name=«action» type=«xs:string»use=«required» /> xs:complexType </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Time_Ordered_MDD_Objects»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Time_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string»/> <xs:attribute form=«unqualified» name=«action»type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«Event_Ordered_MDD_Objects»> xs:complexType
<xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Event_Occurrence_Of_MDD_Object»> xs:complexType xs:sequence <xs:element name=«MDD_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name» type=«xs:string» /> <xs:attribute form=«unqualified» name=«action»type=«xs:string» /> </xs:complexType> </xs:element> <xs:element name=«MDD_Qualifiers»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Qualifier_Name»> xs:complexType <xs:attribute form=«unqualified» name=«name»type=«xs:string» /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Attributes» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Methods» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Resources» /> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Constraints»/> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Extensions» />
<xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Lower_Levels»/> <xs:element minOccurs=«0» maxOccurs=«unbounded» name=«List_Of_CC_Subtemplates»/> </xs:sequence> </xs:complexType> </xs:schema>

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

ПРОФИЛИ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ПРИКЛАДНЫХ ПРОГРАММНЫХ МОДУЛЕЙ

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

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

<CapabilityProfiling xmlns:xsi=«http://www.w3.org/2 001/XMLSchema-instance» xsi:noNamespaceSchemaLocation= «C:\ISO\SmartPump\SmartPumpDaq.xsd»>