ПНСТ 758-2022. Предварительный национальный стандарт Российской Федерации. Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений. Часть 4. Определение единиц возможностей

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

до 1 января 2026 года

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением «Российский институт стандартизации» (ФГБУ «РСТ») и Некоммерческим партнерством «Русское общество содействия развитию биометрических технологий, систем и коммуникаций» (Некоммерческое партнерство «Русское биометрическое общество»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Кибер-физические системы»

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва, Инновационный центр Сколково, улица Нобеля, д. 1, e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

В серии стандартов «Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений» рассмотрены требования пользователей и поставщиков производственного программного обеспечения к интероперабельности программного обеспечения в области промышленной автоматизации.

Требования пользователей к интероперабельности программного обеспечения включают:

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

Требования поставщиков к интероперабельности программного обеспечения включают:

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

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

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

Возможности программного обеспечения определяются как набор функций и служб с набором критериев для оценки эксплуатационных характеристик. Возможности характеризуют, как и что может делать программное обеспечение. Серия стандартов ГОСТ Р ИСО 16100 определяет метод описания возможностей производственного программного обеспечения с использованием профиля возможностей модуля производственного программного обеспечения (MSU). В соответствии с серией стандартов ГОСТ Р ИСО 16100 компонент программного обеспечения включен в MSU. Серия стандартов ГОСТ Р ИСО 16100 также предоставляет способ обмена возможностями MSU в качестве информации посредством профиля возможностей. Профилирование возможностей программного обеспечения является основой для обеспечения служб интероперабельности программного обеспечения. Серия стандартов ГОСТ Р ИСО 16100 является основополагающей для серии стандартов ПНСТ «Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений».

ПНСТ 434-2020 определяет структуру для описания решения автоматизации в виде возможностей, обеспечиваемых набором MSU. Структура определяет набор элементов возможностей и правил компоновки для представления критериев интероперабельности согласно требованиям к возможностям прикладной системы автоматизации предприятия.

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

ПНСТ 436-2020 определяет схему верификации интероперабельности модулей производственных возможностей на предмет соответствия требованиям приложения и системного решения.

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

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

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

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

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

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

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

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

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

ПНСТ 434-2020 (ИСО 16300-1:2018) Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений. Часть 1. Критерии интероперабельности единиц возможностей согласно требованиям к применению

ПНСТ 435-2020 (ИСО 16300-2:2019) Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений. Часть 2. Шаблоны возможностей и каталогизация программных блоков

ПНСТ 436-2020 (ИСО 16300-3:2017) Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений. Часть 3. Верификация и валидация интероперабельности единиц возможностей

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

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

В настоящем стандарте применены термины по ГОСТ Р ИСО 16100-1, ГОСТ Р ИСО 16100-6, ПНСТ 434-2020, ПНСТ 435-2020, ПНСТ 436-2020, а также следующие термины с соответствующими определениями:

3.1 соответствующий профиль возможностей MSU (matched MSU capability profile): Профиль возможностей MSU, который выполняет возможности, определенные в требуемом профиле возможностей.

3.2 пользователь MSU (MSU user): Сущность, которая использует модули производственного программного обеспечения, зарегистрированные в каталоге модулей программного обеспечения.

4 Сокращения

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

CSS — структура класса возможности (Capability Class Structure);

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

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

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

5 Обзор оценки модулей возможностей

5.1 Каталог модулей программного обеспечения

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

На рисунке 1 представлен каталог модулей программного обеспечения в соответствии с ПНСТ 435-2020. Для перевода семантики шаблона возможностей и профилей возможностей каталог модулей программного обеспечения ссылается на словарь описания возможностей программного обеспечения. Каждый MSU имеет один профиль возможностей, который принадлежит одному шаблону возможностей в каталоге модулей программного обеспечения. Пример шаблона возможностей представлен в приложении А.

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

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

• профили возможностей должны быть определены в соответствии с ГОСТ Р ИСО 16100-3 и ГОСТ Р ИСО 16100-5;
• профили возможностей должны использовать зарегистрированные шаблоны возможностей в репозитории шаблонов возможностей;

- шаблоны возможностей должны быть определены в соответствии с ПНСТ 435-2020.

5.2 Общая процедура оценки модулей возможностей

Перед проведением оценки:

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

б) требование должно быть разложено на набор деятельностей.

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

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

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

