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

ГОСТ Р 57323-2016/ISO/TS 15926-11:2015

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

Системы промышленной автоматизации и интеграция

ИНТЕГРАЦИЯ ДАННЫХ ЖИЗНЕННОГО ЦИКЛА ПЕРЕРАБАТЫВАЮЩИХ ПРЕДПРИЯТИЙ, ВКЛЮЧАЯ НЕФТЯНЫЕ И ГАЗОВЫЕ ПРОИЗВОДСТВЕННЫЕ ПРЕДПРИЯТИЯ

Часть 11

Методология упрощенного промышленного использования справочных данных

Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 11. Methodology for simplified industrial usage of reference data

ОКС 25.040.40, 75.020

Дата введения 2017-06-01

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному документу ISO/TS 15926-11:2015* "Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных" (ISO/TS 15926-11:2015 "Industrial automation systems and integration - Integration of life-cycle data for process plants including oil and gas production facilities - Part 11: Methodology for simplified industrial usage of reference data", IDT).

________________

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

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

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

6 ПЕРЕИЗДАНИЕ. Март 2020 г.

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

Введение

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

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

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

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

- Триплеты (тройные взаимосвязи) абсолютно доступны для понимания инженером, чтобы он мог интерпретировать модель продукции. Это было доказано Судостроительной группой NL Ship Building Group, которая разработала на основе языков Gellish/RDF практическую реализацию стандартизированного обмена данными о продукции для оборудования фирмы HVAC на ежедневной основе.

- Стандартные спецификации API, NORSOK и т.п., используемые в промышленности для насосов, компрессоров и другого оборудования, поддерживаются моделью продукции на основе Gellish/RDF, позволяющей промышленным предприятиям как работать с их конкретными спецификациями, так и обмениваться данными стандартизированным образом в соответствии с настоящим стандартом. Это подтверждено Компрессорной группой ICAAMC (International Compressed Air & Allied Machinery Committee) в рамках пилотного проекта по разработке спецификаций API 617.

- Данный подход использовался в нескольких проектах, например в проекте Pearl для нефтегазовой промышленности.

- Настоящий стандарт может использоваться совместно с методологией шаблонов, используемой в ИСО/ТС 15926-7 и ИСО/ТС 15926-8, например в проекте IIР компании FIATECH. Это поможет инженерам легче понимать содержание подобных проектов.

- Генеральный подрядчик (ЕРС - контрактор) использовал проект настоящего стандарта в различных туннельных проектах для решения задач информационного моделирования при системном проектировании объектов, которые требовались для голландских органов власти. Благодаря применению настоящего стандарта совместно с ИСО/МЭК 15288 выполнение этой задачи стало взоможным. Также была построена система измерения/оценки эксплуатационных характеристик туннельных установок, где методология настоящего стандарта использовалась с целью подтверждения полученных результатов для Министерства транспорта Нидерландов (в качестве доказательной базы).

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

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

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

Настоящий стандарт содержит положения, касающиеся:

- деятельности обрабатывающих предприятий в соответствии с ИСО 15926-1;

- использования RDF-триплетов, представляющих собой утверждения (выражения) в соответствии с ИСО 15926;

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

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

- примеров возможных вариантов использования.

Область применения настоящего стандарта не распространяется на:

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

- синтаксические структуры и формат реализации моделей данных о продукции и/или экземпляров данных;

- какие-либо методы и руководства, кроме именованных RDF-графов, для реализации в соответствии с ИСО 15926-2.

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

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

ISO/TS 15926-4, Industrial automation systems and integration - Integration of lifecycle data for process plants including oil and gas production facilities - Part 4: Initial reference data (Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 4. Исходные справочные данные)

3 Термины, определения и сокращения

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

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

3.1.1 класс (class): Категория или разделение объектов на основе одного или более критериев для включения или исключения.

Примечание - Класс не обязательно включает какие-либо известные члены (объекты, соответствующие критерию членства).

[ИСО 15926-1:2004, определение 3.1.1]

3.1.2 данные характеристик (characteristic data): Описание объекта в соответствии с описанием класса, к которому он относится, и совокупность значений свойств этого объекта.

Примечание - В модели данных стандартов ИСО 13584, ИСО 15926, ИСО 22745, ИСО 13399 и ИСО/ТС 29002 включены данные характеристик. В некоторых случаях используется термин "характеристические данные".

[ИСО 8000-2:2012, определение 7.2]

3.1.3 данные (data): Предоставление информации в формальном виде, пригодном для передачи, интерпретации или обработки людьми или компьютерами.

[ИСО 10303-1:1994, определение 3.2.14]

3.1.4 формальный синтаксис (formal syntax): Спецификация правильных предложений формального языка с применением формальной грамматики.

Примечание - Формальный язык - это машинно-интерпретируемый язык.

Пример 1 - Определение типа документа (DTD) по системе XML - это пример формального синтаксиса.

Пример 2 - ИСО 10303-21 включает в себя формальный синтаксис по форме WSN, который применяется во всех физических файлах этого документа.

[ИСО 8000-2:2012, определение 6.1]

3.1.5 информация (information): Факты, понятия или инструкции.

[ИСО 10303-1:1994, определение 3.2.20]

3.1.6 именованный граф (Named Graph): Основная концепция архитектуры семантической паутины (Semantic Web), в которой набор утверждений (граф) среды описания ресурса (триплетов RDF) идентифицирован с помощью уникального унифицированного идентификатора ресурса (URI).

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

[W3C Рекомендация от 25 февраля 2014 г.]

3.1.7 утверждения в формате N-Quad, формат N-Quad (N-Quad statement, N-Quad): Последовательность RDF терминов, состоящих из субъекта, предиката, объекта и идентификатора RDF-графа-триплета; граф является частью набора данных.

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

Пример - <//one.example/subject1> <//one.example/predicate1> <//one.example/object1> <//one.example/graph3> . # комментарии здесь.

[W3C Рекомендация от 25 февраля 2014 г.]

3.1.8 RDF-граф (RDF graph): Графическая структура, сформированная набором триплетов RDF.

[W3C Рекомендация от 25 февраля 2014 г.]

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

[ИСО 15926-1:2004, определение 3.1.18]

3.1.10 библиотека справочных данных (reference data library; RDL): Управляемый фонд справочных данных.

[ИСО 15926-1:2004, определение 3.1.19]

3.1.11 взаимосвязь (relationship): Абстрактный объект, который характеризует отношения между сущностями или объектами реального мира.

[ИСО 15926-2:2003, определение 4.6.4]

3.1.12 семантическое кодирование (semantic encoding): Техника замены в сообщениях терминов естественного языка на идентификаторы, которые имеют ссылку на информационные данные словаря.

[ИСО 8000-2:2012, определение 6.2]

3.1.13 утверждение, факт (statement, fact): Информация, рассматриваемая как неделимая и не подвергающаяся оспариванию.

Примечание - Утверждение может быть зарегистрировано как экземпляр сущности relationship (отношение) согласно ИСО 15926-2. Множество, состоящее из одного или нескольких утверждений, может быть зарегистрировано в сокращенной форме как один элемент (реализация шаблона) согласно ИСО/ТС 15926-7.

[ИСО/ТС 15926-6:2013, определение 3.1.25]

3.1.14 элемент (объект) реального мира (thing): Фактическая часть реального мира, воспринимаемая часть реального мира или предмет рассмотрения.

Примечание 1 - Объект может быть материальным или нематериальным объектом, идеей или действием.

Примечание 2 - Данное определение заимствовано из ИСО 15926-2, где "вещь" - это сущность, но термин не определен.

[ИСО/ТС 15926-6:2013, определение 3.1.26]

3.1.15 триплет (triple): RDF-триплет представляет взаимосвязи между объектами или данными, которые он связывает.

Примечание - Триплет включает в себя как минимум:

- объект, называемый "субъектом";

- предикат (также называемый свойством), который обозначает взаимосвязь между субъектом и объектом;

- объект или данные, называемые "объектом".

[Рекомендация от 25 февраля 2014 г.]

3.1.16 продукт (product): Объект или вещество, полученные естественным или искусственным путем.

[ИСО 10303-1:1994, определение 3.2.26]

3.1.17 данные о продукте (product data): Представление информации об изделии в формальном виде, пригодном для ее передачи, интерпретации или обработки людьми или компьютерами.

[ИСО 10303-1:1994, определение 3.2.27]

3.2 Сокращения

4 Фундаментальные концепции и допущения

4.1 Цели и задачи

Настоящий стандарт определяет методологию семантического моделирования технических данных, которая может относительно "легко" восприниматься инженерами и является универсальной в части адаптации методологии для конкретного домена или проекта. Представленная методология моделирования основана на ИСО 15926-2 и ИСО/ТС 15926-4. Соответствующих результатов удалось достичь благодаря тому, что концепция триплетов RDF-стандарта Консорциума всемирной паутины (W3C), дополненная концепцией именованного графа W3C, была принята и расширена набором взаимосвязей, в дальнейшем называемых "исходным набором взаимосвязей".

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

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

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

4.2 Позиционирование настоящего стандарта

На рисунке 1 приведены слои (уровни), которые можно отдельно выделить, рассматривая обмен данными предприятия в целом. Самый верхний слой представляет собой роль, которую выполняет конкретная организация или предприятие в рамках информационного обмена. Исходные данные и область применения информации представлены на втором слое. В настоящем стандарте под исходными данными можно рассматривать аспекты качества данных в том виде, как они определены в ИСО 8000-1, в то время как область применения информационного обмена определена в ИСО/МЭК 15288 и является специфичной в контексте обрабатывающей промышленности.

Слой информационного содержимого (контента) характеризует смысловое содержание (значения) объектов, которыми обмениваются, как это определено в рамках RDL-модели в соответствии с ИСО/ТС 15926-4.

Семантический слой относится к области применения настоящего стандарта и представлен методологией именованного RDF-графа.

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

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

В рамках конкретного проекта каждый слой может быть специфицирован посредством конкретного для данного проекта "Справочника по доставке информации" (IDМ).

Рисунок 1 - Позиционирование настоящего стандарта в рамках информационного обмена данными

4.3 Использование утверждений в соответствии с ИСО 15926

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

Форма представления утверждений состоит из "объекта (выполняющего роль 1) -> взаимосвязи -> объекта (выполняющего роль 2)", построенных на основе простейшего грамматического шаблона: субъект -> предикат -> объект. Данный шаблон также называется RDF-триплетом, разработанным Консорциумом W3C (см. рисунок 4).

RDF является языком, используемым для представления моделей данных в виде утверждений в формате триплетов. В связи с тем, что данный подход описывается в "Рекомендациях" W3C, на данный момент уже разработано большое количество наборов инструментов и сервисов. Принцип использования утверждений, описывающих "конкретный мир" (онтологию), может заменить фиксированные модели данных и предоставить расширяемую онтологию со справочными данными с целью определения, настройки и гармонизации систем. С этой целью методология, описанная в настоящем стандарте, использует таксономию взаимосвязей (relationship) и таксономию "объектов реального мира" (thing), чтобы иметь возможность описать мир последовательным и однозначным образом. Это обеспечивается использованием правила, что соответствующие объекты реального мира должны классифицироваться с помощью класса в библиотеке справочных данных.

На рисунке 2 приведен используемый в настоящем стандарте принцип (шаблон) объект - взаимосвязь - объект. Объект на левой стороне (выполняющий роль 1) "airco xyz" классифицируется с помощью объекта на правой стороне (выполняющего роль 2), который является "кондиционером воздуха". Таким же образом "capacity airco xyz" классифицируется как "номинальная охлаждающая способность" кондиционера. Данная информация предназначена для однозначного прочтения и понимания человеком и соответствует информации, которая обычно содержится в перечне технических характеристик. Например, мощность кондиционера "capacity airco xyz" измеряется в кВт и имеет величину, равную 100. Инженеры интегрируют факты, выраженные в текстовых предложениях, со всем, что они уже знают, таким образом, что в дальнейшем инженеры способны будут использовать значение, которое они получили из утверждений, предназначенных для создания новых знаний, и которые могут быть легко переданы коллегам и приведут к конкретным действиям.

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

Рисунок 2 - Представление фрагмента информации о продукции в формате утверждения

Оба объекта в утверждении имеют конкретные роли, относящиеся к значению во взаимосвязи. По этой причине утверждение всегда должно быть читаемым в двух направлениях, слева направо и справа налево. Таким образом, каждая взаимосвязь, определенная в исходном наборе, имеет два имени: "предписанное" имя, считываемое с объекта, выполняющего роль 1, и объекта, выполняющего роль 2, и резервное имя, считываемое с объекта, выполняющего роль 2, на объект, выполняющий роль 1 (airco xyz имеет роль 1 и capacity airco xyz имеет роль 2 в части взаимосвязи). Обратные утверждения для утверждений, приведенных на рисунке 2, представлены на рисунке 3.

Рисунок 3 - Утверждения, приведенные на рисунке 2, представленные в обратном направлении

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

4.4 Требования утверждений

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

Пример - Примером утверждения об утверждении является утверждение о времени, когда некоторое лицо заявило о конкретном утверждении.

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

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

- создатель (автор) утверждения (участник или роль);

- дата и время создания утверждения;

- участник или роль, внесшая изменение в утверждение;

- дата и время изменения утверждения;

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

- модальность утверждения; возможные модальные словосочетания для выражения модуса утверждения: могут использоваться следующие возможные величины (экземпляры) модальности, например "может быть", "должен быть" и "должен иметь", поддерживающие управление требованиями и моделирование знаний о продукции. Значением по умолчанию модуса утверждения будет "является случаем" (is the case);

- назначение утверждения, возможные значения (экземпляры): "запрашиваемый", "предполагаемый", "одобренный". Поддерживающие рабочий поток (workflow) в процессе обмена и при управлении изменениями, особенно для значений характеристик;

- мощность множества элемента (применяется для "объекта, выполняющего роль 2") для утверждений, поддерживающих управление требованиями и моделирование знаний о продукции;

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

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

- определение таких понятий для утверждений, как "начало жизни" (begin of life) и "конец жизни" (end of life), чтобы можно было определить период времени, с какого момента конкретное утверждение действительно.

В 5.4 и 5.5 реализация вышеупомянутых требований приведена в явном виде с помощью примеров.

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

4.5 Представление утверждений в виде RDF-триплетов

Среда описания ресурсов (RDF) является формальным языком Консорциума W3C, который позволяет описывать семантику информации таким же образом, как и механизм утверждений, описанный в 4.3. RDF является универсальным языком; изначально он предполагался для представления информации в веб-среде. Он определяет язык для описания взаимосвязей между ресурсами в виде именованных свойств и величин. Свойства в контексте RDF являются экземплярами класса rdf:Property и описывают взаимосвязь между ресурсами субъекта (левая сторона взаимосвязи, элемент с ролью 1 утверждения) и ресурсами объекта (правая сторона взаимосвязи, элемент с ролью 2 утверждения). При таком использовании свойство является предикатом в контексте RDF.

RDF не предоставляет механизмов описания свойств, а также механизмов описания взаимосвязей между свойствами и другими ресурсами. Данные средства предусмотрены RDF-схемой (языком RDFS), которая содержит набор классов и свойств для модели представления знаний RDF, составляющий основу для описания онтологии с использованием расширенного RDF-словаря для структуры RDF-ресурсов. Эти ресурсы используются для определения характеристик других ресурсов, таких как домены и диапазоны свойств. Описания RDFS-словаря написаны на языке RDF.

Большинство абстрактных моделей RDF сводится к четырем простым правилам:

- утверждение выражается в виде триплета Субъект-Предикат-Объект: аналогично (краткому) предложению на английском языке;

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

- имена представляют собой унифицированные идентификаторы ресурсов (URIs), которые являются глобальными по области охвата и всегда относящимися к одному и тому же элементу в любом документе RDF, в котором они используются;

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

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

Рисунок 4 - Использование принципа RDF-триплетов для представления утверждений

Структура RDF-среды может быть охарактеризована как:

- основанная на простой модели данных;

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

- использующая наращиваемый словарь на основе URI;

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

- позволяющая пользователям создавать утверждения о любом ресурсе.

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

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

- RDF-среда предоставляет модель данных для объектов и связей между ними, а также простую семантику для модели данных;

- RDF-схема предоставляет словарь для описания свойств и классов RDF-объектов с семантикой для обобщения иерархий свойств и классов.

RDF использует принцип связанных данных (linked data). Связанные данные описывают метод публикации структурированных данных таким образом, чтобы они могли быть взаимосвязанными и более эффективными в применении. Данный метод дает возможность интегрировать знания из других словарей в модель продукции путем формальной ссылки на элементы этих словарей, при этом с помощью языка SPARQL (языка запросов для RDF) осуществляется автоматическое считывание данных. Для обозначения сущностей связанные данные используют URIs. Конкретные HTTP URIs используются таким образом, что на эти сущности можно ссылаться и они могут отыскиваться (в том числе с получением значений переменных объекта по указателям) людьми и пользовательскими программами-агентами.

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

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

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

- (/) слэш URI, применяющийся, если необходима ссылка на то, что находится в веб-среде и имеет свой точный адрес;

- обычно под пространством имен понимается контейнер для набора идентификаторов (имен). В пространствах имен имена группируются на основе их функциональности. Пространство имен может быть частью URI;

- абсолютная URI ссылка (абсолютная форма) состоит из трех частей: схемы, конкретной иерархической части схемы и фрагментного идентификатора.

Пример 1 - //standards.iso.org/iso/15926/-4/tech/reference-data#RDL7459 как пример хэш URI для класса из ИСО/ТС 15926-4, который разбит на части таким образом, что первые три части являются пространством имен URI:

Для фрагментарной части именованного графа предпочтительно используется универсальный уникальный идентификатор (см. ИСО/МЭК 11578).

Пример 2 - Пример универсального уникального идентификатора (UUID) в соответствии с ИСО/МЭК 11578: //example.сom/myproject#40bb99c0-1f74-11e2-81c1-0800200c9a66.

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

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