в) процедура оценки интерфейса. Данная процедура обеспечивает сопоставление интерфейса требуемого профиля возможностей с профилями возможностей MSU в каталоге модулей программного обеспечения;

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

После оценки всех требований приложения выводятся отчеты об оценках.

Оценка модуля возможностей должна соответствовать структуре интероперабельности программного обеспечения по следующим аспектам (см. ПНСТ 436-2020, пункт 5.2):

• синтаксис и семантика между MSU;
• функциональные взаимоотношения между МСУ;
• службы, интерфейсы и протоколы, предоставляемые MSU;
• возможность обеспечить профилирование возможностей MSU.

6 Процедура поиска каталога модулей программного обеспечения

Процедура поиска каталога модулей программного обеспечения представлена на рисунке 3.

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

а) выбор одной деятельности из набора декомпозированных деятельностей. На основе выбранной деятельности проводится выбор CCS и класса возможностей, которые поддерживают данную деятельность;

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

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

7 Процедура оценки функциональности

В процедуре оценки функциональности проводится сопоставление элементов возможностей в требуемом профиле возможностей с элементами возможностей в профилях возможностей MSU. На рисунке 4 представлена процедура оценки функциональности.

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

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

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

в) проверяется, все ли обязательные элементы возможностей требуемого и выбранного профилей совпадают:

1. если да, то необходимо перейти на этап г);

2. если нет, то необходимо установить для результата сопоставления значение «нет совпадения» и перейти к процедуре отчета об оценке (этап б));

г) необязательные элементы возможностей требуемого профиля возможностей сопоставляются с элементами возможностей выбранного профиля возможностей MSU;

д) проверяется, все ли необязательные элементы возможностей требуемого и выбранного профилей совпадают:

1. если да, то необходимо установить для результата сопоставления значение «полное совпадение» и перейти на этап е);

2. если нет, то необходимо установить результат сопоставления на «совпадение обязательных элементов» и перейти на этап е);

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

1. если да, то необходимо перейти к процедуре оценки интерфейса (см. раздел 8);

2. если нет, то необходимо перейти к этапу б).

8 Процедура оценки интерфейса

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

• протокол связи;
• метод обмена данными;
• способ обмена данными;
• способ вызова службы.

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

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

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

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

в) проверяется, все ли профили возможностей MSU прошли оценку интерфейса:

1. если да, то необходимо перейти к процедуре формирования отчетов об оценке (см. раздел 9);

2. если нет, то необходимо перейти к этапу а).

9 Процедура формирования отчета об оценках

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

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

полное совпадение/совпадение обязательных требований/нет совпадения; - результат оценки интерфейса: - протокол связи: - значение (пример: OPC-UA); - результат сопоставления: совпадение/нет совпадения; - совместное использование данных: - значение (пример: СУБД); - результат сопоставления: совпадение/нет совпадения; - обмен данными: - значение (пример: MTConnect); - результат сопоставления: совпадение/нет совпадения; - вызов службы: - значение (пример: REST); - результат сопоставления: совпадение/нет совпадения.

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

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

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

б) описание результатов оценки функциональности профиля возможностей MSU;

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

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

1. если да, то необходимо перейти к следующей процедуре;

(справочное)