- "www.example.сom/myproject#" для идентификации конкретных сущностей проекта, где пространство имен www.example.сom/myproject#" представлено строкой символов "myproject:";

- "www.example.сom/part2#" для идентификации концепций, взятых из ИСО 15926-2, где пространство имен "www.example.сom/part2#" представлено строкой символов "part2"";

- "www.example.com/part4#" для идентификации концепций, взятых из ИСО/ТС 15926-4, где пространство имен "www.example.сom/part4#" представлено строкой символов "part4";

- "www.example.com/part11#" для идентификации взаимосвязей и типов именованных графов, где пространство имен "www.example.com/part11#" представлено строкой символов "part11";

- "www.example.сom/library#" для сущностей, которые определены в частных библиотеках, где пространство имен "www.example.сom/library#" представлено строкой символов "library:".

Пример 3 - На рисунке 5 показан пример набора графов, который является набором утверждений о спецификации свойства "nominal load weight" (номинальный вес груза) типового пьедестального крана, включая классификацию пьедестального крана. Используется пространство имен "library:". На рисунке 5 представлены следующие утверждения:

- "pedestal crane" (пьедестальный кран) является подклассом класса "crane" (кран);

- класс "crane" (кран) имеет свойство "nominal load weight" (номинальный вес груза);

- свойство "nominal load weight" (номинальный вес груза) является подклассом свойства "weight" (вес);

- свойство "nominal load weight" (номинальный вес груза) имеет верхнюю границу "440";

- свойство "nominal load weight" (номинальный вес груза) измеряется с помощью единицы измерения "tonnes" (тонны).

Рисунок 5 - Пример RDF-спецификации свойства крана

Пример 4 - На рисунке 6 показан пример набора графов, который представляет собой набор утверждений о спецификации свойства "nominal load weight" типового пьедестального крана (пьедестальный кран В710, являющийся индивидуальным объектом) в качестве его инстанцирования. Экземпляры определены на пространстве имен "myproject:", классы определены на пространстве имен "library:". На рисунке 6 представлены следующие утверждения:

- "deck crane В710" (палубный кран В710) является экземпляром "пьедестального крана";

- "deck crane В710" имеет свойство "nominal load weight deck crane B710" "номинальный вес груза палубного крана В710";

- свойство "nominal load weight deck crane B710" является экземпляром свойства "nominal load weight";

- свойство "nominal load weight deck crane B710" измеряется в "tonnes" (тоннах);

- свойству "nominal load weight deck crane B710" присвоено значение "400".

Рисунок 6 - Пример инстанцирования RDF-свойства "номинальный вес", как это определено на рисунке 5

Примечание 2 - Прикладное программное обеспечение поможет проверить, вписывается ли величина "400", используемая на рисунке 6, в заданную верхнюю границу "440", определенную в типовом классе "Pedestal Crane", приведенном на рисунке 5.

4.6 Именованные RDF-графы

Именованные графы являются ключевой концепцией архитектуры Семантической паутины Semantic web, в которой набор RDF (RDF-триплетов) утверждений (граф) идентифицирован с помощью уникального URI. Таким образом, утверждение может выборочно сопровождаться дополнительной информацией. Это необходимо для того, чтобы можно было точно определить характеристики, контекст или метаданные утверждения.

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

Именованные графы являются небольшим расширением абстрактного RDF-синтаксиса. Именованные графы дают возможность рассуждать об RDF-графах с помощью RDF-утверждений (другими словами, позволяют создавать утверждения об утверждениях). Метаданные утверждения, например ресурс, лицо, вносящее изменение, информация об изменении, контекст, могут быть выражены в виде триплетов, принадлежащих утверждению. Эти дополнительные триплеты однозначно принадлежат триплету, который представляет собой утверждение. Поэтому в настоящем стандарте используется W3С-версия именованных RDF-графов. Помещая триплет "main" (главного) утверждения в именованный RDF-граф, любое требуемое количество дополнительных триплетов может указывать на первый триплет, представляющий собой метаданные.

Пример 2 - Конкретное утверждение может определять количество элементов (кардинальное число) объекта, содержащегося в другом конкретном утверждении.

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

Концепция именованных RDF-графов обеспечивает гибкость при моделировании продукции и производственных объектов. Также эта концепция дает возможность представлять любой рабочий процесс или процесс создания продукта в виде графа, что облегчает извлечение требуемых предикатов (эквивалент взаимосвязи). Этот метод применен для процесса ИСО/МЭК 15288 с целью определения утверждений субъекта, предиката и объекта таким образом, что стало возможным внести аспект проектирования систем в среду ИСО 15926.

Пример 4 - На рисунке 7 приведен пример с тремя именованными графами, представляющими собой три утверждения, указанные на рисунке 6. Первый именованный граф указывает на то, что DeckCraneB710 (ПалубныйКранВ710) является экземпляром класса "PedestalCrane" ("ПьедестальныйКран"). Второй именованный граф указывает на то, что экземпляр класса DeckCraneB710 имеет свойство "NominalLoadWeightDeckCraneB710" ("НоминальныйВесГрузаПалубногоКранаВ710") и третий именованный граф указывает на то, что этому свойству присвоено значение, равное "400". Каждый триплет сопровождается метаданными типа "isCreated by" ("Создан, указание на создавшее лицо"), "isCreated at" ("Создан, указание на дату/время") и "isModifiedAt" ("Изменен, указание на дату/время").

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

Рисунок 7 - Применение принципа именованных графов для триплетов, приведенных на рисунке 6

В таблице 1 именованные графы, показанные на рисунке 7, записаны в формате N-Quad W3C.

Таблица 1 - Представление именованных графов в формате N-Quad W3C

4.7 Связь RDF с Библиотекой справочных данных (RDL)

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

- rdf:type;

- rdf:Property;

- rdfs:Class;

- rdfs:subClassOf;

- rdfs:subPropertyOf.

В настоящем стандарте взаимосвязь "is a specialization" (является специализацией) идентична "rdfs:subClassOf", а взаимосвязь "is an instance of" (является экземпляром) идентична "rdf:type".

Для того чтобы можно было использовать ИСО/ТС 15926-4 совместно с настоящим стандартом в контексте RDF-конфигурации, существует класс "thing", определяемый как rdf:type или rdfs:Class. В упрощенном виде, корневой элемент "thing" ИСО 15926-2 можно рассматривать как корневой класс для всех объектных классов настоящего стандарта (см. рисунок 8). Корневые классы настоящего стандарта адаптированы на рисунке 8 подклассам с целью описания информационных моделей в соответствии с разделом 6.

Рисунок 8 демонстрирует, что корневой элемент "thing" является обобщением исходного набора базовых классов, приведенных в настоящем стандарте и взятых из сущностей ИСО 15926-2, которые, в свою очередь, относятся к классам Библиотеки справочных данных ИСО/ТС 15926-4.

Рисунок 8 - Расширение RDF базовыми классами RDL путем мэппинга rdfs:Class в part2:thing

Методология, описанная в настоящем стандарте, позволяет определить закрытые классы (внутренние члены класса) как специализацию классов в Библиотеке справочных данных. Далее эти специализации составляют часть модели продукта, проекта и/или процесса и ссылаются на класс в Библиотеке справочных данных посредством UID конкретного класса в соответствии с ИСО/ТС 15926-4.

Пример - На рисунке 9 показан пример того, как отдельный элемент (экземпляр класса RDL) соотносится с rdfs:Resource.

Рисунок 9 - Пример того, как отдельный элемент "myprojectMyCar", являющийся экземпляром транспортного средства, как это определено в Библиотеке ИСО/ТС 15926-4, соотносится с rdfs:Resource

4.8 Использование RDF с взаимосвязями RDL

Для расширения RDF-среды в рамках настоящего стандарта инкорпорируется библиотека справочных данных взаимосвязей. Корневым элементом Библиотеки справочных данных взаимосвязей является элемент "part11:relationship", который определяется как rdf:type элемента rdf:Property. Все взаимосвязи в рамках исходного набора в настоящем стандарте являются элементами rdfs:subPropertyOf корневого элемента "part11:relationship".

Рисунок 10 - Расширение RDF за счет определенного набора взаимосвязей с корневым элементом "part11:relationship"

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

- взаимосвязи в контексте создания утверждений о данных системного проектирования;

- взаимосвязи с целью создания утверждений об утверждениях (метаданные).

Оба вида взаимосвязей определены в исходном наборе взаимосвязей, как это показано в приложении А.

Пример 1 - "Objective A is threatened by risk В" (Достижение цели А находится под угрозой риска В) является утверждением в контексте системного проектирования.

Пример 2 - "Statement A is created by person В" (Утверждение А создано лицом В) является утверждением об утверждении.

Правила использования:

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

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

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

Примечание - Для корневого элемента "part11:relationship" действует то же самое определение, что и для сущности "relationship" ИСО 15926-2.

5 Методология использования именованных графов

5.1 Логические структурные компоненты методологии