Провайдер MSU и пользователь MSU используют шаблоны возможностей, которые описываются схемами XML. Пример шаблона возможности следующий. xml version=«1.0» encoding=«UTF-8»?> <xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema»> <xs:element name=«CapabilityProfiling»> xs:complexType <xs:sequence maxOccurs=«unbounded»> <xs:element name=«Type»> xs:complexType <xs:attribute 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 name=«version» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Common» type=«CommonPartType»/> <xs:element name=«Specific» type=«SpecificPartType»/> </xs:sequence> <xs:attribute name=«date» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name=«CommonPartType»> xs:sequence xs:choice <xs:element name=«Requirement»> xs:complexType xs:sequence <xs:element name=«ID» type=«xs:string»/> </xs:sequence> <xs:attribute name=«id» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«MSU_Capability»> xs:complexType xs:sequence <xs:element name=«ID» type=«xs:string»/> </xs:sequence> <xs:attribute name=«id» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:choice> <xs:sequence maxOccurs=«unbounded»> <xs:element name=«ReferenceCapabilityClassStructure»> xs:complexType <xs:attribute name=«id» type=«xs:string» form=«unqualified»/> <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> <xs:attribute name=«version» type=«xs:string» form=«unqualified»/> <xs:attribute name=«url» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«TemplateID»> xs:complexType <xs:attribute name=«id» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> <xs:element name=«Capability_Class_Name»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Reference_Capability_Class_Structure_Name»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Version»> xs:complexType <xs:attribute name=«major» type=«xs:string» form=«unqualified»/> <xs:attribute name=«minor» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Owner»> xs:complexType xs:sequence <xs:element name=«Name» type=«xs:string» minOccurs=«0»/> <xs:element name=«Street» type=«xs:string» minOccurs=«0»/> <xs:element name=«City» type=«xs:string» minOccurs=«0»/> <xs:element name=«Zip» type=«xs:string» minOccurs=«0»/> <xs:element name=«State» type=«xs:string» minOccurs=«0»/> <xs:element name=«Country» type=«xs:string» minOccurs=«0»/> <xs:element name=«Comment» type=«xs:string» minOccurs=«0»/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«ComputingFacilities» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType xs:sequence <xs:element name=«Processor» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«type» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«OperatingSystem» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«type» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Language» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Memory» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«size» type=«xs:string» form=«unqualified»/> <xs:attribute name=«unit» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«DiskSpace» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«size» type=«xs:string» form=«unqualified»/> <xs:attribute name=«unit» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=«type» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Performance» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«elapsedTime» type «xs:string» form=«unqualified»/> <xs:attribute name=«transactionsPerUnitTime» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«ReliabilityData» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType xs:sequence <xs:element name=«UsageHistory» type=«xs:string» minOccurs=«0»/> <xs:element name=«Shipments» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«IntendedSafetyIntegrity» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«level» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«Certification» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«SupportPolicy» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«index» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«PriceData» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«invest» type=«xs:string» form=«unqualified»/> <xs:attribute name=«annualSupport» type=«xs:string» form=«unqualified»/> <xs:attribute name=«unit» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«ReferenceDictionaryName»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfProfileAttributes» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfMethods» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfResources» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfConstraints» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfExtensions» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfLowerLevels» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«NumberOfSubtemplatesAtNextLowerLevel» minOccurs=«0» maxOccurs=«unbounded»> xs:complexType <xs:attribute name=«number» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«SpecificPartType»> xs:sequence <xs:element name=«AssessmentIndicatorDescriptionFormat»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> <xs:element name=«ListOfFunctionalCapabilityElements»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Parameter»> xs:complexType <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> <xs:attribute name=«mandatoryLevel» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«ListOfInterfaceCapabilityElements»> xs:complexType xs:sequence <xs:element name=«CommunicationProtocol»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«Protocol»> xs:complexType <xs:attribute name=«usage» type=«xs:string» form=«unqualified» use=«optional»/> <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element» <xs:element name=«DataSharing»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«DataSharing»> xs:complexType <xs:attribute name=«usage» type=«xs:string» form=«unqualified» use=«optional»/> <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«DataExchange»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«DataExchange»> xs:complexType <xs:attribute name=«usage» type=«xs:string» form=«unqualified» use=«optional»/> <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«ServiceCalling»> xs:complexType <xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«ServiceCalling»> xs:complexType <xs:attribute name=«usage» type=«xs:string» form=«unqualified» use=«optional»/> <xs:attribute name=«name» type=«xs:string» form=«unqualified»/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=«List_Of_CC_Attributes» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«List_Of_CC_Methods» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«List_Of_CC_Resources» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«List_Of_CC_Extensions» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«List_Of_CC_Lower_Levels» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«List_Of_CC_Subtemplates» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> </xs:schema>

(справочное)

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

 <ListOfFunctionalCapabilityElements>
 <Parameter  name="drilling" mandatoryLevel="Mandatory"/>

(справочное)

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

REQ17-0001 SUC1-0001 MSU-000 Any comments