В данном разделе методология семантического моделирования описана на логическом уровне, состоящем из набора правил, позволяющих пользователям последовательным образом объединять RDF-триплеты, именованные RDF-графы, набор взаимосвязей и классы RDL для построения моделей продукции и/или процесса. В рамках данной методологии существует три типа элементов "building constructs" (используемые структурные компоненты), все они представлены конкретным видом именованного графа:

- "individual graph" (отдельный граф), при котором любой новый класс объекта или класс экземпляра будет представлен в модели продукта, проекта и/или процесса. "individual graph" (отдельный граф) является только "местом для заполнения" (placeholder) для конкретного класса или экземпляра и на данном этапе не добавляет семантики классу или экземпляру, а только определяет метку (обозначение) для URI класса объекта или экземпляра класса;

- "relationship class Graph" (граф класса взаимосвязи). Этот вид графа представляет, классифицирует и предписывает взаимосвязь в виде имени и разрешенного домена и диапазона;

- "statement graph" (граф утверждения), который используется для создания конкретного утверждения о другом утверждении или любом объекте, представленном в "individual graph".

Рассмотренные три типа именованных графов дают возможность интеграции библиотеки и экземпляров классов в одну среду именованного RDF-графа. Специализации классов Библиотеки справочных данных на основе ИСО/ТС 15926-4 могут быть также интегрированы в модель продукта, проекта и/или процесса.

Правила объединения:

- каждое утверждение имеет свой собственный тип именованного RDF-графа, как это определено в настоящем стандарте путем назначения одного из трех типов именованных графов;

- используемые взаимосвязи происходят из исходного набора взаимосвязей, представленного в разделе 7. Исходный набор взят из справочных моделей ИСО/МЭК 15288, указанных в разделе 6.2;

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

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

- каждый именованный граф включает как минимум метаданные о своем создателе и дате/времени своего создания.

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

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

- никакие модификации для графов не разрешены, чтобы обеспечить полную прослеживаемость истории (т.е. ничто не будет когда-либо удалено). Конкретный граф, подлежащий модификации, будет заменен новым с взаимосвязью "replaces" (взамен) к URI замещенного графа. Взаимосвязь "replaces" может содержаться в том же именованном графе, что и новый именованный граф, который замещает старый именованный граф, или может быть "is replaced by" (заменен на) взаимосвязь в старом именованном графе, либо может содержаться в отдельном именованном графе посредством взаимосвязи "is replaced by" (заменен на). В зависимости от контекста применения можно выбрать, какой из этих трех механизмов использовать.

Примечание 1 - - Для понятий "создатель", "создан", "изменен" используются термины Дублинского ядра (dc:creator, dc:created и dc:modified).

Примечание 2 - Для понятия "replace relationship" используется термин Дублинского ядра dc:isReplacedBy или dc:replaces.

5.2 Методология именованных графов

На рисунке 11 представлены три типа именованных графов, указанных в 5.1. С этой целью для рассмотренных трех типов именованных графов из сообщества W3C заимствован в виде корневого класса RDF-подкласс rdfg:Graph.

Рисунок 11 - Пример использования трех типов именованных графов, определенных в настоящем стандарте

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

Рисунок 12 - Пример специализации одной взаимосвязи из исходного набора взаимосвязей

5.3 Метаданные именованных графов

С целью позиционирования именованного графа в его контексте необходимо добавить метаданные. Для этого в рамках данной методологии используются нижеуказанные термины из Дублинского ядра (//dublincore.org):

- dc:creator;

- dc:created;

- dc:modified;

- dc:source;

- dc:language;

- dc:description;

- dc:provenance;

- dc:replaces, dc:isReplacedBy.

Для описания метаданных именованного графа используются следующие предикаты из пространства имен RDFS:

- rdfs:label;

- rdfs:domain;

- rdfs:range.

С целью описания метаданных, определяющих контекст именованного графа, не охватываемого Дублинским ядром и/или RDF(S), в исходном наборе взаимосвязей определены следующие дополнительные взаимосвязи:

- part11:hasReverseLabel;

- part11:domainlsRestrictedByClass;

- part11:rangelsRestrictedByClass;

- part11:hasModality;

- part11:haslntention;

- part11:hasCertainty;

- part11:hasCardinality;

- part11:hasMinCardinality;

- part11:hasMaxCardinality;

- part11:hasAsBeginOfLife;

- part11:hasAsEndOfLife;

- part11:isModifiedBy;

- part11:concernsStage.

5.4 Пример использования методологии именованных графов

5.4.1 Представление основных типов именованных графов, используемых в настоящем стандарте

В данном разделе три структурных компонента методологии именованных графов определены посредством конкретного именованного графа для каждого структурного компонента (см. 5.1 и рисунок 13), как это показано на рисунке 13, рисунке 14 и рисунке 15 соответственно. Графики на рисунках 13, 14 и 15 сосредоточены вокруг URI именованного графа.

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

Рисунок 13 - Именованный граф, представляющий класс "part11:lndividualGraph"

Рисунок 14 - Именованный граф, представляющий класс "RelationshipClassGraph"

Рисунок 15 - Именованный RDF-граф, представляющий класс "StatementGraph"

Корневой элемент part11:relationship, являясь корневой взаимосвязью настоящего стандарта (см. рисунок 10), определяется посредством экземпляра part11:RelationshipClassGraph. Каждая взаимосвязь, определенная в Библиотеке справочных данных взаимосвязей, будет являться элементом rdfs:subPropertyOf корневого элемента part11:relationship.

На рисунке 16 данная корневая взаимосвязь представлена посредством именованного графа с URI part11:relationship.

Рисунок 16 - Именованный RDF-граф, представляющий корневой класс "part11:relationship"

5.4.2 Представление конкретных элементов проекта

Набор именованных графов может использоваться для определения конкретных элементов проекта. Далее представлен пример, в котором легковой автомобиль (МуСаr) состоит из двигателя (MyEngine) и символьного операнда, имеющего свойство "Power of the car". Это свойство имеет свои единицы измерения; присвоенное значение свойства будет заменено на новое значение.

МуСаr, MyEngine и "Power of the car" являются экземплярами классов, содержащихся в RDL.

Во-первых, на рисунке 17 место для заполнения значения для MyCar представлено посредством экземпляра отдельного графа с URI myproject:MyCar. В именованном графе метка (обозначение) для экземпляра класса "MyCar" присвоена данному URI. Позднее (см. рисунок 28) экземпляр класса MyCar будет классифицирован как машина в соответствии с ИСО/ТС 15926-4.

Рисунок 17 - Именованный RDF-граф, представляющий место для заполнения для "МуСаr"

На рисунке 18 представлено место для заполнения для экземпляра класса "MyEngine", и позднее, на рисунке 29, он будет классифицирован как "engine" (двигатель) в соответствии с ИСО/ТС 15926-4.

Рисунок 18 - Именованный RDF-граф, представляющий место для заполнения для "MyEngine"

На рисунке 19 представлено место для заполнения для свойства "Power of my car" (мощность моей машины) с URI myproject:PowerOfMyCar, и позднее, на рисунке 33, оно будет классифицировано как "nominal power" (номинальная мощность) в соответствии с ИСО/ТС 15926-4.

Рисунок 19 - Именованный RDF-граф, представляющий место для заполнения для "PowerOfMyCar"

5.4.3 Представление конкретных взаимосвязей проекта

Первым шагом основная версия взаимосвязи "consists of" (состоит из) вводится в проект (в рамках рассматриваемого примера) посредством элемента part11:RelationshipclassGraph с URI part11:consistsOf (см. рисунок 20) и адресным указателем "consists of" (состоит из) и определяется как rdfs:subPropertyOf элемента part11:relationship в соответствии с рисунком 16.

Рисунок 20 - Именованный RDF-граф, представляющий взаимосвязь part11:consistsOf как rdfs:subPropertyOf корневого элемента part11:relationship

Вторым шагом на рисунке 20 введенная основная версия взаимосвязи "consists of" специализируется, в рамках данного примера для взаимосвязи в пространстве имен "myproject" с доменом и диапазоном, оба из которых объявляются как экземпляры RDL класса "physical object" (физический объект). URI присвоено значение myproject:myConsistOf и метка (обозначение) "consist of Physical Object".

Рисунок 21 - Именованный RDF-граф, специализирующий в рамках пространства имен "myproject" (см. рисунок 20) взаимосвязь с меткой (обозначением) "consistsOf" для взаимосвязи с меткой (обозначением) "consistsOfPhysicalObject"

На рисунке 22 взаимосвязь с меткой (обозначением) "has modality" (имеет модальность) из исходного набора представлена URI part11:hasModality и меткой (обозначением) "has modality" как rdfs:subPropertyOf элемента part11:relationship (см. рисунок 16).

Рисунок 22 - Именованный RDF-граф, представляющий взаимосвязь части 11 с меткой (обозначением) "has modality"

На рисунках 23, 24, 25, 26 и 27 нижеуказанные взаимосвязи представлены в пространстве имен "part11" аналогичным образом, что и на рисунке 22 "part11:hasModality": part11:isQuantifiedln, part11:hasMagnitude, part11:hasCertainty, part11:haslntention и part11:hasProperty.

Рисунок 23 - Именованный RDF-граф, представляющий взаимосвязь part11 с меткой (обозначением) "is quantified in"

Рисунок 24 - Именованный RDF-граф, представляющий взаимосвязь part11 с меткой (обозначением) "has magnitude"

Рисунок 25 - Именованный RDF-граф, представляющий взаимосвязь part11 с меткой (обозначением) "has certainty"

Рисунок 26 - Именованный RDF-граф, представляющий взаимосвязь part11 с меткой (обозначением) "has intention"

Рисунок 27 - Именованный RDF-граф, представляющий взаимосвязь part11 с меткой (обозначением) "has property"

5.4.4 Представление конкретных утверждений проекта

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

На рисунке 28 URI myproject:MyCar с меткой (обозначением) "МуСаr" определен как экземпляр класса "part4:MotorVehicle" ИСО/ТС 15926-4.

Рисунок 28 - Именованный RDF-граф, указывающий на то, что "МуСаr" является экземпляром RDL класса "part4:MotorVehicle"

На рисунке 29 утверждение устанавливает, что URI myproject:MyEngine с меткой (обозначением) "My Engine" является экземпляром класса "part4:Engine" ИСО/ТС 15926-4.

Рисунок 29 - Именованный RDF-граф, указывающий на то, что "My Engine" является экземпляром RDL класса "part4:Engine"

На рисунке 30 утверждение создано с помощью URI myproject:MyCarConsistOfMyEngine и указывает на то, что myproject:МуСаr состоит из myproject:MyEngine на основе предиката с URI myproject:myConsistOf.

Рисунок 30 - Именованный RDF-граф, указывающий на то, что "MyCarConsistsOfMyEngine" (моя машина состоит из моего двигателя)

На рисунке 31 утверждение указывает на то, что myproject:MyCar имеет свойство myproject:PowerOfMyCare*, используя взаимосвязь part11:hasProperty.

________________

* Текст документа соответствует оригиналу. - .

Рисунок 31 - Именованный RDF-граф, указывающий на то, что "МуСаr" имеет свойство "PowerOfMyCar"

На рисунке 32 приведено утверждение, которое указывает на то, что для myproject:MyCar требуется свойство (значение модальности, равное "shall have") myproject:PowerOfMyCar.

Рисунок 32 - Именованный RDF-граф, указывающий на то, что утверждению МуСаr следовало бы иметь ("shall have") свойство PowerOfMyCar посредством взаимосвязи part11:hasModality

На рисунке 33 утверждение указывает на то, что myproject:PowerOfMyCar является экземпляром класса номинальной мощности ИСО/ТС 15926-4.

Рисунок 33 - Именованный RDF-граф, указывающий на то, что утверждение со свойством "PowerOfMyCar" классифицируется как номинальная мощность в соответствии с RDL классом "NominalPower"

На рисунке 34 утверждение указывает на то, что myproject:PowerOfMyCar (мощность моей машины) должна измеряться с помощью класса "kW" ИСО/ТС 15926-4.

Рисунок 34 - Именованный RDF-граф указывает на то, что утверждение со свойством myproject:PowerOfMyCar выражено в кВт в соответствии с RDL классом "kW"

На рисунке 35 утверждение указывает на то, что свойство myproject:PowerOfMyCar имеет значение, равное 240.

Рисунок 35 - Именованный RDF-граф указывает на то, что утверждение со свойством PowerOfMyCar имеет значение, равное 240

На рисунке 36 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar (равное "240") является предположением.

Рисунок 36 - Именованный RDF-граф, указывающий на то, что утверждение о значении свойства myproject:PowerOfMyCar, равном "240", является предположением

На рисунке 37 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar является оценочной величиной.

Рисунок 37 - Именованный RDF-граф, указывающий на то, что утверждение со значением свойства PowerOfMyCar является оценочной величиной

На рисунке 38 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar изменено на "250". Посредством dc:provenance это изменение обосновано. Данный именованный граф заменяет именованный граф на рисунке 35.

Рисунок 38 - Именованный RDF-граф, указывающий на то, что утверждение со значением свойства PowerOfMyCar, значение которого изменено на "250", обосновано

На рисунке 39 утверждение указывает на то, что значение, равное "250", свойства myproject:PowerOfMyCar одобрено.

Рисунок 39 - Именованный RDF-граф, указывающий на то, что утверждение со значением свойства PowerOfMyCar одобрено

На рисунке 40 утверждение указывает на то, что значение, равное "250", свойства myproject:PowerOfMyCar является расчетным.

Рисунок 40 - Именованный RDF-граф, указывающий на то, что утверждение со значением свойства PowerOfMyCar содержит расчетное значение

5.5 Пример использования методологии именованных графов при моделировании знаний о продукции

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

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

В данном примере повторно используются взаимосвязи из взаимосвязей пространства имен part11, как это определено в 5.4.

5.5.1 Представление конкретных элементов продукта

На рисунке 41 для продукта "Pump type А" (насос типа А) вводится место заполнения посредством экземпляра конкретного графа.

Рисунок 41 - Именованный RDF-граф, представляющий место заполнения для "PumpType" (тип насоса)

На рисунке 42 место заполнения для детали продукта "Impeller type В" (крыльчатка типа В) представлено посредством экземпляра конкретного графа.

Рисунок 42 - Именованный RDF-граф, представляющий место заполнения для "ImpellerType" (тип крыльчатки)

На рисунке 43 место заполнения для свойства "Nominal power of pump type А" (номинальная мощность насоса типа А) представлено посредством экземпляра конкретного графа.

Рисунок 43 - Именованный RDF-граф, представляющий место заполнения для "PumpTypePower" (мощность насоса типа)

5.5.2 Представление конкретных взаимосвязей проекта

На рисунке 44 взаимосвязь "part11:consistsOf" (см. рисунок 20) специализирована для взаимосвязи с доменом, ограниченным подклассами "physical object" (физический объект) ИСО/ТС 15926-4, и диапазоном, ограниченным подклассами "physical object" (физический объект) ИСО/ТС 15926-4.

Поскольку элементы rdf:domain и rdf:range указывают на экземпляры классов в этом именованном графе, то взаимосвязи part11:domainlsRestrictedByClass и part11:rangelsRestrictedByClass используются для уточнения домена и диапазона, конкретно используемых для указания (под)классов.

Рисунок 44 - Именованный RDF-граф, специализирующий взаимосвязь part11:consistsOf для взаимосвязи myproduct:ConsistsOfByClassOfPhysicalObject

На рисунке 45 взаимосвязь "hasMinCardinality" из исходного набора взаимосвязей введена в модель продукта.

Рисунок 45 - Именованный RDF-граф, определяющий взаимосвязь MinCardinality из исходного набора взаимосвязей

На рисунке 46 взаимосвязь "hasMaxCardinality" из исходного набора взаимосвязей введена в модель продукта.

Рисунок 46 - Именованный RDF-граф, определяющий взаимосвязь hasMaxCardinality из исходного набора взаимосвязей

5.5.3 Представление конкретных утверждений о продукте

На рисунке 47 элемент myproduct:PumpType [с меткой (обозначением) "Pump type А"] определяется как подкласс класса "pump" в соответствии с ИСО/ТС 15926-4.

Рисунок 47 - Именованный RDF-граф, определяющий myproduct:PumpType как подкласс класса "pump" в соответствии с ИСО/ТС 15926-4

На рисунке 48 myproduct:lmpellerType [с меткой (обозначением) "Impeller type В"] определяется как подкласс класса "Impeller" в соответствии с ИСО/ТС 15926-4.

Рисунок 48 - Именованный RDF-граф, определяющий myproduct:lmpellerType как подкласс класса "Impeller" в соответствии с ИСО/ТС 15926-4

На рисунке 49 приведено утверждение, что класс myproduct:pumpType [с меткой (обозначением) "Pump type А"] состоит из класса myProduct:impellerType (с меткой (обозначением) "Impeller type В").

Рисунок 49 - Именованный RDF-граф, указывающий на то, что класс myproduct:PumpType обычно состоит из класса myproduct:lmpellerType

На рисунке 50 приведено утверждение, что утверждение myProduct:ProductTypeConsistsOflmpellerType имеет минимальное кардинальное число, равное двум. Таким образом, экземпляр класса myproduct:pumpType [с меткой (обозначением) "Pump type А"] состоит как минимум из двух экземпляров myProduct:impellerType [с меткой (обозначением) "Impeller type В"].

Рисунок 50 - Именованный RDF-граф, указывающий на то, что экземпляр класса myproduct:PumpType состоит как минимум из двух экземпляров myproduct:lmpellerType"2"

На рисунке 51 приведено утверждение, что утверждение myproduct:ProductTypeConsistsOflmpellеrТуре имеет максимальное кардинальное число, равное четырем. Таким образом, экземпляр класса myproduct:PumpType [с меткой (обозначением) "Pump type А"] состоит как максимум из четырех экземпляров myproduct:lmpellerType [с меткой (обозначением) "Impeller type В"].

Рисунок 51 - Именованный RDF-граф, указывающий на то, что экземпляр класса myproduct:PumpType состоит как максимум из четырех экземпляров myproduct:lmpellerType"4"

На рисунке 52 утверждение указывает на то, что myproduct:PumpTypePower [с меткой (обозначением) "Nominal power of pump type А"] является экземпляром класса номинальной мощности ИСО/ТС 15926-4.

Рисунок 52 - Именованный RDF-граф, классифицирующий myproduct:PumpTypePower как экземпляр класса "NominalPower" в соответствии с определением данного класса в ИСО/ТС 15926-4

На рисунке 53 приведено утверждение, что myproduct:PumpTypePower измеряется в кВт в соответствии с ИСО/ТС 15926-4.

Рисунок 53 - Именованный RDF-граф, указывающий на то, что myproduct:PumpTypePower измеряется в кВт в соответствии с его определением в ИСО/ТС 15926-4

На рисунке 54 приведено утверждение, что измерение myproduct:PumpTypePower, которое приводится в кВт, является произвольным со значением модальности "can be" (может быть), как это определено в пространстве имен "library".

Рисунок 54 - Именованный RDF-граф, указывающий на то, что утверждение myproduct:PumpTypePower2 имеет значение модальности "can be"

На рисунке 55 приведено утверждение, что myproduct:PumpTypePower измеряется в единицах измерения лошадиная сила (hp) в соответствии с ИСО/ТС 15926-4.

Рисунок 55 - Именованный RDF-граф, указывающий на то, что myproduct:PumpTypePower измеряется в лошадиных силах в соответствии с его определением в ИСО/ТС 15926-4

На рисунке 56 приведено утверждение, что измерение в лошадиных силах myproduct:PumpTypePower является произвольным со значением модальности "can be" (может быть), как это определено в пространстве имен "library" по отношению к именованному графу "myproduct:PumpTypePower4".

Рисунок 56 - Именованный RDF-граф, указывающий на то, что утверждение myproduct:PumpTypePower4 имеет значение модальности "can be"

6 Справочные данные

6.1 Происхождение исходного набора взаимосвязей

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

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

С целью получения полного набора взаимосвязей, применимых в контексте системного проектирования, в качестве первоисточника был использован ИСО/МЭК 15288.

Для реализации системы в ИСО/МЭК 15288 определены 25 процессов, начиная от утверждения целей системы и набора высокоуровневых требований (заинтересованные стороны) и завершая ее эксплуатацией и обслуживанием.

Для подготовки исходного набора взаимосвязей, приведенных в настоящем стандарте, с учетом общих описаний процесса жизненного цикла системы, приведенных в ИСО/МЭК 15288, составлен набор информационных моделей. Набор информационных моделей функционирует в качестве справочной онтологии системного проектирования. Поэтому информационные модели могут быть также использованы в качестве справочных моделей при системном проектировании.

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

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

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

Каждый элемент в рамках утверждения (элемент с ролью 1, взаимосвязь и элемент с ролью 2) должен обладать прослеживаемостью для возможности определения этого элемента. По этой причине настоящий стандарт следует использовать совместно с Библиотекой справочных данных ИСО 15926 (RDL, ИСО/ТС 15926-4) или сопоставимой ей. Прослеживаемость для определения может быть достигнута, если каждый раз, когда новый элемент (сущность) вводится в утверждение, проводится классификационное сопоставление между новым введенным элементом и соответствующим классом RDL.

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

Рисунок 57 - Пример корневой структуры (таксономии) терминов в контексте системного проектирования, используемых в информационных моделях в рамках настоящего стандарта

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

6.2 Справочные информационные модели, относящиеся к системному проектированию

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

- модель технологической и физической частей системы (рисунок 58);

- модель структурной декомпозиции физической части системы (рисунок 59);

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

- модель взаимодействия между элементами системы, а также между элементами системы, средой и заинтересованными сторонами (рисунок 61);

- модель режимов отказа и анализа воздействий на систему (рисунок 62);

- модель анализа технических требований системы (рисунок 63);

- модель верификации технических требований системы (рисунок 64);

- информационная модель управления рисками (рисунок 65);

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

- (структурная) модель распределения работ в системе (рисунок 67);

- модель информационного потока между участниками (рисунок 68);

- модель проектных организаций (рисунок 69);

- информационная модель оценки (рисунок 70);

- информационная модель допущений/предположений (рисунок 71);

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

- модель документов и версий документов (рисунок 73).

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

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

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

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

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

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

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

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

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

Рисунок 59 - Информационная модель, представляющая собой структурную декомпозицию физической части системы

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

- функциональный физический объект;

- специфицированный физический объект;

- модель производителя;

- материализованный физический объект.

Функциональный физический объект может быть определен на нескольких абстрактных уровнях, от подсистемы (например, системы мониторинга) до уровня оборудования (например, насоса) или материализованного уровня. На уровне подсистемы функциональный физический объект находится в структурной декомпозиции, учитывая принципы разработки, что ведет к появлению набора новых функциональных физических объектов. На уровне оборудования функциональный физический объект находится в структурной декомпозиции и использует выбранную модель производителя. Фактически модель производителя является выбранным решением для функционального физического объекта, которое будет действовать в течение временной части функционального физического объекта и будет иметь уникальный экземпляр в течение временной части жизненного цикла системы. Используя взаимосвязи "begin of life" (начало жизни) и "end of life" (конец жизни), можно определить существование материализованного физического объекта во времени для более чем одного функционального физического объекта.

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

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

Примечание - В так называемой "hamburger model" (модели гамбургера) (Функциональная Единица - модель Технического Решения) функциональный физический объект и специфицированный физический объект объединены в функциональную единицу. Модель гамбургера описана в Общей эталонной модели программных систем в сфере строительства и архитектуры (General АЕС reference model; GARM), являющейся интеграционной моделью для применения в сферах строительства и архитектуры, которая была определена в ранние годы развития стандарта обмена данными STEP.

Рисунок 60 - Информационная модель, представляющая упрощенное использование свойств и статуса (на основе модели данных, определенных в ИСО 15926-2)

На рисунке 60 представлена информационная модель, относящаяся к свойствам элемента "possible individual" (возможный индивид; возможный индивидуальный объект, см. ИСО 15926-2) системы со специальным подходом для уникальных экземпляров классов (целой жизни индивида в конкретном состоянии). Сколько элемент системы (например, это может быть физический объект, деятельность или событие) существует на уровне класса или уровне спецификации, столько же свойство сопровождается диапазоном свойств, определяемым верхней и нижней границами и единицами измерения, в которых это свойство выражено. Как только элемент системы реализован и будет находиться в конкретном состоянии, реальное свойство будет иметь конкретную величину и будет выражено в конкретных единицах измерения.

Свойство не всегда выражается единицами измерения, оно может также выражаться строковой величиной, будучи индивидуальным объектом. В этом случае свойство может быть квалифицировано конкретным именем, где посредством нумерации несколько строковых величин могут определяться последовательным образом, каждый с заданным именем в виде возможного значения для конкретного свойства, например квалификацию свойства можно назвать IP 44, IP 55 и IP 66 как возможные IP-классы в контексте свойства "Protection Rating" (класс защиты).

Аналогичным образом могут быть определены возможные состояния элемента системы путем определения класса возможных значений статуса. На уровне экземпляра элемента системы состояние индивидуального объекта, а именно конкретный статус, может быть идентифицировано с помощью имени [например, "red" (красный) или "green" (зеленый) в случае использования цвета].

Рисунок 61 - Информационная модель, представляющая взаимодействия между внутренними элементами системы и взаимодействия между элементами системы, средой и/или заинтересованными сторонами

Функциональные физические объекты взаимодействуют со своей средой посредством интерфейса. Интерфейс функционального физического объекта состоит из портов, как это показано на рисунке 61. Существует 4 основных вида портов: материальный порт, энергетический порт, информационный порт и конструкционный (3D) порт. Взаимодействия могут происходить между функциональными физическими объектами, а также между функциональными физическими объектами, средой и/или заинтересованными сторонами.

На основе моделей, представленных на рисунках 59, 60 и 61, производители могут создавать свои собственные модели знаний о продукции, которые могут быть использованы и интегрированы в процесс разработки/проектирования систем.

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

Рисунок 62 - Информационная модель, представляющая режим отказов и анализ воздействий системы путем определения соответствующих элементов и взаимосвязей между этими элементами

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

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

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

Рисунок 63 - Информационная модель, представляющая анализ требований системы путем определения соответствующих сущностей и взаимосвязей между ними

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

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

Спецификации требований определяются элементом "text fragment" (текстовый фрагмент), который имеет статус в контексте его жизненного цикла, версию и источник, может являться контрактом или другим документом.

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

Сами по себе технические требования имеют статус, который может быть, например назначен элементу системы, ожидать назначения, быть отложенным (не требуется выполнения), если требование больше не является существенным, учтенным "taking count of" или выполненным.

Рисунок 64 - Информационная модель, представляющая процесс верификации технических требований путем определения соответствующих элементов и взаимосвязей

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

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

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

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

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

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

Рисунок 65 - Информационная модель, представляющая информацию о процессе управления рисками путем определения соответствующих элементов и взаимосвязей

Управление рисками требует контроля информации, которая характеризует риск, а также информации о возможности снижения конкретного риска.

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

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

Рисунок 66 - Информационная модель, представляющая процесс управления изменениями контракта системы путем определения соответствующих элементов и взаимосвязей

На рисунке 66 представлен процесс управления изменениями контракта. Центральной сущностью является контрактная поставка (поставляемые по контракту продукты/изделия), которая заявлена заказчиком поставки (например, клиентом) в контракте с контрактором. Контракт заключается между заказчиком и контрактором, где иногда участвует третья сторона (заинтересованная сторона, предпочтительный поставщик и т.п.).

Контрактная поставка должна отвечать одному или более техническому требованию и состоять из поставляемых позиций по пакету (комплексу) работ (см. рисунок 67). Полный набор поставляемых позиций по пакету работ должен соответствовать набору поставляемых по контракту продуктов/изделий.

Для того чтобы можно было разбить работу на этапы, необходимо определить несколько контрольных точек (меток), в рамках которых часть поставляемых по контракту продуктов/изделий будет принята и некоторые из них будут оплачены (по аналогии с календарным планом и актом выполненных работ по этапу). Эти финансовые контрольные точки (вехи) являются конкретными контрольными точками, как это определено на рисунке 67.

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

Рисунок 67 - Информационная модель, представляющая структурную модель распределения работ в системе путем определения соответствующих сущностей и взаимосвязей

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

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

Каждая деятельность в рамках пакета работ будет являться экземпляром деятельности в контексте одного из процессов ИСО/МЭК 15288.

Важным элементом в рамках системного проектирования является решение. В рассмотренных моделях решения представлены элементами "design principles" принципы разработки (см. рисунок 59), "measures" оценки/меры (см. рисунок 70) и "assumptions" допущения (см. рисунок 71); все они по своей сущности содержат аспекты принятия решения и связаны с деятельностями, включенными в пакет работ и, следовательно, связаны с контрольными точками, поэтому основные решения могут быть определены только введением конкретных контрольных точек.

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

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

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

Контракт состоит из одного или более видов деятельности определенного типа. Деятельность по выполнению контракта может инициироваться и осуществляться как организацией, так и конкретным лицом (используются соответствующие роли). Деятельность по выполнению контракта может находиться в одном из следующих типов состояний: требуемая (requested), обещанная (promised), в процессе реализации (delivered) или принятая (accepted). Типы состояний следуют друг за другом в заранее определенном порядке. Изменение состояния деятельности по выполнению контракта может быть инициировано только посредством формального сообщения/передаваемой информации (formal message) как результата этой деятельности.

Сообщение имеет определенный тип, посылается и принимается сущностью с ролью "party", должно иметь некоторый объект реального мира (thing) в виде субъекта и может быть дополнено документом.

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

Рисунок 69 - Информационная модель, представляющая организационные условия и взаимоотношения

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

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

Организация состоит из реальных физических лиц - специалистов (роль - "лицо, сотрудник"; role of a person), рабочих команд и департаментов. Рабочие команды управляются лицами с ролью "сотрудник" и могут состоять из нескольких человек.

Организации и специалисты располагаются в офисе.

Рисунок 70 - Информационная модель, представляющая информационную модель конкретной меры (подкласса деятельности), создаваемую и используемую в других информационных моделях

В рассматриваемой модели под мерой понимается смягчающая риск мера ("risk mitigating measure"), как это представлено на рисунке 65. Мера характеризуется конкретным потоком операций (workflow), предлагается участником (party), который отвечает за управление рисками, и одобряется теми участниками, на которых она оказывает прямое воздействие. Например, мера получает статус "approved" (одобрена), и в дальнейшем назначается конкретный участник, ответственный за ее реализацию.

Для реализации конкретной меры необходимо инициировать выполнение некоторой деятельности из состава пакета работ. Когда мера успешно осуществлена, ее статус изменяется, например на "executed" (выполнена). В этом случае должен появиться документ, который подтверждает осуществление меры.

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

Рисунок 71 - Информационная модель допущения (подкласса информационного объекта), создаваемая и используемая в других информационных моделях

Сущность "assumption" (допущение) представлена на рисунке 67. Допущение можно использовать для формализации, например, проектного решения или интерпретации требования. По аналогии с мерой допущение также характеризуется конкретным потоком операций; допущение предлагается участником (party), осуществляющим деятельность в рамках пакета работ, например проектные работы. Допущение должно одобряться теми участниками, на которых оно оказывает воздействие. В таком случае допущения получают, например, статус "approved" (одобрено), и инициируется деятельность в рамках пакета работ, которая будет иметь допущение в качестве своего результата. Когда допущение успешно проработано, статус деятельности меняется, например, на "executed" (выполнено). В этом случае должен появиться документ, который подтверждает выполнение допущения. В рамках потока операций для пояснения конкретного допущения различными участниками могут быть разработаны утверждения. Допущение может использоваться, например, для прояснения технического требования как результата деятельности по анализу требований (конкретная деятельность в составе пакета работ) или для описания проектов систем человеческой деятельности.

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

Рисунок 72 - Информационная модель, представляющая возможность подключения физического объекта, например посредством магистралей и кабелей

На рисунке 72 представлена информация, касающаяся возможности подключения материализованных физических объектов в качестве частей системы. Данная модель, для указания возможных соединений, может включать в себя такие элементы, как магистрали и кабели (тип соединения). Соединение на обоих концах имеет характерные черты (особенности), называемые "end1" (конец1) и "end2" (конец2). Необходимый для установления соединения материал представлен соединением в виде сборки и состоит из материала и физических объектов, как болты и гайки.

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

Пространственное расположение может быть также соединено и даже перекрывать друг друга, что может быть точно выражено посредством взаимосвязей "is adjacent to" (смежно расположенный с) в соответствии с "has overlap with" (имеет перекрытие с).

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

Рисунок 73 - Информационная модель, представляющая информацию о документе

На рисунке 73 представлена информация, касающаяся документа и версий документа.

Любой элемент типа документа имеет метаданные и взаимосвязи с устойчивыми элементами, такими как автор, источник, а также субъект и тип документа.

В целом документ описывает результаты деятельности в рамках пакета работ, например систему или оборудование (см. рисунок 67).

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

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

7 Исходный набор справочных взаимосвязей

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

Исходный набор взаимосвязей определен на основе моделей справочной информации, указанных в разделе 6 (см. рисунки 58-73). Взаимосвязи соответствуют сущностям (см. ИСО 15926-2) и основаны на принципах, описанных в приложении D.

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

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

Если приложение представляет взаимосвязь в обратном направлении, то для представления взаимосвязи пользователю следует использовать обратное имя взаимосвязи, указанное в колонке 3 приложения А.

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

Добавление новых взаимосвязей подразумевает расширение одной из информационных моделей или введение новой информационной модели в настоящий стандарт.

Электронная таблица, упомянутая в приложении А, имеет структуру, приведенную в таблице 2.

Таблица 2 устанавливает:

- порядок колонок в таблице;

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

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

- формат данных в колонке.

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

Таблица 2 - Колонки электронной таблицы, содержащие исходный набор взаимосвязей

8 Связь настоящего стандарта с другими частями и комплексами стандартов

8.1 Взаимосвязь настоящего стандарта с ИСО 15926-2 и ИСО/ТС 159267-7

Цель использования настоящего стандарта в качестве "упрощающего слоя" ("simplification layer") для ИСО/ТС 15926-7 заключается в повышении возможности использования комплекса стандартов ИСО 15926 практикующими инженерами. В данном случае настоящий стандарт будет являться средством достижения цели ("Stepping Stone") от простой к более детальной семантической точности в контексте шаблонов ИСО/ТС 15926-7.

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

Настоящий стандарт также можно использовать для создания моделей продукции, процессов или требований, используя ИСО/ТС 15926-4, но не ограничиваясь только представленным в настоящем стандарте. Также допускается интеграция с другими библиотеками.

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

Используемые взаимосвязи отображены на сущности ИСО 15926-2 и экземпляры ИСО/ТС 15926-4 и в целом рассматриваются как наиболее быстрый путь в контексте применения моделей данных ИСО 15926-2. Данное отображение (мэппинг) можно использовать для отображения информации в соответствии с настоящим стандартом в шаблоны ИСО/ТС 15926-7 или для создания новых шаблонов ИСО/ТС 15926-7.

Пример - Для иллюстрации взаимосвязи между настоящим стандартом и ИСО 15926-2 и ИСО/ТС 15926-7 приведен следующий пример, в котором полное, соответствующее ИСО 15926-2 представление свойства передатчика (см. рисунок 74), а именно информация о нем, приведено с использованием именованных RDF-графов.

Рисунок 74 - Схема рабочей температуры передатчика по ИСО 15926-2

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

В таблице 3 набор этих утверждений записан в формате N-Quad W3C. Только первое из утверждений сопровождается метаданными "isCreatedBy" и "isCreatedAt".

Таблица 3 - Колонки представления электронной таблицы, содержащие исходный набор взаимосвязей

8.2 Взаимосвязь настоящего стандарта с ИСО 10303-233

ИСО 10303-233 отличается от комплекса международных стандартов ИСО 15926 по следующим аспектам:

- ИСО 10303-233 является STEP-протоколом (стандарт по обмену данными моделей изделий) с ААМ, ARM и AIM, осуществляющим мэппинг с помощью возможностей языка EXPRESS. ИСО 10303-233 направлен на обеспечение интероперабельности, обмен информацией и данными между компьютерами.

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

- Могут возникнуть трудности при использовании ИСО 10303-233 напрямую для приложения, основанного на принципах ИСО 15926. Именно поэтому настоящий стандарт переносит концепции системного проектирования ИСО 10303-233 в среду ИСО 15926 посредством набора взаимосвязей настоящего стандарта, также поддерживаемых ИСО/МЭК 15288.

- Таким образом, можно использовать и другие функциональные возможности ИСО 15926 в приложениях с аспектами системного проектирования и при этом можно сделать куда больше, чем только просто отобразив все на ИСО 10303-233.

Приложение А
(обязательное)

Исходный набор взаимосвязей

Исходный набор взаимосвязей опубликован в виде электронной таблицы в формате Excel, зарегистрированной ТК 184/ПК 4/РГ 3 под именем: n2643_WG3_initial set of relationships_ISO/TS 15926-11_2014-07-07.

Доступен по следующему адресу:

//standards.iso.org/iso/15926/-11/

Это выполнено в соответствии с документом ПК 4 для конвенций URI (ISO ТС 184/SC 4 N 2265, см. библиографию). Для технических спецификаций это означает следующую адресную структуру:

//standards.iso.org/iso/ts/15926/-3/ed-1/tech/reference-data/spreadsheet/

В данном случае словосочетание "reference-data" означает представление стандарта, например в OWL, электронной таблице и т.п.

Представление электронной таблицы для настоящего стандарта содержит набор взаимосвязей, который называется relationship_p11.xlsx.

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

Приложение В
(обязательное)

Возможные синтаксические форматы именованных графов

В.1 Общие положения

Данное приложение содержит примеры возможных синтаксических форматов методологии именованных графов RDF. Далее приведены три примера: формат TriX, формат N-Quads и электронные таблицы. Реализация настоящего стандарта с использованием одного из трех указанных форматов предоставляет гибкий механизм обмена промышленными данными.

В.2 Формат TriX

Триплеты в XML (TriX) являются сериализацией для представления триплетов RDF в XML-формате. Это обеспечивает высоконормализованное единообразное XML-представление RDF-графов. Преимущество TriX состоит в том, что он позволяет использовать общедоступный инструментарий XML, например XSLT, XQuery и т.д. Данный инструментарий обеспечивает доступ и позволяет оценивать структуру графа или тексты документов в формате TriX для проверки синтаксиса. Более полную информацию можно найти на сайте www.w3.org/2004/03/trix/.

Графическое представление утверждения о том, что МуСаr состоит из MyEngine, приведено далее.

<TriX>

<graph>

<uri>myproject:myCarConsistOfMyEngine </uri>

<triple>

<uri>myproject:myCarConsistOfMyEngine</uri>

<uri>dc:creator</uri>

<uri>myproject:JohnDoe</uri >

</triple>

<triple>

<uri>myproject:myCarConsistOfMyEngine</uri>

<uri>dc:created</uri>

<typedLiteral datatype="xsd:dateTime" > 2013-05-5T12:00:00Z < /typedLiteral >

</triple>

<triple>

<uri>myproject:myCarConsistOfMyEngine</uri>

<uri>rdf:type</uri>

<uri>part11:StatementGraph</uri>

</triple>

<triple>

<uri>myproject:MyCar</uri>

<uri>myproject:MyEngine</uri>

</triple>

</graph>

</TriX>

В.3 Формат N-Quads

Формат N-Quads является стандартом W3C, который определяет легкий для парсинга текстовый язык кодирования наборов RDF-данных (см. https://www.w3.org/TR/2013/CR-n-quads-20131105/).

Утверждения в формате N-Quad являются последовательностью RDF-терминов, представляющих собой субъект, предикат, объект и метку (обозначение) RDF-графа-триплета и графа, чьей частью он является в наборе данных. Термины разделяются между собой символом (пробела). Данная последовательность заканчивается символом '.' и новой строкой (произвольно в конце документа). В таблице В.1 тот же пример приведен в формате N-Quad.

Таблица В.1 - Представление именованного графа в формате N-Quad W3C

B.4 Формат "RDF expression table" в виде электронной таблицы

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

Таблица В.2 - Представление именованного графа с помощью электронной таблицы

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

Примеры применения настоящего стандарта

С.1 Пример: использование настоящего стандарта для определения модели знаний о продукции

Группа из международного комитета по сжатому воздуху и смежным областям машиностроения (ICAAMC) разработала модель знаний компрессора. Модель компрессора содержит нормативную ссылку на ИСО/ТС 15926-4, и в частности на rotating_equipment.xls, к разработке которого ICAAMC была привлечена.

На рисунке С.1 представлен снэпшот данных модели знаний компрессора, который использует взаимосвязи, определенные в исходном наборе в приложении А, и информационные модели, указанные в разделе 5.

Рисунок С.1 - Снэпшот модели компрессора группы ICAAMC, представленный в виде сущностей ИСО/ТС 15926-4 и взаимосвязей настоящего стандарта

С.2 Пример: использование настоящего стандарта для уточнения требований

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

Пример традиционного проектного требования:

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

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

Таблица С.1 - Представление неявного требования в явные утверждения

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

На рисунке С.2 приведен пример, где для обмена данными используется BIM-контейнер (например, ZIP-файл). На рисунке С.2 показан BIM-контейнер, состоящий из:

- файла заголовка, основанного на информационной модели транзакций, как показано на рисунке 68, и использующего методологию именованного графа настоящего стандарта;

- файла информационной модели, использующего методологию именованного графа настоящего стандарта;

- файлов документов (например, файлы Word или 3D-модели), которые определены в рамках информационной модели.

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

BIM-часть содержит ссылки на RDL [посредством взаимосвязи "is of type" (является типом)]. Также присутствуют представления, определенные в BIM-части из документов, которые положены в тот же контейнер (отражаются в документальной части).

Рисунок С.2 - Пример структуры и содержания BIM-контейнера на основе настоящего стандарта

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

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

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

Реализация в среде, не основанной на триплетах, требует, как правило, использования структуры базы данных, аналогичной показанной на рисунке С.3. Этот рисунок также относится и к колонкам в формате N-Quad, как это описано в приложении В, при комбинировании функциональности хранилища данных и информационного обмена, оба из которых основаны на именованных RDF-графах.

Рисунок С.3 - Модель базы данных для реализации структуры именованного графа в не основанной на триплетах среде, например на традиционной системе управления реляционными базами данных (RDBMS)

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

Причины представления технических данных с помощью триплетов

Из-за сложности существующих стандартов различные (промышленные) группы начали разрабатывать упрощенную методологию моделирования знания о продукции либо инициировать и организовывать в своих организациях работы по системному проектированию. Для достижения этой цели некоторые организации воспользовались формализованным естественным языком, на основе принципов ИСО 10303-221 и ИСО 15926-2, который стал известен как "Gellish" (см. [18]). Gellish доказал возможность своего практического применения на практике в силу эффективности полученных результатов.

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

Словарь/таксономия/онтология на основе языка Gellish могут быть использованы, помимо прочего, для стандартизации контента существующих систем, например, таких как данные в системах проектирования, ERP-системах и системах снабжения/закупок. Он также позволяет интегрировать данные из различных источников, таких как данные из различных инженерных приложений и приложений электронного бизнеса. Например, он позволяет описывать каталоги продукции независимым от конкретной системы образом или описывать требования к продукции, спецификации оборудования, техническое состояние оборудования, бизнес-процессы и бизнес-транзакции таким образом, чтобы ими можно было обмениваться между различными системами и различными участниками без необходимости преобразования или трансляции данных. Использование данного языка поддерживается на общедоступном и бесплатном веб-сайте по адресу: //sourceforge.net/projects/gellish/.

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

Это оказалось очень полезным на практике, например в части того, что компьютер должен хранить и обрабатывать выражения, а также управлять процессами изменений. Колонки таблицы данных Gellish стандартизованы (см. [18]). Различные подмножества таблицы данных Gellish могут распознаваться. В простейшей версии (являющейся частью полной версии) включены только утверждения.

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

Таблица D.1 - Простейшая форма представления триплетов в RDF

Взаимосвязь между Gellish и именованными RDF-графами приведена на рисунке D.1

Рисунок D.1 - Взаимосвязь между Gellish и RDF

На рисунке D.2 проиллюстрирован факт на языке Gellish.

Рисунок D.2 - Принцип представления факта на языке Gellish

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

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

Таблица ДА.1

Библиография

Электронный текст документа

и сверен по:

, 2020